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

[Toerless Eckert <[e-mail]>]

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.

Cheers
	Toerless
_______________________________________________
Ssm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ssm