From ssm-bounces@ietf.org Sat Jan 07 09:50:10 2006 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 1EvFOU-0003oe-FS; Sat, 07 Jan 2006 09:50:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvFOS-0003mm-TD for ssm@megatron.ietf.org; Sat, 07 Jan 2006 09:50:08 -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 JAA13308 for ; Sat, 7 Jan 2006 09:48:51 -0500 (EST) Received: from smtp.ee.ethz.ch ([129.132.2.219] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvFUX-0004n8-VI for ssm@ietf.org; Sat, 07 Jan 2006 09:56:28 -0500 Received: from localhost (tranquillity.ee.ethz.ch [129.132.2.222]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6B678D938C for ; Sat, 7 Jan 2006 15:50:05 +0100 (MET) Received: from smtp.ee.ethz.ch ([129.132.2.217]) by localhost (tranquillity [129.132.2.222]) (amavisd-new, port 10024) with LMTP id 06927-01-4 for ; Sat, 7 Jan 2006 15:50:05 +0100 (MET) Received: from [10.0.0.9] (athedsl-01672.otenet.gr [87.202.6.148]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9F5EED935B for ; Sat, 7 Jan 2006 15:50:04 +0100 (MET) Message-ID: <43BFE329.8040402@tik.ee.ethz.ch> Date: Sat, 07 Jan 2006 16:50:01 +0100 From: Kostas Katrinis User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ssm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at ee.ethz.ch X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Subject: [ssm] Session Relaying in SSM: architectural aspects X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: katrinis@tik.ee.ethz.ch List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org 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), 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. 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). 2) How many of the benefits of SSM are lost (e.g. source filtering), if one goes for the relaying solution. 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. Thanks, Kostas. [1] Daniel Zappala, and Aaron Fabbri, Using SSM Proxies to Provide Efficient Multiple-Source Multicast Delivery . 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 From ssm-bounces@ietf.org Mon Jan 09 20:01:15 2006 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 ; 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 ; 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: Date: Mon, 9 Jan 2006 20:01:07 -0500 From: Marshall Eubanks 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 List-Unsubscribe: , List-Post: List-Help: List-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 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 ed= ge. > > 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 > . 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