Re: MTU of the Internet?

["Sean M. Doran" <smd () clock org>]

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.