Subject: mboned: Path MTU in IPv6 Multicast

From: "Marshall Eubanks" <[email-masked]>
Date: Wed, 12 May 2004 10:25:03 -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 ?

Any help would be appreciated.

Regards
Marshall Eubanks
_______________________________________________________________
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 17:14:28 +0200

> just do "administrative" MTU limits ?

For ecmh I refrained from doing it and actually I would be
more for fragmenting multicast in routers, which it did at
one moment, but then I took it out again is it is against the RFC.

Best is to ask the m6bone people as they have'working experience'
with running a big IPv6 multicast network.

Rationale for the above:
Big network, 100000 subscribers to a multicast stream.

Stream is 1500 bytes on average, there is one client who
only accepts 576 bytes*, thus it sends back a ICMP-PacketTooLarge
Now the complete network suddenly has to cope with a 3-fold
packet rate because somewhere at the edge one device doesn't
accept a large packet.

Which is also is one of the reasons why currently, with quite
a lot of tunneling, on average one will find a path mtu of 1200+

In this setup it would IMHO be better to let the first router closest to
the "I want want small packets" device fragment the packet into
some smaller chunks than having the sending system do that.

Notez bien that the fragments + headers also need to be sent over
the complete network when this isn't done.

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

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 May 2004 18:41:51 +0300 (EEST)

> just do "administrative" MTU limits ?

AFAICS, there are two options:

1) just set the MTU for multicast to 1280 and you're done, or

2) use bigger packets and run PMTUD as specified.  I think many PMTUD
implementations do this already (but I haven't tested it). 

That is, Packet Too Big messages are also sent in response to too big
v6 multicast packets, so the only thing implementations need to be
sure of that they decrease the packet size for the multicast group
when they receive such an error, just as they do for unicast.

If I'd have to deal with this, I'd probably pick 1) :)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: John Zwiebel <[email-masked]>
Date: Wed, 12 May 2004 08:56:10 -0700

2 more cents:
Another reason for a Multicast Source Discovery Protocol that
will enable SSM.  Users would not join to multicast groups that
were offering a MTU size that was too large for their data path.
Receivers would be responsible for determining if the path is
too small.

I recognize that this is not what unicast does, but multicast
has always been receiver centric and one has always had to
"stand on your head" to understand it.

---

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

> Any help would be appreciated.

I already said another place in the thread that Linux does it.
There are some issues with doing it, but unless I'm missing
something, the implementation should be exactly the same as
for unicast UDP.

I've done some experiments with this on Linux, happy to go
into details.

Stig