slevy@UMN-REI-UC.ARPA (Stuart Levy) (12/11/87)
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 fragmenting it.
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.
A gateway giving buffering advice would have to make some assumption about
what fraction of its capacity (or its links' capacity) should be available
to a given session. It might make a static decision ("I expect to have <= 10
active connections passing through me at once, so I advise everybody to use
no more than 1/10th of my capacity") or a dynamic one ("Things are getting
too crowded, so I'll tell everyone to send no more than 1000 bytes per second").
If implemented as an IP option it could be hung on Source Quenches to give
some crude quantitative information. Capacity assumptions could be wrong,
but at least they would prevent hosts with 32K TCP windows from swamping
gateways with 20K of buffer space.
Is anything along these lines being discussed? (Or has it already been
discussed and abandoned?)
Stuart Levy, Minnesota Supercomputer Center
slevy@uc.msc.umn.edu, (612) 626-0211mogul@DECWRL.DEC.COM (Jeffrey Mogul) (12/15/87)
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
fragmenting it.
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):
Minimum MTU
Minimum bandwidth
Maximum delay (intrinsic, not queueing)
Maximum (gateway) queue length
Maximum error rate
Hop count
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!
-Jeff
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.)PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") (12/15/87)
[ Probing gateways for MTU and transmission characteristics ]
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.
-Jeff
Certainly some of the regional networks might be interested in
experimenting with it to measure effects. A lot of the Internet
is still growing -- it would be less trouble to build it into the
new networks... And me, I love to tinker.
-Philip