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

[Hugh Holbrook <holbrook@cisco.com>]

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
wrote about resource discovery:

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

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

> > 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
> 
> "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."
>
> *** 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.
> 
> > application that desires to provide a secondary data source in case the
> > primary source fails must implement the failover mechanism in the
>                        ~~~~
> Similar to above: "must" -> "might"
> 
> > 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.
> 
> 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
> _______________________________________________
> ssm mailing list
> ssm@ietf.org
> https://www1.ietf.org/mailman/listinfo/ssm
> 
> _______________________________________________
> ssm mailing list
> ssm@ietf.org
> https://www1.ietf.org/mailman/listinfo/ssm
_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm