Re: Minutes of MTU Discovery Working Group Meeting (7 Feb 1990)

[Steve Deering <[e-mail]>]

Taking a short break from the thesis gindstone (millstone?), I have
some questions/comments on the minutes of the MTU discovery meeting.

>	...there are 3 unused in the TOS field...

Looking at the IP spec, I see only two unused bits (6 and 7).  Where is
the third?

>	Within "a few" years, the routing protocols will provide
>	path-MTU information, so MTU discovery will be unnecessary.

This keeps popping up.  Would someone please explain this in more
detail?  Exactly how are the routing protocols going to maintain or
acquire the path-MTU information that hosts need, and how are the hosts
going to learn that information and detect changes in that information?
I can imagine several possible schemes, including giving up dynamic,
datagram routing in favor of static, virtual-circuit routing (which
seems to be where politics-based routing is headed), but I'd really
like to get some facts before I start flaming. :-)

>	In general, we realize that fragmentation is not inherently evil.

One case in which fragmentation is inherently evil is when the packet
rate is high enough to allow the Identifier field to wrap around within
the maximum packet lifetime, raising the possibility of incorrect
reassembly.  (For example, Identifier wraparound occurs in less than 60
seconds, the TTL recommended for TCP, if packets are sent faster than
1092 per second.)

One solution to this problem is to somehow extend the Identifier field,
perhaps in an IP option (yuck!).  A better solution is to avoid
fragmentation, or at least, avoid reassembly.  Under the RF-bit scheme,
we could require the receiver of RF-marked fragments to *drop* such
packets after sending the ICMP Fragment Received message, rather than
reassembling them.  The source host would then treat an ICMP message
as a signal to immediately retransmit using the newly-discovered MTU.

I have yet another proposal which I will post as a separate message.

>	One problem that came up right away is that James VanBokkelen
>	believes there to exist many PC-based systems that
>	    (1) do not reassemble fragments

They wouldn't, by any chance, send an ICMP Reassembly Time Exceeded message
instead, would they?  I suppose that's too much to hope for...

>	One question arose about the use of a previously unused bit in
>	the IP header: what would current implementations do if they
>	see it set? ... Unfortunately, John Moy from Proteon admitted
>	that Proteon routers drop such datagrams, and Noel Chiappa says
>	that this is true of other implementations based on his old MIT
>	"C-gateway" code.

I believe that under 4.3BSD and derivatives (e.g., recent versions of
SunOS and Ultrix), the RF bit does not survive fragmentation.  That is,
if a datagram must be fragmented, the initial fragment ends up with a
zero RF bit, regardless of that bit's value in the original datagram.
Under my scheme, that prevents the sender from detecting the fragmentation,
and we depend on reassembly succeeding or timing-out (until those gateways
are upgraded).

This problem wouldn't arise if we used one of the unused bits in the
TOS field instead, as inelegant as that would be.

Steve