[vlc-devel] Streaming wizard issues

[jpd at videolan.org]

On Tue, Dec 01, 2009 at 08:15:02AM +0100, Marian ??urkovi?? wrote:
> I said "even" the biggest - meaning that packets with TTL=1 cause
> *any* router to perform extra processing in SW.

But _only_ the first router. The number affected explodes with TTL>1.


> 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.

Routers are prohibited from sending ICMP in response to multicast.[1]
If they do then they're broken.


> 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).

No, I'm looking for a sensible default that doesn't cause too much
trouble in adverse conditions. I've said so in a few different ways
already.

If you do see ICMP in response to multicast then your routers are
"total crap" and I suddenly fail to see the basis of your previous
insistence of assuming a correctly configured network.


> > 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.

Different issue than setting TTL=1, which IMO, and for all the reasons
already detailed, should be not only possible, but the default. If you
propose to reduce choice to only TTL=1 and TTL=255, then that would be
sensible. For a `streaming wizard' it would be appropriate for all but
the `advanced' section. But you haven't, so far.


> > > 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.

The RFC you quoted implicitly assumes a ``production environment'',
obviously with a TTL>1, but that isn't what I'm after, as explained
above.


> 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.

VideoLAN isn't distributing a ready to go production box for streaming,
but rather a toolbox to build such a thing. And then it's perfectly fine,
even sensible and sane, to deliver the tools with the safety catch on.


[1] http://www.icir.org/fenner/mcast/icmp.html mentions RFC1112 7.2,
    RFC1122 3.2.2, and RFC1812 4.3.2.7 as saying the same thing.