Re: [ssm] Re: last call comments on ssm-arch doc
Pavlin Radoslavov <pavlin@icir.org> Fri, 17 January 2003 04:39 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 XAA02312 for <ssm-archive@lists.ietf.org>; Thu, 16 Jan 2003 23:39:31 -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 h0H4snJ18801; Thu, 16 Jan 2003 23:54:49 -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 h0H4lRJ18548 for <ssm@optimus.ietf.org>; Thu, 16 Jan 2003 23:47:27 -0500
Received: from possum.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02229 for <ssm@ietf.org>; Thu, 16 Jan 2003 23:31:30 -0500 (EST)
Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.3/8.12.3) with ESMTP id h0H4Yp2U067291; Thu, 16 Jan 2003 20:34:51 -0800 (PST) (envelope-from pavlin@possum.icir.org)
Message-Id: <200301170434.h0H4Yp2U067291@possum.icir.org>
To: holbrook@cisco.com
cc: Michael Luby <luby@digitalfountain.com>, Pavlin Radoslavov <pavlin@icir.org>, ssm@ietf.org
Subject: Re: [ssm] Re: last call comments on ssm-arch doc
In-Reply-To: Message from Hugh Holbrook <holbrook@cisco.com> of "Thu, 16 Jan 2003 02:12:47 EST." <20030116071247.5A2D810B869@holbrook-laptop.cisco.com>
Date: Thu, 16 Jan 2003 20:34:51 -0800
From: Pavlin Radoslavov <pavlin@icir.org>
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>
> 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] 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