RE: [ssm] Re: last call comments on ssm-arch doc

"Rolland Vida" <Rolland.Vida@lip6.fr> Wed, 15 January 2003 16:13 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01546 for <ssm-archive@lists.ietf.org>; Wed, 15 Jan 2003 11:13:56 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGSIJ22115; Wed, 15 Jan 2003 11:28:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGLgJ21810 for <ssm@optimus.ietf.org>; Wed, 15 Jan 2003 11:21:42 -0500
Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01238 for <ssm@ietf.org>; Wed, 15 Jan 2003 11:06:30 -0500 (EST)
Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h0FG8kmT012506 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Wed, 15 Jan 2003 17:08:46 +0100
X-pt: isis.lip6.fr
Received: from otos (otos [132.227.61.47]) by tibre.lip6.fr (8.11.6/8.11.3) with SMTP id h0FG8k320015; Wed, 15 Jan 2003 17:08:46 +0100 (MET)
From: Rolland Vida <Rolland.Vida@lip6.fr>
To: Toerless Eckert <eckert@cisco.com>
Cc: ssm@ietf.org
Subject: RE: [ssm] Re: last call comments on ssm-arch doc
Date: Wed, 15 Jan 2003 17:08:46 +0100
Message-ID: <NDBBLPHLPKFAHIKICCDPCEFMCMAA.Rolland.Vida@lip6.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <20030115155041.GF2103@cypher.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Scanned-By: isis.lip6.fr
Content-Transfer-Encoding: 7bit
Sender: ssm-admin@ietf.org
Errors-To: ssm-admin@ietf.org
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Id: Source-Specific Multicast <ssm.ietf.org>
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>
Content-Transfer-Encoding: 7bit

> Because in SSM the reflection is done at application level, so the
> reflecting server can do a lot of useful stuff like source filtering
> (access control), (re-)encoding/fec, (re-)encryption, filtering,
> synchronization, buffering, shaping, adding coffee.

It depends on the application. For some, I agree that this model can be
useful. for a small size videoconference for example, you could mix all the
voice flows together at the server, and send out only one voice stream on
the SSM channel (for the video it's more complicated...)

But in any case, I see it as a way to use SSM for doing something that is
quite different from what SSM was originaly meant for. One basic feature of
SSM is source filtering. In your model the server can only filter out
malicious sources for example. But if two different receivers want to listen
to two different "legal" sources, and do not want to listen to nobody else,
your server can never support that on the same SSM channel.

Regards,
Rolland

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