Subject: Re: mboned: brief IMAD BOF summary

From: Dino Farinacci <[email-masked]>
Date: Wed, 10 Aug 2005 11:50:40 -0700

>> If you make a directory of SSM, you are indeed drifting away from msdp
>> and relying on some static application to do its work.  If we thought
>> MSDP deployment was bad, wait until we require some directory (I.E. sdr)
>> to make it going.  Does sdr work yet?

    Alternatives?

    This is certainly a different perspective. And a perspective one might
    interpret as MSDP isn't actually that bad comparitively?   ;-)

Dino
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Colin Perkins <[email-masked]>
Date: Thu, 11 Aug 2005 00:18:28 +0100

>>> to make it going.  Does sdr work yet?

sdr? That code hasn't been updated in 8 years. I sincerely hope no- 
one's using it anymore.

>     Alternatives?

Put the session description on a web page? Seems to work for the  
unicast streaming applications out there, so I don't see why it  
couldn't work for SSM streaming...

Colin

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 10 Aug 2005 18:11:19 -0700

>> couldn't work for SSM streaming...

    Sure, that is the obvious use. 

    So this thread seems to imply the directory is not a show-stopper for SSM
    deployment?

Dino

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 11 Aug 2005 14:42:48 +0900 (JST)

> >> couldn't work for SSM streaming...

Putting the session description on a web page is ok, but a multicast
directory system needs to manage fully dynamic session information to
a large number of end-users spread throughout the Internet, while it
is difficult for a regular web system to support it because sessions
are launched and stopped more frequently.
Furthermore, relying on a central management server (e.g. a web
server) contradicts our requirements, because such system is possibly
outside of the session scope and hence defining and applying scope
areas is impossible by any means.

Hence, there are several reasons that a *regular* web system or search
engine cannot become the new session directory system we could use.

>     So this thread seems to imply the directory is not a show-stopper for SSM

Precisely because the potential directory system does not exist in the
Internet, it could be the one.

In fact, I've been working for designing a new session directory
system named "Channel Reflector". Although it's too early to
introduce the detail spec to public at this moment, if some of you are
interested in the topic, the related work can be referred with;
http://www.sfc.wide.ad.jp/~asaeda/paper/saint2004.pdf (slides)
http://www.sfc.wide.ad.jp/~asaeda/paper/SAINT2004.pdf (paper)
This paper also includes discussions about SSM deployment problems as
well as the possible ASM-to-SSM translation.
--
Hitoshi Asaeda
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Stig Venaas <[email-masked]>
Date: Thu, 11 Aug 2005 09:35:01 +0200

> > >> couldn't work for SSM streaming...

First of all I want to say that a directory system is needed. sdr is
not ideal but I still find sdr useful for finding ASM sessions today.
And sdr code has actually been updated over the last years. There are
also other applications than sdr using SAP.

> engine cannot become the new session directory system we could use.

I agree with all of this and mostly the below as well.

Stig

---

From: Colin Perkins <[email-masked]>
Date: Sat, 13 Aug 2005 09:45:51 +0100

>     So this thread seems to imply the directory is not a show- 

Streaming applications typically use unicast (via a content  
distribution network) launched from a web page. These can use SSM,  
triggered from the same sort of web page. No central directory needed  
now; nor when using SSM. Google works just fine for finding sessions...

Conferencing applications typically use SIP to locate participants,  
and negotiate media formats and transport addresses using SDP. The  
SDP extensions needed to use SSM addresses are with the IESG now;  
nothing needs change with SIP. These systems can negotiate a set SSM  
addresses instead of a unicast mesh, or instead of an ASM group,  
should they desire. Participants can be found using SIP - no wide  
area ASM session directory used now, none needed for SSM.

Applications which use a hard-coded ASM address to distribute, for  
example, stock quotes, can use a hard-coded SSM distribution channel  
from a source identified by DNS name. No directory used now, none  
needed for SSM.

This is not to say that an SSM session directory is useless, or that  
there aren't interesting applications that require such a directory.  
But there are many, many, applications which can use SSM without such  
a directory.

Colin

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 15 Aug 2005 12:07:48 -0700

>> now; nor when using SSM. Google works just fine for finding sessions...

    Yep.

>> area ASM session directory used now, none needed for SSM.

    Sounds like things are in order. Think you can give us a presentation
    on this progress at the next mboned meeting?

>> from a source identified by DNS name. No directory used now, none  

    Right. Do you think this working group should recommend such use?

>> But there are many, many, applications which can use SSM without such  

    Do you know any products which use the SIP-based directory approach?

Dino