2.8.11 Path MTU Discovery (pmtud)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-06

Chair(s):

Matt Mathis <mathis@psc.edu>
Matthew Zekauskas <matt@internet2.edu>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Allison Mankin <mankin@psg.com>

Mailing Lists:

General Discussion: pmtud@ietf.org
To Subscribe: pmtud-request@ietf.org
In Body: In Body: subscribe email_address
Archive: http://www.ietf.org/mail-archive/web/pmtud/index.html

Description of Working Group:

The goal of the PMTUD working group is to specify a robust method for
determining the IP Maximum Transmission Unit supported over an
end-to-end path. This new method is expected to update most uses of
RFC1191 and RFC1981, the current standards track protocols for this
purpose. Various weakness in the current methods are documented in
RFC2923, and have proven to be a chronic impediment to the deployment
of new technologies that alter the path MTU, such as tunnels and new
types of link layers.
                                                                     
                   
The proposed new method does not rely on ICMP or other messages from
the network. It finds the proper MTU by starting a connection using
relatively small packets (e.g. TCP segments) and searching upwards by
probing with progressively larger test packets (containing application
data). If a probe packet is successfully delivered, then the path MTU
is raised. The isolated loss of a probe packet (with or without an
ICMP can't fragment message) is treated as an indication of a MTU
limit, and not a congestion indicator.
                                                                     
                   
The working group will specify the method for use in TCP, SCTP, and
will outline what is necessary to support the method in transports
such as DCCP. It will particularly describe the precise conditions
under which lost packets are not treated as congestion indications.
The work will pay particular attention to details that affect
robustness and security.
                                                                     
                   
Path MTU discovery has the potential to interact with many other parts
of the Internet, including all link, transport, encapsulation and
tunnel protocols. Thereforethis working group will particularly
encourage input from a wide cross section of the IETF to help to
maximize the robustness of path MTU discovery in the presence of
pathological behaviors from other components.
                                                                     
                   
Input draft:
                                                                     
                   
                Packetization Layer Path MTU Discovery
                draft-mathis-plpmtud-00.txt

Goals and Milestones:

Done  Reorganized Internet-Draft. Solicit implementation and field experience.
Done  Update Internet-Draft incorporating implementers experience,
Feb 2005  Submit completed Internet-draft and a PMTUD MIB draft for Proposed Standard.

Internet-Drafts:

  • draft-ietf-pmtud-method-05.txt

    No Request For Comments

    Current Meeting Report

     
    Path MTU Discovery WG (pmtud)
Monday, 7 November 2005, 18:50--19:50
=====================================

CHAIRS: Matt Mathis 
        Matt Zekauskas 

(Jabber) Scribe: Michael Richardson

These minutes were generated by the Chairs from notes taken by 
Michael Richardson and Matt Zekauskas.

AGENDA:

1. Agenda bashing, milestones review
2. PMTUD method draft update and issue summary
3. draft-templin-linkadapt-01.txt - should it be a pmtud item?
    (dynamically-generated item)
4. Remaining Issues



1. Agenda bashing, milestones review

Matt Z opened the meeting reviewing the agenda, and milestones.
We think we're close to the end of the second milestone (revise draft based
on stakeholder feedback and implementation experience).  We need to come
to closure and submit the method draft along with a MIB document.
John Heffner is working on a Linux implementation that follows the
current draft; when that is done and the one or two remaining technical
issues resolved, we should be ready to submit the method draft.




2. PMTUD method draft overview
   --John Heffner

John Heffner gave a presentation on the rewrite of the method draft.
The changes were all to make it simpler, and relax things that were
overspecified.  There's only a small part that needs to be in
standards language -- when it is OK to ignore loss as a congestion
signal.  Most of the text describes heuristics.  The algorithm is now
strictly an extension to classical PMTUD: there are no changes to ICMP
processing specified, the probing algorithm has been decoupled from
verification, and the terminology has been simplified.

Historically, the drafts have had a lot of ICMP verification.  However,
this wasn't strictly necessary, and it dovetailed with work Fernando Gont
has been doing more generally with ICMP.  Thus it was all removed from
this draft, which simplifies the text considerably.  The old text could
be made into a separate document, or combined with Fernando's work.

The other major change was to decouple verification from probing; this
was discussed a bit in Minneapolis, and the idea is based on
implementation experience.  By decoupling verification from probing,
an implementation could potentially probe with larger and larger
packets every RTT, and keep pace with slow-start.  It makes
discovering a large MTU quite fast.  It also simplifies the
description; there can now be two independent state machines.  It also
allows for evolution and innovation in verification; the authors feel
that the current verification method could be improved.

Finally, the notion of maximum packet size was removed, and all descriptions
are in terms of MTU.  This implies that the packetization protocol must
now know the total packet sizes sent out (including IP headers).  However,
how it knows is no longer specified.

