Jeffrey Mogul (email@example.com)
Mon, 14 Dec 87 18:02:58 PST
In article <8712110823.AA05126@uc.msc.umn.edu> Stuart Levy writes:
Some recent messages on this list described efforts to define a scheme
for hosts to find a network path's maximum preferred message size, e.g.
the largest datagram which could be sent without some gateway
Has anyone considered having gateways give advice to hosts on how
-much- data they should send, either in terms of total amount of
outstanding data (which TCPs could use to limit windows) or data flow
rate (which, say, NETBLTs could use to set rate parameters)?
This seems like a natural function to piggyback onto a max-message-size
probe. It suffers from some of the same limitations, that there may be
multiple paths with different behavior.
Yet another one of the points Chris Kent and I covered in our paper
"Fragmentation Considered Harmful", presented at SIGCOMM '87. (Proceedings
should be available, as an issue of CCR, in early 1988; Chris and I
have also produced a slightly revised version that will be available
as a DECWRL Technical Report at about the same time.)
In our paper, we proposed two different ways (use of IP options, or
use of a separate ``Probe'' protocol) to gather the following information
about a path (as opposed to a single gateway, which would be an
interesting thing as well, but probably not quite as useful. Probing
the path periodically should resolve most multipath problems):
Maximum delay (intrinsic, not queueing)
Maximum (gateway) queue length
Maximum error rate
This kind of info would let a protocol implementation control such
things as datagram size, rate of packet injection, rate of total
data injection, use of forward error correction, perhaps better
RTT estimates, etc.
I think this is a good idea, but realize that it might not be
feasible to retrofit the existing Internet, or enough of it
to make a difference.
At some point, the proposal in our paper should be turned into
a couple of RFCs. Anyone who would rather write an RFC than wait
for us to do it, please go ahead!
P.S.: someone recently complained that probes don't work because
paths are asymmetric. Our proposals, as well as those made by
others, are ``round-trip'' rather than one way; if the probes
follow the same route that the useful packets follow, asymmetry
is not a problem. If the path were known to be symmetric, the
information would be available 1/2 RTT sooner, but the kinds of
things we want to probe for are not meant to vary that rapidly.
(Reported queue lengths might have to be smoothed before using
them in a congestion-control method.)
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:40:15 GMT