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
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, PMTUDPlease send comments to me by the end of this week, either on- of off-list, as you deem appropriate.
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.