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
- [ssm] Re: last call comments on ssm-arch doc Hugh Holbrook
- Re: [ssm] Re: last call comments on ssm-arch doc Hitoshi Asaeda
- RE: [ssm] Re: last call comments on ssm-arch doc Rolland Vida
- Re: [ssm] Re: last call comments on ssm-arch doc Hitoshi Asaeda
- Re: [ssm] Re: last call comments on ssm-arch doc Toerless Eckert
- RE: [ssm] Re: last call comments on ssm-arch doc Rolland Vida
- Re: [ssm] Re: last call comments on ssm-arch doc Toerless Eckert
- RE: [ssm] Re: last call comments on ssm-arch doc Rolland Vida
- Re: [ssm] Re: last call comments on ssm-arch doc Toerless Eckert
- Re: [ssm] Re: last call comments on ssm-arch doc Pavlin Radoslavov
- RE: [ssm] Re: last call comments on ssm-arch doc Michael Luby
- Re: [ssm] Re: last call comments on ssm-arch doc Daniel Zappala
- Re: RE: [ssm] Re: last call comments on ssm-arch … Hugh Holbrook
- Re: Re: [ssm] Re: last call comments on ssm-arch … Hugh Holbrook
- Re: [ssm] Re: last call comments on ssm-arch doc Pavlin Radoslavov
- Re: Re: [ssm] Re: last call comments on ssm-arch … Hugh Holbrook
- [ssm] building multi-sender apps with ssm Hugh Holbrook
- Re: [ssm] building multi-sender apps with ssm Pavlin Radoslavov
- Re: Re: [ssm] building multi-sender apps with ssm Hugh Holbrook