Re: [ssm] msnip status

hoerdt Mickael <hoerdt@clarinet.u-strasbg.fr> Thu, 20 October 2005 10:16 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXT3-0000se-He; Thu, 20 Oct 2005 06:16:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXT2-0000sX-J2 for ssm@megatron.ietf.org; Thu, 20 Oct 2005 06:16:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29417 for <ssm@ietf.org>; Thu, 20 Oct 2005 06:16:01 -0400 (EDT)
Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESXeu-0002J3-4b for ssm@ietf.org; Thu, 20 Oct 2005 06:28:29 -0400
Received: (qmail 22571 invoked for bounce); 20 Oct 2005 10:15:34 -0000
Received: from unknown (HELO ?129.241.205.105?) (hoerdt@unknown) by unknown with RC4-MD5 encrypted SMTP; 20 Oct 2005 10:15:34 -0000
Message-ID: <43576E56.4040805@clarinet.u-strasbg.fr>
Date: Thu, 20 Oct 2005 12:15:50 +0200
From: hoerdt Mickael <hoerdt@clarinet.u-strasbg.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051007 Debian/1.7.12-1
X-Accept-Language: en
MIME-Version: 1.0
To: Pekka Savola <pekkas@netcore.fi>
Subject: Re: [ssm] msnip status
References: <20051019124841.GL9025@storhaugen.uninett.no> <ce8f3212bc8ba11a7739b4c9433e3a22@innovationslab.net> <20051019231203.GG29643@cisco.com> <Pine.LNX.4.61.0510201201450.27313@netcore.fi>
In-Reply-To: <Pine.LNX.4.61.0510201201450.27313@netcore.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA29417
Cc: Toerless Eckert <eckert@cisco.com>, Brian Haberman <brian@innovationslab.net>, Isidor Kouvelas <kouvelas@cisco.com>, ssm mailing list <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

Hi,

MSNIP (or any logical equivalent, let call it protocol X) allows 
ressources saving at the following points of the network :

1. the DR(s).
2. the link connecting the DR to the multicast source host(s).
3. the host(s).

A possible scenario showing that protocol X is (relatively) useful would 
be the following :

. Exhaust the ressources available at any of these three points, 
sourcing multicast
  content without  protocol X.
. Activate protocol X, and replay the same scenario showing that now the 
ressources
  aren't exhausted.
 
Does it make sense to define a protocol X wich do not have to be 
deployed/implemented
in the routers, using possibily unicasting and/or pooling from the 
source ? As a multicast
application developer/coder, i would say that it depends on the SSM 
multicast service
availability....

Hoerdt Mickaƫl





Pekka Savola wrote:

> On Wed, 19 Oct 2005, Toerless Eckert wrote:
>
>> I think MSNIP tried to solve a key functionality for the SSM 
>> architecture,
>
>
> Could you elaborate a bit on what you think is this "key 
> functionality" and why exactly it's "key" (e.g., specific scenarios 
> you have in mind)?
>
> I'm having difficulty understanding the (relative) importance of a 
> sender being able to stay quiet if there are no receivers.  The waste 
> of bandwidth and processing power at the DR (who'd just discard the 
> traffic) doesn't seem to be sufficiently concinving at least in the 
> scenarios I have in mind.
>


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