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

From: Hugh Holbrook <[email-masked]>
Date: Wed, 15 Jan 2003 04:33:05 -0500 (EST)

I wrote:
> Pavlin wrote:
> >  * After enumerating the benefits of the SSM model in Section 1,
> >    what about enumerating its limitations/drawbacks? :)
> 
> Fair enough.  I'll come up with something.

I promised to come up with some text.  How about this:

SSM is particularly well-suited to dissemination-style applications with
a single sender.  It can be used in multi-source applications, but the
multi-source "rendezvous" functionality must be implemented by the
application or by an application-layer library.  For instance, an
application that desires to provide a secondary data source in case the
primary source fails must implement the failover mechanism in the
application itself, presumably by using two channels, as two hosts
cannot both send to a single SSM channel.  SSM does not support network-
layer multicast resource discovery.

-Hugh
_______________________________________________
Ssm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ssm

---

From: Hugh Holbrook <[email-masked]>
Date: Wed, 15 Jan 2003 04:33:05 -0500 (EST)

-Hugh

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 15 Jan 2003 12:26:55 +0100 (MET)

Hugh,

> layer multicast resource discovery.

I'm confusing the terminology (or definition) of "channel" now.

Let's imagine something like an application of a panel discussion.
E.g., now, there are two senders (S1 and S2) as the speakers, and then
we do ((S1,S2),G) join. In this case, does this panel discussion works
as "a single channel" application or "two channels" application?
This example can be similar case of using a whiteboard application. S1
and S2 write some words on a same whiteboard, and many receivers watch
it. In this application, do we say the receivers join "a single
channel" or "two channels"?

I've thought these answers would be "a single channel" since both S1
and S2 work for a same application, but your statements would make me
reform...
So, if each answer is "two channels", is it correct that a channel
MUST consist of a single source except such failover mechanism? Or,
are there any other applications that would prompt ((multiple Ss),G)
join for a single channel?
If the answer is "a single channel", then above statements might not
be fair enough for me. Especially, "but the multi-source "rendezvous"
functionality must be implemented by the application or by an
application-layer library." seems to be strange.

Thanks.
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 15 Jan 2003 12:26:55 +0100 (MET)

Hugh,

Thanks.

---

From: "Rolland Vida" <[email-masked]>
Date: Wed, 15 Jan 2003 14:19:05 +0100

Hitoshi,

> as "a single channel" application or "two channels" application?

We obviously have two channels: (S1, G) and (S2,G). The fact that a receiver
sends an IGMPv3 join containing (INCLUDE(S1,S2),G) does not mean that there
is a unified channel, but that he wants to join two channels in the same
time.

You might have another receiver that sends INCLUDE(S1,G) only, so the
channels have to be separated.

> and S2 work for a same application,

The fact that it is the same application or not has nothing to do with it.
Each source has its own channel.

> MUST consist of a single source except such failover mechanism?

As Hugh said, the channel ALWAYS corresponds to a single source. If we want
a secondary source to assure a failover mechanism for example, it should
have its own channel. But to assure the transparency of the mechanism for
the end-user, the binding between these two channels should be built in the
application itself, and not at the network layer. At least this is what I
understood from Hugh's message, and this is what seems to be correct for me
too.

Regards,
Rolland Vida

---

From: "Rolland Vida" <[email-masked]>
Date: Wed, 15 Jan 2003 14:19:05 +0100

Hitoshi,

Regards,
Rolland Vida

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 15 Jan 2003 15:11:09 +0100 (MET)

> have its own channel.

Okay, I understand.

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 15 Jan 2003 15:11:09 +0100 (MET)

Okay, I understand.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jan 2003 07:05:59 -0800

One note on the discussed application requirement: If you're
building a pure ad-hoc multi-peer application then what was said in before
on this thread is correct. One could argue though that in face of
overwhelmingly web based or bound applications client/server models
for application architectures have become more ubiquitous because
they provide easier architectural solution to some typical problems,
and if such a client/server architecture is used, then the use
of IPmulticast or SSM specifically can easily be designed to be
really "single source". Eg:

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. Given
that today most networked applications are somehow started via the
web, makes it quite easy to imagine the typical solution to be one
involving some web server applet or the like.

