Re: PMTU-D: remember, your load balancer is broken

[woods () weird com (Greg A. Woods)]

[ 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>