Subject: RE: (ngtrans) Re: 6to4/isatap MTU

From: "Christian Huitema" <[email-masked]>
Date: Wed, 4 Sep 2002 08:42:34 -0700

> > I see Itojun's point: tunnels are a transition strategy; we don't
want
> > to plug too much complexity in any transition strategy; it is OK to
keep
> > it simple even if it causes degraded performance, because simplicity
> > reduces support cost, and tunneling causes performance issue anyhow.
> 
> I find this astonishing. You have clearly been doing alot of thinking
> about the "decapsulator monitors IPv4 fragmentation" solution dating
> back to your message on 8/21/2002. You have proposed a well
thought-out
> decapsulator algorithm in your message dated 9/02/2002. Now you just
throw
> your hands up and say: "Let's forget the whole thing and go with the
> lowest common denominator solution"? Please explain...

Once burned, twice shy. I know that we can do clever tricks, such as the
one I described, in order to get performance benefits. The "burned" part
comes from the experience that clever tricks often backfire: the sender
assumes that the clever trick is implemented, the receiver does not
implement it, or implements it wrongly, and you get a black hole. So, we
have to be careful when writing optimizations as we must balance
performance against robustness. Itojun's proposal essentially sacrifices
performance for maximum robustness; it is a design point that is well
worth considering.

For an observation on the reality of IP fragmentation today I recommend
reading "Beyond Folklore: Observations on Fragmented Traffic" by 
Colleen Shannon, David Moore, and k claffy
(http://www.caida.org/outreach/papers/2002/Frag/). I observe from their
result that when fragmentation does occur, the fragments are smaller
than 1500 bytes in more than 99.6% of the cases. Another recommended
reading is indeed the 1987 report "Fragmentation Considered Harmful" by
Christopher A. Kent and Jeffrey C. Mogul
(http://research.compaq.com/wrl/techreports/abstracts/87.3.html).

I am not sure that an attempt to use large MTU for tunnels would
actually result in better overall performance. There are some benefits
to using larger packets, but these benefits are mostly visible when
transmitting at very high data rates, i.e. Gbps; modern PCs can saturate
a 100 Mbps link with packets of about 1KO. On the other hand, there is a
cost to fragmentation, in terms of higher packet losses; these losses
can prevent TCP from achieving even a 1Mbps data rate. If we restrict
the MTU of tunneled traffic, we will not see any performance loss in low
speed environment -- not in modems, not in DSL, not in T1, not even in
100 Mbps Ethernet environments. We will observe a performance loss when
the network is operating at Gbps speed end-to-end; this is indeed the
environment in which large packets are desired; but it is also a
high-end environment that is a prime candidate for rapid migration to
native IPv6.

-- Christian Huitema

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 04 Sep 2002 10:16:40 -0700

Christian Huitema wrote:
> implement it, or implements it wrongly, and you get a black hole.

This is why we develop standards.

> actually result in better overall performance.

Are you talking about tunnels generically here?

Fred
[email-masked]

---

From: Robert Elz <[email-masked]>
Date: Thu, 05 Sep 2002 17:31:54 +0700

Date:        Wed, 4 Sep 2002 08:42:34 -0700
    From:        "Christian Huitema" <[email-masked]>
    Message-ID:  <[email-masked]>

  | We will observe a performance loss when
  | the network is operating at Gbps speed end-to-end; this is indeed the
  | environment in which large packets are desired; but it is also a
  | high-end environment that is a prime candidate for rapid migration to
  | native IPv6.

You'd think so, and hope so, but unfortunately, even if that's true,
it doesn't help.   For 6to4 at least (ISATAP I don't know enough of
to speak of), it just doesn't work like that.   6to4 prefers to send
IPv4 as much as possible (because that's what works today, one assumes).

That is, the IPv6 packets get routed to the nearest 2002::/16 advertiser,
and then sent via IPv4 over the net until they reach the destination (site).

So, until IPv4 vanishes completely, we're going to have IPv6 packets
embedded in IPv4 traveling over the backbone networks, regardless of
whether or not those nets can handle native IPv6.   It is just the way
that 6to4 works.

This is going to be a long time into the future, which is why I'd like
to set a minimum MRU that won't be a total embarrassment in 10 or 15
years from now.   I'm not advocating that anyone actually send packets
anything like that size today, I'd just like the receivers to prepare to
be able to receive them.

Whether that's by providing enough buffering, or by using your reassembly
queue hack to cut off packets that will grow too large, doesn't matter
(both can be handled transparently).   But I certainly don't think that
we should be condemning a segment of the net to tinygrams forever, just
because we're afraid that some node might not have 8K of buffer space
available, and be unable to implement your idea, and be sold in sufficient
quantities that anyone cares.

kre