Subject: RE: mboned: Path MTU in IPv6 Multicast

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 12 May 2004 12:50:14 -0400

> > Does anyone have a pointer to how path MTU discovery is 
> > done with IPv6 multicast ? Since only end nodes
> > fragment, you need to do path MTU discovery, and rfc1981
> > says this is true for multicast, but does anyone actually do
> > it ? If so, is there available code to do so ? Or do people
> > just do "administrative" MTU limits ?

Path MTU discovery is really only meant for unicast. The source increases its packet size until it receives an ICMP "packet too large" error message, then backs off slightly.

The source of a multicast does not know who the destinations are, assuming there are any destinations, and the source also does not know if suddenly a new member joins in a network with smaller MTU than all the previous members. And an ICMP error message in the middle of a long media stream would disrupt the entire multicast, as the source reduces its packet size and increases the packet rate.

> * = RFC1883:
>  IPv6 requires that every link in the internet have an MTU of 576
>  octets or greater.

RFC 2460:

5. Packet Size Issues

   IPv6 requires that every link in the internet have an MTU of 1280
   octets or greater.

If it were up to me, I'd set up the source for a packet size of 1280 bytes and call it good.

Bert

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 12 May 2004 19:00:06 +0200

On Wed, 2004-05-12 at 18:50, Manfredi, Albert E wrote:
> Path MTU discovery is really only meant for unicast.
> The source increases its packet size until it receives an ICMP
> "packet too large" error message, then backs off slightly.
> 
> The source of a multicast does not know who the destinations are,
> assuming there are any destinations, and the source also does not
> know if suddenly a new member joins in a network with smaller MTU
> than all the previous members. And an ICMP error message in the
> middle of a long media stream would disrupt the entire multicast,
> as the source reduces its packet size and increases the packet rate.

Exactly what my bubbled in my head.

> If it were up to me, I'd set up the source for a packet size of 1280 bytes and call it good.

I missed out on that RFC while checking for the minimum MTU value.
Thus indeed 1280 is perfect. This is accidentally also the minimum size
of all the IPv6-in-IPv4 tunneling systems.

Shouldn't this be in a BCP/RFC somewhere mentioning this?
It does give a problem when one wants to send large amounts of
multicast. But in those cases I think we can assume one is in a
testing/research network already and will be controlling most parts of
the network anyhow. At least I have not heared of 'commercial ISP's
we are able to use jumbograms (yet).

Greets,
 Jeroen

---

From: Stig Venaas <[email-masked]>
Date: Thu, 13 May 2004 00:33:58 +0200

> Exactly what my bubbled in my head.

Linux does PMTU discovery for multicast. I've seen myself how it
changes when different clients join and leave.

An interesting thing is also that the PIM spec says DR may send
"packet too big" if packet is too large for register tunnel.
However in most cases only a few packets would be registered,
before one switches to native path. Which means that one might
switch to smaller MTU (or actually fragment packets at source)
for about 10 minutes (Linux default), before one can resume and
use the PMTU for the native path.

For fun I've experimented with adjusting the datagram size used
by the application and dynamically change it when PMTU changed.
Worked pretty well.

Stig