State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza

2006-10-26

11

Jon Peterson

[Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson

2006-10-26

11

David Kessens

[Ballot discuss]In section '7.2. Selecting initial values'

It is RECOMMENDED that search_low be initially set to an MTU size that is likely ...

[Ballot discuss]In section '7.2. Selecting initial values'

It is RECOMMENDED that search_low be initially set to an MTU size that is likely to work over a very wide range of environments. Given today's technologies, a value of 512 bytes is probably safe. For IPv6 flows, a value of 1280 bytes is appropriate. The initial value for search_low SHOULD be configurable.

When 1280 was selected as the minimum MTU for ipv6, it was choosen because it was considered that there were no (reasonable) media thatcannot at least support a MTU of 1280 and that 1280 bytes was therefora 'safe value'. Why is it that this documentrecommends a different value for ipv4 while it really deals with thesame problem. Basically, why penalize short lived tcp connectionsover normal media for pathological cases ?

Combined with the following advice in section '7.3. Selecting probe size':

However, for some protocols, such as TCP, failed probes are more expensive than successful ones, since data in a failed probe will need to be retransmitted. For such protocols, a strategy that raises the probe size in smaller increments might have lower overhead.

it might take a long time before you reach the proper MTU size.

Considering that I would not qualify 'TCP' as 'some' protocol as itnormally is the majority of all traffic on any network this can havemajor consequences for the number of packets that need to be processedby all routers in the network, especially with a large number of short lived connections. In addition to this, the end-user experience mightsuffer as well. Obviously, this all depends on the exact algorithm choosenfor raising the probe size which is underspecified at best.

Did anybody do any research in this topic ? Did anybody run any simulations based on the actual traffic mix that we see on the Internet?

Without that (please correct me if I am wrong), I believe we cannot recommend this work as a Proposed Standard. Maybe experimental witha clear warning that it supposed to be used to research the issue, butnot for full scale deployment.

I also received a review by Pekka Savola from the Ops Directorate.

Please fix the first issue that he brings up or convince me that he is wrong ;-). See below for his full review:

The first one is probably Discuss unless some other AD picks it upfirst, the rest more editorial comments.

Section 5.4: " It is worth noting that classical PMTUD does not work at all as+ICMP PTB messages are never generated in response to packets with multicast destination addresses [RFC1112][RFC2460]."

==> while this is correct for v4, it is not true for v6. RFC1981specifically includes text on how to do PMTUDv6 with multicast.RFC2460 also includes discussion on how ICMP errors may be generatedin response to a multicast packet. See RFC 4443 section 2.4 clausee.3. So, while this error must be corrected, it can easily be done byjust rewording (or removing) this paragraph and no further changes arerequired.

Abstract is not very abstract. A shorter, single paragraph versionmight be better.

Section 4: "All Internet nodes SHOULD implement PLPMTUD ..", yet thedoc says that each protocol needs to have its own implementation ofPLPMTUD. So it's not quite clear what the above requirement means.That at least one of the protocols of the node should implementPLPMTUD?

Section 13.1, I-D.ietf-tsvwg-sctp-padding is a normative reference,but the state is still "AD watching". Hence this document will haveto wait in the RFC-ed queue.

2006-10-26

11

David Kessens

[Ballot Position Update] New position, Discuss, has been recorded by David Kessens

2006-10-26

11

Bill Fenner

[Ballot Position Update] New position, No Objection, has been recorded by Bill Fenner

[Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings

2006-10-25

11

Ross Callon

[Ballot Position Update] New position, No Objection, has been recorded by Ross Callon

2006-10-25

11

Mark Townsley

[Ballot comment]The abstract is very long. I recommend sticking with just the first paragraph, and moving the rest to an introduction section (eliminating redundant ...

[Ballot comment]The abstract is very long. I recommend sticking with just the first paragraph, and moving the rest to an introduction section (eliminating redundant information).

2006-10-25

11

Mark Townsley

[Ballot Position Update] New position, Yes, has been recorded by Mark Townsley

2006-10-25

11

Jari Arkko

[Ballot comment]> Some protocols may require additional packets after a loss to detect> it promptly (e.g., TCP loss detection using duplicate> ...

[Ballot comment]> Some protocols may require additional packets after a loss to detect> it promptly (e.g., TCP loss detection using duplicate> acknowledgments). Such a protocol SHOULD wait until sufficient data> and window space is available so that it will be able to transmit> enough data after the probe to trigger the loss detection mechanism> in the event of a lost probe.

It would be useful to have some additional suggestedparameters that guide how long such wait should be.

2006-10-25

11

Yoshiko Fong

IANA Last Call Comment:

As described in the IANA Considerations section, we understand this document to have NO IANA Actions.

2006-10-25

11

Brian Carpenter

[Ballot discuss]This is very welcome document and I hope this issuecan be quickly resolved:

> 5.2. Storing PMTU information...> ...

[Ballot discuss]This is very welcome document and I hope this issuecan be quickly resolved:

> 5.2. Storing PMTU information...> If IPv6 flows are in use, an implementation MAY use the IPv6 flow id> [RFC2460][RFC1809] as the local representation of a path. Packets> sent to a particular destination but belonging to different flows may> use different paths, with the choice of path depending on the flow> id. This approach will result in the use of optimally sized packets> on a per-flow basis, providing finer granularity than MTU values> maintained on a per-destination basis.

One problem here is that the informative reference to RFC 1809 needs tobe replaced by a normative reference to RFC 3697 (which updates 2460).

The second problem is that the flow label is not a routing tag.The second sentence is therefore very speculative. I believe the thirdsentence is misleading and should say something much more tentativesuch as "Such an approach could theoretically result...".

2006-10-25

11

Brian Carpenter

[Ballot Position Update] New position, Discuss, has been recorded by Brian Carpenter

2006-10-25

11

Jari Arkko

[Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko

2006-10-25

11

Dan Romascanu

[Ballot comment]I like the way this document (especially section 7) deals with operational and initial deployment considerations, analyzing carefully the impact of the usage ...

[Ballot comment]I like the way this document (especially section 7) deals with operational and initial deployment considerations, analyzing carefully the impact of the usage of the discovery method in the Internet.

2006-10-25

11

Dan Romascanu

[Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu

2006-10-24

11

Russ Housley

[Ballot comment]COMMENT

The Abstract seem a little bit long. Maybe it can be reworded to include less of the information that ...

[Ballot comment]COMMENT

The Abstract seem a little bit long. Maybe it can be reworded to include less of the information that is also in the Introduction.

2006-10-24

11

Russ Housley

[Ballot Position Update] New position, No Objection, has been recorded by Russ Housley

2006-10-24

11

Sam Hartman

[Ballot Position Update] Position for Sam Hartman has been changed to Yes from No Objection by Sam Hartman

2006-10-24

11

Sam Hartman

[Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman

2006-10-24

11

Magnus Westerlund

[Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund

2006-10-23

11

Ted Hardie

[Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie

2006-10-23

11

Lars Eggert

[Ballot Position Update] New position, Yes, has been recorded for Lars Eggert

2006-10-23

11

Lars Eggert

Ballot has been issued by Lars Eggert

2006-10-23

11

Lars Eggert

Created "Approve" ballot

2006-10-20

11

Lars Eggert

State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Lars Eggert

2006-10-19

11

(System)

State has been changed to Waiting for AD Go-Ahead from In Last Call by system

2006-10-16

11

Lars Eggert

Seen no significant LC comments so far, tentatively placing this on the agenda for the next telechat.

2006-10-16

11

Lars Eggert

Placed on agenda for telechat - 2006-10-26 by Lars Eggert

2006-09-28

11

Amy Vezza

Last call sent

2006-09-28

11

Amy Vezza

State Changes to In Last Call from Last Call Requested by Amy Vezza

2006-09-28

11

Lars Eggert

State Changes to Last Call Requested from AD Evaluation::AD Followup by Lars Eggert

2006-09-28

11

Lars Eggert

Last Call was requested by Lars Eggert

2006-09-28

11

(System)

Ballot writeup text was added

2006-09-28

11

(System)

Last call text was added

2006-09-28

11

(System)

Ballot approval text was added

2006-09-27

11

(System)

Sub state has been changed to AD Follow up from New Id Needed

2006-09-27

10

(System)

New version available: draft-ietf-pmtud-method-10.txt

2006-09-06

11

Lars Eggert

State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Lars Eggert

State Changes to AD Evaluation from Publication Requested by Lars Eggert

2006-09-05

11

Dinara Suleymanova

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the InternetDraft (ID), and in particular, do they believe this ID is ...

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the InternetDraft (ID), and in particular, do they believe this ID is readyto 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 membersand key non-WG members? Do you have any concerns about thedepth or breadth of the reviews that have been performed?

The document has had considerable review by the working group over itseight revisions, and the comments have been incorporated in thecurrent draft. Reviewers have had background in TCP, SCTP, DCCP,the use of tunnels (ipsec and other) and IPv6. The current versionhas had four careful reviews that only revealed nits, and are fixedin 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 aparticular (broader) perspective (e.g., security, operationalcomplexity, someone familiar with AAA, etc.)?

No.

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

No.

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

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

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

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

No.

1.i) For Standards Track and BCP documents, the IESG approvalannouncement includes a write-up section with the followingsections:

* Technical Summary

* Working Group Summary

* Protocol Quality

1.j) Please provide such a write-up. Recent examples can be found inthe "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) thatrelies on TCP or some other Packetization Layer to probe an Internetpath with progressively larger packets. This method is described asan extension to RFC 1191 and RFC 1981, which specify ICMP based PathMTU Discovery for IP versions 4 and 6, respectively.

The general strategy of the new algorithm is to start with a smallMTU and search upward, testing successively larger MTUs by probingwith single packets. If a probe is successfully delivered then theMTU can be raised. If the probe is lost, it is treated as an MTUlimitation and not as a congestion signal.

PLPMTUD introduces some flexibility in the implementation ofclassical Path MTU discovery. If can be configured to perform justICMP black hole recovery to increase the robustness of classical PathMTU Discovery, or at the other extreme, all ICMP processing can bedisabled and PLPMTUD can completely replace classical Path MTUDiscovery.

Working Group Summary:

The working group feels that an update to path MTU discovery is neededto rectify problems with current "classical" path MTU discovery thatoccur in today's network deployments (which result in Path MTU "blackholes", and the failure of not only the algorithm but often the entireconnection). The document has had considerable review by the workinggroup over its eight revisions, and the comments have beenincorporated in the current draft. Reviewers have had background inTCP, SCTP, DCCP, the use of tunnels (ipsec and other) and IPv6. TheWGLC version has had four careful reviews that only revealed nits andclarifications 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 transportprotocol. Previous versions have had implementation in Linux, NetBSD,and FreeBSD, by different people, resulting in comments that contributedto document changes. Other operating systems vendors and tunnel vendorshave reviewed the document.

2006-09-05

11

Dinara Suleymanova

State Changes to Publication Requested from AD is watching by Dinara Suleymanova