From beepwg-admin@lists.beepcore.org Wed Jul 24 16:37:31 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01881 for ; Wed, 24 Jul 2002 16:37:30 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6OKYCQ13708; Wed, 24 Jul 2002 13:34:13 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6OKXnQ13690 for ; Wed, 24 Jul 2002 13:33:49 -0700 (PDT) Received: from spamsicle.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6OKbgVS014684 for ; Wed, 24 Jul 2002 16:37:43 -0400 (EDT) Received: from PAANDREWW2K3 (dhcp-161-44-180-140.cisco.com [161.44.180.140]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAH74451; Wed, 24 Jul 2002 16:37:07 -0400 (EDT) From: "Paul Andrews" To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C23330.59A70500" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Subject: [BEEPwg] Channel response serialization Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Jul 2002 16:37:07 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C23330.59A70500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I'm curious about the justification for the requirement that responses to queries on a channel be in the same order in which the queries were issued. I understand that it has been stated that this simplifies the protocol implementation. Does this mean that it simplifies the protocol or the libraries that implement it? If its just the libraries, couldn't the serialization requirement be made optional (i.e. part of the session negotiation)? I ask because it seems that this excludes a large class of applications from using BEEP, so that those of us who need truly asynchronous messaging are left with the same problem that BEEP was intended to solve. Namely: HTTP doesn't quite fit and SMTP doesn't quite fit. Now BEEP doesn't quite fit either :-( ------=_NextPart_000_0024_01C23330.59A70500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I'm = curious about=20 the justification for the requirement that responses to queries on a = channel be=20 in the same order in which the queries were issued. I understand that it = has=20 been stated that this simplifies the protocol implementation. Does this = mean=20 that it simplifies the protocol or the libraries that implement it? If = its just=20 the libraries, couldn't the serialization requirement be made optional = (i.e.=20 part of the session negotiation)?

I ask = because it=20 seems that this excludes a large class of applications from using BEEP, = so that=20 those of us who need truly asynchronous messaging are left with the same = problem=20 that BEEP was intended to solve. Namely: HTTP doesn't quite fit = and SMTP=20 doesn't quite fit.

Now = BEEP doesn't=20 quite fit either :-(

------=_NextPart_000_0024_01C23330.59A70500-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Jul 24 18:52:31 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04809 for ; Wed, 24 Jul 2002 18:52:30 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6OMm5Q14746; Wed, 24 Jul 2002 15:48:05 -0700 (PDT) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6OMlYQ14729 for ; Wed, 24 Jul 2002 15:47:35 -0700 (PDT) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id 940E913E71; Wed, 24 Jul 2002 18:50:56 -0400 (EDT) To: "Paul Andrews" Cc: Subject: Re: [BEEPwg] Channel response serialization References: From: Jered Floyd In-Reply-To: Message-ID: <87vg74buzz.fsf@questionably-configured.permabit.com> Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 24 Jul 2002 18:50:56 -0400 > I ask because it seems that this excludes a large class of > applications from using BEEP, so that those of us who need truly > asynchronous messaging are left with the same problem that BEEP was > intended to solve. Namely: HTTP doesn't quite fit and SMTP doesn't > quite fit. In what situations is the opening of multiple channels insufficient for your purposes? --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Jul 24 18:53:44 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04844 for ; Wed, 24 Jul 2002 18:53:44 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6OMn2Q14771; Wed, 24 Jul 2002 15:49:02 -0700 (PDT) Received: from kalia.dbc.mtview.ca.us (dhcpd253.dbc.mtview.ca.us [64.168.10.253]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6OMmXQ14757 for ; Wed, 24 Jul 2002 15:48:33 -0700 (PDT) Received: from kalia (localhost [127.0.0.1]) by kalia.dbc.mtview.ca.us (8.11.6+3.4W/8.11.6) with SMTP id g6OMocO00979; Wed, 24 Jul 2002 15:50:38 -0700 (PDT) From: Marshall Rose To: beepwg@lists.beepcore.org Cc: paandrew@cisco.com Subject: Re: [BEEPwg] Channel response serialization Message-Id: <20020724155037.6c29bb0e.mrose@dbc.mtview.ca.us> In-Reply-To: References: Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Wed, 24 Jul 2002 15:50:37 -0700 Content-Transfer-Encoding: 7bit > I'm curious about the justification for the requirement that responses to > queries on a channel be in the same order in which the queries were issued. > I understand that it has been stated that this simplifies the protocol > implementation. Does this mean that it simplifies the protocol or the > libraries that implement it? If its just the libraries, couldn't the > serialization requirement be made optional (i.e. part of the session > negotiation)? > > I ask because it seems that this excludes a large class of applications from > using BEEP, so that those of us who need truly asynchronous messaging are > left with the same problem that BEEP was intended to solve. Namely: HTTP > doesn't quite fit and SMTP doesn't quite fit. hi. you're right: it's probably a silly limitation in that the only thing that it makes "simpler" is the implementation on the side receiving the responses. (the side generating the responses couldn't care less, right?) i guess my question though is why not use the MSG/ANS approach to dealing with this? without understanding what the traffic looks like for the class of problems you're interested in, i can't really comment more. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 09:17:57 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02608 for ; Thu, 25 Jul 2002 09:17:56 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PDF5Q21234; Thu, 25 Jul 2002 06:15:05 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PDEvQ21215 for ; Thu, 25 Jul 2002 06:14:57 -0700 (PDT) Received: from spamsicle.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6PDIj7b007663; Thu, 25 Jul 2002 09:18:46 -0400 (EDT) Received: from PAANDREWW2K3 (che-vpn1-74.cisco.com [10.86.240.74]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAH75809; Thu, 25 Jul 2002 09:18:11 -0400 (EDT) From: "Paul Andrews" To: "Marshall Rose" , Subject: RE: [BEEPwg] Channel response serialization Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <20020724155037.6c29bb0e.mrose@dbc.mtview.ca.us> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 09:18:10 -0400 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: beepwg-admin@lists.beepcore.org > [mailto:beepwg-admin@lists.beepcore.org]On Behalf Of Marshall Rose > Sent: Wednesday, July 24, 2002 6:51 PM > To: beepwg@lists.beepcore.org > Cc: paandrew@cisco.com > Subject: Re: [BEEPwg] Channel response serialization > > > > I'm curious about the justification for the requirement that > responses to > > queries on a channel be in the same order in which the queries > were issued. > > I understand that it has been stated that this simplifies the protocol > > implementation. Does this mean that it simplifies the protocol or the > > libraries that implement it? If its just the libraries, couldn't the > > serialization requirement be made optional (i.e. part of the session > > negotiation)? > > > > I ask because it seems that this excludes a large class of > applications from > > using BEEP, so that those of us who need truly asynchronous > messaging are > > left with the same problem that BEEP was intended to solve. Namely: HTTP > > doesn't quite fit and SMTP doesn't quite fit. > > hi. you're right: it's probably a silly limitation in that the > only thing that it makes "simpler" is the implementation on the > side receiving the responses. (the side generating the responses > couldn't care less, right?) > > i guess my question though is why not use the MSG/ANS approach to > dealing with this? without understanding what the traffic looks > like for the class of problems you're interested in, i can't > really comment more. The application is one where many (i.e. hundreds or thousands) of independent entities on one peer wish to send a request to a remote peer acting as a server. The server process the requests in parallel and sends responses to the requests as soon as it can so that senders don't block on the slowest response. I think this answers your question about MSG/ANS. My reading of the RFC implies that although multiple ANS can be sent in any order to a single MSG. The processing of multiple MSGs on one channel is still performed serially, right? Now I could use a pool of channels. But this seems wrong for several reasons: 1. I would like to use channels for semantic purposes - i.e. they are strongly associated with the meaning of the message. If I don't do that then I have to layer another addressing mechanism on top of that provided by BEEP. BEEP, itself, associates channels with message purpose by assigning channel 0 as the control channel. 2. If I'm going to have a pool of channels, why not just have a pool of sockets instead? OK, I know there are some reasons but the more that I have to layer on top of BEEP, the less compelling is the argument for using it. 3. If I can implement parallel MSG/RPY over a single logical channel, then BEEP could do it over a single BEEP channel and save me the bother. > > /mtr > _______________________________________________ > BEEPwg mailing list > BEEPwg@lists.beepcore.org > http://lists.beepcore.org/mailman/listinfo/beepwg _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 09:26:49 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02934 for ; Thu, 25 Jul 2002 09:26:48 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PDO1Q21312; Thu, 25 Jul 2002 06:24:01 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PDNOQ21295 for ; Thu, 25 Jul 2002 06:23:24 -0700 (PDT) Received: from spamsicle.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6PDRM7P008529; Thu, 25 Jul 2002 09:27:23 -0400 (EDT) Received: from PAANDREWW2K3 (che-vpn1-74.cisco.com [10.86.240.74]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAH75841; Thu, 25 Jul 2002 09:26:48 -0400 (EDT) From: "Paul Andrews" To: "Jered Floyd" Cc: Subject: RE: [BEEPwg] Channel response serialization Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <87vg74buzz.fsf@questionably-configured.permabit.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 09:26:48 -0400 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: beepwg-admin@lists.beepcore.org > [mailto:beepwg-admin@lists.beepcore.org]On Behalf Of Jered Floyd > Sent: Wednesday, July 24, 2002 6:51 PM > To: Paul Andrews > Cc: beepwg@lists.beepcore.org > Subject: Re: [BEEPwg] Channel response serialization > > > > > I ask because it seems that this excludes a large class of > > applications from using BEEP, so that those of us who need truly > > asynchronous messaging are left with the same problem that BEEP was > > intended to solve. Namely: HTTP doesn't quite fit and SMTP doesn't > > quite fit. > > In what situations is the opening of multiple channels insufficient > for your purposes? It isn't insufficient in itself, but it prevents me from attaching a semantic purpose to the channel number (all of the requests have the same semantic here, just a different payload). It also means that I have to implement yet-another-pool-mechanism to manage the allocation of channels in a manner invisible to the application. It struck me that that wasn't really the purpose of channels. I got the impression that channels were intended to have a semantic purpose - and that's how I would like to use them, e.g. channel 0 is a control channel - you wouldn't allocate multiple control channels arbitrarily to get around the serialization restriction otherwise how would BEEP know that they were control messages? Finally the restriction on reply ordering seems to be arbitrary and forces people like me to put in a lot of extra work that we wouldn't have to do if the restriction wasn't there (I know, we all want something for nothing :-) ). > > --Jered > > _______________________________________________ > BEEPwg mailing list > BEEPwg@lists.beepcore.org > http://lists.beepcore.org/mailman/listinfo/beepwg _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 10:00:42 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04507 for ; Thu, 25 Jul 2002 10:00:41 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PDw3Q21602; Thu, 25 Jul 2002 06:58:03 -0700 (PDT) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PDvvQ21590 for ; Thu, 25 Jul 2002 06:57:57 -0700 (PDT) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id 2E68A13E76; Thu, 25 Jul 2002 10:01:25 -0400 (EDT) To: "Paul Andrews" Cc: Subject: Re: [BEEPwg] Channel response serialization References: From: Jered Floyd In-Reply-To: Message-ID: <871y9rewju.fsf@questionably-configured.permabit.com> Lines: 55 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 25 Jul 2002 10:01:25 -0400 > It struck me that that wasn't really the purpose of channels. I got the > impression that channels were intended to have a semantic purpose - and > that's how I would like to use them, e.g. channel 0 is a control channel - > you wouldn't allocate multiple control channels arbitrarily to get around > the serialization restriction otherwise how would BEEP know that they were > control messages? Hm. I defer to Marshall on any statements regarding intent, but I think that semantic binding is only one of the purposes of channels. While the binding of some specific profile to each channel provides semantic separation between channels, the serialization of messages on a single channel allows the client to pipeline requests with a guaranteed execution ordering. In fact, this is how we make use of multiple channels when performing complex tasks in our protocols. We manage a pool of channels bound to a given profile, and then assign messages to 'free' channels (i.e. ones with no currently outstanding message), while honouring data dependencies by pipelining requests on a single channel. While I don't fundamentally object to the idea of allowing out-of-order replies on a channel, I don't want to lose the guarantee of in-order processing of subsequent messages on a single channel. I posit that in any protocol that allows for volatile data, there are few situations in which one is likely to have in-order processing with out-of-order replies (while maintaining correctness). Question: If we remove the restriction on reply-ordering, do we then also allow frames on multiple RPYs or ERRs to be interleaved? That seems like the logical next step. Of course, then for parallelism we really ought to allow frames of MSGs to be interleaved. But, then we're back to something that looks like the channel mechanism, though less explicitly managed! > Finally the restriction on reply ordering seems to be arbitrary and forces > people like me to put in a lot of extra work that we wouldn't have to do if > the restriction wasn't there (I know, we all want something for nothing > :-) ). PermaBEEP goes a step further towards enforcing this by not allowing the application to retrieve the next message on a channel until it has initiated a reply to the last message delivered to the application. (Note that is initiated, not fully sent.) This decision was a bit contentious, but I think it best serves developers in that it prevents them from shooting themselves in the foot in a system that dispatches requests into a server framework. If you think it would be interesting to explore, I believe it would be relatively easy to modify PermaBEEP to remove both this and the restriction on reply ordering. I'm not sure there's a lot of value in it, though. (Hm, and I really must roll the 0.9 release soon; I meant to do that last month.) --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 10:20:56 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05503 for ; Thu, 25 Jul 2002 10:20:56 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PEI3Q21805; Thu, 25 Jul 2002 07:18:03 -0700 (PDT) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PEHPQ21793 for ; Thu, 25 Jul 2002 07:17:25 -0700 (PDT) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id 64F3D13E76; Thu, 25 Jul 2002 10:20:56 -0400 (EDT) To: "Paul Andrews" Cc: "Marshall Rose" , Subject: Re: [BEEPwg] Channel response serialization References: From: Jered Floyd In-Reply-To: Message-ID: <87wurjdh2v.fsf@questionably-configured.permabit.com> Lines: 43 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 25 Jul 2002 10:20:56 -0400 I'm not adding terribly much here from the message I just sent, but I'll add my $0.02. > The application is one where many (i.e. hundreds or thousands) of > independent entities on one peer wish to send a request to a remote > peer acting as a server. I believe that a (perhaps dynamically managed) pool of channels is the right solution here. > 1. I would like to use channels for semantic purposes - i.e. they are > strongly associated with the meaning of the message. I'm not sure I follow what you mean by this. Is it that your profile is not stateless, and so each channel has some 'defaults' that make multiple channels operating with the same profile notable and distinct? If that's the case, multiple channel pools are necessary. > If I don't do that then I have to layer another addressing mechanism > on top of that provided by BEEP. BEEP, itself, associates channels > with message purpose by assigning channel 0 as the control channel. If the profile is stateless, but the messages are indistinguishable as independent entities (i.e. the same data sent on different channels could have different actions), it sounds like this is a case for more than one profile. > 2. If I'm going to have a pool of channels, why not just have a pool of > sockets instead? OK, I know there are some reasons but the more that I have > to layer on top of BEEP, the less compelling is the argument for using it. This is a straw man. The resource overhead of a channel, once running, is negligible to that of a socket. BEEP allows up to 2^31 channels per connection; TCP/IP allows only 2^16 ports per address. > 3. If I can implement parallel MSG/RPY over a single logical channel, then > BEEP could do it over a single BEEP channel and save me the bother. I think the complexity of maintaining a channel pool is not as bad as you think, but I'm still curious as to what you meant back in point 1. --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 11:42:51 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09184 for ; Thu, 25 Jul 2002 11:42:50 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PFX3Q22313; Thu, 25 Jul 2002 08:33:03 -0700 (PDT) Received: from miz-mishtal.dbc.mtview.ca.us (miz-mishtal.dbc.mtview.ca.us [64.168.10.250]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PFWgQ22300 for ; Thu, 25 Jul 2002 08:32:42 -0700 (PDT) Received: from sales140 ([65.125.189.73]) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g6PF8Dd23610; Thu, 25 Jul 2002 08:08:13 -0700 (PDT) Message-ID: <005201c233f1$4e9c0d60$8c00000a@easyinc> From: "Marshall Rose" To: "Paul Andrews" , Cc: "Marshall Rose" References: Subject: Re: [BEEPwg] Channel response serialization MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 08:38:21 -0700 Content-Transfer-Encoding: 7bit hi. first, i think the simplest solution is to simply define a beep feature that gets negotiated during the greeting that relaxes the serial processing requirement. > The application is one where many (i.e. hundreds or thousands) of > independent entities on one peer wish to send a request to a remote peer > acting as a server. The server process the requests in parallel and sends > responses to the requests as soon as it can so that senders don't block on > the slowest response. I think this answers your question about MSG/ANS. My > reading of the RFC implies that although multiple ANS can be sent in any > order to a single MSG. The processing of multiple MSGs on one channel is > still performed serially, right? true. but i was perhaps too subtle in my explanation. darren's use of MSG/ANS in the syslog profile is rather inspired: the server sends a MSG and the client streams back zero or more ANS. now, if i wanted to do your application with a vanilla beep engine, i would have each side send a MSG to the other. i would then allow each side to put their requests and responses in the ANSs that get sent back. although there's an extra level of wrapping here (you put request numbers in the data you send and the BEEP msgno's are opaque), you can implement whatever policy you want all over one channel... > Now I could use a pool of channels. But this seems wrong for several > reasons: > > 1. I would like to use channels for semantic purposes - i.e. they are > strongly associated with the meaning of the message. If I don't do that then > I have to layer another addressing mechanism on top of that provided by > BEEP. BEEP, itself, associates channels with message purpose by assigning > channel 0 as the control channel. i'm not really sure i understand the concern, even though i agree with the first sentence. you can certainly define a profile that says each MSG/RPY contains an opaque blob (or whatever you want). > 2. If I'm going to have a pool of channels, why not just have a pool of > sockets instead? OK, I know there are some reasons but the more that I have > to layer on top of BEEP, the less compelling is the argument for using it. firewalls, redirectors (IP address shifting), NATs, etc. > 3. If I can implement parallel MSG/RPY over a single logical channel, then > BEEP could do it over a single BEEP channel and save me the bother. i agree. hence your original comment about defining a new BEEP feature... /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 11:46:47 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09383 for ; Thu, 25 Jul 2002 11:46:46 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PFi3Q22416; Thu, 25 Jul 2002 08:44:03 -0700 (PDT) Received: from smtp2.san.rr.com (smtp2.san.rr.com [24.25.195.39]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PFh5Q22404 for ; Thu, 25 Jul 2002 08:43:05 -0700 (PDT) Received: from san.rr.com (66-74-216-166.san.rr.com [66.74.216.166]) by smtp2.san.rr.com (8.11.4/8.11.4) with ESMTP id g6PFkUj06092; Thu, 25 Jul 2002 08:46:30 -0700 (PDT) Message-ID: <3D401D73.CAD54726@san.rr.com> From: Darren New Organization: Boxes! X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Andrews CC: beepwg@lists.beepcore.org Subject: Re: [BEEPwg] Channel response serialization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 08:46:59 -0700 Content-Transfer-Encoding: 7bit Paul Andrews wrote: > The application is one where many (i.e. hundreds or thousands) of > independent entities on one peer wish to send a request to a remote peer > acting as a server. The server process the requests in parallel and sends > responses to the requests as soon as it can so that senders don't block on > the slowest response. Then the client peer can send a MSG with the request and receive a NUL in response, and then the server can send a MSG as a response and the client can send a NUL in response. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** Things to be thankful for, #37: No sausage was served at the Last Supper. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 11:51:38 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09539 for ; Thu, 25 Jul 2002 11:51:37 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PFn2Q22497; Thu, 25 Jul 2002 08:49:02 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PFmmQ22485 for ; Thu, 25 Jul 2002 08:48:48 -0700 (PDT) Received: from spamsicle.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6PFqfPC025412; Thu, 25 Jul 2002 11:52:42 -0400 (EDT) Received: from PAANDREWW2K3 (che-vpn1-73.cisco.com [10.86.240.73]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAH76490; Thu, 25 Jul 2002 11:52:05 -0400 (EDT) From: "Paul Andrews" To: "Jered Floyd" Cc: "Marshall Rose" , Subject: RE: [BEEPwg] Channel response serialization Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <87wurjdh2v.fsf@questionably-configured.permabit.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 11:52:04 -0400 Content-Transfer-Encoding: 7bit Thanks for taking the time to think about this, and hopefully I'm not being too troublesome (or just plain dumb) but there are few people around that I can work through these sorts of issues with. I've been trying to think of an example that would illustrate what I am driving at and I think that a web browser loading a web page works quite well - it is familiar to everyone and it illustrates what I am trying to say from the point of view of a client. So. When a web browser loads an HTML page, that page will have on it many references to objects that also need to be retrieved in order to fully render the page. Generally, the layout of the page is known from the HTML document - all the render has to do is retrieve the various referenced objects and render them into the space that has been left for them. That, to me, is the interesting part. A browser parallelises the retrieval of those objects by opening multiple TCP connections and issuing HTTP/GET commands down each one. Each connection itself operates serially. The analogy in BEEP would be to create a profile that specifies the use of GET. The browser then uses multiple channels to download the multiple objects. Intra channel communication being serial, inter channel communication being parallel. The browser now has essentially the same management problem that it had with plain old TCP. It has to decide when to create a channel and when to release it to avoid the overhead of channel creation. It has to queue requests to each channel to ensure that the requests are written atomically (actually, that's a supposition). If one response on a channel takes a long time (maybe the server is drawing a graph into a JPEG and then returning the JPEG) subsequent responses on that channel will be held up and the page renderer will have to wait. On the other hand, if the browser could just use one channel (the GET channel), down which it could pump requests and from which it could retrieve responses in any order, the renderer would not be held up (at least not by the communication protocol). There would be less management overhead - just the one channel to decide to open and release. There would be no contention for the use of channels (either writing to them or reading from them). OK, so the renderer would have to decide just how many objects it was going to try and draw in parallel, but that decision would be independent of how it uses a protocol to retrieve the objects it wants to draw. In fact, it might have a thread pool that it allocates rendering operations to. But the point is (maybe) that there is only one pool to have to worry about, at least as far as the browser is concerned. I guess the point is that the restriction on ordering of responses seems to be arbitrary when it comes to the actual protocol definition itself. If a given library feels that it has to impose that restriction, then that should be up to the library. Though I guess that both ends would have to agree on any ordering restrictions as part of the session negotiation. The problem I have on the server side is very similar - i.e. there is an engine that can process many requests in parallel. Now, I receive multiple requests on one channel and I could process them in parallel. If the API will not deliver me a request until it has received a response to an outstanding request, it is effectively throttling me. Maybe the API will deliver me multiple requests but relies on me returning response strictly in order - now I have to throttle myself. If the API will deliver multiple requests and accept responses in any order then it will have to throttle itself in order to meet the serialization requirement. OK the client could use multiple channels, but then the client is effectively dictating how many operations the server can perform in parallel. > -----Original Message----- > From: beepwg-admin@lists.beepcore.org > [mailto:beepwg-admin@lists.beepcore.org]On Behalf Of Jered Floyd > Sent: Thursday, July 25, 2002 10:21 AM > To: Paul Andrews > Cc: Marshall Rose; beepwg@lists.beepcore.org > Subject: Re: [BEEPwg] Channel response serialization > > > > I'm not adding terribly much here from the message I just sent, but > I'll add my $0.02. > > > The application is one where many (i.e. hundreds or thousands) of > > independent entities on one peer wish to send a request to a remote > > peer acting as a server. > > I believe that a (perhaps dynamically managed) pool of channels is the > right solution here. > > > 1. I would like to use channels for semantic purposes - i.e. they are > > strongly associated with the meaning of the message. > > I'm not sure I follow what you mean by this. Is it that your profile > is not stateless, and so each channel has some 'defaults' that make > multiple channels operating with the same profile notable and > distinct? If that's the case, multiple channel pools are necessary. > > > If I don't do that then I have to layer another addressing mechanism > > on top of that provided by BEEP. BEEP, itself, associates channels > > with message purpose by assigning channel 0 as the control channel. > > If the profile is stateless, but the messages are indistinguishable as > independent entities (i.e. the same data sent on different channels > could have different actions), it sounds like this is a case for more > than one profile. > > > 2. If I'm going to have a pool of channels, why not just have a pool of > > sockets instead? OK, I know there are some reasons but the more > that I have > > to layer on top of BEEP, the less compelling is the argument > for using it. > > This is a straw man. The resource overhead of a channel, once > running, is negligible to that of a socket. BEEP allows up to 2^31 > channels per connection; TCP/IP allows only 2^16 ports per address. > > > 3. If I can implement parallel MSG/RPY over a single logical > channel, then > > BEEP could do it over a single BEEP channel and save me the bother. > > I think the complexity of maintaining a channel pool is not as bad as > you think, but I'm still curious as to what you meant back in point 1. > > --Jered > > _______________________________________________ > BEEPwg mailing list > BEEPwg@lists.beepcore.org > http://lists.beepcore.org/mailman/listinfo/beepwg _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 12:02:52 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09957 for ; Thu, 25 Jul 2002 12:02:52 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PG08Q22653; Thu, 25 Jul 2002 09:00:08 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PFx9Q22617 for ; Thu, 25 Jul 2002 08:59:09 -0700 (PDT) Received: from spamsicle.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6PG39dI026662; Thu, 25 Jul 2002 12:03:09 -0400 (EDT) Received: from PAANDREWW2K3 (che-vpn1-73.cisco.com [10.86.240.73]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAH76531; Thu, 25 Jul 2002 12:02:33 -0400 (EDT) From: "Paul Andrews" To: "Jered Floyd" Cc: Subject: RE: [BEEPwg] Channel response serialization Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <871y9rewju.fsf@questionably-configured.permabit.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 12:02:33 -0400 Content-Transfer-Encoding: 7bit First of all, thanks for your considered reply. Its difficult to find people I can have this level of conversation with so forgive me for delving further into this below... > -----Original Message----- > From: beepwg-admin@lists.beepcore.org > [mailto:beepwg-admin@lists.beepcore.org]On Behalf Of Jered Floyd > Sent: Thursday, July 25, 2002 10:01 AM > To: Paul Andrews > Cc: beepwg@lists.beepcore.org > Subject: Re: [BEEPwg] Channel response serialization > > > > > It struck me that that wasn't really the purpose of channels. I got the > > impression that channels were intended to have a semantic purpose - and > > that's how I would like to use them, e.g. channel 0 is a > control channel - > > you wouldn't allocate multiple control channels arbitrarily to > get around > > the serialization restriction otherwise how would BEEP know > that they were > > control messages? > > Hm. I defer to Marshall on any statements regarding intent, but I > think that semantic binding is only one of the purposes of channels. > While the binding of some specific profile to each channel provides > semantic separation between channels, the serialization of messages on > a single channel allows the client to pipeline requests with a > guaranteed execution ordering. That's a good point that hadn't really sunk in for me. In fact the SOAP over BEEP example does precisely that, i.e. binds a particular SOAP message to a profile, then you can get multiple channels bound to that profile. One way of looking at that is that there is a virtual channel that is the sum of all channels that share a profile. > > In fact, this is how we make use of multiple channels when performing > complex tasks in our protocols. We manage a pool of channels bound to > a given profile, and then assign messages to 'free' channels > (i.e. ones with no currently outstanding message), while honouring > data dependencies by pipelining requests on a single channel. I take your point about the benefit of having enforced pipelining for certain types of problem. > > While I don't fundamentally object to the idea of allowing > out-of-order replies on a channel, I don't want to lose the guarantee > of in-order processing of subsequent messages on a single channel. I > posit that in any protocol that allows for volatile data, there are > few situations in which one is likely to have in-order processing with > out-of-order replies (while maintaining correctness). I agree. But that is not a requirement in my case. Or at least, where it is a requirement there are fairly simple mechanisms for enforcing ordering that do not require support from the communications protocol. > > Question: If we remove the restriction on reply-ordering, do we then > also allow frames on multiple RPYs or ERRs to be interleaved? That > seems like the logical next step. Of course, then for parallelism we > really ought to allow frames of MSGs to be interleaved. But, then > we're back to something that looks like the channel mechanism, though > less explicitly managed! So are you saying that MSGs are essentially sent serially, regardless of how many channels are open? i.e. if I am sending a very large message on one channel, othe channels will have to wait to before they can send anything? > > > Finally the restriction on reply ordering seems to be arbitrary > and forces > > people like me to put in a lot of extra work that we wouldn't > have to do if > > the restriction wasn't there (I know, we all want something for nothing > > :-) ). > > PermaBEEP goes a step further towards enforcing this by not allowing > the application to retrieve the next message on a channel until it has > initiated a reply to the last message delivered to the application. > (Note that is initiated, not fully sent.) This decision was a bit > contentious, but I think it best serves developers in that it prevents > them from shooting themselves in the foot in a system that dispatches > requests into a server framework. But I like shooting myself in the foot! I guess the point is that serialization is something that can be layered on top of parallelism, but not vice-versa. At least when operating within the constraints if a single framework. > > If you think it would be interesting to explore, I believe it would be > relatively easy to modify PermaBEEP to remove both this and the > restriction on reply ordering. I'm not sure there's a lot of value in > it, though. (Hm, and I really must roll the 0.9 release soon; I meant > to do that last month.) Interesting point. I guess I tend to think that standards are written in stone. I could act unilaterally to remove the serialization requirement but I guess I need to convince myself that I'm not talking rubbish and I would also prefer to work within the standards process if at all possible. Once again, thanks for taking the time to think about this. > > --Jered > > _______________________________________________ > BEEPwg mailing list > BEEPwg@lists.beepcore.org > http://lists.beepcore.org/mailman/listinfo/beepwg _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 12:16:29 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10522 for ; Thu, 25 Jul 2002 12:16:28 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PGD3Q22802; Thu, 25 Jul 2002 09:13:03 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PGCGQ22790 for ; Thu, 25 Jul 2002 09:12:16 -0700 (PDT) Received: from spamsicle.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6PGG9T8027871; Thu, 25 Jul 2002 12:16:10 -0400 (EDT) Received: from PAANDREWW2K3 (che-vpn1-73.cisco.com [10.86.240.73]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAH76577; Thu, 25 Jul 2002 12:15:35 -0400 (EDT) From: "Paul Andrews" To: "Marshall Rose" , Subject: RE: [BEEPwg] Channel response serialization Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <005201c233f1$4e9c0d60$8c00000a@easyinc> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 12:15:34 -0400 Content-Transfer-Encoding: 7bit OK. I don't want to rat-hole on this so: do I understand correctly that you are proposing to amend the RFC to make serialization on a channel optional? The rest of my points below all boil down to the same thing (I think). Namely that it would be a shame to have to layer another communications protocol on top of BEEP. Naturally I'd be layering an application protocol on top, but then that's the whole point. By the way if we end up using BEEP in our projects I'd be more than happy to get involved either at the standards level or at the library level assuming that no-one objects of course (and assuming that my boss didn't mind and our legal department etc. etc.). Thanks for taking the time to reply by the way. > -----Original Message----- > From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us] > Sent: Thursday, July 25, 2002 11:38 AM > To: Paul Andrews; beepwg@lists.beepcore.org > Cc: Marshall Rose > Subject: Re: [BEEPwg] Channel response serialization > > > hi. first, i think the simplest solution is to simply define a > beep feature > that gets negotiated during the greeting that relaxes the serial > processing > requirement. > > > > The application is one where many (i.e. hundreds or thousands) of > > independent entities on one peer wish to send a request to a remote peer > > acting as a server. The server process the requests in parallel > and sends > > responses to the requests as soon as it can so that senders > don't block on > > the slowest response. I think this answers your question about > MSG/ANS. My > > reading of the RFC implies that although multiple ANS can be sent in any > > order to a single MSG. The processing of multiple MSGs on one channel is > > still performed serially, right? > > true. but i was perhaps too subtle in my explanation. darren's use of > MSG/ANS in the syslog profile is rather inspired: the server > sends a MSG and > the client streams back zero or more ANS. > > now, if i wanted to do your application with a vanilla beep > engine, i would > have each side send a MSG to the other. i would then allow each > side to put > their requests and responses in the ANSs that get sent back. although > there's an extra level of wrapping here (you put request numbers > in the data > you send and the BEEP msgno's are opaque), you can implement > whatever policy > you want all over one channel... > > > > Now I could use a pool of channels. But this seems wrong for several > > reasons: > > > > 1. I would like to use channels for semantic purposes - i.e. they are > > strongly associated with the meaning of the message. If I don't do that > then > > I have to layer another addressing mechanism on top of that provided by > > BEEP. BEEP, itself, associates channels with message purpose by > assigning > > channel 0 as the control channel. > > i'm not really sure i understand the concern, even though i agree with the > first sentence. you can certainly define a profile that says each MSG/RPY > contains an opaque blob (or whatever you want). > > > > 2. If I'm going to have a pool of channels, why not just have a pool of > > sockets instead? OK, I know there are some reasons but the more that I > have > > to layer on top of BEEP, the less compelling is the argument > for using it. > > firewalls, redirectors (IP address shifting), NATs, etc. > > > > 3. If I can implement parallel MSG/RPY over a single logical > channel, then > > BEEP could do it over a single BEEP channel and save me the bother. > > i agree. hence your original comment about defining a new BEEP feature... > > /mtr > > _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 12:19:11 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10631 for ; Thu, 25 Jul 2002 12:19:10 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PGG2Q22858; Thu, 25 Jul 2002 09:16:02 -0700 (PDT) Received: from smtp2.san.rr.com (smtp2.san.rr.com [24.25.195.39]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PGFFQ22840 for ; Thu, 25 Jul 2002 09:15:15 -0700 (PDT) Received: from san.rr.com (66-74-216-166.san.rr.com [66.74.216.166]) by smtp2.san.rr.com (8.11.4/8.11.4) with ESMTP id g6PGIVj24253; Thu, 25 Jul 2002 09:18:31 -0700 (PDT) Message-ID: <3D4024F4.34DF4723@san.rr.com> From: Darren New Organization: Boxes! X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Andrews CC: Jered Floyd , Marshall Rose , beepwg@lists.beepcore.org Subject: Re: [BEEPwg] Channel response serialization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 09:19:00 -0700 Content-Transfer-Encoding: 7bit Paul Andrews wrote: > So. When a web browser loads an HTML page, that page will have on it many > references to objects that also need to be retrieved in order to fully > render the page. ... > The analogy in BEEP would be to create a profile that specifies the use of > GET. The browser then uses multiple channels to download the multiple > objects. Intra channel communication being serial, inter channel > communication being parallel. The browser could send one MSG with a GET listing *all* the URLs it wants to retrieve from that server. The server could put each response into a separate ANS. The ANS can be returned in any order, interleaved. However, the browser would not get any responses to the second GET until all responses to the first GET had been received. (It would also be difficult to abort cleanly without dropping the TCP connection.) > If the API will deliver multiple > requests and accept responses in any order then it will have to throttle > itself in order to meet the serialization requirement. This is how the core of the BEEP-C library works. If you reply out of order, your reply is just queued in the library until you have everything in order. You can even process and queue chunks in interleaved order, with the first response being picked out of the stream, then the second response being sent. > So are you saying that MSGs are essentially sent serially, regardless of how > many channels are open? i.e. if I am sending a very large message on one > channel, othe channels will have to wait to before they can send anything? No, he's saying that if you're allowing multiple MSGs being processed at once, then the next logical step is to allow multiple MSGs to be sent concurrently. Otherwise, you're holding up the second MSG while waiting for the first MSG to go out over the wire. If the first MSG is very large and the second MSG is small and fast to process, you might be able to get the response from the second MSG before you even finish sending the first MSG. But that's not how it works now, because once you start sending the first MSG, you have to finish sending it. Right now, you can start sending a MSG on a second channel before the MSG on the first channel is finished. > I would > also prefer to work within the standards process if at all possible. You are working within the standards process. Look at the name of the mailing list. :-) -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** Things to be thankful for, #37: No sausage was served at the Last Supper. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 14:23:41 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15647 for ; Thu, 25 Jul 2002 14:23:39 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PIK4Q23630; Thu, 25 Jul 2002 11:20:04 -0700 (PDT) Received: from miz-mishtal.dbc.mtview.ca.us (miz-mishtal.dbc.mtview.ca.us [64.168.10.250]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PIJRQ23612 for ; Thu, 25 Jul 2002 11:19:27 -0700 (PDT) Received: from sales140 ([65.125.189.73]) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g6PHt2d24378; Thu, 25 Jul 2002 10:55:02 -0700 (PDT) Message-ID: <005301c23408$9d3a46a0$8c00000a@easyinc> From: "Marshall Rose" To: "Paul Andrews" , "Jered Floyd" Cc: References: Subject: Re: [BEEPwg] Channel response serialization MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 11:25:11 -0700 Content-Transfer-Encoding: 7bit > Thanks for taking the time to think about this, and hopefully I'm not being > too troublesome (or just plain dumb) but there are few people around that I > can work through these sorts of issues with. no. this is a good discussion as it illustrates a lot of issues... darren pretty much explained the issues in his reply, in particular the so-called head-of-line problem in trying to move multiple things on one channel. this leads us to: [ the web browser example ] > OK the client could use multiple channels, but then the client is > effectively dictating how many operations the server can perform in > parallel. the whole point here is that client should be using multiple channels because tit should want to manage the html and the gifs with different priorities! /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 14:30:13 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15967 for ; Thu, 25 Jul 2002 14:30:12 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PIN1Q23677; Thu, 25 Jul 2002 11:23:01 -0700 (PDT) Received: from miz-mishtal.dbc.mtview.ca.us (miz-mishtal.dbc.mtview.ca.us [64.168.10.250]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PIMLQ23665 for ; Thu, 25 Jul 2002 11:22:21 -0700 (PDT) Received: from sales140 ([65.125.189.73]) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g6PHvvd24394; Thu, 25 Jul 2002 10:57:57 -0700 (PDT) Message-ID: <007501c23409$059b9eb0$8c00000a@easyinc> From: "Marshall Rose" To: "Paul Andrews" , Cc: "Marshall Rose" References: Subject: Re: [BEEPwg] Channel response serialization MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 11:28:06 -0700 Content-Transfer-Encoding: 7bit > OK. I don't want to rat-hole on this so: do I understand correctly that you > are proposing to amend the RFC to make serialization on a channel optional? no. what i'm proposing is that we use beep's extension mechanism (called "features") and write a new document that talks defines a feature that removes the same-order property. rfc3080 doesn't change. presumably a new rfc gets published that describes how something implementing rfc3080 can also say that it does the new thing too. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 15:07:20 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17512 for ; Thu, 25 Jul 2002 15:07:19 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PJ0CQ23968; Thu, 25 Jul 2002 12:00:12 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PIxRQ23929 for ; Thu, 25 Jul 2002 11:59:27 -0700 (PDT) Received: from spamsicle.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6PJ3LCM016781; Thu, 25 Jul 2002 15:03:21 -0400 (EDT) Received: from PAANDREWW2K3 (che-vpn1-73.cisco.com [10.86.240.73]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAH77301; Thu, 25 Jul 2002 15:02:46 -0400 (EDT) From: "Paul Andrews" To: "Marshall Rose" , "Jered Floyd" Cc: Subject: RE: [BEEPwg] Channel response serialization Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <005301c23408$9d3a46a0$8c00000a@easyinc> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 15:02:45 -0400 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us] > Sent: Thursday, July 25, 2002 2:25 PM > To: Paul Andrews; Jered Floyd > Cc: beepwg@lists.beepcore.org > Subject: Re: [BEEPwg] Channel response serialization > > > > Thanks for taking the time to think about this, and hopefully I'm not > being > > too troublesome (or just plain dumb) but there are few people > around that > I > > can work through these sorts of issues with. > > no. this is a good discussion as it illustrates a lot of issues... > > darren pretty much explained the issues in his reply, in particular the > so-called head-of-line problem in trying to move multiple things on one > channel. this leads us to: > > [ the web browser example ] > > > OK the client could use multiple channels, but then the client is > > effectively dictating how many operations the server can perform in > > parallel. > > the whole point here is that client should be using multiple channels > because tit should want to manage the html and the gifs with different > priorities! Yes. So it uses one channel for HTML and one channel for all of the GIFs it wants to download in parallel. Or is that what you're saying? > > /mtr > > _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 15:24:55 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17906 for ; Thu, 25 Jul 2002 15:24:54 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PJM3Q24161; Thu, 25 Jul 2002 12:22:03 -0700 (PDT) Received: from noisybox.convivian.com (someone@noisybox.convivian.com [140.239.226.142]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PJLbQ24149 for ; Thu, 25 Jul 2002 12:21:38 -0700 (PDT) Received: from questionably-configured.permabit.com.convivian.com (gw.permabit.com [4.36.55.2]) by noisybox.convivian.com (Postfix) with ESMTP id CE37268404D; Thu, 25 Jul 2002 15:25:00 -0400 (EDT) To: "Paul Andrews" Cc: Subject: Re: [BEEPwg] Channel response serialization References: From: Jered Floyd In-Reply-To: Message-ID: <87bs8vd303.fsf@questionably-configured.permabit.com> Lines: 76 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 25 Jul 2002 15:25:00 -0400 "Paul Andrews" writes: > First of all, thanks for your considered reply. Its difficult to > find people I can have this level of conversation with so forgive me > for delving further into this below... You're welcome... there's no need to apologize; as Darren pointed out, you're fulfilling the purpose of this list. And it's always useful to have more people with an understanding of BEEP, so that it can take over the world. :-) > One way of looking at that is that there is a virtual channel that > is the sum of all channels that share a profile. As long as the channels are stateless, yes. It's a nice abstraction to have if your application wishes request parallelism. You can also use channel groups, or the pipelining on individual channels, to provide the same sort of functionality as SCSI's tagged queuing. "I want all of these tasks done as quickly as possible, and here are a few ordering constraints." > > Question: If we remove the restriction on reply-ordering, do we > > then also allow frames on multiple RPYs or ERRs to be interleaved? > > That seems like the logical next step. Of course, then for > > parallelism we really ought to allow frames of MSGs to be > > interleaved. But, then we're back to something that looks like > > the channel mechanism, though less explicitly managed! > > So are you saying that MSGs are essentially sent serially, > regardless of how many channels are open? i.e. if I am sending a > very large message on one channel, othe channels will have to wait > to before they can send anything? Not quite, MSGs are sent serially on a particular channel, but frames on multiple channels may be interleaved. If we remove the restrictions on RPY ordering, it seems most sensible to also allow MSGs and RPYs on the same channel to be interleaved, and then I think we've gone and lost most of the advantages of having multiple channels in the first place. (That is, we get something that is confusing and complicated.) > But I like shooting myself in the foot! I guess the point is that > serialization is something that can be layered on top of parallelism, but > not vice-versa. At least when operating within the constraints if a single > framework. Metatarsal ballistics aside, while we can implement serialization on top of a parallel layer, we can't implement pipelining on top of a parallel layer (because we have to wait for the response to arrive on a channel before we know we can send the next request and have it be processed in order.) I think one of the purposes of the channel abstraction is to explicitly allow for both the intra-channel asynchorony of pipelining and the inter-channel asynchrony of parallelism. I'd rather not see pipelining go away in favor of intra-channel parallelism... I don't think it's called for. (I won't address your web browser example here, as I think Darren and Marshall did a good job of that.) > > If you think it would be interesting to explore, I believe it would be > > relatively easy to modify PermaBEEP to remove both this and the > > restriction on reply ordering. I'm not sure there's a lot of value in > > it, though. (Hm, and I really must roll the 0.9 release soon; I meant > > to do that last month.) > > Interesting point. I guess I tend to think that standards are written in > stone. I could act unilaterally to remove the serialization requirement but > I guess I need to convince myself that I'm not talking rubbish and I would > also prefer to work within the standards process if at all possible. I'd be happy to point you at the right parts of the code if you'd like to explore this further, but I really do think that channel pools are the right way to go about doing this. But perhaps I'm old and set in my ways. *grin* --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 15:35:40 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18211 for ; Thu, 25 Jul 2002 15:35:39 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PJX2Q24256; Thu, 25 Jul 2002 12:33:02 -0700 (PDT) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PJWiQ24244 for ; Thu, 25 Jul 2002 12:32:44 -0700 (PDT) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id E644A13E71; Thu, 25 Jul 2002 15:36:08 -0400 (EDT) To: "Paul Andrews" Cc: "Marshall Rose" , Subject: Re: [BEEPwg] Channel response serialization References: From: Jered Floyd In-Reply-To: Message-ID: <877kjjd2hj.fsf@questionably-configured.permabit.com> Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 25 Jul 2002 15:36:08 -0400 > > the whole point here is that client should be using multiple channels > > because tit should want to manage the html and the gifs with different > > priorities! > > Yes. So it uses one channel for HTML and one channel for all of the GIFs it > wants to download in parallel. Or is that what you're saying? Not necessarily; I think Marshall was suggesting that with a set of indistinguishable channels, it uses some subset (say, one) for retrieving HTML, and another subset (as many as it wishes, or thinks it can handle in parallel), for retrieving the GIFs. It can always hold onto more channels than it is using at any given time, as channels are lightweight and cheap. Consider this to be the same way existing browsers manage multiple connections, except that the resource cost is not as steep. --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 16:35:50 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20364 for ; Thu, 25 Jul 2002 16:35:49 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PKX3Q24713; Thu, 25 Jul 2002 13:33:03 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PKWQQ24701 for ; Thu, 25 Jul 2002 13:32:26 -0700 (PDT) Received: from spamsicle.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6PKaQNi026871; Thu, 25 Jul 2002 16:36:26 -0400 (EDT) Received: from PAANDREWW2K3 (che-vpn1-73.cisco.com [10.86.240.73]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAH77738; Thu, 25 Jul 2002 16:35:52 -0400 (EDT) From: "Paul Andrews" To: "Jered Floyd" Cc: Subject: RE: [BEEPwg] Channel response serialization Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <87bs8vd303.fsf@questionably-configured.permabit.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 16:35:51 -0400 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jered Floyd [mailto:jered@permabit.com] > Sent: Thursday, July 25, 2002 3:25 PM > To: Paul Andrews > Cc: beepwg@lists.beepcore.org > Subject: Re: [BEEPwg] Channel response serialization > > > "Paul Andrews" writes: > > > But I like shooting myself in the foot! I guess the point is that > > serialization is something that can be layered on top of > parallelism, but > > not vice-versa. At least when operating within the constraints > if a single > > framework. > > Metatarsal ballistics aside, while we can implement serialization on > top of a parallel layer, we can't implement pipelining on top of a > parallel layer (because we have to wait for the response to arrive on > a channel before we know we can send the next request and have it be > processed in order.)... Weeeelllll. If I understand correctly (a big if at this point). You still don't have that guarantee because all you are specifying is that replies have to be sent in the same order that requests are received. Nothing is stated about the order in which requests have to be processed. In fact to paraphrase an earlier reponse in this thread: the library actually holds responses until all repsonses to eariler requests have been sent. This implicitly allows you to give responses to the library out-of-order. > ... I think one of the purposes of the channel > abstraction is to explicitly allow for both the intra-channel > asynchorony of pipelining and the inter-channel asynchrony of > parallelism. I'd rather not see pipelining go away in favor of > intra-channel parallelism... I don't think it's called for. It would be nice to be able to negotiate the exact level of synchronicity (synchronousnous?) required on a single channel. i.e.: - Totally asynchronous. - Synchronous responses. - Synchronous requests and synchronous responses. In fact I think Marshall has pointed out that that is a possibility using 'features'. This would not obviate the need for channels, it would just free them up to be used at a purely application semantic level rather than a mix of application and protocol semantic levels. > > (I won't address your web browser example here, as I think Darren and > Marshall did a good job of that.) > > > > If you think it would be interesting to explore, I believe it would be > > > relatively easy to modify PermaBEEP to remove both this and the > > > restriction on reply ordering. I'm not sure there's a lot of value in > > > it, though. (Hm, and I really must roll the 0.9 release soon; I meant > > > to do that last month.) > > > > Interesting point. I guess I tend to think that standards are written in > > stone. I could act unilaterally to remove the serialization > requirement but > > I guess I need to convince myself that I'm not talking rubbish > and I would > > also prefer to work within the standards process if at all possible. > > I'd be happy to point you at the right parts of the code if you'd like > to explore this further, but I really do think that channel pools are > the right way to go about doing this. But perhaps I'm old and set in > my ways. *grin* LOL. Bet you're not as old as me. Anyway, yes you can point me at the right parts of code. I'm a Java programmer by preference. Of course, I might come to the same conclusions as y'all. By the way, why isn't PermaBEEP listed at beepcore.org? > > --Jered > _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 16:44:50 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20664 for ; Thu, 25 Jul 2002 16:44:49 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PKg3Q24807; Thu, 25 Jul 2002 13:42:03 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PKfCQ24795 for ; Thu, 25 Jul 2002 13:41:12 -0700 (PDT) Received: from spamsicle.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6PKj6R2027813; Thu, 25 Jul 2002 16:45:07 -0400 (EDT) Received: from PAANDREWW2K3 (che-vpn1-73.cisco.com [10.86.240.73]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAH77771; Thu, 25 Jul 2002 16:44:32 -0400 (EDT) From: "Paul Andrews" To: "Marshall Rose" , Subject: RE: [BEEPwg] Channel response serialization Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <007501c23409$059b9eb0$8c00000a@easyinc> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 16:44:31 -0400 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: beepwg-admin@lists.beepcore.org > [mailto:beepwg-admin@lists.beepcore.org]On Behalf Of Marshall Rose > Sent: Thursday, July 25, 2002 2:28 PM > To: Paul Andrews; beepwg@lists.beepcore.org > Cc: Marshall Rose > Subject: Re: [BEEPwg] Channel response serialization > > > > OK. I don't want to rat-hole on this so: do I understand correctly that > you > > are proposing to amend the RFC to make serialization on a channel > optional? > > no. what i'm proposing is that we use beep's extension mechanism (called > "features") and write a new document that talks defines a feature that > removes the same-order property. rfc3080 doesn't change. presumably a new > rfc gets published that describes how something implementing rfc3080 can > also say that it does the new thing too. Boy. Talk about jumping in at the deep end (to mix my metamphors). Just when I thought I was getting a handle on all this BEEP stuff I'm introduced to features. I have to say I'd tried to find out how the 'Extensible' bit worked. I guess I should've read the RFC from start to finish. I don't suppose you have an 'Idiots Guide to Adding Features' do you? > > /mtr > > > _______________________________________________ > BEEPwg mailing list > BEEPwg@lists.beepcore.org > http://lists.beepcore.org/mailman/listinfo/beepwg _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 17:26:48 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21985 for ; Thu, 25 Jul 2002 17:26:47 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PLO3Q25103; Thu, 25 Jul 2002 14:24:03 -0700 (PDT) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PLNFQ25081 for ; Thu, 25 Jul 2002 14:23:16 -0700 (PDT) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id 9A1A313E71; Thu, 25 Jul 2002 17:26:48 -0400 (EDT) To: "Paul Andrews" Cc: Subject: Re: [BEEPwg] Channel response serialization References: From: Jered Floyd In-Reply-To: Message-ID: <873cu7cxd3.fsf@questionably-configured.permabit.com> Lines: 43 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 25 Jul 2002 17:26:48 -0400 > Weeeelllll. If I understand correctly (a big if at this point). You still > don't have that guarantee because all you are specifying is that replies > have to be sent in the same order that requests are received. Nothing is > stated about the order in which requests have to be processed. It's not as clear as I'd like, but Section 2.6.1 of RFC 3080 says: A BEEP peer acting in the server role must process all "MSG" messages for a given channel in the same order as they are received. I suppose this could be taken to mean that the BEEP layer, and not necessarily the application, need do so, but I don't like that interpretation. > In fact to paraphrase an earlier reponse in this thread: the library > actually holds responses until all repsonses to eariler requests > have been sent. This implicitly allows you to give responses to the > library out-of-order. BEEPCore-C does this. This moves the responsibility for adhering to S2.6.1 to the application. We chose not to do this in PermaBEEP to protect developer toes. > Anyway, yes you can point me at the right parts of code. I'm a Java > programmer by preference. Of course, I might come to the same > conclusions as y'all. To remove the restriction on delivery of MSGs to the application, I think it should just be a matter of removing a check in Channel.getMessage() (and perhaps cleaning up assorted unneeded notifications.) How do provide out of order RPYs (non-interleaved) actually requires a bit more thought from me, but all of the relevant modifications for everything we've discussed would be to Channel.java. > By the way, why isn't PermaBEEP listed at beepcore.org? It's listed under Products, not Projects. I suppose I should create a duplicate entry, but embarassingly I've forgotten my beepcore login password. Who's in charge of the site these days? --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 17:28:14 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22051 for ; Thu, 25 Jul 2002 17:28:13 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PLPdQ25138; Thu, 25 Jul 2002 14:25:39 -0700 (PDT) Received: from monsoon.us.ny.firstrain.com ([208.198.42.246]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6PLNSQ25086 for ; Thu, 25 Jul 2002 14:23:28 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Idiot's guide to Features (was: RE: [BEEPwg] Channel response serialization) Message-ID: Thread-Topic: Idiot's guide to Features (was: RE: [BEEPwg] Channel response serialization) Thread-Index: AcI0HQ10U23lhymhR1eQkR6Cx/MSEAAAYQew From: "Bob Wyman" To: "Paul Andrews" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by qawoor.dbc.mtview.ca.us id g6PLNSQ25086 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 17:29:54 -0400 Content-Transfer-Encoding: 8bit Paul Andrews wrote: > I don't suppose you have an 'Idiots Guide to > Adding Features' do you? A Beep feature gets advertised as part of the greetings messages. A Beep "x-outoforder" feature might look something like the following: (Note: If registered with IANA, this feature would be 'outoforder'. The "x-" prefix is only for things not IANA registered.) L: I: L: RPY 0 0 . 0 999 L: Content-Type: application/beep+xml L: L: L: L: L: END I: RPY 0 0 . 0 999 I: Content-Type: application/beep+xml I: I: I: END To register a feature, you fill out the Feature Registration Template which is in section 5.2 of the BEEP RFC. The registration might be something like: ============ Feature Identification: 'x-outoforder' Feature Semantics: This feature permits a BEEP peer acting in the server role to process "MSG" messages for a given channel in any order it chooses. This is a relaxation of the requirement for "in-order" processing defined in RFC3080 at Section 2.6.1. If both the BEEP peer acting as the initiator and the BEEP peer acting as the server send greetings messages containing the x-outoforder feature token, both BEEP peers must assume that the reply ordering constraints of RFC3080 at Section 2.6.1 do not apply to the current attachment. Contact Information: Postal Address of author: Electronic Address of author: =========== It is that simple -- unless I'm a real idiot... bob wyman _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Jul 25 22:39:29 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27987 for ; Thu, 25 Jul 2002 22:39:28 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6Q2a4Q27125; Thu, 25 Jul 2002 19:36:04 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6Q2ZHQ27108 for ; Thu, 25 Jul 2002 19:35:18 -0700 (PDT) Received: from spamsicle.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6Q2dJHC018963; Thu, 25 Jul 2002 22:39:20 -0400 (EDT) Received: from PAANDREWW2K3 (che-vpn1-24.cisco.com [10.86.240.24]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAH78568; Thu, 25 Jul 2002 22:38:44 -0400 (EDT) From: "Paul Andrews" To: "Chris Newman" , "Jered Floyd" Cc: Subject: RE: [BEEPwg] Channel response serialization Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016_01C2342C.07A11DC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <2147483647.1027609423@nifty-jr.west.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-MS-TNEF-Correlator: Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Jul 2002 22:38:43 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C2342C.07A11DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sorry Chris. Your messages appear with nop body and an attachment (called something like 'quotation by Paul Andrews on 2002_7_25 12_02 -0400_.dat ') that is complete gibberish if I try and open it. > -----Original Message----- > From: Chris Newman [mailto:Chris.Newman@Sun.COM] > Sent: Thursday, July 25, 2002 6:04 PM > To: Paul Andrews; Jered Floyd > Cc: beepwg@lists.beepcore.org > Subject: RE: [BEEPwg] Channel response serialization > > << File: quotation by Paul Andrews on 2002_7_25 12_02 -0400_.dat >> ------=_NextPart_000_0016_01C2342C.07A11DC0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IisCAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHBwAZABUAIQAAAAQAMwEB A5AGAFAHAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAoAAAAW0JFRVB3Z10gQ2hhbm5lbCByZXNwb25zZSBzZXJpYWxpemF0aW9uAAIB cQABAAAAFgAAAAHCNER0AddcptchrExamJ05tKHRk18AAAIBHQwBAAAAGAAAAFNNVFA6UEFBTkRS RVdAQ0lTQ08uQ09NAAsAAQ4AAAAAQAAGDgBubWBENMIBAgEKDgEAAAAYAAAAAAAAAG8cU1mkhHxO uZZTvIX27Q/CgAAACwAfDgEAAAACAQkQAQAAAJMCAACPAgAAqQMAAExaRnUMPFKjAwAKAHJjcGcx MjUWMgD4C2BuDhAwMzNPAfcCpAPjAgBjaArAc/BldDAgBxMCgwBQEGYYcHJxDlAQ2FRhaJsDcQKA fQqACMggOwlvLQ4wNQKACoF2CJB3a2kLgGQ0DGBjAFALA2MPEgILxAYABbByeSBDQmgFEHMuIFkI YSARB4FzYWcHkWFwcAZlCsED8HRoIG5vtHAgBuBkGNAAcGQbgTcaMAJAANBoB4ACMCAoymMHQGwJ gCBzA3ARMAJoC4BnIGxpa2WMICcXwRFQcXVvAZAcdGkCIBswGNBQYXXtAyBBFwAJcHcEIB7xAdCg MDJfN18OMCAOIEJfIHAgLTA0IGBfLC5kHAAeECkXwiAg1xrQIdEEACAFoG0LUBEwoR4AZ2liYgZx cxrg+QaQIEkicBjBG5IbEAnw+SLAdC4KogqECoQLMB3QfDM2AUAeQQqgA2AjYGP6dAvSNCJgJpAP EyfgEfRsMTYhQClCTwUQI5Bu/wdABdAZxClDJYYnVCchCxNhJ1ZpLTE0IXAmkTGOOCBgDMEs42Ig RgNh9joDMAySYhFQGPMHsgOCxlsAwAMQdG86GPQvdABAU3VuLkNPTb5dCuMKgS4QBmACMDoulhRU aAhwcyHAeSwgPkofcBjQDjAzoCBSIDbWOiFgH0BNMcdUMEAull0fWjszsASQHQFGCQB5MwsxMeVD YzKXI8BlcMh3Z0Ad0HN0GTA5IikFoWUuBbBnMch1YiZqJ4Eyl1JFLnBbQnhFRVA5YDGgGPAAcG7m ZQMgCXBzcAIgESAdIPMGcQdAaXoewyWMK28ngscmpA8GGAcgPDwuIAMQPmUucB6PH58gryGzPj4L MbUUIQBHgAAeAEIQAQAAAC4AAAA8MjE0NzQ4MzY0Ny4xMDI3NjA5NDIzQG5pZnR5LWpyLndlc3Qu c3VuLmNvbT4AAAALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAA4AIIAYAAAAAAMAA AAAAAABGAAAAABCFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAACdqAQAeAAmACCAG AAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAAHgAKgAggBgAAAAAAwAAAAAAAAEYAAAAA NoUAAAEAAAABAAAAAAAAAB4AC4AIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAe AAyACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwANgAggBgAAAAAAwAAAAAAA AEYAAAAAgoUAAAEAAAALADqACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAPIAIIAYAAAAA AMAAAAAAAABGAAAAABGFAAAAAAAAAwA9gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALAFKA CCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMAU4AIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAA AAAAAgH4DwEAAAAQAAAAbxxTWaSEfE65llO8hfbtDwIB+g8BAAAAEAAAAG8cU1mkhHxOuZZTvIX2 7Q8CAfsPAQAAAJoAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAUFNUUFJYLkRMTAAAAAAAAAAATklU Qfm/uAEAqgA32W4AAABEOlxEb2N1bWVudHMgYW5kIFNldHRpbmdzXHBhYW5kcmV3XExvY2FsIFNl dHRpbmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcb3V0bG9vay5wc3QAAAAD AP4PBQAAAAMADTT9NwAAAgF/AAEAAAAyAAAAPEhNRU9MSkpHRE1LQU5HS1BFSklMT0VGRENFQUEu cGFhbmRyZXdAY2lzY28uY29tPgAAAAMABhBU2CFtAwAHEI8BAAADABAQAAAAAAMAERACAAAAHgAI EAEAAABlAAAAU09SUllDSFJJU1lPVVJNRVNTQUdFU0FQUEVBUldJVEhOT1BCT0RZQU5EQU5BVFRB Q0hNRU5UKENBTExFRFNPTUVUSElOR0xJS0VRVU9UQVRJT05CWVBBVUxBTkRSRVdTT04yMAAAAACp ng== ------=_NextPart_000_0016_01C2342C.07A11DC0-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Jul 26 11:12:56 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24465 for ; Fri, 26 Jul 2002 11:12:55 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6QFA4Q02518; Fri, 26 Jul 2002 08:10:04 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6QF9ZQ02496 for ; Fri, 26 Jul 2002 08:09:35 -0700 (PDT) Received: from spamsicle.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6QFDf5X003070 for ; Fri, 26 Jul 2002 11:13:41 -0400 (EDT) Received: from PAANDREWW2K3 (dhcp-161-44-180-140.cisco.com [161.44.180.140]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAH79488; Fri, 26 Jul 2002 11:13:06 -0400 (EDT) From: "Paul Andrews" To: "Beepwg" Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C23495.6B2C1DE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [BEEPwg] RFC Terminology Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Fri, 26 Jul 2002 11:13:07 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C23495.6B2C1DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Is there any particular reason why the BEEP RFCs don't use the terminology recommended in RFC 2119? ------=_NextPart_000_004D_01C23495.6B2C1DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Is = there any=20 particular reason why the BEEP RFCs don't use the terminology = recommended in RFC=20 2119?

------=_NextPart_000_004D_01C23495.6B2C1DE0-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Jul 26 13:53:19 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02129 for ; Fri, 26 Jul 2002 13:53:18 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6QHo4Q03572; Fri, 26 Jul 2002 10:50:04 -0700 (PDT) Received: from miz-mishtal.dbc.mtview.ca.us (miz-mishtal.dbc.mtview.ca.us [64.168.10.250]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6QHnsQ03549 for ; Fri, 26 Jul 2002 10:49:55 -0700 (PDT) Received: from FATORA (dhcpd253.dbc.mtview.ca.us [64.168.10.253]) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g6QHPSd29555; Fri, 26 Jul 2002 10:25:28 -0700 (PDT) Message-ID: <000001c234cd$1f0b9cf0$0701000a@FATORA> From: "Marshall T. Rose" To: "Paul Andrews" , "Beepwg" Cc: "Marshall Rose" References: Subject: Re: [BEEPwg] RFC Terminology MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C2348A.C9D49A80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Fri, 26 Jul 2002 09:57:01 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C2348A.C9D49A80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit some of us don't like SHOUTING! others of us feel that people who know how to write specifications well don't need the formalisms that 2119 provides. /mtr ----- Original Message ----- From: Paul Andrews To: Beepwg Sent: Friday, July 26, 2002 08:13 Subject: [BEEPwg] RFC Terminology Is there any particular reason why the BEEP RFCs don't use the terminology recommended in RFC 2119? ------=_NextPart_000_002E_01C2348A.C9D49A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

some of us don't like SHOUTING!

others of us feel that people who know how to write=20 specifications well don't need the formalisms that 2119 = provides.

/mtr

----- Original Message -----
From:=20 Paul = Andrews=20
To: Beepwg

Sent: Friday, July 26, 2002 = 08:13

Subject: [BEEPwg] RFC = Terminology

Is = there any=20 particular reason why the BEEP RFCs don't use the terminology = recommended in=20 RFC 2119?

------=_NextPart_000_002E_01C2348A.C9D49A80-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Jul 26 14:38:58 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03720 for ; Fri, 26 Jul 2002 14:38:57 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6QIa3Q03892; Fri, 26 Jul 2002 11:36:03 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6QIZCQ03875 for ; Fri, 26 Jul 2002 11:35:13 -0700 (PDT) Received: from spamsicle.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6QIdChD027144; Fri, 26 Jul 2002 14:39:12 -0400 (EDT) Received: from PAANDREWW2K3 (dhcp-161-44-180-140.cisco.com [161.44.180.140]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAH80403; Fri, 26 Jul 2002 14:38:37 -0400 (EDT) From: "Paul Andrews" To: "Marshall T. Rose" , "Beepwg" Subject: RE: [BEEPwg] RFC Terminology Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01C234B2.20A3BD60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <000001c234cd$1f0b9cf0$0701000a@FATORA> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Fri, 26 Jul 2002 14:38:37 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_0061_01C234B2.20A3BD60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit WELL ALL RIGHT THEN :-) -----Original Message----- From: Marshall T. Rose [mailto:mrose@dbc.mtview.ca.us] Sent: Friday, July 26, 2002 12:57 PM To: Paul Andrews; Beepwg Cc: Marshall Rose Subject: Re: [BEEPwg] RFC Terminology some of us don't like SHOUTING! others of us feel that people who know how to write specifications well don't need the formalisms that 2119 provides. /mtr ----- Original Message ----- From: Paul Andrews To: Beepwg Sent: Friday, July 26, 2002 08:13 Subject: [BEEPwg] RFC Terminology Is there any particular reason why the BEEP RFCs don't use the terminology recommended in RFC 2119? ------=_NextPart_000_0061_01C234B2.20A3BD60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

WELL=20 ALL RIGHT THEN :-)

-----Original Message-----
From: Marshall T. Rose=20 [mailto:mrose@dbc.mtview.ca.us]
Sent: Friday, July 26, 2002 = 12:57=20 PM
To: Paul Andrews; Beepwg
Cc: Marshall=20 Rose
Subject: Re: [BEEPwg] RFC = Terminology

some of us don't like SHOUTING!

others of us feel that people who know how to = write=20 specifications well don't need the formalisms that 2119 = provides.

/mtr

----- Original Message -----
From:=20 Paul=20 Andrews
To: Beepwg

Sent: Friday, July 26, 2002 = 08:13

Subject: [BEEPwg] RFC = Terminology

Is = there any=20 particular reason why the BEEP RFCs don't use the terminology = recommended in=20 RFC = 2119?

------=_NextPart_000_0061_01C234B2.20A3BD60-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Jul 26 14:57:47 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04309 for ; Fri, 26 Jul 2002 14:57:47 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6QIt4Q04066; Fri, 26 Jul 2002 11:55:04 -0700 (PDT) Received: from wetware.wetware.com (wetware.wetware.com [199.108.16.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g6QIsbQ04047 for ; Fri, 26 Jul 2002 11:54:37 -0700 (PDT) Received: from (local broken client) localhost(dh07.wetware.com[199.108.16.47]) (1664 bytes) by wetware.wetware.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Fri, 26 Jul 2002 11:58:10 -0700 (PDT) (Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Jan-4) Subject: Re: [BEEPwg] RFC Terminology Content-Type: multipart/alternative; boundary=Apple-Mail-1-10569835 Mime-Version: 1.0 (Apple Message framework v482) From: james woodyatt To: BEEPwg In-Reply-To: <000001c234cd$1f0b9cf0$0701000a@FATORA> Message-Id: X-Mailer: Apple Mail (2.482) Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Fri, 26 Jul 2002 11:58:13 -0700 --Apple-Mail-1-10569835 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Friday, July 26, 2002, at 09:57 AM, Marshall T. Rose wrote: > [...] > others of us feel that people who know how to write specifications well > don't need the formalisms that 2119 provides. Some of the more jaded among us also feel that people who don't know how to *read* a well-written specification need a lot more help than the RFC 2119 formalisms provide. -- j h woodyatt