Re: Another proposal to think about

Steve Deering <> Fri, 24 November 1989 07:17 UTC

Received: from by (5.54.5/4.7.34) id AA11720; Thu, 23 Nov 89 23:17:35 PST
Received: by; id AA08703; Thu, 23 Nov 89 23:17:06 -0800
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA01850; Thu, 23 Nov 89 23:16:56 PDT
Date: 23 Nov 1989 23:10-PST
From: Steve Deering <>
Subject: Re: Another proposal to think about
To: mtudwg
Message-Id: <89/11/23>
In-Reply-To: Philippe Prindeville's message of Thu, 23 Nov 89 152708 -0100

[I apologize if some of you receive this twice.  Of the three messages I
posted to mtudwg this afternoon, this one got bounced back to me from
decwrl, leading me to believe that it didn't reach everyone. --Steve]

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:

               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

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.