Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery f

Lars,

> Matthew Luckie and Ben Stasiewicz. 2010. Measuring path MTU discovery 
> behaviour. In Proceedings of the 10th ACM SIGCOMM conference on Internet 
> measurement (IMC '10). ACM, New York, NY, USA, 102-108. 
> DOI=http://dx.doi.org/10.1145/1879141.1879155
>
> PDF here: https://www.caida.org/~mjl/pubs/measuring-pmtud.pdf
>
> "This paper measures PMTUD behaviour for
> 50,000 popular websites and finds the failure rate in IPv4
> is much less than previous studies. We measure the overall
> failure rate between 5% and 18%, depending on the MTU of
> the constraining link."
>
> 5-18% is pretty bad. I would expect that the widespread deployment of CGNs 
> since this was published in 2010 to not have improved things.
Emilie also did some work on this:
https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters

If you took this argument to it's extreme logical conclusion, wouldn't you then 
just state that the only thing that works in the Internet is TCP port 443 and 
UDP port 53?
I'm not sure how much sense it makes to let broken middlebox behaviour steer 
standardisation.
1981 is proven to work well. If a network operator has chosen to pull the plug 
on ICMP then there really isn't much IETF can do about that.

PLMTUD is better, and it is even better combined with PMTUD. But PLMTUD isn't 
deployed everywhere, nor used for UDP etc..
I don't see how that has any bearing on making 1981 an Internet standard.

I would really encourage more work on the Path MTU discovery problem though. 
Possibly combined with removing fragmentation from the IP layer. But that's far 
outside of the context of taking 1981 to Internet standard.

Best regards,
Ole

signature.asc
Description: Message signed with OpenPGP