SMB's proposal: using an IP option for "Report Fragmentation" flag
mogul (Jeffrey Mogul) Mon, 27 November 1989 23:29 UTC
Received: by acetes.pa.dec.com (5.54.5/4.7.34)
id AA08318; Mon, 27 Nov 89 15:29:31 PST
From: mogul (Jeffrey Mogul)
Message-Id: <8911272329.AA08318@acetes.pa.dec.com>
Date: 27 Nov 1989 1529-PST (Monday)
To: smb@hector.att.com
Cc: MTU Discovery <mtudwg>
Subject: SMB's proposal: using an IP option for "Report Fragmentation" flag
In-Reply-To: Msg from smb@hector.att.com dated Thu, 23 Nov 89 09:57:43 EST.
<8911231457.AA22278@hector.homer.nj.att.com>
Steve B's proposal (introduce a new "flag" IP Option that means "Report Fragmentation") has several nice advantages. First, it doesn't appear to require any changes to existing gateway implementations (which are all required to pass along unknown options, subject to the usual orthogonal rules about copying on fragmentation). Second, it doesn't intrude on any "architecture resource" scarcities (i.e., bits in the IP header). Although this may turn out to be the best compromise, there are a few problems here. First, as has been noted, option processing is a pain for gateways. Even though this option would not actually require action on the part of the gateway, the gateway would still have to parse the options list. True, this option would not be sent on every packet, but it would be sent far more often than the RFC1063 option. This leads me to my second point, which is also a complaint about Steve D's proposal (and indeed, anything based on "report fragmentation"). The problem is that the sender has no way of knowing if it has discovered the path MTU unless and until it receives an ICMP report. Perhaps the ICMP reports are being dropped on the return path; or perhaps the datagrams aren't large enough to be fragmented yet. Either way, the sender's algorithm for deciding when to send the option (or set the RF flag) is going to be complex, and (this is the part that applies equally to Steve D's method) it might take a while for the sender to discover the MTU. Meanwhile, the sender might have filled the transmission pipe with mobygrams that are all being fragmented. I think (powers that be permitting) the use of a "no-cost-to-routers" RF flag in the IP header, which can be set on all the datagrams sent by a host, is more efficient than the occasional sending of an option. We would still have to worry a bit about what a "naive" host/router would do when it receives packets with this bit set. The RFC1063 option, while it has its drawbacks, does manage to discover the MTU as early as possible during the lifetime of a connection; since many connections (e.g., SMTP) are short, this could be a plus. -Jeff
- Re: Another proposal to think about Rich Fox
- Re: Another proposal to think about Philippe Prindeville
- Re: Another proposal to think about smb
- Re: Another proposal to think about Philippe Prindeville
- Re: Another proposal to think about Steve Deering
- Re: Another proposal to think about Steve Deering
- Re: Another proposal to think about Steve Deering
- SMB's proposal: using an IP option for "Report Fr… Jeffrey Mogul
- Re: Another proposal to think about Rich Fox
- Re: Another proposal to think about smb
- Re: Another proposal to think about Philippe Prindeville
- Re: Another proposal to think about Jeffrey Mogul