[pmtud] Minutes for PMTUD at IETF60

[Matthew J Zekauskas <matt at internet2.edu>]

Attached.  In addition, these minutes and all presentations
are available off of
http://people.internet2.edu/~matt/pmtud/meetings/ietf60/

--Matt
Path MTU Discovery WG (pmtud)
Tuesday, August 3, 2004 at 14:15 to 15:15
=========================================
The meeting was chaired by Matt Zekauskas and Matt Mathis.
Dave Thalor was the Jabber scribe.  These minutes are edited from
notes taken by Aaron Falk.

AGENDA:

1. Agenda Bashing, Milestones Status

2. Packet-Level Path MTU Discovery Method update
   http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-02.txt
   Additional background reading:
   http://www.ietf.org/internet-drafts/draft-richardson-ipsec-fragment-01.txt

3. Datagram Transport Layer Security

4. MTU and Fragmentation Issues with In-the-network Tunneling

5. Path MTU Discovery Using Options
   http://www.ietf.org/internet-drafts/draft-welzl-pmtud-options-01.txt

6. Packet-Level Path MTU Discovery implementation experiences

7. If Time Available: Fragmentation Considered Very Harmful
   http://www.ietf.org/internet-drafts/draft-mathis-frag-harmful-00.txt
   Slides are at http://www.psc.edu/~mathis/papers/frag200408




1. Agenda Bashing, Milestones Status

Matt Zekauskas opened the meeting.  There were no additional agenda
changes requested.

   - Milestones:
     * DONE: reorganized ID incorporating  implementers experience.
     * Aug 04: update ID, solicit feedback from communities affected
         we feel this is done.
     * Jan 05: Is the current target for a draft to the IESG.  One issue
         is the MIB: there really isn't a single MIB for this technique,
         but more that each protocol would have entries in its MIB.
         The current draft has language about what protocols must
         provide to allow debugging; that's the basis for items that
         should be included in individual MIBs.





2. Packet-Level Path MTU Discovery Method update
   -- Matt Mathis

Matt began with an algorithm review: start with 1k MTU, test larger MTUs
by probing with larger packets, verify provisional MTU for 1 RTT.  Most of
the algorithm runs in the transport layer but you want to keep cached/shared
state in the IP layer.  Matt showed a trace from an implementation.

The key properties of packetization-layer PMTUD: not designing a protocol, 
but making use of existing features of protocols.  Careful thought has
been placed into maximizing robustness.  Implementation differences don't
affect interoperability; it's a sender-side change only.

There is now a new unofficial status page:
     http://www.psc.edu/~mathis/MTU/pmtud/index.html.
Included is a pointer to the draft, and both this page and the draft
give the latest updates in "real time".

The changes from -01 to -02: Three are no significant changes to algorithms;
the text has been restructured for cleaner layer separation, and to make
the document much less TCP-centric.   TCP may be harder than most protocols
in that it has no way to mark out-of-band data.  There is new text on SCTP.

Robustness issues: there is added discussion of "full stop timeouts",
and we removed state machine to detect pMTU discovery induced failures.
Devices that ignore DF remain the big worry.

New Topics added: Tunnels discussion with sermon on not ignoring
DF, subnets with non-uniform MTU, recommendation that IPv4 fragmentation
be used in a mode that emulates IPv6 fragmentation.

Christian Huitema said that he was getting feedback from an implementer
that there is tension between wanting to retain incentive to fix broken
traditional ICMP MTU discovery and develop a new solution (plPMTUD).
Matt noted that the traditional way is a layer violation, and that
it was permanently broken and won't be fixed. Christian responded that
a working ICMP-based pmtud is very valuable when there are tunnels
on the path.  Many tunnel endpoints don't copy DF bit in the outer header.

