[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Use of SAP in a PIM SSM Network
How does this help the end user ? It seems that having a mechanism
similar
in functionality to SAP would be preferred by users. Using the direct
TV model,
a user may not want to access the provider's channel to view the list
of streams
available from that provider. By having a directory service, users
will have one
place to access to choose any content from any provider. Scalability
will be one
of the issues to resolve, ultimately the flexibility of this model
will likely make
it more desirable and usable.
Thanks,
Zaid
-----Original Message-----
From: Mike Luby <luby@digitalfountain.com>
To: tme@21rst-century.com <tme@21rst-century.com>; Toerless Eckert
<eckert@cisco.com>; Ross Finlayson <finlayson@live.com>; Al Adler
<al@on-the-i.com>
Cc: HANSEN CHAN <hansen.chan@alcatel.com>;
ssm-interest@external.cisco.com <ssm-interest@external.cisco.com>
Date: Tuesday, November 14, 2000 11:36 PM
Subject: RE: Use of SAP in a PIM SSM Network
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:tme@21rst-century.com]
Sent: Tuesday, November 14, 2000 6:43 PM
To: Toerless Eckert; Ross Finlayson; Al Adler
Cc: HANSEN CHAN; ssm-interest@external.cisco.com
Subject: Re: Use of SAP in a PIM SSM Network
Toerless Eckert wrote:
>
> > 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?
>
> 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
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 : tme@on-the-i.com http://www.on-the-i.com