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

Hugh Holbrook <holbrook@dsg.stanford.edu> Fri, 17 January 2003 17:55 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29943 for <ssm-archive@lists.ietf.org>; Fri, 17 Jan 2003 12:55:56 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HIB1J19022; Fri, 17 Jan 2003 13:11:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HI1tJ17946 for <ssm@optimus.ietf.org>; Fri, 17 Jan 2003 13:01:55 -0500
Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29660 for <ssm@ietf.org>; Fri, 17 Jan 2003 12:45:43 -0500 (EST)
Received: from holbrook-laptop.cisco.com (sjc-vpn2-304.cisco.com [10.21.113.48]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0HHmxFp013308; Fri, 17 Jan 2003 09:48:59 -0800 (PST)
Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 67CD010B7A7; Fri, 17 Jan 2003 01:55:57 -0500 (EST)
From: Hugh Holbrook <holbrook@dsg.stanford.edu>
To: Pavlin Radoslavov <pavlin@icir.org>
Cc: holbrook@cisco.com, Michael Luby <luby@digitalfountain.com>, Pavlin Radoslavov <pavlin@icir.org>, ssm@ietf.org
In-reply-to: <200301170434.h0H4Yp2U067291@possum.icir.org>
Subject: Re: Re: [ssm] Re: last call comments on ssm-arch doc
Reply-To: holbrook@dsg.stanford.edu
Message-Id: <20030117065557.67CD010B7A7@holbrook-laptop.cisco.com>
Date: Fri, 17 Jan 2003 01:55:57 -0500
Sender: ssm-admin@ietf.org
Errors-To: ssm-admin@ietf.org
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Id: Source-Specific Multicast <ssm.ietf.org>
List-Post: <mailto:ssm@ietf.org>
List-Help: <mailto:ssm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=subscribe>

Great.  Thanks for your comments.
-Hugh
> Cc: "Michael Luby" <luby@digitalfountain.com>,
> 	"Pavlin Radoslavov" <pavlin@icir.org>, ssm@ietf.org
> Date: Thu, 16 Jan 2003 20:34:51 -0800
> From: Pavlin Radoslavov <pavlin@icir.org>
> 
> > 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.
> 
> Looks good to me.
> 
> > 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
> 
> Fine with me.
> 
> > 
> > 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.
> 
> I think there is no need to say that, so the "Peer-to-peer..."
> paragraph is just fine.
> 
> Thanks,
> Pavlin
> 
> > 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?
> _______________________________________________
> 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