Subject: RE: (ngtrans) 6to4 MRU - need WG consensus

From: "Christian Huitema" <[email-masked]>
Date: Thu, 5 Sep 2002 09:20:40 -0700

> >> So, I once again suggest a required MRU for 6to4 receivers of 4664
> bytes.
> >We've had enough discussion I think. If you object to this proposal
> >please say so and propose an alternative value.
> >Let's get this decided before the WG is closed down...
> >(And please please do not take this new thread into any topic except
> >the MRU for 6to4.)
> 
> 	yes, i propose required IPv6 link MRU be 1480 (1500 - 20)

Fine with me.

There are two rebuttals to KRE's arguments for a larger size:

1) The amount of memory is NOT "just one packet". Given multiple ongoing
connections, packets will arrive in parallel from various sources, and
there will be multiple parallel reassemblies taking place.

2) If Gigabit nodes go "native IPv6", they have a simple way to avoid
the standard "2002:://16" route and the corresponding segmentation: they
can obtain a native IPv6 address.

By the way, did you check the CAIDA paper:
http://www.caida.org/outreach/papers/2002/Frag/
Based on observations at 6 exchange points, they observe that between
0.25% and 1% of IPv4 packets incur fragmentation. The most frequent
segment sizes, after fragmentation, are:
1500 bytes: 79%
1484 bytes: 18%
1492 bytes:  1%
 576 bytes:  0.96%
1496 bytes:  0.37%
1356 bytes:  0.15%
1396 bytes:  0.16%
 124 bytes:  0.093%
 764 bytes:  0.081%
1452 bytes:  0.055%
These packets sums up to 99.872% of the observed fragments. Specifying a
minimal 1280 MTU for the tunnels implies that we would only observe 1.5%
of the current IPv4 fragmentation. This does not invalidate the
requirement for a 1480 bytes MRU.

-- Christian Huitema

---

From: Robert Elz <[email-masked]>
Date: Fri, 06 Sep 2002 18:01:46 +0700

Date:        Thu, 5 Sep 2002 09:20:40 -0700
    From:        "Christian Huitema" <[email-masked]>
    Message-ID:  <[email-masked]>

  | 1) The amount of memory is NOT "just one packet". Given multiple ongoing
  | connections, packets will arrive in parallel from various sources, and
  | there will be multiple parallel reassemblies taking place.

You'd think so, wouldn't you?   But, while that might occasionally happen,
in general, it won't any time it matters.

That is, if you're connected to a link that has an actual MTU of 4K or
so, then you're going to want to be able to receive/transmit multiple
packets of that size anyway.   And you're going to have enough RAM to
cope with that.

On the other hand, the baby devices that we're apparently so concerned
with handling, aren't going to be connected to such links.   If they
receive and reassemble a 4K packet (or so), all they're going to do with
it is send back a "ICMPv6 too big" to the sender, which will drive the
sender's PMTUD algorithm, and reduce further packets to something smaller
(most probably, smaller than 1500...)

Future packets won't be that big any more.

So, the only time that multiple of these packets will be being reassembled
at once, is when multiple different new senders are sending to destinations
behind the 6to4 that they haven't sent to before.

Now remember, the suggested devices that were not going to be able to
cope with this reassembly, of larger packets, are those $100 home router
boxes that exist now (the ADSL to LAN converters, and such).   Almost
by definition, those things are used in homes - where the number of
different incoming connections, simultaneously, is likely to be very
very low.   If Google, or eBay or someone, want to try and cope by using
a $100 6to4 router, and because of that lots of packets get lost because
the router runs out of memory, then I think the answer is "what did you
expect???   Of course..."    No-one who expects to be receiving lots of
traffic is going to be using such a device (and note, "lots" here means
lots of independent connections, all starting about the same time - data
volume is irrelevant).

So, that argument I'm afraid refutes nothing.

  | 2) If Gigabit nodes go "native IPv6", they have a simple way to avoid
  | the standard "2002:://16" route and the corresponding segmentation: they
  | can obtain a native IPv6 address.

This one is better, but it relies upon the world developing the way
we expect, and even then, it ignores FDDI.    People already have that
(and as more commercial users are moving up to higher bandwidth, GigE
and even ATM 655MB before that, surplus FDDI equipment is now available
fairly cheaply - which means, available to home users who want better
than 100MB ether, but cannot yet afford GigE switches (interface cards are
affordable, switches that work, aren't).   Because much of this equipment
is old, it tends not to support IPv6 (and home users often don't want to
enter into maintenance agreements in order to be able to upgrade to the
latest code - even if it is available - I still have a cisco AGS+ that
has FDDI in it, which all works fine - but I'm not anticipating getting
IPv6 code for it any time soon).

  | By the way, did you check the CAIDA paper:

I haven't, but will.   But I'm afraid that I didn't follow your point
with respect to it at all, would you care to rephrase?

kre