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

Toerless Eckert <> Wed, 15 January 2003 15:54 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id KAA00787 for <>; Wed, 15 Jan 2003 10:54:46 -0500 (EST)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h0FG9AJ20972; Wed, 15 Jan 2003 11:09:10 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h0FG2WJ20078 for <>; Wed, 15 Jan 2003 11:02:32 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id KAA00619 for <>; Wed, 15 Jan 2003 10:47:19 -0500 (EST)
Received: from ( []) by (8.12.2/8.12.6) with ESMTP id h0FFof0E022051; Wed, 15 Jan 2003 07:50:41 -0800 (PST)
Received: (from eckert@localhost) by (8.8.8/2.6/Cisco List Logging/8.8.8) id HAA02537; Wed, 15 Jan 2003 07:50:41 -0800 (PST)
Date: Wed, 15 Jan 2003 07:50:41 -0800
From: Toerless Eckert <>
To: Rolland Vida <>
Cc: Toerless Eckert <>,
Subject: Re: [ssm] Re: last call comments on ssm-arch doc
Message-ID: <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4i
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Source-Specific Multicast <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On Wed, Jan 15, 2003 at 04:38:01PM +0100, Rolland Vida wrote:
> Toerless,
> > If you're building the white board application as pure peer to peer,
> > each peer has to become a SSM channel source. If you implement the
> > application as a client/server system, the clients could unicast to
> > the server, and the server would have one SSM channel to all clients.
> > Advantages: Easier model for access control, session management
> > and ressource allocation then in a full peer to peer model.
> This is a nice trick to provide a multi-source service through SSM. However,
> there are also some drawbacks: no source filtering, no shortest path
> delivery. It is basicly like standard PIM-SM: everybody sends to the RP
> (server), which forwards then on the shared tree (here the SSM channel). And
> as in PIM-SM already the shared tree is switched for a source-specific tree
> (to optimize delivery), why should it be now acceptable to use such a shared
> tree just to enable multi-source SSM?

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. And security 
of the applications data flow is now completely under the control of
the application.

Reflection at the PIM-SM RP is not under application control, and source
filtering on the RP doesn't really work except for well controlled and
architected intradomain applications. Also, it's static only. Besides,
there are so many shortcut possiblities in PIM-SM that it's almost not
possible to really guarantee in all situations that traffic has to go
through the RP for means of filtering.

> >   b) client/server control, peer-to-peer data:
> >      clients have control connection with server to learn
> >      about peers multicasting. Data itself is multicasted
> >      on SSM channels from each client to other interested
> >      clients.
> >
> >   c) peer-to-peer control and data:
> >      There is no central server. Instead new peers have to
> >      somehow discover at least one existing peer, who can then
> >      signal to all other peers the existance of this new peer.
> >      This peer-to-peer control connections can be unicast
> >      with some topology between peers or can be SSM.
> The difference between b) and c) seems to be only the way how the receivers
> learn the address of the SSM source. But, as far as I know, it was always
> said that this is out of scope of the SSM specs. Hugh said in its last
> sentence: "SSM does not support network-layer multicast resource discovery".
> In my understanding, this is related exactly to our discussion.

I was talking about the application architecture on layers above SSM,
and the difference between b) and c) is mostly complexity: b) is simple
and well understood. c) is highly complex, like a self learning topology.
You can try to approach c) very simple, but that means full mesh and that
means wasted ressources.

Ssm mailing list