perhaps this is one of the not-so-obvious benefits of running a web
proxy cache such as squid. the greater internet can have larger
packets floating around, and the local proxy of the ISP can deal with
horrible tcp stacks, retransmissions and client machine with small
receive buffer sizes.
what we did in our transparent web cache was to always try to use persistence
when talking to origin servers, fix everything we could fix in our TCP stack,
and use a quota so that we would only talk to the same origin server N times
in parallel. this means when clients disconnect from what they think of as
the origin server after 15 seconds of inactivity, and then (happens a lot!)
reconnect and grab something else, their requests are interleaved on one of
our persistent connections to the origin server. this also means that if too
many clients try (doesn't happen often) to use our quota of connections to an
origin server, some of them have to wait for a slot on one of our persistent
connections. we will ultimately time out or LRU our origin connections but
while we have them open, TCP's window size and RTT estimates are more accurate
than when a bazillion new connections keep coming up and doing slow start and
the fratricide thing someone else mentioned earlier today.
this hurts our benchmark numbers but helps the backbones (where i came from)
and the origin servers (where some of my friends are). quite the dilemma.
Paul A Vixie <paul@vix.com> writes:
the fratricide thing someone else mentioned earlier today.
That would be Frank Kastenholz, who I am pleased to
discover slumming here.
this hurts our benchmark numbers but helps the backbones (where i came from)
and the origin servers (where some of my friends are). quite the dilemma.
Frankly, the backbones could care less these days.
Heavily decorated micropackets are becoming less and less
toxic; at least one implementation is known to smile and
ask for more at OC12 rates, another has hardware that can
probably do this too. Magic flow-based switching
schemes that open VCs and so forth might be happier, but I
don't know of any actually deployed in a "backbone" per se.
Tli was just pointing out n messages ago that no matter
how well you do in terms of aggregating data traffic into
bigger chunks, you still will see an enormous number of
small packets around (ACKs). You have to be prepared to
switch those at line rate; engineering for some
statistical mix of big and small packets is asking for a
disaster when someone suddenly goes simplex.
There is, however, the spectre of there being so many SYNs
flying around that they alone might cause congestion
collapse. I dunno if I should be frightened of that or
not, but I am not one of your origin server friends. --
Finally, could your explain the "benchmark" comment a bit?
Sean.
Tli was just pointing out n messages ago that no matter
how well you do in terms of aggregating data traffic into
bigger chunks, you still will see an enormous number of
small packets around (ACKs). You have to be prepared to
switch those at line rate; engineering for some
statistical mix of big and small packets is asking for a
disaster when someone suddenly goes simplex.
some of the histograms i've seen show close to 50%
of the packets being 40 bytes long. the 'desired'
tcp behavior is to have no more than 2 data packets
for every ack (since congestion control uses ack-reception
to pace the transmission of data and try to
quickly detect losses).
There is, however, the spectre of there being so many SYNs
flying around that they alone might cause congestion
collapse. I dunno if I should be frightened of that or
not
you should be.
not because of the packet-load it causes (as tony pointed out,
you have to be able to move 40-byte packets at 'fiber speed')
but because it's a symptom of lots of short-lived tcp connections.
these connections never get out of slowstart. when there is only
a small number of them, it's not important. when there is a large
number of them, you have large, non-congestion-controlled, data flows.
it's called being nibbled to death by mice.