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

["Templin, Fred L" <[e-mail]>]

Hi Fred,

In Section 10.3 of RFC4821, it says: 

   "However, other more serious failure modes do exist, such as might be
   caused by middle boxes or upper-layer routers that choose different
   paths for different protocol types or sessions.  In such
   environments, adjunct protocols may legitimately experience a
   different Path MTU than the primary protocol.  If the adjunct
   protocol finds a larger MTU than the primary protocol, PLPMTUD may
   select an MTU that is not usable by the primary protocol.  Although
   this is a potentially serious problem, this sort of situation is
   likely to be viewed as incorrect by a large number of observers, and
   thus there will be strong motivation to correct it."

This passage is in regards to "Probing Method for IP Fragmentation", but
the same considerations apply to tunnel endpoints that would employ an
adjunct protocol to probe the path MTU.

Where RFC4821 says:

    "Although this is a potentially serious problem, this sort of situation is
      likely to be viewed as incorrect by a large number of observers, and
      thus there will be strong motivation to correct it."

I agree that this is a potentially serious problem, but the situation could
not be viewed as incorrect if a legitimate service such as Equal Cost
Multipath (ECMP) is employed somewhere along the path and the
adjunct probes take a path with a larger MTU while the primary protocol
takes a path with a smaller MTU.

An erratum could change this sentence to something like:

   "This is a potentially serious problem that could be due to either a
     misconfiguration or a legitimate service such as Equal Cost Multipath
     (ECMP) that allows the adjunct probes to take a different path than
     the primary protocol."

Thanks - Fred
[e-mail]


> -----Original Message-----
> From: Fred Baker [mailto:[e-mail]]
> Sent: Friday, February 03, 2017 12:59 PM
> To: Templin, Fred L <[e-mail]>
> Cc: Brian E Carpenter <[e-mail]>; [e-mail]
> Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
> 
> 
> 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.