[pmtud] (draft) Minutes from pmtud at IETF61

If anyone has a comment, we'd appreciate it on the pmtud list
or to the chairs soon.  These will also be available off of
<http://people.internet2.edu/~matt/pmtud/meetings/ietf61/>.

--Matt
=================================================================

Path MTU Discovery WG (pmtud)
Tuesday, November 9, 2004 at 13:00 to 14:00
===========================================
The meeting was chaired by Matt Zekauskas and Matt Mathis.
These minutes are edited from notes taken by Jeff Dunn and
John Heffner.

AGENDA:

1. Agenda Bashing, Milestones Status
2. PMTUD draft update
3. Fragmentation considered very harmful

PMTUD Draft Update
   -- Matt Mathis
   draft-ietf-pmtud-method-03.txt

Matt noted that lots changed, based on a huge amount of input from
the working group.  He started with a quick algorithm overview (see
slides) and then noted the changes based on the feedback so far.
Major feedback included making the method (transport) protocol independent,
and the results of the questionnaire on different protocols sent
sent to the mailing list.  There is a large amount of commonality
for all transport protocols, and the document has been restructured.
>From beginning this effort has focused on increasing PMTUD robustness,
and part of that was to not require any dependence on ICMP.  Based
on feedback the document now describes how to fully interoperate with
the existing path MTU discovery.

The document also incorporates the observation that the algorithm is
parallel to congestion control; this is a fundamental observation that
was not recognized.  Incorporating that idea clarified what needed to
be specified rigorously earlier.  Both use loss as the primary signal
(with well understood limitations); this is more consistent with the
end to end principle... and shows why packet-level PMTUD is more robust
than ICMP-based PMTUD.

ICMP limitations could be argued as being artifact of layering violation.

Matt noted the issues surrounding robustness in more detail.  Worries
about respecting the "don't fragment" bit are addressed in the draft;
Matt felt this was the most significant lingering robustness issue.
The method can be used in exceptional cases; there is no increased risk from
striping across multiple paths with dissimilar MTUs.  Magnus Westerlund
noted that header compression over a link could lead to the same problems
as striping.

Matt noted that another issue has also arisen: with streaming media
protocols, compression depends on codec parameters; you can't
independently set packet sizes.  Magnus said that was a different
issue; how to generate data.  With variable rate codecs you can have
a number of segments with very small headers; then you might need
a full-context header which could exceed the MTU.

Finally,  Matt felt that even though the 03 version missed the last
40 or so hours of editing due to a machine crash, it was far better
than the previous version.  Matt is reluctant to push further without
other implementation experience.

However, we do need to do a MIB.   All of the important state is in the
IP layer; should we augment the IP MIB?

Larry Dunn felt the document is pretty much wrapped up; maybe have one
more meeting.  He wanted to know Matt's opinion.  Matt wants to get
it done, but feels we do need to get some implementations.
John Heffner promised an implementation for next meeting, but
he is an author, so he too would like to get another.

2. Fragmentation considered very harmful
   --Matt Mathis
   draft-mathis-frag-harmful-00.txt

Since the IP id field is 16 bits, modern systems can wrap the field
really quickly.  The Internet checksums aren't strong enough to protect
a packet if you splice fragments together.  For example, it takes
8 seconds to wrap IPid at 100Mbps. If you lose a low fragment, and
the IPid wraps, you might associate the low fragment from the new
packet with the old high fragment.  This is sustainable.

If you lose the high fragment, things aren't quite as bad.  The
standards don't specify what do.  Generally, the new low fragment
replaces the old low fragment.

Did some experiments (see slides for details).  With 250 runs
of random data, got 41,000 UDP checksum errors and one corrupted file.
With pathological data, the checksum passes even though the data is
incorrect.

However, this phenomenon can occur with low-rate servers or application,
if the server is busy enough to wrap it's own IPid space.  Say the server
wraps in a few seconds, and an individual connection is slow so the
IPids are not well correlated.  Every time there's a loss,
there is a 1 in 2^32 chance of the next packet being misassociated.
So, a low-rate vpn on busy server is exposed to problem.

Things like IPsec help - strengthen checksum.  With ssh,
you would get an encryption error and the session would be dropped.

An audience member questioned the 2^16 in the slide.  The two
instances of 1^16 on slide 7 should be replaced by 2^16.

What about changing TCP to crc-32 like SCTP?  You could, but then
once you open it up to make this change, there are a whole host
of other things that people would try to change.  There could be
an alternate checksum option.

Matt said the point is that IPv4 fragmentation basically doesn't work.
Anyone just depends on it us inviting troubles.

Michael Richardson noted that in IKEv2, there was a long conversation
about fragment attacks, and state attack of someone sending thousands
of non-initial fragments for port 500.   It doesn't want to send
any payloads that fragment.  PKI for IPsec is looking at this again.
It doesn't want to transport complete CERT chains because they become
too big.

Matt Mathis asked if those protocols have state to do MTUd?

Michael felt that IKE has enough state, or you can have the fragment header
in IKE. You could reassemble larger things in IKE once figure out what it was.

Someone noted that most assume a 1280 minimum MTU.  The
biggest problem is a PKIX cert at 500 bytes, so 3 layers of CERT
e.g. verisign-corpCA-deptCA : too big.  verisign-corpCA would be ok.

It was also noted that some applications use fragmented UDP
because they observed higher data rates in some situations.

Gorry Fairhurst asked about "full stop timeouts". Go back to 512 bytes for
both v4 and v6, or just for one and why?

Matt replied that his fear was that there would be an implementation
that would be a tunnel , with overhead that created an effective MTU
below 1280.  How should we deal with that?

One can argue it should be forbidden;  but is it better to sort-of work?
We could go back to 1024.

Another problem relates to making congestion control work with small
windows; what if loss rate is so high that appropriate average window
size is below 6Kbytes?  In that case, you might be better off using
512 byte packets than 1500, because fast retransmit doesn't work well
with less than four packets in flight.

Gorry noted that going back to small segments for other transports
might be strange.

This raises the point that whenever change MTU for whatever reason,
there ought to be opportunity for transport protocol to speak up and
say "I can't deal with it".

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