[vlc-devel] Streaming wizard issues

[Marian Ďurkovič]

On Mon, 30 Nov 2009 20:08:38 +0100, jpd wrote
> On Mon, Nov 30, 2009 at 05:44:18PM +0100, Marian ??urkovi?? wrote:
> > It doesn't limit the damage, it creates one, even with biggest routers.
> 
> Who has a linkup to the biggest routers and _doesn't_ know to set this
> straight? 

I said "even" the biggest - meaning that packets with TTL=1 cause *any* router
to perform extra processing in SW. Router is required to send TTL Exceeded 
ICMP message back to the source, while unwanted multicast packets are silently
dropped in HW with zero CPU overhead.

> Remember that nobody proposed to use this in production; rather to make
> sure unconfigured setups don't accidentally cause problems in production.

They can't. Router which does not understand multicast or is not configured to
route it drops all multicast packets anyway. Router configured for multicast
routes it only when requested to do so. You're trying to solve a non-existent
problem (or better said, a problem which should never happen unless the IP stack
on some "router" is total crap).

> Your complaint of overloaded core routers would happen if we'd set the
> TTL to some arbitrary number above one but below the average diameter 
> of the internet

That indeed happens from time to time, since some users put e.g. 5 into the TTL
field instead of 255. That shoudn't be possible.

> > It violates the current RFCs.
> 
> Er, no, it doesn't. "SHOULD" is not quite the same as "MUST". 

The point here is, that modern multicast networking concepts consider TTL
scoping harmful and applications SHOULD avoid it unless absolutely necessary.
All RFCs have been updated to clearly state it's deprecated, and for IPv6 this
broken concept is not even applicable. This is nothing new - the brokenes of TTL
scoping is known since ~15 years. A modern multicast application should use TTL
only as a safety-belt against infinite loops, i.e. exactly the same way as it's
used in unicast. I fail to see why VLC should be different.

   With kind regards,

         M.