[pmtud] Request for publication of draft-ietf-pmtud-method-09.txt as a proposed standard

Matthew J Zekauskas <matt@internet2.edu> Fri, 01 September 2006 10:58 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ6j0-0001bf-85; Fri, 01 Sep 2006 06:58:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ6iy-0001bZ-Kk; Fri, 01 Sep 2006 06:58:12 -0400
Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ6iy-0001OK-7a; Fri, 01 Sep 2006 06:58:12 -0400
Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 0264C47D20; Fri, 1 Sep 2006 06:58:12 -0400 (EDT)
Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32182-07; Fri, 1 Sep 2006 06:58:11 -0400 (EDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 4C85947C7D; Fri, 1 Sep 2006 06:58:10 -0400 (EDT)
Message-ID: <44F8123E.1070503@internet2.edu>
Date: Fri, 01 Sep 2006 06:58:06 -0400
From: Matthew J Zekauskas <matt@internet2.edu>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Lars Eggert <lars.eggert@netlab.nec.de>, Magnus Westerlund <magnus.westerlund@ericsson.com>, iesg-secretary@ietf.org
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by mail.internet2.edu virus scanner
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7
Cc: Matt Mathis <mathis@psc.edu>, pmtud@ietf.org, Matt Zekauskas <matt@internet2.edu>, John Heffner <jheffner@psc.edu>
Subject: [pmtud] Request for publication of draft-ietf-pmtud-method-09.txt as a proposed standard
X-BeenThere: pmtud@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Maximum Transmission Unit Discovery <pmtud.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pmtud>, <mailto:pmtud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pmtud>
List-Post: <mailto:pmtud@ietf.org>
List-Help: <mailto:pmtud-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pmtud>, <mailto:pmtud-request@ietf.org?subject=subscribe>
Errors-To: pmtud-bounces@ietf.org

The Path MTU Discovery WG requests publication of
draft-ietf-pmtud-method-09.txt, "Packetization Layer Path MTU
Discovery", as a proposed standard.

Below is the questionnaire and protocol writeup requested as part of the
"PROTO" process. [Interested group members can reference
 draft-ietf-proto-wgchair-doc-shepherding-05.txt
 for details on the document shepherding process.]


--Matt Zekauskas, PMTUD co-chair

-=-=-=-

Shepherd Note for draft-ietf-pmtud-method-09.txt
   "Packetization Layer Path MTU Discovery"

Shepherd: Matt Zekauskas <matt@internet2.edu>


QUESTIONNAIRE:

   1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes.  Note that the other chair is an author.

   1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

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 current version
has had four careful reviews that only revealed nits, and are fixed
in this version.  I have no concern about the depth or breadth of reviews.

   1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

   1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.

   1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

I believe the working group as a whole understands and agrees with
it.  There are a few vocal proponents, but it has had wide review
and discussion within the working group, both on the list and at
working group meetings.

   1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

No.

   1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes.

   1.h) Is the document split into normative and informative references?

Yes.
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

No.


   1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality

   1.j) Please provide such a write-up.  Recent examples can be found in
        the "protocol action" announcements for approved documents.

[[1.k (explanation of the writeup) elided for brevity]]



PROTOCOL WRITEUP:

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.


_______________________________________________
pmtud mailing list
pmtud@ietf.org
https://www1.ietf.org/mailman/listinfo/pmtud