[pmtud] comments and discusses on draft-ietf-pmtud-method-10

Lars Eggert <lars.eggert@netlab.nec.de> Thu, 26 October 2006 16:31 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd890-00038y-N2; Thu, 26 Oct 2006 12:31:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd88y-00038Y-LY; Thu, 26 Oct 2006 12:31:48 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd88u-0002sA-5B; Thu, 26 Oct 2006 12:31:48 -0400
Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 90A4320031DE; Thu, 26 Oct 2006 18:32:14 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLNh+spl4FQy; Thu, 26 Oct 2006 18:32:14 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6E21D2000168; Thu, 26 Oct 2006 18:32:14 +0200 (CEST)
Received: from n-eggert.office ([10.1.1.112]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 18:31:43 +0200
Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id 6DDBC25D7B9; Thu, 26 Oct 2006 18:31:42 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v752.2)
To: pmtud-chairs@tools.ietf.org, jheffner@psc.edu, pmtud@ietf.org
Message-Id: <972FA678-B6CB-44FD-BEC2-B7DED47A7703@netlab.nec.de>
From: Lars Eggert <lars.eggert@netlab.nec.de>
Date: Thu, 26 Oct 2006 18:31:40 +0200
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 26 Oct 2006 16:31:43.0534 (UTC) FILETIME=[38E17CE0:01C6F91C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8
Cc: IESG Group <iesg@ietf.org>
Subject: [pmtud] comments and discusses on draft-ietf-pmtud-method-10
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>
Content-Type: multipart/mixed; boundary="===============1541713747=="
Errors-To: pmtud-bounces@ietf.org

Hi,

draft-ietf-pmtud-method-10 has gathered some discusses and comments  
during IESG evaluation. The most serious one is probably David  
Kessens'. I encourage the authors to try and resolve these with the  
discussing ADs.

Lars

Jari Arkko:
Comment:
[2006-10-25] > 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.

Brian Carpenter:
Discuss:
[2006-10-25] 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...".

Bill Fenner:
Comment:
[2006-10-25] Normative reference to draft-ietf-tsvwg-sctp-padding may  
cause delay.

Russ Housley:
Comment:
[2006-10-24]
   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.

David Kessens:
Discuss:
[2006-10-26]
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.

Dan Romascanu:
Comment:
[2006-10-25] 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.

Mark Townsley:
Comment:
[2006-10-25]
The abstract is very long. I recommend sticking with just the first  
paragraph, and moving the rest to an introduction section  
(eliminating redundant information).

-- 
Lars Eggert                                     NEC Network Laboratories


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