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, 09 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
- [ssm] Session Relaying in SSM: architectural aspe… Kostas Katrinis
- Re: [ssm] Session Relaying in SSM: architectural … Marshall Eubanks