Subject: Use of SAP in a PIM SSM Network

From: "HANSEN CHAN" <[email-masked]>
Date: Tue, 14 Nov 2000 17:39:56 -0500

Hello all,

I am trying to understand in a pure SSM network without any shared tree,
how would SAP operate? My understanding is that SAP is transmitting on a
shared tree. Does it mean that we always stuck with a PIM-SM shared
tree, even in a pure SSM network?

Cheers,
Hansen

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 14 Nov 2000 15:16:15 -0800 (PST)

> tree, even in a pure SSM network?

I think you have a network without a shared tree and without SAP. You can
of course use SSM to get SAP information, but the receivers need to know
the address of the sources in the first place, which is a bit beyond the
point of what SAP was meant for in the first place. SAP is nice to have
in limited environments, but simply trying to broadcast directory information
on a world-wide scale is not a scaling solution. Already today lots of
SDP sessions are just made available via the web instead of SAP.

-- Toerless

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 14 Nov 2000 21:43:15 -0500

> SDP sessions are just made available via the web instead of SAP.

I am not sure that I agree with this. We would certainly be interested
in hosting a directory service using SSM, and I suspect others would as
well. I would, in fact, claim that in some ways a multicast directory
service scales better than web pages FOR AGGREGATED INFORMATION.

Suppose that one fine day there are 50,000 SSM groups in permanent operation.
Clearly, a web page covering ALL of these groups would basically be a search
engine - just a list would not be useful. If each group was announced
by a sap type packet with a size (say) of 200 bytes, to go through the entire
list would require 10 megabytes. Even if 8 kilobits/sec were allocated to
a multicast directory service, it would still take > 3 hours to go through
all of these announcements. If, however, the groups were divided into 100
classes, each with ~500 members, and each class getting its own SSM group
for directory announcements, all the sessions in a class could be
discovered in
only 100 seconds, about the time it takes the program announcements on Channel
1 of my cable TV service to cycle through. I think that such a service
would be
useful; therefore I think that, while SAP may die, multicast session announcements
will live on.

                                   Regards
                                   Marshall Eubanks

   Multicast Technologies, Inc.
   10301 Democracy Lane, Suite 201
   Fairfax, Virginia 22030
   Phone : 703-293-9624          Fax     : 703-293-9609     
   e-mail : [email-masked]     http://www.on-the-i.com

---

From: "Mike Luby" <[email-masked]>
Date: Tue, 14 Nov 2000 19:34:12 -0800

I think there are different kinds of services that can be offered, and that
is the difference in the discussion below.  I happen to agree with Toerless
that webpage access is the more natural way that SSM groups will be
accessed.  Today, there are many many more than 50,000 pieces of content and
streams available on the web from different content providers, and there is
absolutely no attempt to make available a centralized listing of all those
piece of content in one place on one webpage: each content provider makes
their content available on their webpages through hyperlinks, and the
organization and presentation of that content is designed by them according
to their needs.  For example, Yahoo has many many pieces of content and
streams available on its extensive website, and each one is accessed by the
click of a hyperlink on a given webpage.  There is absolutely no attempt to
have a global organization of all the content and streams available on the
Internet.  Thus, I'm wondering what is so special about SSM, and why it
won't roll into the same access model as all other content and streams out
there?  I suspect that if something different is attempted to organize SSM
content and streams that was different than the rest of the Internet, then
it will have a very limited use on the general Internet.  This is the beauty
of SSM: it really fits into current practices for making content and streams
available on the Internet.  Each content provider can independently source
their own SSM streams just like they put content up on their webpages today
available through http servers, and they don't have to worry about the old
style of having a global listing service of all multicast groups in the
world (which I suspect was there more because of the problems with having
multicast group address clashes, which is not a problem for SSM), they just
list their SSM content and streams as they are today on their webpages.  The
advantage of course is the massive scalability that SSM offers (of course,
this is assuming it is deployed across the Internet as we all hope).  The
advantage of listing SSM content and streams on webpages is that it is what
is done today for other content and this way nobody has to change their
current practices.  Of course, this is not to say that a global listing
service would not be useful, but I'm not sure I see why this is anymore
useful than a service that is a global listing service for all content and
streams on the Internet, i.e., what is special about SSM streams versus
other streams other than the massive scalability of SSM?

My two cents,
Mike

-----Original Message-----
From: Marshall Eubanks [mailto:[email-masked]]
Sent: Tuesday, November 14, 2000 6:43 PM
To: Toerless Eckert; Ross Finlayson; Al Adler
Cc: HANSEN CHAN; [email-masked]
Subject: Re: Use of SAP in a PIM SSM Network

