Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt

["Fred Baker (fred)" <[e-mail]>]

On Jun 26, 2013, at 3:56 AM, Mark ZZZ Smith <[e-mail]> wrote:
> ----- Original Message -----
>> From: Fred Baker (fred) <[e-mail]>
>> To: Randy Bush <[e-mail]>
>> Cc: IPv6 Deployment Prevention <[e-mail]>
>> Sent: Wednesday, 26 June 2013 1:30 PM
>> Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
>> 
>> On Jun 25, 2013, at 12:42 PM, Randy Bush <[e-mail]> wrote:
>>> in reality, you can not count on pmtud working
>> 
>> One of these days, I'll understand why Linux/FreeBSD/Windows/Apple don't implement RFC 4821. 
> 
> Actually, Linux does, it just needs to be switched on in /proc/sys/net/ipv4/
> tcp_mtu_probing - INTEGER Controls TCP Packetization-Layer Path MTU Discovery.  Takes three values: 0 - Disabled 1 - Disabled by default, enabled when an ICMP black hole detected 2 - Always enabled, use initial MSS of tcp_base_mss.

In other words, it's not on. There is some dead code there, but unless you are the writer of the application or a Linux techie, it doesn't work for you.

> I think Windows also implements something similar:
> "
> Troubleshooting PMTU Black Hole Routers"
> http://technet.microsoft.com/en-us/library/cc958871.aspx

"To respond effectively to black hole routers, you must enable the Path MTUBH Detect feature of TCP/IP."

In other words, it's not on. There is some dead code there, but unless you are the writer of the application or a Windows techie, it doesn't work for you.

My question isn't whether there is some experimental code somewhere that could possibly implement it if someone rewrote the application or did some surgery in the system's configuration files. If my daughter bought a standard system and started using it, would it work for her? My question is why folks aren't implementing it in the normal case. Experimental code is kind of pointless in the general case.

> One of the issues with conventional ICMP PTB based PMTUD is the default rate limits on ICMP messages on broadband routers with PPPoE subscribers i.e. dumbell [1500][1492][1500] MTUs, slowing down PMTUD. Upping the limit on ICMP PTBs is an obscure parameter to have to remember to change, and it isn't clear exactly what to change it to - IIRC, the value I've used in the past is 1000/s up from 10/s. RFC4821 would be nice because it would avoid control plane processing that ICMP based PMTUD causes.
> 
> Regards,
> Mark.

If at first the idea is not absurd, then there is no hope for it.  
Albert Einstein