[vlc-devel] Streaming wizard issues

[jpd at videolan.org]

On Tue, Dec 01, 2009 at 12:09:44PM +0100, Marian ??urkovi?? wrote:
> On Tue, Dec 01, 2009 at 11:05:11AM +0100, jpd at videolan.org wrote:
> > 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.
> 
> What? Always, only a *single* router which sees TTL=1 is affected, because
> the ASIC copies such packets to CPU. If initial TTL is 2, then not the first,
> but the second router is affected, and so on... 

Correction: the second-hop routerS.

For any multicast packet sent with TTL=N, all routers in all the
distribution paths, at hop distance N, will see packets with TTL=1 that
they have to drop. For higher N, more routers will see packets with
TTL=1, possibly exponentially many.

That is a direct consequence of the very definition of multicast: One
source, multiple destinations, consequently a distribution path that
isn't a path but a tree of multiple paths, and therefore a possibly
quite large number of intermediary routers at any given hop length.

So, no, not a single router as such, no. Possibly quite a large number.


> > Routers are prohibited from sending ICMP in response to multicast.[1]
> > If they do then they're broken.
> 
> Again, ASIC copies packets with TTL=1 to the CPU. Of course, CPU does
> not send ICMP for multicast, but it gets the copy anyway and needs to
> process it.

Sure. So, for a default that causes the least damage in case of failure,
I choose the one that causes the least aggregate cpu spikes, in the
least total number of intermediary routers, and as close to the source
as I can.

TTL=255 does not meet that criterion for the simple reason that VideoLAN
cannot know what any given multicast address will do, whether it is
officially designated administratively scoped or not. We only know what
it ought to do, but what it actually does is by very definition up to
each individual site.


> > No, I'm looking for a sensible default that doesn't cause too much
> > trouble in adverse conditions.
> 
> You never gave real-world example where this really helps. This is
> just hypothetical help to non-existent problem, I'm afraid.

If you assume everything else works as advertised, yet your arguments
are full of other things not properly working either. And so are mine,
for that matter, as that is the point I'm making. That I haven't
personally had to chase such (yet) is not an argument. I've seen
enough other fsckups, some while working as a sys/netadmin alongside
developers, to become much more conservative in my defaults than what
one could term the average developer. Especially defaults shipped to
some millions of users. Many, most of whom are very much not academics.


> > 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.
> 
> Might be better than what's available now, but still, default of TTL=1
> is clearly *invalid* for IPv6 and unnecessary for IPv4.

Wasn't talking about IPv6 and I strongly disagree with your assessments
of necessity, for I don't believe your expectations of network
configuration are valid for the wider internet.


> > 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.
> 
> Any decent application is supposed to work correctly in
> standards-based environment out of the box. That's what standards are
> all about.

And so VLC does. You can argue until you're blue in the face that SHOULD
equals MUST, but it doesn't, and so sayeth the relevant RFC.


> If every application introduces strange config knobs, we'll be doing
> nothing else than seeking what to tweak just to get basic things
> working.

I disagree that multicast is a basic thing, seeing how large parts of
the internet don't support it at all. That still is not a reason to
make it set to explode if it suddenly gets enabled, probably wrongly
the first few times, as such networks are wont to do.


> Bottom line: This debate does not make sense anymore. I've expressed
> my opinion in a clear way, using the state-of-the-art knowledge, but
> you still seem to believe multicast is a bad monster and everyone
> needs to be protected from it by ugly hacks.

Don't slam the door too loudly while at it, and the neighbour has
nightwatch duty so keep your voice down too. Stamping your feet is fine
as long as you do it outside.

I don't think that shipping with a safety catch on is inappropriate.
Your characterization above is a poor attempt at equating that with
insisting VLC must use TTL for administratively scoping production
streams, which I clearly and explicitly did not. Several times.

And, of course, I have little respect for academics that claim their
cosy research networks are representative for the rest of the world.
They're not; they are supposed to support work that bleeds the edge.
But VLC also ships to those that need their tools delivered fail-safe.
Iff they later take off the safety catches, that's their outlook, but
choosing a safe default is VideoLAN's.


> Please realize, that people on multicast-enabled networks view
> multicast as yet another thing that is expected to "just work" and
> TTL=1 is clearly preventing that.

So ship your own version for your academic network with the default
changed to a) default to the TTL you like and b) default to properly
scoped multicast ranges. VLC cannot do the latter because they are
site-dependent, but we can do the former.

If you want to win the argument get an RFC approved for standards track
that specifically prohibits TTL=1 for all IPv4 multicast. I think that
would be unwise, but I'll enjoy the popcorn watching you try.