John then described a Linux implementation he is working on that
follows the current draft.  It currently has no verification phase,
he's adding that back in.  He did add a black hole discovery mechanism
that allows an implementation to start with a large MTU, and only
"probe up" (that is, fall back to a small MTU and then probe for larger
and larger values) if the initial MTU is too big.  He's also working
on the proper caching of state.

Fernando Gont asked about starting with large packets, and is there
any guidance for implementers?  John replied that the general point is
that if you expect large packets won't work, then start with a small
MTU and probe for larger values.  If you expect them to work in the
common case, then start with a large MTU.

Fernando also commented on the difficulty of TCP (or any other
packetization protocol) finding the complete size of packets with
headers.  He noted that in BSD-derived systems, at least, it is not
difficult.  John stated that in all stacks, you know the maximum
packet size; the issue is if the packetization layer knows the length
of the particular packet.  He noted that in general, you know how much
is reserved, not how much is used.  Matt Mathis pointed out the real
issue for PMTUD is that the probe will fail if it's not padded out the
proper length, including headers.  In particular, if options are used
there could be a problem.

Fernando also offered to create an implementation in OpenBSD.  John
(and Matt) thought it would be an excellent contribution; Kevin Lehey
did an very early implementation for netbsd, and a new current
implementation would be appreciated (as would comments based on
the implementation).

Matt Mathis started a discussion around one of the open technical issues
in the draft: how often should you probe to see if the MTU has been raised
along a path.   The draft currently says five minutes, but that value
was somewhat arbitrary.  Matt wondered if anyone has insights into
existing precedent or a rational way of picking a number.
Michael Richardson thought 5 minutes sounded about right, and in
any case it should be greater than the 2 minute TCP timeout; he
also thought it should not be larger than the typical damping interval
for BGP.  John Heffner commented that ten minutes is commonly used for
values in route caches.  Fernando Gont suggested a strategy being considered
for OpenBSD: base the probe interval based on the current MTU size.  If the
size is small, probe more frequently; if the value is large (and still
working) use a larger timeout.  Matt asked if Fernando considered 1500
large or small.  Fernando thought "small", and a "large" value might
be something greater than 6000 right now; a value of 10 to 15 minutes
might be appropriate there.  Dave Thalor noted that since the draft
is now an extension of "PMTUD classic", RFC 1981 says 10 minutes,
so that's a value that you would not have to defend.




3. draft-templin-linkadapt-01.txt

Fred Templin came in late, but wanted to bring up one of his drafts,
draft-templin-linkadapt-01.txt.  As we currently understand it, this
draft discusses having IPv6 tunnel endpoints know the size of the MTU
for the IPv4 tunnel, so that they can respond correctly.  Thus, the
endpoints would run PMTUD on the tunnel itself.  This generated
discussion to see what the draft proposed, and try to understand the
nature of Fred's request, which we believe is: "is this draft in-scope
for PMTUD?".

Dave Thalor noted that this draft tries to solve the same problem, as
the current draft, but for IPv6 tunnel over IPv4 endpoints.  It was
noted that there are cases where an IPv4 packet might or might not
have the DF bit set; and even then there is the problem noted in
earlier meetings that IPsec allows an IPsec tunnel to fragment packets
and reassemble them at tunnel exit.  In any event, the tunnel entry
would like to send back an appropriate ICMP packet too big response.

Dave Thalor felt that the draft is certainly of interest to working
group members, but wasn't sure if it was in scope.

Matt Mathis thought that the current outline of what to do with
transports such as DCCP would be applicable to tunnels.  He also
noted that he felt pressure to get the current draft done, and didn't
want to broaden scope before we were done.  Whether we should consider
it for the group will require AD discussion, and we should remain
mindful that there is a lot of desire to get the current working
group draft done.




4. Remaining Issues

Dave Thalor asked about a more specific plan to get the MIB
written.  Matt Mathis asked for volunteers to help specify the MIB
(no one stepped forward in the meeting -- the chairs will ask again on the
mailing list).  One issue that Matt Mathis hasn't solved is what to use for an
index; you want something like a protocol-independent connection ID.
It's a bit more granular than what is in existing host MIB RFCs, since
it potentially specifies a particular flow.  Perhaps it should be an
extension to the IP MIB if the contents are (transport) protocol independent.

Fernando Gont asked about the ICMP text that was taken out of the -05
version of the draft; John Heffner mentioned that it could go in another
more general ICMP advice draft.   Matt and John said that they have no
concrete plans to pursue this at this time; there are some really good
ideas that are only embodied in Internet Drafts and they deserve a more
permanent home.  The current focus is in finishing the milestones.

With that the meeting ended.

    Slides

    Agenda
    Path MTU Discovery Method Update