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.