Re: Path MTU and beacon
On Wed, 9 Feb 2005 18:56:53 +0100
Stig Venaas <Stig.Venaas@uninett.no> wrote:
> On Wed, Feb 09, 2005 at 12:47:24PM -0500, Marshall Eubanks wrote:
> > On Wed, 09 Feb 2005 17:17:38 +0100
> > Jean-Jacques Pansiot <pansiot@crc.u-strasbg.fr> wrote:
> > > Marshall Eubanks wrote:
> > Got you. However, this is the beacon, which can go who knows where. An MTU should be chosen to
> > maximize the probability of working globally.
>
> Mostly agree, but it depends a bit what you're measuring. If you want to
> see how some specific multicast applications would work in your network,
> then you may want to use same packet size as them?
Yes. This should be a setable parameter (what if you are all gig-E - you might want 8940 !).
>
> > Remember, many I1 ISP's still use overlay networks for multicast. Other networks (I1 or I2) are
> > likely to drop fragmented packets entirely.
>
> [...]
>
> > > What about using Path-MTU discovery ?
> > >
> >
> > Unlikely to be useful or supported, alas :(
>
> To my surprise I've found that this actually works with IPv6 multicast
> on Linux. The Path-MTU is determined the usual way based on ICMP packet
> too big messages.
>
> For IPv4 I'm not so sure you're allowed to send such ICMP messages in
> response to multicast. Not quite sure.
Bill Fenner told me once it works. However, the point I had was, will networks pass
the required traffic. That is much less likely.
I tend to think of this as a debugging tool. If I am not getting multicast data to point X,
I do not want to have to worry about whether some different protocol works in my debugging tools
in order to interpret them.
>
> Stig
>
Marshall