I-D on operational MTU/fragmentation issues in tunneling
jmaimon at ttec.com
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.
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
More information about the NANOG