[pmtud] Fwd: Protocol Action: 'Packetization Layer Path MTU Discovery' to Proposed Standard

[Lars Eggert <[e-mail]>]

Congratulations!

Begin forwarded message:

> From: The IESG <[e-mail]>
> Date: December 11, 2006 6:43:12 PM GMT+01:00
> To: IETF-Announce <[e-mail]>
> Cc: pmtud chair <[e-mail]>, Internet  
> Architecture Board <[e-mail]>, RFC Editor <rfc-editor@rfc- 
> editor.org>
> Subject: Protocol Action: 'Packetization Layer Path MTU  Discovery'  
> to Proposed Standard
>
> The IESG has approved the following document:
>
> - 'Packetization Layer Path MTU Discovery '
>    <draft-ietf-pmtud-method-11.txt> as a Proposed Standard
>
> This document is the product of the Path MTU Discovery Working Group.
>
> The IESG contact persons are Lars Eggert and Magnus Westerlund.
>
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-11.txt
>
> Technical Summary
>
> This document describes a robust method for Path MTU Discovery
> ("Packetization Layer Path MTU Discovery" or PLPMTUD) that
> relies on TCP or some other Packetization Layer to probe an Internet
> path with progressively larger packets. This method is described as
> an extension to RFC 1191 and RFC 1981, which specify ICMP based Path
> MTU Discovery for IP versions 4 and 6, respectively.
>
> The general strategy of the new algorithm is to start with a small
> MTU and search upward, testing successively larger MTUs by probing
> with single packets. If a probe is successfully delivered then the
> MTU can be raised. If the probe is lost, it is treated as an MTU
> limitation and not as a congestion signal.
>
> PLPMTUD introduces some flexibility in the implementation of
> classical Path MTU discovery. If can be configured to perform just
> ICMP black hole recovery to increase the robustness of classical Path
> MTU Discovery, or at the other extreme, all ICMP processing can be
> disabled and PLPMTUD can completely replace classical Path MTU
> Discovery.
>
>
> Working Group Summary
>
> The working group feels that an update to path MTU discovery is needed
> to rectify problems with current "classical" path MTU discovery that
> occur in today's network deployments (which result in Path MTU "black
> holes", and the failure of not only the algorithm but often the entire
> connection). The document has had considerable review by the working
> group over its eight revisions, and the comments have been
> incorporated in the current draft. Reviewers have had background in
> TCP, SCTP, DCCP, the use of tunnels (ipsec and other) and IPv6. The
> WGLC version has had four careful reviews that only revealed nits and
> clarifications that are fixed in this version.
>
>
> Protocol Quality
>
> The current protocol has one implementation in Linux, by a co-author,
> and another independent implementation in a user-space transport
> protocol. Previous versions have had implementation in Linux, NetBSD,
> and FreeBSD, by different people, resulting in comments that  
> contributed
> to document changes. Other operating systems vendors and tunnel  
> vendors
> have reviewed the document.
>
> Matt Zekauskas ([e-mail]) acted as Document Shepherd.
>
> Lars Eggert ([e-mail]) has reviewed this document for the
> IESG.
>
>
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

Lars


_______________________________________________
pmtud mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pmtud