Subject: Re: 6to4 default MTU [was Re: (ngtrans) 6to4 MRU - need WG consensus]

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 16 Sep 2002 10:18:21 -0700

Erik,

Interesting document - thanks for pointing it out. Have you had a chance
to read it? If so, what is your assessment of the "How to detect" and
"How to fix" suggestions given in section 2.1 from the standpoint of
robustness and efficiency?

Fred

Erik Nordmark wrote:
 >>>...and the OS vendors refused to tie a
 >>>black-hole detector to their PMTU discovery engine.
 >>
 >>Is the concept of a "black-hole detector" for PMTU documented
 >>somewhere?
 >
 >
 > RFC 2923
 >
 >   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 17 Sep 2002 14:49:27 +0200 (CEST)

> robustness and efficiency?

I think it is a bit tricky because there are multiple things you'd might
want to trigger when the transport protocol is retransmitting.
For instance in IPv4 you want to trigger dead gateway detection.
And in an SCTP case you might want to try an alternate path for
the retransmitted packets.
Thus transport retransmissions might be due to at least
 - loss due to congestion
 - loss due to lossy (e.g. wireless) links
 - loss due to the path having failures (1st hop router or some other part
   of the path)
 - loss due to sending large packets and the ICMP too big not being returned

The TCP specification handles the first two.
The SCTP specification handles the first three even though the heuristics
for path failures are really basic.

I haven seen an easy way to combine all four.

  Erik

---

From: Robert Elz <[email-masked]>
Date: Tue, 17 Sep 2002 23:23:04 +0700

Date:        Tue, 17 Sep 2002 14:49:27 +0200 (CEST)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <[email-masked]>

  | I haven seen an easy way to combine all four.

No.

PMTUD black hole detection really needs to be a last resort (because
in theory it shouldn't be needed at all, if everyone did the right
thing).

But you can get to the stage where you simply can't believe that any
path is *that* congested, or *that* lossy, and if the problem is a broken
route, then everything dies anyway (if sctp switches destinations, that
can also avoid a pmtud black hole, so that's OK), so eventually, lots of
loss, and a pmtud black hole avoidance strategy can certainly be attempted.

But this is something that nothing should be relying upon using, if for
no other reason but that it is going to take a long time to make things
work again - and have to be repeated over and over (PMTUD does require
increasing the packet size from time to time, in case the PMTU has grown).

So, for this, we really want the ICMP "too big" messages, which implies
that nodes really cannot send bigger than the MRU of the recipient, and
since they have no knowledge of what that will be, that means they
MUST send no bigger than the required MRU.    And that's regardless of
what size MTU might seem advisable (that is an independent question,
unless the MRU is set at 1280, in which case  the MTU has nowhere else
to go).

This is why I still believe we need a required MRU bigger than 1500.
And 4664 still looks like a good number.

Note that Christian's technique doesn't work to allow nodes to send bigger
than the required MRU (because one cannot assume that it will be implemented
at the recipient).   What it allows is for a node that cannot implement
the required MRU to not break the world (effectively, it pretends that
it handled the larger packet, but that it turned out to be too big for the
next hop).

kre