I-D on operational MTU/fragmentation issues in tunneling

Joe Maimon jmaimon at ttec.com
Tue Oct 19 19:16:19 UTC 2004



Sam Stickland 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:
>>>
>>> Hi Pekka and others,
>>>
>>>
>>>> Please send comments to me by the end of this week, either on- of
>>>> off-list, as you deem appropriate.
>>>>
>>>
>>> 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?
>
>
> You mean something like Packetization Layer Path MTU Discovery (PLPMTUD)?
>
> http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-02.txt
>
> http://www.psc.edu/~mathis/MTU/pmtud/
>
> Sam

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.

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 
current PMTUD
* 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 
concerns.

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 
returned value.

*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 
opinion.
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.

>
>



More information about the NANOG mailing list