2.8.26 Packetization Layer Path MTU Discovery (plpmtud) Bof

Current Meeting Report

should.Minutes from the Packetization Layer Path MTU Discovery BOF
Thursday, March 20 at 1630-1730

From notes compiled by Peter by Peter O'Neil and Matt Zekauskas and 
edited by Matt Mathis.


The majority of the material discussed at the BOF came directly from the 
slides.  (See 
http://www.psc.edu/~mathis/papers/mtuBOF200303/ ).

The goal was to introduce a new algorithm to implement end-to-end path MTU 
discovery and discuss how the IETF might complete the work.

The new algorithm does not rely on ICMP or other messages from the 
network (so it is not subject to the problems described in RFC2923).  
Instead TCP or other upper layer protocol finds the proper MTU by 
starting with relatively small packets and searching upwards by probing 
with larger packets.

There are already two independent prototype implementations.

In the BOF there were two questions discussed in the wider group:

First: What existing standards and technologies might be affected by 
changes to RFC 1191 path MTU discovery?  This discussion served to 
identify some of the issues that might need to be considered when 
evaluating a possible new standard, and therefore influence the scope of a 
potential WG.

Second: Is this worthwhile and doable withing the IETF?  There was clear 
consensus that, yes this work is appropriate for the IETF, and we should 
press on and draft a Working Group charter.

Minutes from the Packetization Layer Path MTU Discovery BOF
Thursday, March 20 at 1630-1730

Matt and Kevin presented slides illustrating known problems with path MTU 
discovery (taken from on RFC2923), a summary of work to date on the new 
algorithm, including two implementations and some unresolved details.  (The 
slides are available from 
http://www.psc.edu/~mathis/papers/mtuBOF200303/ ) This material is not 
replicated in the minutes.

Slide 13 was used to collect input from the audience on the question "What 
existing standards and technologies might be affected by changes to RFC 
1191 path MTU discovery?"  (Responses are grouped by area, not strict 
chronological order).

Anything that resembles link-layer tunneling is likely to be sensitive to 
MTU issues.

Steve Casner noted that RTP and media world makes assumption on UDP just 
having to use minimal size packets or accept fragmentation.  Since this BoF 
focusing on TCP so he is not sure how it might help his concerns.

Allison Mankin (not speaking as AD): RTTP might use DCCP, and DCCP might ask 
how it might chose link that it uses for TFRC's fixed length packet.  
RFC3489 STUN - NAT traversal tool, might have interesting 
interactions with MTU discovery. 

Reiner Ludwig pointed out that wireless handoff might result in 
different MTUs in different areas of the same network.  Can we address this 

Arron Falk pointed out that X-Bone, emulab and other overlay networks are 
sensitive to MTU issues.

Sally Floyd observed that some aspects of raising MTU sizes may 
potentially belong in another standards organization (implying IEEE).

It was pointed out that there are products on the market that ignore the DF 
bit (as a work around for RFC1191 problems).  How will these products 
interact with the new algorithm?

Spencer Dawkins raised the issue if long RTTs might interfere with the new 
algorithm (They are not believed to).  It is however critically 
important that lower layered deterministically discard packets that are too 

There were some worries about router and ISP upgrades.  Since the new 
algorithm does care about non-uniform MTU and does not require any new 
behaviors of the routers, this is also not believed to be a problem.

It was pointed out that there are several other communities that have 
considered MTU negotiation, but usually within a specific context (e.g. a 
wireless network), and not the open Internet.

Carriers are worried about scaling concerns with tunneling of MPLS.  How 
would this work for tunnels if you have a little script on the router that 
checks to see if all the MTU's are within bounds?  If I'm hopping around 
from system to system with different MTU's how will this help resolve the 

Reiner asked if probe packets contain dummy data or real data?
Carrying real data.

The closing discussion was about how to charter the work in the IETF:

Steve Casner thinks these issues raised here interact with other current 
TSVWG work and we should use TSVWG.

Allison responded saying she wanted to avoid discouraging 
participation by people in INT and other IETF areas since it involves the 
IPv6 efforts and OPS area too.  Unanticipated stuff clearly lurking here and 
she wants others to have input and to contribute.  TSVWG spends so much 
time on detailed TCP discussions that it would discourage 
participation by others.

John Loughney said that this is good work to take forward especially since 
he's seen lots of weird path MTU discovery efforts from the wireless 
world.  This is a good problem to solve for all networks wired and 

Allison asked if any of the prototype implementations were being used 
routinely.  They are not.   She added, it would be good to have users 
using the code as the documents being written.

Allison called a hum as to whether people think this is valuable work for 
the IETF.  There was overwhelming support (no opposing hums).  Matt 
should submit a charter to the IESG and IAB, and then send it out for 
comments on the IETF list.  Consensus of the wider community approves the 

There was general agreement that we need a better name than PLPMTUD.