Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard

[Fred Baker <[e-mail]>]

On Feb 3, 2017, at 12:11 PM, Templin, Fred L <[e-mail]> wrote:
> A note about RFC4821. We think it will work for end-to-end MTU determination and
> black hole avoidance, but from discussions on intarea we now no longer think it will be
> applicable to tunnel endpoints. That is because the tunnel ingress is not the source
> of the original packets - it is only the source of the tunneled packets and the RFC4821
> probes. And, if the original packets (once admitted into the tunnel) travel a different
> path than the probes the system could black hole.
> 
> Is this worth an errata to RFC4821?

I guess my question is "what in 4821 would you like to see changed". 4821 says, in effect, "try a number of different trial PMTU values in a rational sequence, and use the largest that seems to work". As you say, the tunnel endpoint doesn't implement the TCP, and therefore doesn't implement 4821 directly, at least for that purpose. However, if the system sending it packets does, the existence of the tunnel merely forces the 4821 algorithm to choose a smaller number. 4821 in the endpoint that *does* implement TCP should have the right result.

So, with the possible exception of adding one or more appendices saying "X in the network can cause the algorithm to choose a smaller number", I don't see what in a potential 4821-bis would be different. In such a case, I don't see the case for an erratum; an erratum is a request for a change.


A change I might suggest, which is not an error but an optimization, would suggest trying the first few values (IP message size 9000, 1500, 1400, and 1280?) in the same RTT, and deducing from the first Ack received which one got through first (in that sequence, the host might not try 9000 because it is configured for something shorter, try 1500 and have it not go through a tunnel, but have 1400 and 1280 work. It would get an Ack saying that it expected the next octet to be N+1400, or possibly an Ack pointing to N+1280 and another pointing to N+1400). Rather than waiting for retransmission timeouts, make it all happen in the first RTT.