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

[Hugh Holbrook <[e-mail]>]

<ShamelessPlug>

While we're on the topic, I may as well plug my PhD Thesis (which is
basically about SSM), because it talks at some length about all of the
possible application architectures that Toerless laid out below.

  http://www.dsg.stanford.edu/holbrook/dissertation.ps.gz (two-sided)
  http://www.dsg.stanford.edu/holbrook/dissertation-oneside.ps.gz (one-sided)

Chapters 6, 7, and 8 deal at some length with ways of building
multi-participant applications using SSM and the associated costs and
tradeoffs, including comparisons to various flavors of ASM.

</ShamelessPlug>

Regards,
-Hugh


> Date: Wed, 15 Jan 2003 07:50:41 -0800
> From: Toerless Eckert <[e-mail]>
> Cc: Toerless Eckert <[e-mail]>, [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
_______________________________________________
ssm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ssm