[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Use of SAP in a PIM SSM Network
IMHO, the use of SAP may diminish the merit of SSM anyway.
As an alternative for the directory service that users will access to choose
any content from any provider,
we may think of a common web page service, supported by many content
providers.
Anyway, SAP has concerns that its traffic has to be generated and delivered
to all the users including a large number of uninterest users, and this may
give the non-trivial traffic burden to ISPs.
Seok J. Koh
ETRI/PEC
sjkoh@pec.etri.re.kr
----- Original Message -----
From: zaid <zalbanna@MCI.NET>
To: Mike Luby <luby@digitalfountain.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>
Sent: Wednesday, November 15, 2000 3:01 PM
Subject: 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
>
>
>