So, architecturally, i think one can make three classes of
SSM peer-to-peer applications:

  a) client/server control and data:
     clients send unicast to server, server multicasts on one
     or multiple SSM channels back to clients.
  
  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.

From the applications i know, it seems to me that c) is today only
predominant in application that have lots of good reasons to avoid
servers. The typical examples of course are those in which the
server(s) would be in danger of being sued or bombed away anyhow
(eg: typical file-sharing software or military applications). 

For typical commercial applications you almost always resort to
a) or b), and then b) typically has a lot of advantages on access
control, synchronization, etc., and a) is mostly used in cases
where the added efficiency of avoiding passind data through a
server becomes important. So from that perspective i think that
SSM quite well, if not better fits the typical application retuirements
than compared to ASM.

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jan 2003 07:05:59 -0800

Cheers
	Toerless

---

From: "Rolland Vida" <[email-masked]>
Date: Wed, 15 Jan 2003 16:38:01 +0100

Toerless,

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

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

Regards,
Rolland

---

From: "Rolland Vida" <[email-masked]>
Date: Wed, 15 Jan 2003 16:38:01 +0100

Toerless,

Regards,
Rolland

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jan 2003 07:50:41 -0800

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

> 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

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jan 2003 07:50:41 -0800

Cheers
	Toerless

---

From: "Rolland Vida" <[email-masked]>
Date: Wed, 15 Jan 2003 17:08:46 +0100

> 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
[email-masked]

---

From: "Rolland Vida" <[email-masked]>
Date: Wed, 15 Jan 2003 17:08:46 +0100

Regards,
Rolland

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jan 2003 09:00:56 -0800

On Wed, Jan 15, 2003 at 05:08:46PM +0100, Rolland Vida wrote:
> quite different from what SSM was originaly meant for.

I think that that opinion requires a narrow minded expectation on what
SSM was meant for ;-))

> One basic feature of

Not true. If you ONLY want to have a server for reasons of securities et. al.,
then you can still have this server reflect each sources traffic on an
individual channel. You don't save SSM channels, but this can help you
hide the IP addresses of the sources for example for scurity reasons.

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jan 2003 09:00:56 -0800

Cheers
	Toerless

---

From: Pavlin Radoslavov <[email-masked]>
Date: Wed, 15 Jan 2003 13:54:57 -0800

> I promised to come up with some text.  How about this:

Overall looks good to me. Few comments included below.

> application or by an application-layer library.  For instance, an

"must" is probably a too strong word. Indeed, even though it appears
that application-level solution is the only (reasonable) solution,
someone might be able to come-up with some alternative, so it should
not appear that the document discourages other solutions.

Rewording suggestion:
Replace
  "must be implemented by the application or by an application-layer
   library."
With something like
  "might be implemented in the application level or by some other
alternative solution."

> primary source fails must implement the failover mechanism in the
                       ~~~~
Similar to above: "must" -> "might"

> layer multicast resource discovery.

Strictly speaking, the last sentence is not absolutely true. For
example, lets say that there is something like Resource Discovery
Agent with address S1. Then, all servers supporting service X might
join SSM group (S1,G1), and all servers supporting Y might join SSM
group (S1,G2). If someone wants to do resource discovery, the
Resource Discovery Agent can relay the request to discover the
servers supporting X or Y.

Hence, what about modifying the last sentence to say that resource
discovery might be possible, but with the help of additional
support, such as application-level relay.

Thanks,
Pavlin

---

From: Pavlin Radoslavov <[email-masked]>
Date: Wed, 15 Jan 2003 13:54:57 -0800

Rewording suggestion:
Replace

                       ~~~~

Thanks,
Pavlin

---

From: "Michael Luby" <[email-masked]>
Date: Wed, 15 Jan 2003 15:02:31 -0800

