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. --
i'm not worried about the syn's so much as i am worried about the lack of
interstream resource planning. in all of the popular desktop stacks, a new
tcp stream does its own slow start (not paying any attention to the aggegrate
bandwidth*delay when several streams are open to the same origin server).
this means every new tcp session has to sense the available bandwidth*delay,
causing the other tcp sessions toward the same origin to have to back off
and try to find the new equilibrium. and then, wonder of wonders, it's time
to close all of those connections because the user has clicked "stop" after
getting bored waiting for thos GIFs to populate, and has clicked on something
else, so let's start this whole stupid process over again with some other
origin server.
persistent http helps this a little. aggregation through proxies -- even if
no caching is done -- will help it a little more. t/tcp would help some.
desktop tcp stack fixes to remember end-to-end bandwidth*delay between
connections, and to treat end-to-end bandwidth*delay as an aggregate to be
shared between simultaneous connections from/to the same place (or to just
stop doing that stupid parallelism in favour of one http/1.1 persistent
connection) would also help.
Finally, could your explain the "benchmark" comment a bit?
this was in specific reference to my product's connection quota for each
origin server, and the fact that if we intercept too many simultaneous
connections to a given origin server, we just delay the ones for which no
open connection is available.
Paul A Vixie <paul@vix.com> writes:
desktop tcp stack fixes to remember end-to-end bandwidth*delay between
connections, and to treat end-to-end bandwidth*delay as an aggregate to be
shared between simultaneous connections from/to the same
place
By "desktop tcp stack fixes" you mean at the server
side in the case of HTTP transfers, I guess.
Ow, no. Well, maybe you can share a congestion window
across multiple TCP streams such that you only occupy
the number of buffers a single uninterfered-with TCP
stream would. The idea is that there is space for N
packets between the source and the destination, and
what they are occupied by is immaterial.
Provided that dupack/ecn/timeout all affect the total
congestion window to a particular destination, preserving
additive increase/multiplicative back-off, this might
work. However you would have to think very hard about it
(I'd suggest involving the usual e2e researcher types
before you do a real deployment) and it's not clear it
would really buy you anything over a single TCP flow anyway.
Anything that introduces more traffic than would be
discovered by a single uninterfered-with TCP flow is bad
news. In particular, ramping up suddenly based on
historical conditions is unsafe.
I hate to say it but an obvious push-back mechanism is
per-packet charging (people are already charging by the
byte for web hosting), and it is in the interests of self
defence for web hosts to maximise their efficiency in the
face of this. Another obvious push-back is work along
the lines that VJ has been campaining for in his "penalize
things that are not in profile (with a normal TCP impl.)" talks.
(or to just stop doing that stupid parallelism in favour
of one http/1.1 persistent connection) would also help.
This is the appropriate solution.
  Sean.
This isn't a desktop stack issue
this is a server stack issue. even though
the d.t. opens the connections,
the server is the one sending all the
data and the server is the one doing all
the slowstart, ca/c, etc, etc.