I-D on operational MTU/fragmentation issues in tunneling

Fri Oct 15 13:31:48 UTC 2004

Stephen J. Wilcox wrote:

>On Thu, 14 Oct 2004, Joe Maimon wrote:
>  
>
>>Sabri Berisha wrote:
>>    
>>
>>>On Mon, Oct 11, 2004 at 11:12:55AM +0300, Pekka Savola wrote:
>>>
>>>With the risk of stating the obvious I would say that normally, PMTUD
>>>should do the trick. 
>>> 
>>>
>>>      
>>>
>>On todays internet everything is more reliable than PMTUD.
>>
>>How about replacing it completely with something more inband, less prone 
>>to firewall breakage?
>>    
>>
>
>ok .. if you have access to the end hosts then Sabri's answer works fine but if        
>your an inbetween network as most are then stripping DF is a good option.
>
>not sure how to do this 'inband' .. the point of DF is it prevents the default 
>'inband' fragmentation. so actually - why dont vendors have a 'ignore df-bit' 
>option in their equipment?          
>
>  
>
A mix of schemes is needed. Some inband to the protocol conversation at 
hand and some not.
Should one fail negotiation can still happen. In most cases traffic 
should still flow.

I think the DF bit is a mistake and should not be used, except when 
probing with multiple packets on the wire.
I think giving vendors a free pass on bad fragmentation performance is 
also a problem. Nothing that couldnt have been solved with the ooddles 
of cheaply available memory we have now.

And by that I mean the vendors who consistently shipped routers that had 
only performance resources for bare bones routing.

 (OT Rant: The price margin of the routers being high enough that 
doubling the shipped memory load and enabling upgrades to limits 
comparably available to popular cheap computing equipment out there 
should not have broke the bank on these routers. There really was no 
excuse for 10K equipment coming in with a tenth of available computing 
resources that can be had at 1K. It boggles the mind the free pass they 
got on that. Saying performance is only required of the ASICS that 
switch was incredibly short sighted -- and selfish) (OT Rant #2: The 
whole firewall is not a router -- merely a copout because all these 
routers turn out to be wimps doing anything not limited to switching 
packets from one interface to another. The best place to handle policies 
and security detection for packets is where they are already being 
handled -- the router. ANd the reward for the copout? Big bucks for 
commodity computers with mediocre software.)(OT #3: How about a firewall 
protocol to exchange return traffic information between a set of 
firewalls so that assymetricity works again and firewalling can be done 
at the SP level. Does such a thing exist and if so who supports it)

How about some more tcp or ip options so that machines can tell each 
other what packet sizes are actually coming in, fragmented or not? No 
dropping of packets. The larger they are when they come in the better. 
Any protocol that detects duplicate data can probe with multiple packets 
on the wire. Must be better for slow start, exponential back-off model. 
-- Inband

How about a UDP port designated for IP packets with these options and 
magic cookie values to prevent spoofing? -- Completely outband
Easy enough so that firewall vendors will have that on by default.

How about an additional ICMP type dedicated precisely for this? "Packet 
was sent fragmented, to avoid this lower sending packet size to X". Kind 
of the opposite of Frag needed but DF set message.If this fails to work, 
well we have more fragments. Much better than having stalled traffic. -- 
a little different than current algorithm of drop first notify later

It seem everyone keeps trying to figure out how to fix the 
implementation of PMTUD or to work around it. Perhaps a new solution 
will gain enough traction that the current mechanism will become 
obsolete. Problem solved.

Add in some algorithm fixes as mentioned for the broken PMTUD of today 
and conversing hosts should have more tools than they can use to 
discover and take maximum advantage of pmtu, OR in the alternative, 
still exchange network traffic.

Much better than a single mechanism for detecting PMTU which if fails 
can cause a  blackhole of your packets.

If we ever want to aggressively lift MTU's in tomorrows network we 
really need to solve this with enough nails and screws that it aint 
coming back out again.

And I dont want to hear that ipv6 fixed this or that -- except if its 
possible to apply the lesson learned to the protocol most of us actually 
use. (not that I actually know if/how it works better in ipv6) because 
we all know that ipv4 is here to stay in its dominant position for at 
least 5-10 more years. It will need to be supported for possibley 
another 20.

Joe

>Steve
>
>
>
>  
>