On 2/7/2017 12:06 PM, [email protected] wrote: > Joe, ... >>> I'm very much in favour of working on better ways of doing Path MTU >>> discovery. >>> A blanket statement of "use "PLMTUD" seems very premature though. >>> >> The point is that this document fails to indicate the current state of >> PMTUD. It correctly notes that: >> An extension to Path MTU Discovery defined in this document can be >> found in [ >> RFC4821 >> ]. It defines a method for Packetization Layer Path >> MTU Discovery (PLPMTUD) designed for use over paths where delivery of >> ICMP messages to a host is not assured. >> >> >> >> IMO, it fails to note that this case - where ICMP messages are assured along >> a path - is effectively a unicorn except within systems maintained by a >> single entity. >> >>> RFC1981 has 70 citations: >>> >>> http://www.arkko.com/tools/allstats/citations-rfc1981.html >>> >>> >>> Could you expand on your view of how this pertains to advancing RFC1981? >>> >> It's called last call input. My input is that this document needs to be more >> realistic in noting that, for all intents, ICMP-based MTU discovery isn't >> viable and that other methods need to be *expected*, not just that they're >> available. > Right, but if you are correct that ICMP-based MTU discovery is not viable > then this document should not be advanced. Not necessarily. It's fine to update a protocol that works inside an enterprise or other controlled environment.
> At the same time for many protocols we have nothing else. An operator can > break any protocol if that's their policy. And that's the breakage we're > talking about here, not any issues with the protocol specification. Well, it's a problem with the protocol spec that it's susceptible to operator interference. > There is a philosophical aspect of this. (Which I'm not the best person to > represent as I skipped my University studies in philosophy and used the > student loan to buy a motorcycle... (and only read the art of motorcycle > maintenance years later) ) > This is a tussle. The IETF specifies protocols under the assumption that > operators treat those protocols largely as specified. The 5-10% failure of > PMTUD messages may be caused by misconfiguration, misunderstanding or > mis-intent... Many of our protocols are suffering from the same fate. Should > the IETF adjust all its protocols to be as middlebox friendly as possible? > You can make this argument about IPv6 fragments, any packet with IPv6 > extension headers, IPv4 fragments. Or anything but TCP port 443/80 and UDP > port 53 for that matter. Are we as the IETF going to continue standardising > protocols to work as best as they possible can, ignoring protocol abuse, or > are we going to bend over and do whatever it takes to make it work for those > 5-10% who've actively broken the protocol? What about the 90-90% where the > protocols work as expected? What I'm suggesting is a lot simpler - just text that makes it clear what the current state of deployment of support (or interference) for this protocol is. I appreciate that you want to not point at PLPMTUD because it's not widely supported, but **for the same reason** this doc should not hold up this solution without pointing out very clearly that it basically isn't going to be work. Joe
