[vlc-devel] Streaming wizard issues

jpd at videolan.org jpd at videolan.org
Mon Nov 30 12:29:47 CET 2009


On Mon, Nov 30, 2009 at 11:14:38AM +0100, Marian ??urkovi?? wrote:
> Multicast router does not flood anything behind it even if it's enabled
> to route multicast. It's not a switch. It only starts forwarding when 
> asked to do so, via IGMP or PIM join. 

Assuming it works correctly. ISTR some L3 switches falling back to
broadcast when failing multicast routing. I know certain L2 switches do,
under load, to spectacular effect.


[snippety]
> "Although the TTL MUST be specified, its use to scope multicast traffic
> is deprecated; applications SHOULD use an administratively scoped address
> instead."
> 
> > But I think you are mixing up ``providing a safe default'' and
> > ``depening on TTY=N for your production use'' here. The default in
> > VLC isn't ment for production, but to provide a sane default, and in
> > the case of multicast with its flooding potential,
> 
> It's not a safe default, it's a broken default.

Show me how it is not safe but broken. Assuming a situation with some
but not all switches buckling under multicast related TTL timeouts:
Are the problems harder to diagnose and is it more work to trace the
tormentor with TTL=1 or TTL=255?


I still think you're mixing up production BCP and defaults as safety
nets. In fact, I'm quite sure of it. The simple reason for VLC setting
_default_ TTL is that that administratively scoped addresses require
an administrative scope within which it can be scoped, and VLC cannot
provide that. The reason it is default and not hard coded is that people
can, and indeed SHOULD, provide a better number depending on their
situation. But until they do, TTL=1 keeps them from bothering others too
badly.


> There's no flooding potential in a properly configured L3 multicast
> network. If noone asks the stream, it shouldn't get beyond the first
> router.

If everything else is properly configured then our default doesn't
really matter. Assuming this, however, is not sane, nor safe. In that
light providing a default that limits the damage is the sane thing to
do. Setting TTL to 255 by default is not sane in that regard.


> TTL=1 might work in a home LAN for playing, but in any network consisting
> of more than one L3 segment, users can't get RTP working without tweaking
> the TTL field.

If we are assuming a correctly configured L3 multicast network there
will be competent L3 admins that can correct the oversight. If not, you
just argued it wouldn't work anyway, so there is no point. Within that
constraint I still choose TTL one for the default.





More information about the vlc-devel mailing list