On 2/7/2017 12:06 PM, otroan(_at_)employees(_dot_)org 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