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

Marshall Eubanks <marshall.eubanks@gmail.com> Tue, 10 January 2006 01:01 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew7sx-0000dK-JG; Mon, 09 Jan 2006 20:01:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew7sv-0000cP-Ar for ssm@megatron.ietf.org; Mon, 09 Jan 2006 20:01:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15471 for <ssm@ietf.org>; Mon, 9 Jan 2006 19:59:53 -0500 (EST)
Received: from zproxy.gmail.com ([64.233.162.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew7zU-0004t6-L7 for ssm@ietf.org; Mon, 09 Jan 2006 20:08:02 -0500
Received: by zproxy.gmail.com with SMTP id 9so281990nzo for <ssm@ietf.org>; Mon, 09 Jan 2006 17:01:07 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=buDEJKVc0iuT8jDfzHI77xdrXR9yByM9qwVoEl7Y9cqZKFIi/0agXgIG3ENZCg/BhxgftX7RBaxUz3Q/CzXYmEBv7VYp1ORx1cxKj+37d6EAH78WeC4/8A/b2snv67+fgFy/Q13aEdbxlv4HwRvM7s07vu/GR6hJfucPDc1fGIQ=
Received: by 10.36.43.13 with SMTP id q13mr13428890nzq; Mon, 09 Jan 2006 17:01:07 -0800 (PST)
Received: by 10.36.46.2 with HTTP; Mon, 9 Jan 2006 17:01:07 -0800 (PST)
Message-ID: <dcad22d80601091701v3e3bed5cn3d9871381e5230f1@mail.gmail.com>
Date: Mon, 9 Jan 2006 20:01:07 -0500
From: Marshall Eubanks <marshall.eubanks@gmail.com>
To: katrinis@tik.ee.ethz.ch
Subject: Re: [ssm] Session Relaying in SSM: architectural aspects
In-Reply-To: <43BFE329.8040402@tik.ee.ethz.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <43BFE329.8040402@tik.ee.ethz.ch>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Content-Transfer-Encoding: quoted-printable
Cc: ssm@ietf.org
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Source-Specific Multicast <ssm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ssm@ietf.org>
List-Help: <mailto:ssm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=subscribe>
Sender: ssm-bounces@ietf.org
Errors-To: ssm-bounces@ietf.org

Are you familar with the AMT protocol ?

On 1/7/06, Kostas Katrinis <katrinis@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@ietf.org
> https://www1.ietf.org/mailman/listinfo/ssm
>

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