This thread has drifted all over the place and the only conclusions I can
see are:
The core infrastructure MTU is >= 1500
People are telling clients to set their Win95 MTU to 576
PMTU is randomly broken by clueless filtering
Some dial-access devices are buffer limited
A small MTU (53 byte?) would increase perceived response at the expense of
performance
I have been an advocate of the bigger defaults is better camp, but there is
a real concern that the wrong values could actually cause more damage than
their gain is worth. If the above list is incorrect or incomplete it would
be useful for people to constructively tell Peter that now.
This thread has drifted all over the place and the only conclusions I can
see are:
The core infrastructure MTU is >= 1500
People are telling clients to set their Win95 MTU to 576
People are asserting that Win98 comes with it's MTU set this low, which
appears to be generally considered to be a bad idea.
PMTU is randomly broken by clueless filtering
Some dial-access devices are buffer limited
A small MTU (53 byte?) would increase perceived response at the expense of
performance
Browsers, and other software which open multiple connections should
temper their connection counts based on the size of the perceived pipe;
ie: some connect-level heuristics to do proper PMTUD and _make the
answer available to applications_ would probably be useful.
I have been an advocate of the bigger defaults is better camp, but there is
a real concern that the wrong values could actually cause more damage than
their gain is worth. If the above list is incorrect or incomplete it would
be useful for people to constructively tell Peter that now.
That's the only one that I can see that you missed. Any effort
expended to improve the quality of the default stack in Win9X would
probably be A Good Thing... given the current population of the net.
Cheers,
-- jra
How about the browsers just implement HTTP/1.1 and use pipelined
persistant connections? Why invent some new fangled connection management
crud when there's a much better way to utilize the pipe. See
<http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html> for example.
Just imagine how well that would work if they were talking to a local
proxy.
Dean
"Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us> writes:
Browsers, and other software which open multiple connections should
temper their connection counts based on the size of the perceived pipe;
ie: some connect-level heuristics to do proper PMTUD and _make the
answer available to applications_ would probably be
useful.
Um, no, all the path MTU discovery process tells you is
the upper bound to the size of a non-fragmented datagram
at some point in the immediate past.
Surely the thing to do would be to adjust the congestion
window to send more or less data at a size bounded by
path MTU or advertised MSS, whichever is the lower?
If you really want to get into remote tweaking to
deal with what is perceived to be a long queueing
delay somewhere in the path, then maybe (just maybe)
this could be done by sending segments smaller
than the maximum size.
One could imagine a receiving end system comparing
multiple inbound streams for decent interleaving, and
inferring nearby queue occupation from them, and
signalling desired behaviour back to the sending
end systems. However, when it comes down to it,
what you really want is to avoid the situation where
queues are full to the point where there is heavy
occupation by a small number of "fat" flows.
This is what RED accomplishes.
Deploy RED, it works particularly well in the case of big
queues in front of a slow (dialup) interface, and with a
little more pressure from ISPs and some nagging by Van
Jacobson it'll be in the field much faster than reliable
end-to-end signalling mechanisms for adjusting desired
segment size will ever be invented, let alone deployed.
Sean.