Good direction to go, and I'd go even a bit farther, see comments below
(lines that start with ***).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Pavlin
Radoslavov
Sent: Wednesday, January 15, 2003 1:55 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [ssm] Re: last call comments on ssm-arch doc

Rewording suggestion:
Replace

*** Suggested further rewording: ... It can be used in multi-source
applications,
*** but just like applications that use unicast as the underlying transport
*** the multi-source "rendezvous" functionality can be implemented by the
*** application or by some other alternative solution.

                       ~~~~

Thanks,
Pavlin

---

From: "Michael Luby" <[email-masked]>
Date: Wed, 15 Jan 2003 15:02:31 -0800

-----Original Message-----

Rewording suggestion:
Replace

                       ~~~~

Thanks,
Pavlin

---

From: Daniel Zappala <[email-masked]>
Date: 15 Jan 2003 22:13:25 -0800

> of the applications data flow is now completely under the control of

Well put.  I'd also like to add that you can get around the delay
penalty (because shortest paths are no longer used if all data is
relayed through a single source).  You just use the primary source (the
application-level relay) to bootstrap other relays.  See:

	D. Zappala, and A. Fabbri, Using SSM Proxies to Provide 
	Efficient Multiple-Source Multicast Delivery. IEEE Globecom,
	Sixth Global Internet Symposium, November, 2001.

at

	http://www.cs.uoregon.edu/~zappala/uo/uo.publications.html
or
	http://www.nrg.cs.uoregon.edu/pubs/ssm_gis01.pdf

-- 
======================================================================
Daniel Zappala                                    Computer Science
Assistant Professor                               University of Oregon

---

From: Daniel Zappala <[email-masked]>
Date: 15 Jan 2003 22:13:25 -0800

at

---

From: Hugh Holbrook <[email-masked]>
Date: Thu, 16 Jan 2003 02:12:47 -0500 (EST)

Pavlin and Mike:

I like both your suggestions regarding the building of multi-sender
apps with SSM.  Here's a revision that incorporates your requests; I
think this is an improvement.

    SSM is particularly well-suited to dissemination-style applications
    with a single sender.  It can be used to build multi-source
    applications, but the multi-source "rendezvous" functionality does not
    occur in the network layer.  Just like in an application that uses
    unicast as the underlying transport, this functionality can be
    implemented by the application or by an application-layer library.
    For instance, an application that desires to provide a secondary data
    source in case the primary source fails over might implement this by
    using one channel for each source and advertising both of them to
    receivers.

I'm having more trouble addressing Pavlin's comments regarding what I

> support, such as application-level relay.

I don't like the specific phrase that you suggest, Pavlin: "with the
help of additional support, such as application-level relay" because
it leaves me wondering what other possibilities there might be besides
application-level relaying, and I can't actually think of any.

So how about if I simply say this:

    Peer-to-peer multicast resource discovery of the form in
    which a client sends a multicast query directly to a "service
    location group" to which servers listen is not directly supported
    by SSM

This is true and doesn't rule out other forms of service discovery.
If the group thinks we need to say more about resource discovery than
this, then I also wrote this

    SSM might play a role in a resource discovery
    service as a mechanism that, for instance, well-known relays can
    use to forward client queries or server advertisements to
    interested recipients.

The latter bit of text has the problem for me that I don't actually
think this is a very good application architecture and I hesitate to
make the text look like it endorses it as a good use of SSM.  Once
you've got a set of well-known servers, why wouldn't you just register
the services with them via unicast and let clients do normal unicast
queries?

Any comments or suggestions?

-Hugh

---

From: Hugh Holbrook <[email-masked]>
Date: Thu, 16 Jan 2003 02:12:47 -0500 (EST)

Pavlin and Mike:

-Hugh

---

From: Hugh Holbrook <[email-masked]>
Date: Thu, 16 Jan 2003 20:40:56 -0500 (EST)

<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 <[email-masked]>
> Cc: Toerless Eckert <[email-masked]>, [email-masked]
>

---