Suppose that one fine day there are 50,000 SSM groups in permanent operation
.
Clearly, a web page covering ALL of these groups would basically be a search
engine - just a list would not be useful. If each group was announced
by a sap type packet with a size (say) of 200 bytes, to go through the
entire
list would require 10 megabytes. Even if 8 kilobits/sec were allocated to
a multicast directory service, it would still take > 3 hours to go through
all of these announcements. If, however, the groups were divided into 100
classes, each with ~500 members, and each class getting its own SSM group
for directory announcements, all the sessions in a class could be
discovered in
only 100 seconds, about the time it takes the program announcements on
Channel
1 of my cable TV service to cycle through. I think that such a service
would be
useful; therefore I think that, while SAP may die, multicast session
announcements
will live on.

                                   Regards
                                   Marshall Eubanks

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 15 Nov 2000 08:13:20 +0000

>>SDP sessions are just made available via the web instead of SAP.

Toerless

either you have a well known ssm mcast addr per sap server or you have
a well known web page - same difference - 

the scaling: if yo ucan have 10,000 sessions of video, you can sure
happily have 10,000 session announcements.....

search engines: are not standard. sure, they are a _piece_ of the
picture.

 cheers

   jon

---

From: "Tony Ballardie" <[email-masked]>
Date: Wed, 15 Nov 2000 09:41:44 -0000

> a well known web page - same difference - 

how about www.mcast.net ?

Tony

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 15 Nov 2000 10:50:37 +0000

ha ha ha

finally people realize

ssm entails _exactly_ as many problems as simple multicast in terms of
1/ deploying it in routers
2/ changing all the applications to use igmpv3
3/ chaing host OS to use igmpv3
4/ changing session management/annoucement mechanisms

:-)
(no i dont want to revisit SM - ssm is just fine, and ipv6 with some
simple kinks will do many-source multicast just fine too)

so no, we dont have resources to do this, but we are happy to roll in
SSM/igmpv3 changes to the mbone apps if people contrib. them (spritn
have kindly offered to do some apps) - sdr is a non trivial one in
that it needs completely re-writing which is outside the scope of a
university research department's normal activities....

In message <[email-masked]>, Dirk Ooms typed:

 >>Jon Crowcroft wrote:
 >>> either you have a well known ssm mcast addr per sap server 
 >>
 >>but the 'sap listener' application requires some changes, it has to join
 >>a specific sap server (which again needs to be listed on a webpage?). 
 >>anyone working on sdr for ssm-only networks?
 >>
 >>dirk

 cheers

   jon

---

From: Dirk Ooms <[email-masked]>
Date: Wed, 15 Nov 2000 11:31:20 +0100

dirk

---

From: "HANSEN CHAN" <[email-masked]>
Date: Wed, 15 Nov 2000 07:32:10 -0500

To have SDP sessions available via the web. Is it the same as going to a webcast
site (e.g. Yahoo Broadcast and Lycos TV) and click on the program link? How does
my PC learn the multicast group address by clicking on the link?

Thanks,
Hansen

---

From: Gordon Rogier <[email-masked]>
Date: Wed, 15 Nov 2000 07:57:35 -0600 (CST)

> 4/ changing session management/annoucement mechanisms

