[15106] in North American Network Operators' Group
Re: MTU of the Internet?
daemon@ATHENA.MIT.EDU (Sean M. Doran)
Sun Feb 8 00:17:29 1998
To: "Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us>
Cc: nanog@merit.edu
From: "Sean M. Doran" <smd@clock.org>
Date: 07 Feb 1998 20:56:51 -0800
In-Reply-To: "Jay R. Ashworth"'s message of "Fri, 6 Feb 1998 20:39:46 -0500"
"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.
