"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.