granted i have missed the working group discussions, but i think you would
need to add to this layer2 switching issues.  i have not seen anyone even
start to touch this issue.  will igmp snoopers be upgradable, will
propietary methods (eg. cisco's igmp/cgmp) be upgradable to support the
SSM methods.  the content we are discussing here will be high enough bit
rate that campus level traffic management will be a critical factor.

--*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*--
Gordon Rogier                        [email-masked]            
Network Engineer                     785-864-0381wk 785-550-4468 cell
Great Plains Network                 785-864-9330 FAX

---

From: Supratik Bhattacharyya <[email-masked]>
Date: Wed, 15 Nov 2000 09:42:30 -0800

As an example of a web-based interface for SSM-cast, you can look at the UofO
SSM Trial page :

http://videolab.uoregon.edu/projects.html

Note that this is currently set up to use URD on the receiving host's DR, but this
is not
a fundamental restriction, and can be easily changed to support a v3 host running
v3-enabled
apps (with a v3 DR of course)...

Cheers,

--Supratik

---

From: Hugh LaMaster <[email-masked]>
Date: Wed, 15 Nov 2000 10:13:01 -0800 (PST)

> 4/ changing session management/annoucement mechanisms

I don't know how many people agree with me, but, although
SSM obviously has huge benefits for broadcast-type applications,
the benefits are not so obvious to me for all multicast applications.
So, personally, although I fully support the SSM deployment,
I don't want to abandon completely the capability for global 
shared trees, which I think will continue to be most appropriate
for large numbers of low datarate sources, such as distributed
simulations, as well as multicast-enabled games that were 
"threatened" a few years ago.

At the moment, the assignment of the SSM address space and
a wave of deployments over the next year will give us a
usable SSM infrastructure - that is, addressing item 1/
above - although, of course, /2, 3/, and 4/ will still be
there.  /4 is solvable, though not solved yet.  2/ and 3/ 
are what I see as the main problem, and even after solutions
are available, still won't be *automatic* in the case where 
that matters most -- "personal systems" (e.g. the gaggle of
PC-based systems running legacy Windows 95/98/me).

SSM does seem to have finally given multicast the appeal to 
commercial content providers that was not there before, though, 
so that demand-pull from users may finally start to have an
effect.

> university research department's normal activities....

If somebody is going to rewrite sdr to integrate SSM, I hope 
it is done so that it still handles traditional SAP announcements 
transparently in parallel, both on the receiving and announcement
side.  SAP will continue to be used for some time at least.

Questions/comments/refutations welcome.

--
 Hugh LaMaster, M/S 233-21,    Email: [email-masked]
 NASA Ames Research Center     Or:    [email-masked]
 Moffett Field, CA 94035-1000  Or:    [email-masked]
 Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Nov 2000 12:11:04 -0800 (PST)

> "threatened" a few years ago.

I don't know. I think that access-control, management and
scalability requirements will make it more and more obvious, that
handling source-discovery at the network layer will not fly in
the Internet. Especially not with the unsolved address allocation
problem for application sessions.

I wonder why nobody thinks of session management with a standardizable
solution for a session/ application layer RP function to handle session.
An application programmer really does not care if "joining to a session as
a source and/or receiver" is done with IP Multicast alone, or
if there's a session library that will do this: 

    Contacting some RP-server, signal to the RP if you are a
    source, maybe also if you are active or also a receiver, and
    then have the library also join towards the active currently
    active sources for this session - as indicated by the RP.

Conferencing solutions using unicast are doing things along this 
line since the beginning of time, only that each application has
it's own solution for it, which takes away the ability to really
set up session management facilities in an application independent
way. Maybe i just don't know the solutions space well enough there,
but with something like this i really don't see a need for
"global source-discovery in an ad-hoc managed address space", which
is what we have today.

Cheers

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 15 Nov 2000 16:53:07 -0800 (PST)

I suppose one way to make SAP work in SSM is to modify the protocol to
have the directly connected routers to active sources use unicast to
register with core "rendezvous points".  Then each of these rendezvous
points will talk to each other with another protocol to tell each other
about the active sources that they are each aware of.  Wait, this sounds
familiar...

SSM presents an interesing tradeoff where some functionality is reduced to
meet a much more common model as well as radically simplifying network
deployment.  Being only able to join a single source is inherantly
incompatible with something like SAP, but few commercial content providers
would disagree that sdr doesn't represent the commercially viable future
of multicast.  SSM hinges upon the mass appeal of one-to-many apps like
WMP, Real player and IP/TV, while eliminating the biggest hinderance to
deployment: a PIM-SM/MSDP RP-based infrastructure is too complex.

Maybe SSM is just a stepping stone to the full functionality that
shared-tree infrastructures provide.  But it will be a whole lot better
than what we have now, where multicast is virtually nowhere to be found.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Nov 2000 18:17:09 -0800 (PST)

> about the active sources that they are each aware of.  Wait, this sounds

Selling the spanish inquisition to protestants!

> than what we have now, where multicast is virtually nowhere to be found.

The whole point is that global source discovery in the network layer with
a non-hierarchically managed address space has shown to be a non-scaling
approach. There are things that sound cool in the first place and work
to a point but have some limits. Just because we learnt this about the
IP Multicast model after 10 years doesn't mean that the model is bad or
that we should force to make it work somehow, if there are much more
easy alternatives to get to the same results by just putting tasks into
different layers.

---

From: Ross Finlayson <[email-masked]>
Date: Wed, 15 Nov 2000 18:53:40 -0800

I'm sure that most SSM sessions will end up getting advertised on web 
pages, and launched from web browsers.  This is the technology that most 
people are familiar with, and it scales reasonably well for sessions that 
are long-lasting, and whose information doesn't change frequently (so that 
web caching can take effect, and so that users don't have to keep 
'refreshing' the web page).  (I just hope, though, that people standardize 
on using SDP to describe these sessions - either using data:// URLs 
embedded in web pages, or via links back to a web server.  I'd hate to see 
a proliferation of viewer-specific hacks like we see now with Real or 
Windows Media sessions.)

