Packetization Layer Path MTU Discovery
draft-ietf-pmtud-method-11

[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 ...

[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 that
cannot at least support a MTU of 1280 and that 1280 bytes was therefor
a 'safe value'. Why is it that this document
recommends a different value for ipv4 while it really deals with the
same problem. Basically, why penalize short lived tcp connections
over 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 it
normally is the majority of all traffic on any network this can have
major consequences for the number of packets that need to be processed
by all routers in the network, especially with a large number of short lived connections. In addition to this, the end-user experience might
suffer as well. Obviously, this all depends on the exact algorithm choosen
for 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 with
a clear warning that it supposed to be used to research the issue, but
not 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 up
first, 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.  RFC1981
specifically includes text on how to do PMTUDv6 with multicast.
RFC2460 also includes discussion on how ICMP errors may be generated
in response to a multicast packet.  See RFC 4443 section 2.4 clause
e.3.  So, while this error must be corrected, it can easily be done by
just rewording (or removing) this paragraph and no further changes are
required.

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

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

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

[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).

[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 ...

[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 suggested
parameters that guide how long such wait should be.

[Ballot discuss] This is very welcome document and I hope this issue can be quickly resolved: > 5.2. Storing PMTU information ... > If IPv6 flows are ...

[Ballot discuss]
This is very welcome document and I hope this issue
can 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 to
be 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 third
sentence is misleading and should say something much more tentative
such as "Such an approach could theoretically result...".

PROTO Write-up 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ...

PROTO Write-up

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.