Subject: RE: mboned: Path MTU in IPv6 Multicast

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

> -----Original Message-----
> From: John Zwiebel [mailto:[email-masked]]
> 
> 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.

But some might argue that doing reverse path MTU discovery for multicast would negate some of the advantages of multicast. It would mean that each group member would have to establish a unicast session with the source, even if for only a short time.

Bert

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

---

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

On May 12, 2004, at 10:01 AM, Manfredi, Albert E wrote:

> But some might argue that doing reverse path MTU discovery for 
> multicast would negate some of the advantages of multicast. It would 
> mean that each group member would have to establish a unicast session 
> with the source, even if for only a short time.
>

If one chooses a "one size, fits all" approach, you are correct.
Consider the alternatives.  Are they "better" or is there going
to be some other solution offered.  Will that solution require
the routers to fragment the mpackets?  Will that solution restrict
the packet size?  Will that solution require the source to
probe all the possible paths?

One of the advantages of multicast in -some- situations is
that source does not need to know who the receivers are and
in -some- situations the receivers do not need to know who the
sources are.  It appears after all this time that these advantages
are lost in the interdomain environment -- especially when proposals
like BGMP were being considered.  Luckily, the community seems
to have figured out that additional complexity wasn't the option.

Flexibility through more options would seem to be the right way
to go.  A receiver who wants to avoid joining a source that is
sending packets that are to large to receive and/or a source which
wants to ensure all receivers are getting the packets would be
able to take advantage of this.

But, the important point is, this is a Host solution.  The network
can not manage the MTU size for the hosts.

Hosts need to recognize that the current multicast model is broken.
The network will never be able to "just handle it".  All the network
can do is ensure that the mpackets are delivered down the right
tree.  ASM makes the network guess what that tree might be.