How to use an IP-header bit for Path MTU discovery.
"John M. Wobus" <JMWOBUS%SUVM.BITNET@CORNELLC.cit.cornell.edu> Mon, 19 February 1990 20:29 UTC
Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34)
id AA16519; Mon, 19 Feb 90 12:29:28 PST
Received: by decwrl.dec.com; id AA13003; Mon, 19 Feb 90 12:29:22 -0800
Message-Id: <9002192029.AA13003@decwrl.dec.com>
Received: from SUVM.ACS.SYR.EDU by CORNELLC.cit.cornell.edu (IBM VM SMTP
R1.2.1MX) with BSMTP id 3486; Mon, 19 Feb 90 15:29:28 EST
Received: by SUVM (Mailer R2.03B) id 8513; Mon, 19 Feb 90 15:28:04 LCL
Date: Mon, 19 Feb 90 15:24:34 EST
From: "John M. Wobus" <JMWOBUS%SUVM.BITNET@CORNELLC.cit.cornell.edu>
To: mtudwg
Subject: How to use an IP-header bit for Path MTU discovery.
If an IP header bit is to be dedicated to MTU discovery, then one strategy for using it is to send it in exactly those cases where the recipient host ought to try something it normally wouldn't. For example, if a useful behavior is to normally set the MTU to 576 (I'm speaking of inter-network traffic here: traffic on a LAN would have its own rules) but to use some higher number (say 1500) when doing so causes no fragmentation, then the bit might be defined as follows: The bit means that the sending host has received no fragmented packets from the recipient. Each host-route entry would include a flag meaning "the last oversized packet I received from this recipient was NOT fragmented". It should be turned on when the host route is created. A host would simply copy this bit into all the IP packets that it sends to the other host and would start out with its favorite large MTU. Recipients of this bit use it by simply switching to a smaller MTU (576) if the bit is clear. If they are talking to a host without the feature, they simply always switch down. The advantage of this plan is that it will work smoothly with any other hosts which ignore the bit. Also, the bit is the only new thing that has to be implemented (no ICMP messages or IP options). Possible disadvantages: is the MTU correctly sized at a time when it will do any real good? Are two "candidate" MTU sizes enough? (note: this method can probably be adapted to zoom in on intermediate MTUs--the protocol allows implementations to try one MTU, then another, though it fails to tell a host exactly when is a good time to believe the bit after the first time: that would be left to clever implementation) Is it too much to ask hosts to look up the host route each time it receives a packet? (this method requires the host-route entry be looked up each time an oversized packet is received, be it fragmented or not). Is it OK to save such state in host-route entries? Will some gateways or hosts choke on the bit? John Wobus Syracuse University
- How to use an IP-header bit for Path MTU discover… John M. Wobus
- Re: How to use an IP-header bit for Path MTU disc… Jeffrey Mogul
- Re: How to use an IP-header bit for Path MTU disc… jrd
- Re: How to use an IP-header bit for Path MTU disc… Philippe Prindeville
- Re: How to use an IP-header bit for Path MTU disc… Philippe Prindeville
- Re: How to use an IP-header bit for Path MTU disc… Philippe Prindeville
- Re: How to use an IP-header bit for Path MTU disc… Fred Bohle acc_gnsc
- Re: How to use an IP-header bit for Path MTU disc… Steve Deering
- Re: How to use an IP-header bit for Path MTU disc… Philippe Prindeville
- Re: How to use an IP-header bit for Path MTU disc… Philippe Prindeville