North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: I-D on operational MTU/fragmentation issues in tunneling

  • From: Joe Maimon
  • Date: Tue Oct 19 15:20:05 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.