Re: Comments on PMTU-Draft-RFC

sytek!kzm@hplabs.HP.COM (Keith Mc Cloghrie) Sun, 28 January 1990 03:10 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA20484; Sat, 27 Jan 90 19:10:58 PST
Received: by decwrl.dec.com; id AA22297; Sat, 27 Jan 90 19:10:54 -0800
Received: by hplabs.HP.COM ; Sat, 27 Jan 90 19:11:04 PST
Received: by sytek.hls.hac.com (5.51/5.17) id AA20060; Sat, 27 Jan 90 18:56:38 PST
From: sytek!kzm@hplabs.HP.COM (Keith Mc Cloghrie)
Message-Id: <9001280256.AA20060@sytek.hls.hac.com>
Subject: Re: Comments on PMTU-Draft-RFC
To: pradeep@orville.nas.nasa.gov (Nuggehalli Pradeep)
Date: Sat, 27 Jan 90 18:56:35 PDT
Cc: mtudwg (mtudwg)
In-Reply-To: <9001270212.AA00653@orville.nas.nasa.gov>; from "Nuggehalli Pradeep" at Jan 26, 90 6:12 pm
X-Mailer: ELM [version 2.2 PL0]


> 1.  > ...   ...   ...   ...   ...   ...    Thus, if the option
>     > arrives at the destination with its next-hop field non-
>     > zero, then all gateways along that path have updated the
>     > option and the minimum-MTU-so-far value is indeed the PMTU;
> 
> Not true! (or else I'm missing something here!) It should read:
> "If the option arrives at the destination with its next-hop field *same
> as destination address*, then all routers along that path have updated the
> option and the minimum-MTU-so-far value is indeed the PMTU."
> The destination host should check whether or not the next-hop field
> has the same address as the destination address (not check for zero/non-zero) 

The first thing that the destination host does on receiving this
option is to update the Min-MTU and Next-Hop fields according to the 
interface on which it was received (see section 7.3); thereafter, it 
can indeed test for zero/non-zero.  However, in this descriptive 
section, I agree that the words should be updated as you suggest.  

> 2. Next-Hop-Address:
> 
> I don't see the full justification of using this field.
> The only thing it helps us in detecting is the case of two consecutive
> non-cooperating routers with a low-MTU link when probing. I am inclined
> to think that this case would not be very common. Even so, this case
> would later be detected by the backup fragment-report mechanism.
> Even without this field, isolated non-cooperating routers would not cause a
> problem because the neighboring routers would handle the case.
> But this is only an opinion and I leave it to the group to decide on this.

This is what the group did decide at the December meeting.  It's difficult
to predict which gateways will get updated and which won't, and so I'd
not hazard a guess as to how common your case might be.  However, if 
the destination does not support the backup unexpected-fragment-size
message, then the option is the only indication you have.  In your
case, the low-MTU link is probably the bottleneck in speed as well
as in MTU, and thus having fragmentation on it will really hurt.

> 3. IP PMTU-Query Option:
> 
> The length of the Min-MTU field of 2 bytes is sufficient for almost
> all currently available networks, as it allows a max value of 64 KBytes.
> But, for example, UltraNet is already using an MTU value of 32 KB,
> and I think that new network technologies would soon reach and exceed 
> the limit of 64 KB for the MTU. So, could we consider increasing the
> length of the Min-MTU field in the option to 3 or perhaps 4 bytes.

Jeff, Rich and I did consider that, but decided that there are so
many other fields in IP/ICMP formats where the max is 64K, that it
was not worth making the option any bigger than necessary to allow
for this.  (Note the size of the option reduces the useable PMTU for
at least some, possible all, datagrams.)

> 4.  > ...     ...      ...      and the size of a fragment-0 are
>     > considered accurate indications of the current PMTU of the
>     > path, ...   ...   ...
> 
> Not true! because the fragments of a datagram could take different
> paths, and some of those fragments could get re-fragmented, and we
> don't know which of these paths the subsequent datagrams will take.
> Perhaps we could use the size of the largest fragment, but this would 
> still be a guess.  So, I prefer to use the size of fragment-0.
> Thus, the size of fragment-0 is only a best-guess. 

Whether we call it "a best-guess" or we consider it an "accurate
indication" does not seem important.  What is important is that
in the event that datagrams or their fragments are taking different 
paths with different PMTUs, then the overall-PMTU is the minimum of 
the MTUs of any/all hops of these various paths, and the proposed 
scheme produces a PMTU value which converges to the correct (minimum) 
value.

> Overall, the new hybrid scheme seems to be a pretty good scheme.

Yes, I think so too.
 
Keith.