Re: Another proposal to think about

Steve Deering <deering@pescadero.stanford.edu> Fri, 24 November 1989 01:41 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA10842; Thu, 23 Nov 89 17:41:37 PST
Received: by decwrl.dec.com; id AA16032; Thu, 23 Nov 89 17:41:05 -0800
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA01196; Thu, 23 Nov 89 17:40:37 PDT
Date: 23 Nov 1989 17:05-PST
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: Re: Another proposal to think about
To: Philippe Prindeville <philipp@gipsi.gipsi.fr>
Cc: mtudwg
Message-Id: <89/11/23 1705.809@pescadero.stanford.edu>
In-Reply-To: Philippe Prindeville's message of Thu, 23 Nov 89 152708 -0100

Philip writes:

>	...if the packet was a jumbogram and more than 2 derived packets
>	resulted, I think that any fragment with the MF-bit set (ie. all
>	but the tail) should be usable [as an indicator of the path MTU],
>	since they might arrive out of order.

No, you don't want to do that.  Imagine this scenario:

     [source]------->[gateway]------->[gateway]------->[destination]
               MTU              MTU              MTU
	       600              400              300


The source sends a 600 byte packet.
At the first gateway, it is fragmented into 400 + 200.
At the second gateway, they become 300 + 100 + 200.

If the 100-byte fragment should arrive first at the destination, it should
*not* be used for MTU determination.  Only fragment 0 should be assumed to
be the size of the path MTU, regardless of the order of reception.  (Think
of the initial fragment being trimmed at various gateways, by arbitrary
amounts, until it equals the path MTU.  The other fragments are just the
"trimmings".)

Even when packets are reordered, you expect fragment 0 to show up
eventually (very soon, actually), so it's OK to wait for fragment 0
for MTU determination.

Steve