Comments on PMTU-Draft-RFC

[Nuggehalli Pradeep <[e-mail]>]

Comments on the PMTU Discovery Draft-RFC:

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). 
This applies to all references in the document where the destination checks
for zero/non-zero.
Consider the case where the last-hop router, or the n, n+1, ...thru...
the last-hop router are non-cooperating. Then the option would arrive at
the destination host with its next-hop field non-zero (and not the same as
destination address).

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.

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.
Possible option format:
------------------------------------------------------------
|     Type    |    Length    |  Reserved (for future use)  |
------------------------------------------------------------
|                     Min-MTU                              |
------------------------------------------------------------
|                     Next-Hop                             |
------------------------------------------------------------

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. 

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

--- Pradeep