The main disadvantage of advertising SSM sessions on the web is that the 
announcements will be visible even to those who don't have 
SSM-connectivity.  So be prepared for lots of people asking "Why can't I 
receive this stream after I've launched it from your web site?!"

At the same time, though, I see no reason why *some* SSM sessions - 
especially those that are more ephemeral in nature - can't also be 
advertised within SDP directories, using single-source-SAP as the 
announcement protocol.  This probably makes the most sense for advertising 
multiple sessions that come from the same source (or at least, from the 
same provider); the SDP directory that advertises these sessions can then 
come from the same source (or provider).  However, I don't think there'll 
be much value in trying to have a single large global multicast session 
directory for announcing SSM sessions from independent providers - as we do 
now in the ISM world - because you either have to do this using ISM (which 
not all SSM receivers will have), or else use a SSM source (a single point 
of failure) with some separate unicast protocol needed for announcing 
session description data to that source.

>university research department's normal activities....

Actually, modifying "sdr" to handle launching SSM sessions - including the 
ability to use arbitrary SSM SDP/SAP directories - should not be all that 
difficult, I think.  The most recent "sdr" version already contains my 
patches to support launching of SDP "directory" sessions[*], so it already 
knows how to handle multiple, arbitrary SDP/SAP directories.  All that's 
needed now is the ability to recognize the special SDP syntax for SSM 
sessions, and the ability to subscribe to a SSM SDP/SAP directories using 
an apropriate IGMPv3 API call.

Needless to say, I'll be making such a change to "multikit" at some point :-)

         Ross.

[*] "sdr" currently supports only an old format for SDP "directory" 
sessions, not the newer format described in 
<draft-ietf-mmusic-sdp-directory-type-01.txt>

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 16 Nov 2000 08:26:03 +0000

>>approach. There are things that sound cool in the first place and work

not clear - the GLOP and ipv6 ways of allocating multicast introduce
_some_ hierarchiy - in fact its relatively easy to impose all sorts if
you have _enough_ address space.....

 >>easy alternatives to get to the same results by just putting tasks into

if yo uhave applications which genuijley have significant number of
sources  with dynamics, then the server solution does not scale - you
have just pushed the management problem to that of
1/ locating one of a set of servers (how)
2/ making servers fault tolerant (anyone for anycast? :-)
3/ managing the application state in an unnatural way
4/ putting performance (delay and procerssign) limits on the scale of
the application

ok so you could have a hierarchy of redundant servers....,and what
standard internet protocoos are you going to use to manage those?

no, i think we need to retain the deering multicast model and just
keep up the pressure on Large Router Vendors (this means you:-)
to be smart about scaling the routers up to meet the users
requirements rather than scaling the users expectations down to what
you want to do:-)

 cheers

   jon

---

From: Hugh LaMaster <[email-masked]>
Date: Thu, 16 Nov 2000 09:10:38 -0800 (PST)

> deployment: a PIM-SM/MSDP RP-based infrastructure is too complex.
                                                       ^^^^^^^^^^^

I agree that SSM is much more appealing to commercial providers
at this time, and covers 80% of the users and applications out there,
so, that's great.  If it motivates content providers, enterprises,
and consumer ISP's, wonderful.  But, it doesn't necessarily cover 
100% of the users and applications.

Also, a couple of message have mentioned the difficulties os PIM-SM,
RP's, etc., but, I honestly think it is *easy* compared to many things 
out there- it just doesn't have many people's bottom lines associated 
with it today.  (Compare PIM to, for example, what ISPs do regarding
traffic engineering (in general), or what enterprises do with frame-relay,
and ISDN, and tons of other messy stuff.  PIM is easy by contrast.)

The biggest problem we have today with MSDP is the same thing that
we have always had with multicast -- people generally don't monitor
things until the minute they need them, so, something may be broken
for a while before someone notices it.  When lots of people are
accessing lots of multicast content, network operators will start
hearing complaints when things break, just like they do now with
web access.