Joe Touch thought that the text was missing the concepts of "passive" and
"bidirectional".  Without a bidirectional ULP, you'll never get
the information back you need.  Also, this draft breaks layers
all over the place (so don't throw stones at ICMP).  He also felt that
it is a protocol.  Just because you don't set a tag in a header,
doesn't mean you don't have a protocol.  But, he is more
comfortable with this solution then the ICMP solution.  Joe noted
that it will be hard to make every implementation respect the
DF bit: RFC2401 (a draft standard) says it's OK for implementations
to clear the DF bit.

Magnus Westerlund noted that this pMTUd method has the advantage of
moving the detection up the stack.  Although you can't do it with
generic one-way UDP, RTP RTCP can do it.

Andrew McGregor asked how does this play with middleboxes which play
with maximum segment size as TCP negotiation goes by?  Matt said that
those middleboxes in effect create an upper bound.

Dave Thaler reiterated that ICMP is mandatory for IPv6, and there is
no DF bit.  That's an incentive to fix.  On the other hand, perhaps
UDP-like applications will inappropriately start using TCP with plPMTUD,
rather than providing an incentive to fix the infrastructure.

Fred Templin thought that this probed for the maximum segment size, rather
than maximum MTU, and we might end up with too large value.  Matt 
Mathis clarified the issue: segment size is the natural unit for TCP.
The plPMTUD layering needs to translate between MSS and MTU.  The 
primary difficulty of the draft is describing this translation
clearly everywhere it is needed.


Back to the presentation, Matt noted that we need a section for "every"
packetization layer, including all future protocols.  Perhaps we need 
a list of questions to be answered for every packetization layer?

Joe said that it seems awkward to do this at every packetization layer.
Matt said that's why he's looking for common questions.  Joe argued
that we should just add an API to a, e.g., congestion manager, to determine
the correct MTU -- simpler, cleaner, controllable, and reusable.

Stanislav Shalunov pointed out an analogy between PMTUD and congestion
control.  The same considerations apply to a large extent.  Whether "source
quench" or "fragmentation needed", and hosts inferring congestion from losses:
reduction is required at the sender.  The same layering violation
discussion applies, and the same reuse discussion applies.

Steve Casner noted that RTP doesn't have the same answer for all
codecs/payloads.  So, it is hard to come up with common answer.
Also, an adjunct protocol may not get same answer as primary
protocol, so it may come up with wrong answer.




3. Datagram Transport Layer Security (DTLS)
   -- Eric Rescorla

Eric is working on a version of TLS that works on UDP.  Protocol flow is
the same as for TLS.  Data is sent in DTLS records, which are large.
The handshake is 2-3 RTs contains certificates, 500-1000 bytes per certificate
(possibly many certificates per message).  Application data transfer can
contain records up to 2^14 bytes -- which obviously is larger than most PMTUs.

Aaron Falk asked if application records were all the same size.  Eric
said that there was no need to have them all be the same size;
one could use small packets for handshake then discover during data
exchange.

Matt Mathis asked how often do you talk to same node?  Eric said that the
same nodes communicated often for brief time.

Matt Mathis and Eric will talk more about this.





4. MTU and Fragmentation Issues with In-the-network Tunneling
   -- Pekka Savola

There are a number of different tunneling protocols (e.g., IP-IP,
GRE, L2TP, IPv6-in-IPv4).  Many of those are used in router-to-router
tunneling; all these protocols need to discuss and address the same issues.
This document aims to spell out the issues and describe the options.
Issues with tunneling in the "core" are quite tricky.  Four different
solutions, none of which is good for all cases.

Matt Z asked everyone to please read the draft,  comments to list are
appropriate.




5. Path MTU Discovery Using Options
   -- Michael Welzl

In the end, pMTUd always loses a packet. It would be nice to avoid
this.  In addition, the algorithm should converge fast.  Thus, this
proposes adding a mechanism to converge faster without loss.
Algorithm: before doing pMTUd, include "Provide MTU" IP option, which
routers mark.  The receiver feeds back result to source.
Implementation results shown.  There are some known problems with IP
options: slow path processing and some routers drop packets with
unknown IP options.  Added delay increased by 24% in measurements.
25% of hosts did not respond when there was an IP option.  Clearly not
recommendable for each TCP connection.  Also some security issues:
falsification of MTU value or number of routers.  Recommended mainly
for "special" scenarios.  See

     http://www.welzl.at/research/projects/ip-options/

Mark Allman shared some of his measured data: 98% of 80,000 web servers
reachable, 70% not reachable with unknown option.  With IP record
route option 34% of the servers were not reachable.  With the IP
timestamp option (?), 43% of the servers were not reachable.

Joe Touch said that he liked explicitness of solution but this may
suffer from same problems as ICMP.  Assumption is that processing IP
options is faster than ICMP.  Need mechanisms which ensure that an
overloaded router doesn't have to do more work.  (Have more
suggestions offline.)  See draft-touch-tcp-antispoof: nonces don't
give security, they only protect against off-path attacks.

Phil Karn noted that in the real world a ICMP "message to large" is
never generated most of the time, since local link sets MTU.  So, this
solution only adds overhead.

Krishnan noted a problem with the TTL check proposed in the draft: while
the probability of guessing TTL is less than one in 256, most OS's
set it to some known lower value (32, 64).  It's not random.  So the
window in which you need to guess becomes much smaller.

Matt Z asked if this should become a working group item.

"How many people are interested in having this become a wg item?":  none

"not interested":  clear hum

In order to get us interested, you would need to establish why this
solution is clearly better than ICMP.




6. Packet-Level Path MTU Discovery implementation experiences

Rao Shoaib commented on experience (so far) implementing the algorithm 
in Solaris.

* The draft requirement that TCP not start plPMTUD until it holds
    three packets of data is overly restrictive and too hard to
    implement.  If you're already congested or throttled, you 
    don't want to wait for three packet times.

* A generic solution for all protocols, and not just one per protocol
    would be a better idea.

* The draft should describe the increments for probing, i.e., why not
   suggest well-known MTUs?

Due to lack of time the meeting was adjourned without discussing the
last time.

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