Path: utzoo!mnetor!uunet!husc6!think!ames!ucbcad!ucbvax!DECWRL.DEC.COM!mogul From: mogul@DECWRL.DEC.COM (Jeffrey Mogul) Newsgroups: comp.protocols.tcp-ip Subject: Re: Determining gateway buffer capacity Message-ID: <8712150202.AA06187@bacchus.dec.com> Date: 15 Dec 87 02:02:58 GMT References: <8712110823.AA05126@uc.msc.umn.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: DEC Western Research Lines: 58 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.)