North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: I-D on operational MTU/fragmentation issues in tunneling
- From: Joe Maimon
- Date: Tue Oct 19 15:20:05 2004
Sam Stickland wrote:
Thanks for raising this to the forefront. I had been aware of this I-D
in previous form, also referenced in the linked to by parent I-D.
On Thu, 14 Oct 2004, Joe Maimon wrote:
Sabri Berisha wrote:
On todays internet everything is more reliable than PMTUD.
On Mon, Oct 11, 2004 at 11:12:55AM +0300, Pekka Savola wrote:
Hi Pekka and others,
With the risk of stating the obvious I would say that normally, PMTUD
Please send comments to me by the end of this week, either on- of
off-list, as you deem appropriate.
should do the trick.
How about replacing it completely with something more inband, less
prone to firewall breakage?
You mean something like Packetization Layer Path MTU Discovery (PLPMTUD)?
Its a very ingenuous mechanism to allow discovery while still delivering
packets and looks like a big improvement over what we live with now.
--Downsides as applies to the I-D that pretty much apply as well to the
* its pretty complex and needs to be re-incarnated into every l4 protocol.
* data delivery can be interrupted pending retransmission of dropped
probe packets (if not sent concurrently)
* data packets can only be sent concurrently in different sized packets
if the l4 layer supports detecting duplicate data
* does not operate on the layer it is meant to interrogate. IOW -- its a
l4 protocol feature concerned about l3 features
Other ideas I mentioned that may very well be unworkable or naive.
I would appreciate any pointers to any prior discussion for any of them.
All these do NOT need to set the DF bit.
*A probing mechanism that does not turn on the DF bit would not
interrupt data flow with dropped probes. The protocol would need to
support being informed by the remote site of max payload size received.
It can then use this as the outgoing value or as an indication to
fallback to a previous value and/or reset a timer for when to try a
higher packet size again. Except for spoofing concerns this naturally
belongs in the l3 protocol. A cookie option might mitigate spoofing
This could be implemented in a l3 or l4 protocol. A l3 protocol
implemenation could allow the upper l4 protocol the decision to turn the
l3 one off, turn its own mechanism off, or use both.
One gotcha. hops that optimize by fragging into equal or other sized
packets not clearly corresponding to actual link mtu. An implementation
would need heuristics to catch this, instead of merely using the
*A protocol that is dedicated completely to path mtu discovery would be
a nice addition to the stacks toolbox and would be fairly usefull
for any protocol on the stack that does not have its own method or for
some reason cannot trust its own methods results or just want a second
This is outband enough that if successfull or unsuccessfull operation
should not affect the main traffic flow of interest. A UDP protocol
would need to use cookie values to prevent easy spoofs. Heuristics might
also be neccessary.
* An IP option that when present triggers a new ICMP message,
Fragemented and Delivered with frag size and link size as values. A
returned cookie or packet header contents would minimize spoofs.
* The above without the new IP option.
It now occurs to me that I should take this over to the WG.......oh
well. I have already written it. Sorry for the BW.