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. Summary: 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 situation? 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 big. 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 issues? 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 wireless. 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 charter. There was general agreement that we need a better name than PLPMTUD. |