Subject: Re: mboned: Multicast Detective

From: "Kevin C. Almeroth" <[email-masked]>
Date: Mon, 31 Oct 2005 13:31:52 -0800

I meant to follow-up on this particular point...  it strikes me as
awfully hard to make multicast a robust service if the best we can
do is send a join-message and hope everything along the path just
works.

Basically I'm arguing that there should be feedback to the client
and application.  The fact that this feedback doesn't exist is one
of the reasons we started looking at developing this kind of tool.

-Kevin

>>On Tue, 25 Oct 2005, Kevin C. Almeroth wrote:
>>> Okay, this is a pre-release of some code we put together to
>>> test local multicast capability...  basically it runs 8 tests:
>>>
>>>   3. Checks if the first-hop router is multicast capabile
>>>   4. Checks if the first-hop router is SSM capable
>>>   7. Detects if the first-hop router supports PIM-SM
>>
>>(I didn't run the tool, just gave a look at the source.)
>>
>>These are apparently done simply by pinging 224.0.0.2, 224.0.0.22 and 
>>224.0.0.13, respectively.
>>
>>This doesn't seem to work when the DR is Juniper, because it doesn't 
>>answer to pings on those addresses.
>>
>>-- 
>>Pekka Savola                 "You each name yourselves king, yet the
>>Netcore Oy                    kingdom bleeds."
>>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>>_______________________________________________________________
>>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/

4/8.13.4/Submit) id j9VLW0Pb024426;
	Mon, 31 Oct 2005 13:32:00 -0800
Date: Mon, 31 Oct 2005 13:31:52 -0800
From: "Kevin C. Almeroth" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: mboned: Multicast Detective
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

I meant to follow-up on this particular point...  it strikes me as
awfully hard to make multicast a robust service if the best we can
do is send a join-message and hope everything along the path just
works.

Basically I'm arguing that there should be feedback to the client
and application.  The fact that this feedback doesn't exist is one
of the reasons we started looking at developing this kind of tool.

-Kevin

>>On Tue, 25 Oct 2005, Kevin C. Almeroth wrote:
>>> Okay, this is a pre-release of some code we put together to
>>> test local multicast capability...  basically it runs 8 tests:
>>>
>>>   3. Checks if the first-hop router is multicast capabile
>>>   4. Checks if the first-hop router is SSM capable
>>>   7. Detects if the first-hop router supports PIM-SM
>>
>>(I didn't run the tool, just gave a look at the source.)
>>
>>These are apparently done simply by pinging 224.0.0.2, 224.0.0.22 and 
>>224.0.0.13, respectively.
>>
>>This doesn't seem to work when the DR is Juniper, because it doesn't 
>>answer to pings on those addresses.
>>
>>-- 
>>Pekka Savola                 "You each name yourselves king, yet the
>>Netcore Oy                    kingdom bleeds."
>>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>>_______________________________________________________________
>>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/

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 31 Oct 2005 13:56:17 -0800

> of the reasons we started looking at developing this kind of tool.

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/