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

"Rolland Vida" <> Wed, 15 January 2003 15:43 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id KAA00487 for <>; Wed, 15 Jan 2003 10:43:24 -0500 (EST)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h0FFvkJ19661; Wed, 15 Jan 2003 10:57:46 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h0FFo5J19266 for <>; Wed, 15 Jan 2003 10:50:05 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id KAA00167 for <>; Wed, 15 Jan 2003 10:34:48 -0500 (EST)
Received: from ( []) by (8.12.4/jtpda-5.4+victor) with ESMTP id h0FFc1mT009626 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Wed, 15 Jan 2003 16:38:01 +0100
Received: from otos (otos []) by (8.11.6/8.11.3) with SMTP id h0FFc1318894; Wed, 15 Jan 2003 16:38:01 +0100 (MET)
From: Rolland Vida <>
To: Toerless Eckert <>
Subject: RE: [ssm] Re: last call comments on ssm-arch doc
Date: Wed, 15 Jan 2003 16:38:01 +0100
Message-ID: <>
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: <>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Source-Specific Multicast <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit


> 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?

>   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.


Ssm mailing list