> than what we have now, where multicast is virtually nowhere to be found.
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Multicast is widely available on WANs.  By far the largest problem
is getting it into the enterprise LAN and out to the consumer.  
If SSM is the catalyst that gets content providers and consumers 
demanding multicast, that's great, but, you're still going to have 
to deal with all the legacy enterprise, dialup, tier-2/3 deployment 
issues that you had before.  [Hmm.  I'm plagiarizing...;-)  ]
The hope is, that, with new content providers embracing SSM,
the demand will be there, and hence, the motivation to work on
the deployment issues.

=======

The other issue is the future:  SSM will work fine for accessing
broadcast-type content-- there aren't going to be *that* many
content providers out there, and, consumers will expect to find
that content at the providers web site.  Additional router state
will be small.

SSM doesn't address the problem of a scalable multicast source 
directory (neither does the SAP-via-MSDP method either, really - 
MSDP won't scale to really large numbers of sources either).

SSM also doesn't address the problem of large numbers of "small"
groups.  I think we still need a pure shared-tree implementation
to handle the (1000's of low-bandwidth sources)X(1000's of groups)
problem.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 16 Nov 2000 09:59:09 -0800 (PST)

> you have _enough_ address space.....

Isn't the right phrase for IPv4 "If you had _enough_ address space..." ?

> 4/ putting performance (delay and procerssign) limits on the scale of

Well, /1 i think is not siginificantly more expensive if done outside the
network layer than inside. The way we have it now is to have one common
"server" (RP) infrastructure for all applications together, and isn't
it exactly this one size fits all" that limits flexibility introduces
unnecessary complexity and can not be individually be optimized for
particular suites of applications ?

/2 Sure, i love anycast ;-)

/3 I do not get it.
"Biking is an unnatural way of transportation (TM) automotive society" ?

/4 Only if we can assume that we can not build scaling server infrastructures
for large scale applications. I think we can. There must be something all
those content server boxes will be good for. How about this ? Wasn't there
sufficient research in distributed systems in the last 20 years to come up
with appropriate solutions for larger scale applications, as long as you
stick to some scenarios in the first place (instead of trying to solve
it generically for all of them together in the network layer) ?

> standard internet protocoos are you going to use to manage those?

Why does it have to be standardised in the IETF ? Why not some other place ?
Why are things like CORBA not standardised in the IETF ? Don't those
distributed applications relying on it run over the Internet also ?

> requirements rather than scaling the users expectations down to what

We won't take the holy grail away, Lancelot ;-)
I guess this router vendor would just love to see some return of investment
on multicast, and as far as i am concerned this in the first place means
to get ip packet replication in routers used and payed for. The control plane
operations will just follow the users application demands, and SSM is just
another alternative. If there were more interesting Internet-wide applications
that can not work well with SSM, then certainly the focus would be different.

Cheers
	Toerless

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 17 Nov 2000 07:57:06 +0000

>>it generically for all of them together in the network layer) ?

what i am tellng you is that there WASNT sufficient research in
distributed systems (i know - i was part of it:-)

IP level solutions are better at scaling for fault tolerance - most
the distributed server solutions are good up to Big Numbers like 3.

 >>distributed applications relying on it run over the Internet also ?

oh boy, so we dont need to be able to buy multi-vendor solutions? dont
be silly.

 >>We won't take the holy grail away, Lancelot ;-)

thanks....but it aint that hard if we buy juniper:-)

 >>that can not work well with SSM, then certainly the focus would be different.

hey, dont get me wrongh - i LOVE ssm - its cool, its good, it scales,
it makes really good coffee etc - dont let me put you off - just
trying to say: don't throw out the work on PIM bidir just yet:-)

 cheers

   jon

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 17 Nov 2000 00:28:52 -0800 (PST)

> oh boy, so we dont need to be able to buy multi-vendor solutions? dont

No, multi-vendor solutions are nice (well, if they work, as a customer
i've mostly encountered cases where  they don't, but let's not use practical
experience as a distraction for ideals one would like to follow).

I was only suggesting that the IETF is not the only place to standardise
multi-vendor solutions.

> thanks....but it aint that hard if we buy juniper:-)

Well, if ip multicast were ever to vanish completely due to ssm (which
i neither expect nor hope), then i'd rather guess that Cisco will still
have the last bastions of customers ("he who starts earlier needs to be
backward compatible much longer" - see also reference [Microsoft]).

> trying to say: don't throw out the work on PIM bidir just yet:-)

Oh, on the contrary. As far as architecture is concerned, SSM is so simple,
so well working, so uncontroversial,  so... boring ? Evolving on Bidir-PIM
is much more challenging.  Especially if you think about all the politics
on BGMP. Now just give us lots of customer incentive to evolve there...

Cheers
	Toerless

P.S.: There are no Corba applications with more than 3 hosts involved ? ;-))