[ On Friday, June 16, 2000 at 05:38:25 (-0400), Richard A. Steenbergen wrote: ]
Subject: Re: PMTU-D: remember, your load balancer is broken
If you are a provider running the tunnel (not on an end host where MSS can be set), you would do well to keep the available MTU post-tunnel >= 1500 to keep everyone happy, if at all possible.
Sometimes it's just not that simple. You really do have to make room for the encapsulation header. If the maximum MTU of the tunnel transport is only 1500 bytes then the only way to have an MTU of 1500 bytes on the tunnel as well is to employ forced fragmentation (and perhaps windowing and maybe even retransmission since this level of fragmentation cannot stand for loss or out-of-order reassembly) in the tunneling protocol. Unfortunately there are all kinds of ugly things that can happen when you run TCP inside another windowing protocol. (For further info on that latter issue see "Why TCP Over TCP Is A Bad Idea" at <URL:http://sites.inka.de/sites/bigred/devel/tcp-tcp.html>.)
Just a quick 5:30AM thought, but it seems like a better solution would be to have the hosts signal that fragmentation was encountered on the ACK, so if ICMP discovery is not possible the packets are not lost with no idea why (it can go right next to the ECN bit :P).
Back when I was running with only PPP and a 1024-byte MTU I racked my brain to try and think of something better than PMTU-D. I did come up with a proposal that would allow a PPP router to do a legal end-run around a broken PMTU-D link. I haven't tried to implement it yet. The thing that really makes PMTU-D an ugly hack is that it in effect overloads the meaning of the DF flag. If there were only some room in the IP header for a new flag like "don't fragment unless you really have to...." I am somewhat worried about the vulnerabilities of PMTU-D too now that I've thought about the possibilities. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>