Subject: Re: mboned: Multicast Detective

From: "Kevin C. Almeroth" <[email-masked]>
Date: Tue, 1 Nov 2005 10:36:26 -0800

Sorry Toerless, but multicast is broken.  This is not to say it isn't
a failure, etc. etc.

What I am saying though is that multicast has hit a ceiling.  While
its service definition allowed us to get it off the ground, it has
hit some major roadblocks.

I also CLEARLY understand the abhorrence to violating the boundary
between switches/routers and end-users, but in order to move forward,
we have to either (a) be willing to change the protocols to work in
feedback loops (and just among the network elements is fine), or (b) we
have to violate some long-standing rules.

Finally, a good consideration is whether we even care about "Internet
IP Multicast".  As you mention below, there are plenty of situations
where other tools/solutions can be layered on top to provide robust
intra-enterprise service.  (This consideration is actually one of
the reasons I'm not pushing on (a) a bit harder...  assuming it would
even make a difference.)

-Kevin

>>Take a look at ITU-T's X.6.
>>
>>I think there was a reason why that service definition was not
>>successfull, but ASM/rfc1112 was.
>>
>>The IP multicast service isn't much different in it's underlying
>>model than IP unicast, and the same argument you make could be made
>>about IP unicast and the end-applications inability to have any more
>>knowledge than "works / does not work". It all comes down to the amount
>>of utilization and thereby experience into the failure condition handling:
>>Nobody makes your argument about IP unicast because it's so widely
>>adoped and used that either the problem doesn't come up, or appropriate
>>diagnostic infrastructures are better evolved.
>>
>>There is quite some difference between "robust" and "end-user-diagnostics".
>>Of course, we all on mboned would love more "end-user-diagnostics", but
>>that quite frankly is something that doesn't have many well established
>>precedences. Sure, the phone network had a busy signal, but you didn't
>>even know if the network was overloaded or the remote end was talking (except
>>in some networks ;-).  Sure, X.25 had all kind of error codes to reliably
>>signal you why a connection didn't work, but nobody knew how to read
>>them anyhow.
>>
>>The problem is a service that is so little used that end-users need to
>>be involved in diagnostics and troubleshooting. Not the underlying
>>service model.
>>
>>Which is not to say that i wouldn't be in favour of any additional
>>error condition signaling, but i would doubt that it would make the
>>service any more robust as long as the support model on the operator
>>side does not change. I can already today provide a pretty robust service,
>>and many customers on the enterprise side are doing that by using appropriate
>>NMS solutions and/or active probing. That's just not true for the Internet
>>portion of IP multicast.
>>_______________________________________________________________
>>user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
>>web archive:  http://darkwing.uoregon.edu/~llynch/mboned/
>>
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/