Path Maximum Transmission Unit Discovery PWG (pmtud) 

Thursday, July 17 at 1300-1500
===============================


CHAIRS: Matt Mathis <mathis@psc.edu>
        Matt Zekauskas <matt@internet2.edu>


AGENDA:

    Preliminaries: Blue sheets, Note takers, Agenda bashing, etc


    Status of the preWG and becoming a full WG


    Status and plans for advancing the Internet-Draft
        (Additional contributors welcome)


    Short history and work to date


    Robustness issues (technical discussion)
        - What happens if DF is not honored?
        - What can be done if raising MTU causes losses (3 cases)?
        - What to do on hard (repeated) timeouts?
        - Can we anticipate any other failures?


    Identifying additional stakeholders
        - Other protocols that want to know about hard timeouts
        - Clashing technologies (e.g. ignore DF)
        - Identify possible early adopters


    Mailing list changeover


Documents:
    draft-mathis-pmtud-method-00.txt, "Path MTU Discovery"


        This document ibes Path MTU Discovery for the
        Internet. It is largely derived from RFC 1191 and RFC
        1981, which describe ICMP based Path MTU Discovery for
        IP versions 4 and 6, plus a robust new algorithm.


 Description of Working Group:


 The goal of the PMTUD working group is to specify a robust method for
 determining the IP Maximum Transmission Unit supported over an
 end-to-end path. This new method is expected to update most uses of
 RFC1191 and RFC1981, the current standards track protocols for this
 purpose. Various weakness in the current methods are documented in
 RFC2923, and have proven to be a chronic impediment to the deployment
 of new technologies that alter the path MTU, such as tunnels and new
 types of link layers.


 A new method proposed and supported strongly in the BOF does not rely
 on ICMP or other messages from the network. It finds the proper MTU
 by starting a connection using relatively small packets (e.g. TCP
 segments) and searching upwards by probing with progressively larger
 test packets (containing application data). If a probe packet is
 successfully delivered, then the path MTU is raised. The isolated
 loss of a probe packet (with or without an ICMP can't fragment
 message) is treated as an indication of a MTU limit, and not a
 congestion indicator.


 The working group will determine if there is consensus to pursue this
 method, and if there is, will specify the method for use in TCP,
 SCTP, and will outline what is necessary to support the method in
 transports such as DCCP. It will particularly describe the precise
 conditions under which lost packets are not treated as congestion
 indications.  The work will pay particular attention to details that
 affect robustness and security.


 Path MTU discovery has the potential to interact with many other parts
 of the Internet, including all link, transport, encapsulation and
 tunnel protocols. Thereforethis working group will particularly
 encourage input from a wide cross section of the IETF to help to
 maximize the robustness of path MTU discovery in the presence of
 pathological behaviors from other components.