Re: [ssm] Session Relaying in SSM: architectural aspects

[Marshall Eubanks <marshall.eubanks at gmail.com>]

Are you familar with the AMT protocol ?

On 1/7/06, Kostas Katrinis <katrinis at tik.ee.ethz.ch> wrote:
> Hello all,
>
> within the premises of my PhD work I am studying multi-source
> functionality over SSM.
>
> Pertaining to supporting multiple sources within a single SSM session by
> using a session relay,
> the related bibliography (at least to my knowledge) agrees to placing
> the relay service at the application
> layer (due to many advantages not listed herein).
>
> Now, assuming an application-layer relay service, the possibilities for
> placing the relays are two:
>
> a) At group members
> b)"Inside" the network, using dedicated "proxies" (like Zappala proposed
> in [1]).
>
> Assuming that one does not want to go for a) (for instance because the
> worst case delay is twice as high
> as the worst case delay when using SPTs as proved in Holbrook's thesis),

Why is delay the primary metric here ? These are mostly broadcast or even
VOD precaching services, and delay is pretty irrelevent.  I would
argue that hop (regeneration) count
is a better metric. I  would also argue that P2P broadcasting is
likely to be an important player.

> the goal of my email is to ask, whether
> there is any insight/consensus on how the architectural model will look
> like for the b) option.
>

If I am understanding you, this is dealt with by AMT.
http://www.ietf.org/internet-drafts/draft-ietf-mboned-auto-multicast-05.txt


> Queries are for example of the type:
>
> 1) Who is going to provide the proxy (relay) service? Is it the ISP for
> all SSM groups or does any application provider
> (like a gaming company or a videoconferencing company) have to develop
> its own service. Or just have a dedicated
> provider for the service (e.g. like Akamai).

This is really more a business problem than a technical problem.

In the AMT proposal, this is provided primarily by ISP's, although if
I deploy the service
I would certainly allocate bandwidth to it. A decent question is, is
it intended to supplant or enhance native multicast ? (Very roughly),
if supplant, then Akamai or the source, if enhance, the ISP's.

In other, P2P type proposals (say, with BitTorrent), this is done at the edge.

>
> 2) How many of the benefits of SSM are lost (e.g. source filtering), if
> one goes for the relaying solution.
>

I am not sure why you can't source filter in AMT. Please explain.

> Think of it as searching an answer to the question: "how good can the
> relay solution get without sacrificing the deployment
> benefits of the SSM model (whatever the latter is supposed to mean)".
>
> I would greatly appreciate any inputs, related work hints etc.
>

Hope all these questions are  useful.

> Thanks,
> Kostas.
>

Marshall
>
>
>
>
>
>
>
>
> [1] Daniel Zappala, and Aaron Fabbri, Using SSM Proxies to Provide
> Efficient Multiple-Source Multicast Delivery
> <http://faculty.cs.byu.edu/%7Ezappala/pubs/ssm-gis01.pdf>. IEEE
> Globecom, Sixth Global Internet Symposium, Volume 3, pages 1590-1594,
> November 2001.
>
> _______________________________________________
> ssm mailing list
> ssm at ietf.org
> https://www1.ietf.org/mailman/listinfo/ssm
>

_______________________________________________
ssm mailing list
ssm at ietf.org
https://www1.ietf.org/mailman/listinfo/ssm