From: Hugh Holbrook <[email-masked]>
Date: Thu, 16 Jan 2003 20:40:56 -0500 (EST)

<ShamelessPlug>

</ShamelessPlug>

Regards,
-Hugh

---

From: Pavlin Radoslavov <[email-masked]>
Date: Thu, 16 Jan 2003 20:34:51 -0800

>     using one channel for each source and advertising both of them to

Looks good to me.

>     location group" to which servers listen is not directly supported

Fine with me.

>     use to forward client queries or server advertisements to

I think there is no need to say that, so the "Peer-to-peer..."
paragraph is just fine.

Thanks,
Pavlin

---

From: Pavlin Radoslavov <[email-masked]>
Date: Thu, 16 Jan 2003 20:34:51 -0800

Looks good to me.

Fine with me.

Thanks,
Pavlin

---

From: Hugh Holbrook <[email-masked]>
Date: Fri, 17 Jan 2003 01:55:57 -0500 (EST)

Great.  Thanks for your comments.
-Hugh
> Cc: "Michael Luby" <[email-masked]>,
> 	"Pavlin Radoslavov" <[email-masked]>, [email-masked]
> Date: Thu, 16 Jan 2003 20:34:51 -0800
> From: Pavlin Radoslavov <[email-masked]>
>

---

From: Hugh Holbrook <[email-masked]>
Date: Fri, 17 Jan 2003 01:55:57 -0500 (EST)

---

From: Hugh Holbrook <[email-masked]>
Date: Fri, 17 Jan 2003 13:09:43 -0500 (EST)

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

Hopefully these are the last tweaks.

Hitoshi pointed out that this sentence of what I wrote

>     with a single sender.  

can be interpreted to mean that SSM isn't well-suited to applications
with more than one sender.  I think he is right and furthermore, I
realized that I'm missing a fundamental aspect in this paragraph: The
key attribute of an SSM-based application that introduces the need for
application-layer rendezvous is not the fact that there are multiple
senders but the fact that the senders are not all known in advance, so
I ought to say that.

Furthermore, my example application of a backup data source is more in
the category one of an application with two sources that are known in
advance, so I moved it to follow the text that describes that
application model.

So... this is hopefully my last try on this paragraph.  

  SSM is particularly well-suited to dissemination-style applications
  with one or more senders whose identities are known before the
  application begins.  For instance, a data dissemination application
  that desires to provide a secondary data source in case the primary
  source fails over might implement this by using one channel for each
  source and advertising both of them to receivers.  It can be used to
  build multi-source applications where all participants' identities are
  not known in advance, but the multi-source "rendezvous" functionality
  does not occur in the network layer.  Just like in an application that
  uses unicast as the underlying transport, this functionality can be
  implemented by the application or by an application-layer library.

-Hugh

---

From: Hugh Holbrook <[email-masked]>
Date: Fri, 17 Jan 2003 13:09:43 -0500 (EST)

-Hugh

---

From: Pavlin Radoslavov <[email-masked]>
Date: Fri, 17 Jan 2003 11:23:48 -0800

[ Hopefully my last comment :) ]

>   Peer-to-peer multicast resource discovery of the form in

What about removing "Peer-to-peer", because I think it is not really
needed here. Further, to me it has some association with
application-level multicast, and I guess this is not what you meant
here.

Pavlin

---

From: Pavlin Radoslavov <[email-masked]>
Date: Fri, 17 Jan 2003 11:23:48 -0800

Pavlin

---

From: Hugh Holbrook <[email-masked]>
Date: Fri, 17 Jan 2003 14:36:12 -0500 (EST)

I agree.  Done.
-Hugh

> Cc: [email-masked], Pavlin Radoslavov <[email-masked]>,
> 	"Michael Luby" <[email-masked]>, [email-masked]
> Date: Fri, 17 Jan 2003 11:23:48 -0800

---

From: Hugh Holbrook <[email-masked]>
Date: Fri, 17 Jan 2003 14:36:12 -0500 (EST)

I agree.  Done.
-Hugh