[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

PMTUD charter



Purpose of the changes was to address WG Review comments to make the
charter more open to other solutions if proposed - mailing list has
agreed to the new wording.    If there is no objection from the IESG, this
WG is approved.  Comments?  

Allison

  		o Path Maximum Transmission Unit Discovery
		Token: Allison

		Allison Mankin will provide a revised charter to the IESG for review. 
		The Secretariat will send a WG Action Announcement when Allison Mankin 
		confirms that the IESG has approved the new charter.

 
 Path Maximum Transmission Unit Discovery (pmutd)

 Chair(s):

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

 Area Advisor:
 Allison Mankin <mankin@psg.com>


Mailing Lists:
General Discussion: pmtud@ietf.org
To Subscribe: pmtud-request@ietf.org
In Body: subscribe
Archive: www.ietf.org/mail-archive/working-groups/pmtud/current/maillist.html


 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.  If developing the transport method, it will specify the use
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 of the method in TCP and 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. Therefore this 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.

 Input draft: 

                 Packetization Layer Path MTU Discovery
                 draft-mathis-pmtud-method-00.txt

 Goals and Milestones:

 Jul 03 Reorganized Internet-Draft. Solicit implementation and field experience.

 Dec 03 Update Internet-Draft incorporating implementers experience,
               actively solicit input from stakeholders - all communities that might
               be affected by changing PMTUD.

 Feb 04 Submit completed Internet-draft and a PMTUD MIB draft for 
               Proposed Standard.