From beepwg-admin@lists.beepcore.org Mon Mar 4 12:08: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 MAA03681 for ; Mon, 4 Mar 2002 12:08:29 -0500 (EST) 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 g24Gx6i01763; Mon, 4 Mar 2002 08:59:07 -0800 (PST) Received: from carnivore.defcom.com (carnivore.defcom.com [213.242.182.53]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g24FUEi01054 for ; Mon, 4 Mar 2002 07:30:15 -0800 (PST) Received: (qmail 9042 invoked by uid 0); 4 Mar 2002 15:25:26 -0000 Received: from unknown (HELO defcom.com) (213.242.182.146) by mx.defcom.com with SMTP; 4 Mar 2002 15:25:26 -0000 Message-ID: <3C8393A8.F182BF11@defcom.com> From: krister@defcom.com Organization: Defcom Sweden AB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.16-pre1 i686) X-Accept-Language: en MIME-Version: 1.0 To: beepwg@lists.beepcore.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [BEEPwg] release date 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: Mon, 04 Mar 2002 16:32:57 +0100 Content-Transfer-Encoding: 7bit Hi, when is the next major release of beepcore-c scheduled? // Krister Hedfors _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Mar 7 10:02: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 KAA28386 for ; Thu, 7 Mar 2002 10:02:40 -0500 (EST) 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 g27ErBi26103; Thu, 7 Mar 2002 06:53:11 -0800 (PST) Received: from web20509.mail.yahoo.com (web20509.mail.yahoo.com [216.136.226.144]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g27EqRi26091 for ; Thu, 7 Mar 2002 06:52:27 -0800 (PST) Message-ID: <20020307150101.25518.qmail@web20509.mail.yahoo.com> Received: from [203.122.21.131] by web20509.mail.yahoo.com via HTTP; Thu, 07 Mar 2002 07:01:01 PST From: Mark C To: beepwg@lists.beepcore.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-338272132-1015513261=:25381" Subject: [BEEPwg] SOAP over BEEP 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, 7 Mar 2002 07:01:01 -0800 (PST) --0-338272132-1015513261=:25381 Content-Type: text/plain; charset=us-ascii Hi I have some questions regarding SOAP over BEEP. 1) What is the motivation for providing SOAP bindings with BEEP? 2) How the *asynchrony* would be achieved in SOAP over BEEP? Also does this "synchrony" makes senses for "RPC" (RPC style in SOAP) or it would be just useful to "messaging" (messaging style in SOAP). 3) Would SOAP over BEEP, provides other features of BEEP like sending simultaneous and independent data etc.? 4) Is there any implementation of SOAP over BEEP exists? 5) Would SOAP over BEEP support "Soap with Attachments", "SOAP DSig", "XKMS" and other upcoming standards. in near future? regards, /Mark C. --------------------------------- Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! --0-338272132-1015513261=:25381 Content-Type: text/html; charset=us-ascii

Hi

I have some questions regarding SOAP over BEEP.

1) What is the motivation for providing SOAP bindings with BEEP?

2) How the *asynchrony* would be achieved in SOAP over BEEP? Also does this "synchrony" makes senses for "RPC" (RPC style in SOAP) or it would be just useful to "messaging" (messaging style in SOAP).

3) Would SOAP over BEEP, provides other features of BEEP like sending simultaneous and independent data etc.?

4) Is there any implementation of SOAP over BEEP exists?

5) Would SOAP over BEEP support "Soap with Attachments", "SOAP DSig", "XKMS" and other upcoming standards. in near future?

regards,

/Mark C.


Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email! --0-338272132-1015513261=:25381-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Mar 7 12:02:02 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 MAA07084 for ; Thu, 7 Mar 2002 12:02:01 -0500 (EST) 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 g27Gr3i26790; Thu, 7 Mar 2002 08:53:03 -0800 (PST) Received: from xomi.pair.com (xomi.pair.com [209.68.2.14]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g27GqEi26778 for ; Thu, 7 Mar 2002 08:52:14 -0800 (PST) Received: (qmail 70875 invoked by uid 3039); 7 Mar 2002 17:00:43 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Mar 2002 17:00:43 -0000 From: Gabe Wachob X-Sender: To: Mark C cc: Subject: Re: [BEEPwg] SOAP over BEEP In-Reply-To: <20020307150101.25518.qmail@web20509.mail.yahoo.com> Message-ID: 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: Thu, 7 Mar 2002 09:00:43 -0800 (PST) On Thu, 7 Mar 2002, Mark C wrote: > > Hi > > I have some questions regarding SOAP over BEEP. > > 1) What is the motivation for providing SOAP bindings with BEEP? For me, its that BEEP is a better transport for some message patterns than HTTP. I'm far more interested in the non-RPC uses of SOAP, and HTTP isn't neccesary ideal for those situations. Also, if you have BEEP infrastructure deployed (ie firewall support, BEEP code deployed), I'd like to be able to use SOAP on it instead of having to deploy HTTP as well. In the long run, I think the security features of BEEP (that is, extensibility) will make BEEP more attractive in some network environments than opening up HTTP ports. > 2) How the *asynchrony* would be achieved in SOAP over BEEP? Also does > this "synchrony" makes senses for "RPC" (RPC style in SOAP) or it > would be just useful to "messaging" (messaging style in SOAP). Well, remember that SOAP doesn't say anything about synchronicity vs. asynchronicity except at the transport binding level. SOAP/BEEP does describe RPC as happening over a single channel, and I imagine thats satisfactory in 99% of the cases where you are doing RPC. > 3) Would SOAP over BEEP, provides other features of BEEP like sending > simultaneous and independent data etc.? Sure. You could imagine two peers opening a SOAP channel (for conducting SOAP transactions) and opening a file transfer channel or an "chat" channel or whatever. To use the same underlying TCP connection, you'd have to have multiple profiles share the same BEEP endpoint.. > 4) Is there any implementation of SOAP over BEEP exists? Not that I know of, though I have heard rumors of interest.. > 5) Would SOAP over BEEP support "Soap with Attachments", "SOAP DSig", > "XKMS" and other upcoming standards. in near future? Well, since BEEP provides a MIME payload, and SwA assumes a MIME wrapper, I think that would be straightforward. As for DSig - as far as I remember, thats not visible to the transport, so that should drop into a SOAP message over BEEP. HTH -Gabe -- Gabe Wachob gwachob@wachob.com Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Mar 8 02:28:07 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 CAA24114 for ; Fri, 8 Mar 2002 02:28:06 -0500 (EST) 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 g287J3i01523; Thu, 7 Mar 2002 23:19:03 -0800 (PST) Received: from smtp1.tivoli.com (smtp1.tivoli.com [208.230.244.2]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g27IUfi27352 for ; Thu, 7 Mar 2002 10:30:41 -0800 (PST) Received: (qmail 19432 invoked from network); 7 Mar 2002 18:38:37 -0000 Received: from unknown (HELO devmail.dev.tivoli.com) (208.230.244.136) by smtp1.tivoli.com with SMTP; 7 Mar 2002 18:38:37 -0000 Received: from us.ibm.com (WHAROLD.dyn.tivoli.com [146.84.38.74]) by devmail.dev.tivoli.com (8.9.1/8.9.1) with ESMTP id MAA12411 for ; Thu, 7 Mar 2002 12:39:01 -0600 (CST) Message-ID: <3C87B3BF.DACBCE2E@us.ibm.com> From: Ward Harold Organization: Tivoli Systems X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: beepwg@lists.beepcore.org Subject: Re: [BEEPwg] SOAP over BEEP 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, 07 Mar 2002 12:38:56 -0600 Content-Transfer-Encoding: 7bit Gabe Wachob wrote: > > 4) Is there any implementation of SOAP over BEEP exists? > > Not that I know of, though I have heard rumors of interest.. > beepcore-tcl has an implementation. I tried adapting the new Apache Axis code for a couple of weeks but their transport mechanism didn't handle session-oriented transports and they weren't interested in addressing the problem so I gave up. ... WkH _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Mar 8 04:08:02 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 EAA26426 for ; Fri, 8 Mar 2002 04:08:01 -0500 (EST) 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 g288x3i02065; Fri, 8 Mar 2002 00:59:03 -0800 (PST) Received: from mail.labs2.com (qmailr@mail.framfablabs.com [195.54.107.240]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g288wSi02053 for ; Fri, 8 Mar 2002 00:58:28 -0800 (PST) Received: (qmail 25082 invoked from network); 8 Mar 2002 09:07:05 -0000 Received: from unknown (HELO seluninfmail01.wrk.framfablabs.net) (195.54.107.200) by mail.labs2.com with SMTP; 8 Mar 2002 09:07:05 -0000 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="iso-8859-1" Message-ID: <44059D2977EF4C4DB810E37890E3346E40B3FF@seluninfmail01.wrk.framfablabs.net> Thread-Topic: Intel P2P Kit and BEEP Thread-Index: AcHGgJ39pSCpqZSjQPuMGJkZb/BcXw== From: =?iso-8859-1?Q?Olof_H=E4rwell?= To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by qawoor.dbc.mtview.ca.us id g288wSi02053 Subject: [BEEPwg] Intel P2P Kit and BEEP 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, 8 Mar 2002 10:07:04 +0100 Content-Transfer-Encoding: 8bit Hi, Being new to the list I'm not aware if this has previously been discussed here, but I was wondering if the Intel BEEP implementation that is included in their .NET based P2P kit (http://www.gotdotnet.com/team/p2p/) is compatible with the ones available on beepcore.org. Also, what state would you say the tcl, c & Java implementations are in. Which version is the most complete one and preferable to use? Cheers, Olof /* Olof Härwell Concept Development LABS2 Direct: +46 46 540 01 10 Mobile: +46 70 941 20 10 Phone: +46 46 13 74 25 Fax: +46 46 13 74 26 Address: Winstrupsgatan 1, SE-222 22 Lund, Sweden Internet: http://www.labs2.com */ _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Mar 8 11:55:23 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 LAA16184 for ; Fri, 8 Mar 2002 11:55:22 -0500 (EST) 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 g28Gk9i05173; Fri, 8 Mar 2002 08:46:09 -0800 (PST) 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 g28GjPi05161 for ; Fri, 8 Mar 2002 08:45:25 -0800 (PST) Received: from kalia (dhcpd253 [64.168.10.253] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g28Geq521637; Fri, 8 Mar 2002 08:40:52 -0800 (PST) From: Marshall Rose To: beepwg@lists.beepcore.org Cc: olof.harwell@labs2.com Subject: Re: [BEEPwg] Intel P2P Kit and BEEP Message-Id: <20020308085238.54e6a824.mrose@dbc.mtview.ca.us> In-Reply-To: <44059D2977EF4C4DB810E37890E3346E40B3FF@seluninfmail01.wrk.framfablabs.net> References: <44059D2977EF4C4DB810E37890E3346E40B3FF@seluninfmail01.wrk.framfablabs.net> 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: Fri, 8 Mar 2002 08:52:38 -0800 Content-Transfer-Encoding: 7bit > Being new to the list I'm not aware if this has previously been discussed here, but I was wondering if the Intel BEEP implementation that is included in their .NET based P2P kit (http://www.gotdotnet.com/team/p2p/) is compatible with the ones available on beepcore.org. i wasn't able to find an email address anywhere in the package, so i don't know who to contact to find out what exactly they did. generally, my first step is to go to http://www.beepcore.org/beepcore/products.jsp to see what products support what, but they aren't listed there... if someone associated with the intel p2p kit would privately contact me, that would be nice... > > Also, what state would you say the tcl, c & Java implementations are in. Which version is the most complete one and preferable to use? given a choice between C and Java, for the rest of the month, i'd go with the Java one. there's supposed to be a lot of revisions to the C code by month's end, and at that time, there shouldn't be a clear "x is better than y". the Tcl code is, at present, the most developed. however, Tcl is the forgotten programming language... /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Mar 8 11:56: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 LAA16412 for ; Fri, 8 Mar 2002 11:56:49 -0500 (EST) 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 g28Gm3i05213; Fri, 8 Mar 2002 08:48:03 -0800 (PST) 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 g28GkIi05175 for ; Fri, 8 Mar 2002 08:46:18 -0800 (PST) Received: from kalia (dhcpd253 [64.168.10.253] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g28Gfj521647; Fri, 8 Mar 2002 08:41:45 -0800 (PST) From: Marshall Rose To: beepwg@lists.beepcore.org Cc: wharold@us.ibm.com Subject: Re: [BEEPwg] SOAP over BEEP Message-Id: <20020308085330.123a76a5.mrose@dbc.mtview.ca.us> In-Reply-To: <3C87B3BF.DACBCE2E@us.ibm.com> References: <3C87B3BF.DACBCE2E@us.ibm.com> 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: Fri, 8 Mar 2002 08:53:30 -0800 Content-Transfer-Encoding: 7bit > Gabe Wachob wrote: > > > > 4) Is there any implementation of SOAP over BEEP exists? > > > > Not that I know of, though I have heard rumors of interest.. > > > > beepcore-tcl has an implementation. I tried adapting the new Apache Axis code > for a couple of weeks but their transport mechanism didn't handle > session-oriented transports and they weren't interested in addressing the > problem so I gave up. clipcode has an implementation as well in .NET - http://www.clicpode.com/peer/developer.htm /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Mar 8 11:56:53 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 LAA16425 for ; Fri, 8 Mar 2002 11:56:52 -0500 (EST) 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 g28Gm5i05229; Fri, 8 Mar 2002 08:48:06 -0800 (PST) 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 g28GlCi05187 for ; Fri, 8 Mar 2002 08:47:12 -0800 (PST) Received: from kalia (dhcpd253 [64.168.10.253] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g28Ggc521657; Fri, 8 Mar 2002 08:42:39 -0800 (PST) From: Marshall Rose To: beepwg@lists.beepcore.org Cc: mark_c_78@yahoo.com Subject: Re: [BEEPwg] SOAP over BEEP Message-Id: <20020308085423.5369da20.mrose@dbc.mtview.ca.us> In-Reply-To: <20020307150101.25518.qmail@web20509.mail.yahoo.com> References: <20020307150101.25518.qmail@web20509.mail.yahoo.com> 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: Fri, 8 Mar 2002 08:54:23 -0800 Content-Transfer-Encoding: 7bit > 5) Would SOAP over BEEP support "Soap with Attachments", "SOAP DSig", "XKMS" and other upcoming standards. in near future? the spec says "yes". at present, the soap package for tcl says "no". i hear that's going to change soon... /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Mar 8 16:32:10 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 QAA05341 for ; Fri, 8 Mar 2002 16:32:09 -0500 (EST) 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 g28LJ6i06933; Fri, 8 Mar 2002 13:19:06 -0800 (PST) Received: from loreto.kahleassociates.com (kahle-gw.accessone.net [198.182.115.194]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g28LIVi06921 for ; Fri, 8 Mar 2002 13:18:31 -0800 (PST) Received: (qmail 27277 invoked from network); 8 Mar 2002 21:30:32 -0000 Received: from unknown (HELO losfrailes) (192.168.1.101) by 0 with SMTP; 8 Mar 2002 21:30:32 -0000 From: "Randolph S. Kahle" To: beepwg@lists.beepcore.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Message-Id: <1015622862.7858.89.camel@losfrailes> Mime-Version: 1.0 Subject: [BEEPwg] Question about terminating a session 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: 08 Mar 2002 14:27:42 -0700 Content-Transfer-Encoding: 7bit I am working on an implementation of BEEP in Java (http://www.simplebeep.org) and I am trying to figure out if I understand the specification for the handshake at session termination time. The basic handshake is --> <-- However, with SEQ frames added (for the TCP/IP transport mapping), one could have the following --> SEQ <-- (because it was fully read) <-- SEQ --> (same reason) What about this last SEQ frame? How are other implementation handling this final set of packets? Is it a violation of the BEEP specification to send that frame or (as I read it), not addressed. Randy _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Mar 8 17:39: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 RAA08687 for ; Fri, 8 Mar 2002 17:39:20 -0500 (EST) 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 g28MU3i07346; Fri, 8 Mar 2002 14:30:03 -0800 (PST) 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 g28MTKi07324 for ; Fri, 8 Mar 2002 14:29:20 -0800 (PST) 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 31D00132E2; Fri, 8 Mar 2002 17:38:02 -0500 (EST) To: "Randolph S. Kahle" Cc: beepwg@lists.beepcore.org Subject: Re: [BEEPwg] Question about terminating a session References: <1015622862.7858.89.camel@losfrailes> From: Jered Floyd In-Reply-To: <1015622862.7858.89.camel@losfrailes> Message-ID: <87u1rqbs8l.fsf@questionably-configured.permabit.com> Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) 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: 08 Mar 2002 17:38:02 -0500 "Randolph S. Kahle" writes: > --> > SEQ <-- (because it was fully read) > <-- > SEQ --> (same reason) > > What about this last SEQ frame? How are other implementation handling > this final set of packets? PermaBEEP currently supresses any further traffic (including SEQ traffic) on a channel (or session) after it has sent a close request and before it has received a response. In the case of a positive response, no further traffic will be sent. So, my implementation will not send that final SEQ. Note that this isn't entirely safe. If your response to my close request was larger than the channel window buffer free, we would deadlock. A similar concern exists with the implicit close of all channels when TLS tuning. (See a thread on this I brought up a few months ago.) As a listener, PermaBEEP closes the session after acknowledging a session close with a positive reply, so the SEQ is not a concern. > Is it a violation of the BEEP specification to send that frame or (as I > read it), not addressed. This is an example of a subtle interaction between channel management and transport mappings that I don't think is sufficiently explored in the current spec. --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Mar 8 17:57: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 RAA09517 for ; Fri, 8 Mar 2002 17:57:49 -0500 (EST) 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 g28Mn2i07461; Fri, 8 Mar 2002 14:49:02 -0800 (PST) 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 g28MmPi07449 for ; Fri, 8 Mar 2002 14:48:26 -0800 (PST) Received: from san.rr.com (66-75-151-160.san.rr.com [66.75.151.160]) by smtp2.san.rr.com (8.11.4/8.11.4) with ESMTP id g28Muwr19011; Fri, 8 Mar 2002 14:56:58 -0800 (PST) Message-ID: <3C8941C3.B75DBC43@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: Jered Floyd CC: "Randolph S. Kahle" , beepwg@lists.beepcore.org Subject: Re: [BEEPwg] Question about terminating a session References: <1015622862.7858.89.camel@losfrailes> <87u1rqbs8l.fsf@questionably-configured.permabit.com> 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: Fri, 08 Mar 2002 14:57:07 -0800 Content-Transfer-Encoding: 7bit Jered Floyd wrote: > > "Randolph S. Kahle" writes: > > > --> > > SEQ <-- (because it was fully read) > > <-- > > SEQ --> (same reason) > > > > What about this last SEQ frame? How are other implementation handling > > this final set of packets? > > PermaBEEP currently supresses any further traffic (including SEQ > traffic) on a channel (or session) after it has sent a close request > and before it has received a response. In the case of a positive > response, no further traffic will be sent. So, my implementation > will not send that final SEQ. This needs to be done while starting security layers too. It's not really new. An that starts TLS with an embedded or a on an already-open TLS channel has to do the same sort of thing. > Note that this isn't entirely safe. If your response to my close > request was larger than the channel window buffer free, we would > deadlock. One method (used in beepcore-c) is to send the SEQ *before* the or or whatever. At least you have the full window available. > This is an example of a subtle interaction between channel management > and transport mappings that I don't think is sufficiently explored in > the current spec. Yes, it's a complex interaction there. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. To the user, everything works just as expected, assuming the user's expectations are correct. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Mar 11 11:57: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 LAA14685 for ; Mon, 11 Mar 2002 11:57:19 -0500 (EST) 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 g2BGlAi00601; Mon, 11 Mar 2002 08:47:10 -0800 (PST) Received: from medicor.wustl.edu (medicor.wustl.edu [128.252.223.195]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2BGkqi00589 for ; Mon, 11 Mar 2002 08:46:53 -0800 (PST) To: beepwg@lists.beepcore.org X-Mailer: Lotus Notes Release 5.0.1 July 16, 1999 Message-ID: From: MooreS@mir.wustl.edu X-MIMETrack: Serialize by Router on Medicor/Washington University(Release 5.0.8 |June 18, 2001) at 03/11/2002 10:55:54 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [BEEPwg] Questions about RFC 3080 (and then 3195) 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: Mon, 11 Mar 2002 10:52:09 -0600 We are going to use BEEP to send reliable syslog messages for medical imaging systems (CT scanners, image archives). I could use some help in making sure I understand how this works. If the questions about Reliable Syslog should go to another forum, please point me in the proper direction. 1. We are going to use TLS. Is this how this works? - Initiator/listener exchange greeting messages - Initiator sends a start message with the profile - Listener sends RPY message and says to proceed - TLS negotiation occurs on the open socket. This is not encapsulated in BEEP; it just occurs at the socket level - After TLS negotiation, initiator and listener exchange greeting messages again. These include different profiles, now that we are using TLS encryption. - Initiator would send a new start message, listener would reply, and off we go 2. This is probably a rewording of #1, but I need to be certain. When TLS is used (and operational), I assume it is the next layer above the socket layer. That is, the BEEP messages are then sent through a TLS encapsulated stream. 3. This would imply that for a session, you can only have a single encryption scheme active at a time. That is, you can have multiple channels open, but they will all use the single encryption scheme that was negotiated up front. (Yes/no)? 4. Now, I will drift into RFC 3195. The listener wants to support the COOKED mode of syslog. I think the exchange works something like this: - After the socket is first opened, listener sends a greeting message with the (one) profile http://iana.org/beep/TLS. Initiator sends greeting message as always. - After initiator sends the start message, TLS negotiation occurs. - Listener now sends a greeting message with a profile http://xml.resource.org/profiles/syslog/COOKED. - Initiator sends greeting message (possibly before listener does). - Initiator sends a start message with that profile (COOKED), listener sends the RPY message and then the exchange of syslog messages starts. Do I have this correct? 5. Our group has defined further the content of the syslog messages. They are not just plain text, but are expressed in XML. So we use the syslog wrapper, but add our own XML. Does this look like this? { My XML} 5.1 If the messages have the format as described above, is the text for {My XML} just pasted in as XML Value1 Or do I have to "escape" this somehow (sorry, not an XML expert either)? 5.2 If I can figure out how the XML encoding works, does this mean that I still use the profile 'http://xml.resource.org/profiles/syslog/COOKED or does our group have to define a new profile Thanks in advance for your help, Steve Moore Washington University School of Medicine _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Mar 11 14:06:39 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 OAA19477 for ; Mon, 11 Mar 2002 14:06:39 -0500 (EST) 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 g2BIu7i01368; Mon, 11 Mar 2002 10:56:07 -0800 (PST) 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 g2BItoi01356 for ; Mon, 11 Mar 2002 10:55:50 -0800 (PST) Received: from san.rr.com (66-75-151-160.san.rr.com [66.75.151.160]) by smtp2.san.rr.com (8.11.4/8.11.4) with ESMTP id g2BJ4nE10545; Mon, 11 Mar 2002 11:04:49 -0800 (PST) Message-ID: <3C8CFFDB.38887541@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: MooreS@mir.wustl.edu, beepwg@lists.beepcore.org Subject: Re: [BEEPwg] Questions about RFC 3080 (and then 3195) 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: Mon, 11 Mar 2002 11:04:59 -0800 Content-Transfer-Encoding: 7bit MooreS@mir.wustl.edu wrote: > > We are going to use BEEP to send reliable syslog messages for medical > imaging systems (CT scanners, image archives). I could use some help in > making sure I understand how this works. If the questions about Reliable > Syslog > should go to another forum, please point me in the proper direction. The syslog-reliable working group has a mailing list, too. > 1. We are going to use TLS. Is this how this works? > - Initiator/listener exchange greeting messages > - Initiator sends a start message with the profile > > - Listener sends RPY message and says to proceed > - TLS negotiation occurs on the open socket. This is > not encapsulated in BEEP; it just occurs at the socket level > - After TLS negotiation, initiator and listener exchange > greeting messages again. These include different > profiles, now that we are using TLS encryption. > - Initiator would send a new start message, listener > would reply, and off we go Correct. > 2. This is probably a rewording of #1, but I need to be certain. > When TLS is used (and operational), I assume it is the next > layer above the socket layer. That is, the BEEP messages are > then sent through a TLS encapsulated stream. Correct. > 3. This would imply that for a session, you can only have a single > encryption scheme active at a time. That is, you can have > multiple channels open, but they will all use the single encryption > scheme that was negotiated up front. (Yes/no)? Correct. > 4. Now, I will drift into RFC 3195. The listener wants to support > the COOKED mode of syslog. I think the exchange works something > like this: > - After the socket is first opened, listener sends a greeting message > with the (one) profile http://iana.org/beep/TLS. Initiator sends greeting > message as always. > - After initiator sends the start message, TLS negotiation occurs. > - Listener now sends a greeting message with a profile > http://xml.resource.org/profiles/syslog/COOKED. > - Initiator sends greeting message (possibly before listener does). > - Initiator sends a start message with that profile (COOKED), listener > sends > the RPY message and then the exchange of syslog messages > starts. > Do I have this correct? Yes. In RAW mode, the "exchange of syslog messages" is different, but yes. Note that in COOKED mode, each syslog message sent is answered with . You can't have syslog messages going both directions on the same channel. You can open a second channel in the other direction if you want bidirectional syslog messages. > 5. Our group has defined further the content of the syslog messages. > They are not just plain text, but are expressed in XML. So we use > the syslog wrapper, but add our own XML. Does this look like this? > > { My XML} > That would do, yes. > 5.1 If the messages have the format as described above, is the text > for {My XML} just pasted in as XML > Value1 > Or do I have to "escape" this somehow (sorry, not an XML expert either)? You have to escape it. The in the DTD means that only "parsed character data" may occur there. Hence, since it's parsed, you need to escape (<) any less-than signs in the data. Grok the data in the first couple of examples in 4.4.2. > 5.2 If I can figure out how the XML encoding works, does this mean that > I still use the profile 'http://xml.resource.org/profiles/syslog/COOKED > or does our group have to define a new profile It shouldn't be a problem to use this, if your XML records are small enough. Of course, standard relays and such won't understand what's inside the data, but a custom collector should be able to. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. To the user, everything works just as expected, assuming the user's expectations are correct. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Mar 11 20:49:21 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 UAA01821 for ; Mon, 11 Mar 2002 20:49:20 -0500 (EST) 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 g2C1e4i03508; Mon, 11 Mar 2002 17:40:04 -0800 (PST) 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 g2C1dri03490 for ; Mon, 11 Mar 2002 17:39:53 -0800 (PST) Received: from kallisti.apple.com(wetware.wetware.com[199.108.16.1]) (1748 bytes) by wetware.wetware.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Mon, 11 Mar 2002 17:48:50 -0800 (PST) (Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Jan-4) Mime-Version: 1.0 (Apple Message framework v481) Content-Type: text/plain; charset=US-ASCII; format=flowed From: james woodyatt To: BEEP WG Content-Transfer-Encoding: 7bit Message-Id: <480138C8-355B-11D6-BD17-000502DB38F5@wetware.com> X-Mailer: Apple Mail (2.481) Subject: [BEEPwg] rfc 3081, queueing, implementations 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: Mon, 11 Mar 2002 17:48:41 -0800 Content-Transfer-Encoding: 7bit fellow travelers-- Consider that RFC 3081 has this to say in Section 3.1.4, Use of Flow Control: > Implementations may wish to provide queue management facilities to the > application using BEEP, e.g., channel priorities, (relative) buffer > allocations, and so on. In particular, implementations should not > allow a given channel to monopolize the underlying transport window > (e.g., slow readers should get small windows). I am completely unfamiliar with what other implementations do in this regard (since I still have a long way to go before I begin interoperability testing), but I'm interested to know what facilities are in use now. One thing that concerns me: the proposed standard does not define a way for a BEEP application to signal the desired channel priority or relative buffer allocation to its peer. I'm not sure such facilities are very useful without such a mechanism. Another thing that has me worried: I'd like to understand how giving smaller windows to slower readers prevents a given channel from monopolizing the underlying TCP window. Could someone point me to an explanation of the theory behind this approach? -- j h woodyatt _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Mar 11 21:29:18 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 VAA02445 for ; Mon, 11 Mar 2002 21:29:18 -0500 (EST) 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 g2C2K4i03745; Mon, 11 Mar 2002 18:20:04 -0800 (PST) Received: from xomi.pair.com (xomi.pair.com [209.68.2.14]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g2C2J0i03727 for ; Mon, 11 Mar 2002 18:19:01 -0800 (PST) Received: (qmail 74635 invoked by uid 3039); 12 Mar 2002 02:27:56 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 12 Mar 2002 02:27:56 -0000 From: Gabe Wachob X-Sender: To: james woodyatt cc: BEEP WG Subject: Re: [BEEPwg] rfc 3081, queueing, implementations In-Reply-To: <480138C8-355B-11D6-BD17-000502DB38F5@wetware.com> Message-ID: 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: Mon, 11 Mar 2002 18:27:56 -0800 (PST) On Mon, 11 Mar 2002, james woodyatt wrote: > fellow travelers-- > > Consider that RFC 3081 has this to say in Section 3.1.4, Use of Flow > Control: > > > Implementations may wish to provide queue management facilities to the > > application using BEEP, e.g., channel priorities, (relative) buffer > > allocations, and so on. In particular, implementations should not > > allow a given channel to monopolize the underlying transport window > > (e.g., slow readers should get small windows). > > I am completely unfamiliar with what other implementations do in this > regard (since I still have a long way to go before I begin > interoperability testing), but I'm interested to know what facilities > are in use now. PyBEEP has (when completed) a pluggable "scheduler". This scheduler could be configured to give channels different "priorities" based on almost any algorithm you could choose to implement. Initially, there will only be a round robin scheduler implemented, most likely. (That is, roughly, rotating through the list of "ready to write" channels to write from). This, of course, only directly affects "priority" only as far as *writing* data to remote peers. > One thing that concerns me: the proposed standard does not define a way > for a BEEP application to signal the desired channel priority or > relative buffer allocation to its peer. I'm not sure such facilities > are very useful without such a mechanism. This is a "topside" (or API) specification and is not addressed by BEEP, just as HTTP doesn't address such things as CGI. Perhaps all the implementations will converge on some API or at least concepts, but I think its a little too early quite yet, and even so, it wouldn't be generally applicable for all BEEP-based applications. I saw a draft by someone (which is no longer current) suggesting some ways of negotiating "priorities" between peers (which is a separate issue) - I'm hoping someone will speak up as to the document title and URL. > Another thing that has me worried: I'd like to understand how giving > smaller windows to slower readers prevents a given channel from > monopolizing the underlying TCP window. Could someone point me to an > explanation of the theory behind this approach? Thats hard to do in a short email, and I'll probably butcher it, but I think the idea is that a slow reader is going to leave data in the incoming TCP stream buffer longer (filling the TCP window) and thus doesn't allow other fasters readers (who would empty incoming TCP stream buffers quicker) to use the connection while the slow reader is consuming the data. I think also that windowing manipulation allows for a local peer to influence the ability of a remote peer to send data to "higher priority" local profiles/channels (even if the local profile/channel is not a "slow" reader). This stuff is easy to make misstatements about, so I'll stop here ;-) -Gabe -- Gabe Wachob gwachob@wachob.com Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Mar 11 22:11:16 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 WAA04219 for ; Mon, 11 Mar 2002 22:11:16 -0500 (EST) 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 g2C323i04050; Mon, 11 Mar 2002 19:02:03 -0800 (PST) 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 g2C31hi04038 for ; Mon, 11 Mar 2002 19:01:43 -0800 (PST) Received: from kallisti.apple.com(wetware.wetware.com[199.108.16.1]) (4578 bytes) by wetware.wetware.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Mon, 11 Mar 2002 19:10:40 -0800 (PST) (Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Jan-4) Subject: Re: [BEEPwg] rfc 3081, queueing, implementations Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: BEEP WG To: Gabe Wachob From: james woodyatt In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) 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: Mon, 11 Mar 2002 19:10:32 -0800 Content-Transfer-Encoding: 7bit On Monday, March 11, 2002, at 06:27 PM, Gabe Wachob wrote: > On Mon, 11 Mar 2002, james woodyatt wrote: >> [...] >> I am completely unfamiliar with what other implementations do in this >> regard (since I still have a long way to go before I begin >> interoperability testing), but I'm interested to know what facilities >> are in use now. > > PyBEEP has (when completed) a pluggable "scheduler". This scheduler > could > be configured to give channels different "priorities" based on almost > any > algorithm you could choose to implement. [...] That's good to know. >> One thing that concerns me: the proposed standard does not define a way >> for a BEEP application to signal the desired channel priority or >> relative buffer allocation to its peer. I'm not sure such facilities >> are very useful without such a mechanism. > > This is a "topside" (or API) specification and is not addressed by BEEP, > just as HTTP doesn't address such things as CGI. Perhaps all the > implementations will converge on some API or at least concepts, but I > think its a little too early quite yet, and even so, it wouldn't be > generally applicable for all BEEP-based applications. My concern is with the subclass of BEEP applications for which some kind of queue management facility *is* required. Without a standard mechanism for signaling queueing parameters to a BEEP peer, all such applications will inter-operate only with peers built around the same queue management facility. Seems like an opportunity for vendors to "embrace and extend" the BEEP protocol at the expense of the general Internet welfare. At least, that's the way it seems to me right now. I hope I'm wrong about that. If I'm right, then I humbly suggest that an appropriate amendment should be considered before the protocol advances to Draft Standard. >> Another thing that has me worried: I'd like to understand how giving >> smaller windows to slower readers prevents a given channel from >> monopolizing the underlying TCP window. Could someone point me to an >> explanation of the theory behind this approach? > > Thats hard to do in a short email, and I'll probably butcher it, but I > think the idea is that a slow reader is going to leave data in the > incoming TCP stream buffer longer (filling the TCP window) and thus > doesn't allow other fasters readers (who would empty incoming TCP stream > buffers quicker) to use the connection while the slow reader is > consuming > the data. This doesn't make as much sense to me as I would like. I think that RFC 3081 encourages implementations to read segments out of the TCP stream as soon as they arrive, pushing the frames they contain into per-channel hold-off queues. That's how I'm writing my implementation. Here's where my concern lies: if a channel at your peer is quickly sending really small messages and slowly receiving really large replies, then my peer giving that channel a smaller window might seem like "a good idea" intuitively, but I don't understand how it actually helps prevent that channel from "monopolizing the underlying TCP window" in any useful way. Is this believed to be an application-specific issue? If so, then I suppose I need to adjust my thinking about how cleanly the BEEP protocol separates the application layer from the transport layer. Is there even an issue with regard to channels "monopolizing the underlying TCP window" at all? I find this phrase in RFC 3081 fairly confusing, actually. > I think also that windowing manipulation allows for a local peer to > influence the ability of a remote peer to send data to "higher priority" > local profiles/channels (even if the local profile/channel is not a > "slow" > reader). > > This stuff is easy to make misstatements about, so I'll stop here ;-) Anybody else want to help straighten me out? -- j h woodyatt _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Mar 11 22:36:21 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 WAA05445 for ; Mon, 11 Mar 2002 22:36:20 -0500 (EST) 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 g2C3R2i04219; Mon, 11 Mar 2002 19:27:02 -0800 (PST) Received: from xomi.pair.com (xomi.pair.com [209.68.2.14]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g2C3Qvi04207 for ; Mon, 11 Mar 2002 19:26:57 -0800 (PST) Received: (qmail 85830 invoked by uid 3039); 12 Mar 2002 03:35:59 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 12 Mar 2002 03:35:59 -0000 From: Gabe Wachob X-Sender: To: james woodyatt cc: BEEP WG Subject: Re: [BEEPwg] rfc 3081, queueing, implementations In-Reply-To: Message-ID: 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: Mon, 11 Mar 2002 19:35:58 -0800 (PST) On Mon, 11 Mar 2002, james woodyatt wrote: > My concern is with the subclass of BEEP applications for which some kind > of queue management facility *is* required. Without a standard > mechanism for signaling queueing parameters to a BEEP peer, all such > applications will inter-operate only with peers built around the same > queue management facility. Seems like an opportunity for vendors to > "embrace and extend" the BEEP protocol at the expense of the general > Internet welfare. I hear this, but you could just define your profile with this behavior and then require that multiple channels be controlled by the same object which can orchestrate the 'window sizes' among the channels it controls (which all the channels for a given underlying BEEP connection). > At least, that's the way it seems to me right now. I hope I'm wrong > about that. If I'm right, then I humbly suggest that an appropriate > amendment should be considered before the protocol advances to Draft > Standard. Well, BEEP is cooked and delivered RFC 3080/3081 means its not going to change for a while. > > Thats hard to do in a short email, and I'll probably butcher it, but I > > think the idea is that a slow reader is going to leave data in the > > incoming TCP stream buffer longer (filling the TCP window) and thus > > doesn't allow other fasters readers (who would empty incoming TCP stream > > buffers quicker) to use the connection while the slow reader is > > consuming > > the data. > > This doesn't make as much sense to me as I would like. I think that RFC > 3081 encourages implementations to read segments out of the TCP stream > as soon as they arrive, pushing the frames they contain into per-channel > hold-off queues. That's how I'm writing my implementation. Yes, I'm putting into hold-off queues, but those queus could fill up quite quickly. Essentially our implementations have very large buffers, and as such the windowing stuff seems less important. I think the key is this (RFC 3081, sec 3.1.4): "each time a frame is received, a SEQ frame should be sent whenever the window size that will be sent is at least one half of the buffer space available to this channel; and" The idea is that if a receiving application is about to fill its *application-layer*/channel buffer, then this will back up into TCP-layer buffers and the problems I mentioned will ensue. You should probably check out RFC1122 which I should check out again as well. > Here's where my concern lies: if a channel at your peer is quickly > sending really small messages and slowly receiving really large replies, > then my peer giving that channel a smaller window might seem like "a > good idea" intuitively, but I don't understand how it actually helps > prevent that channel from "monopolizing the underlying TCP window" in > any useful way. Because the data is not being sent to the receiving side at all until the channel profile object has a fighting chance to process it. In the busy-reader state, the BEEP connection may in fact be quiescent even if there is only one channel on the reading side. If another channel started up then, and its window stayed essentially open all the time, it would get full use of the BEEP channel instead of waiting for the slow-reading channel to read data out of the TCP buffer. (and when the slow reader did get open space in its window, it would presumably only get the data it could *immediately* process or buffer at an *application* layer). Does that make sense? Again, its hard to have this discussion non-graphically ;-) > Is this believed to be an application-specific issue? If so, then I > suppose I need to adjust my thinking about how cleanly the BEEP protocol > separates the application layer from the transport layer. I'm not sure what you mean by application-specific here, so I'm not sure I could give you a good response. > Is there even an issue with regard to channels "monopolizing the > underlying TCP window" at all? I find this phrase in RFC 3081 fairly > confusing, actually. I feel the need for some visio diagrams. I'll try to throw together some visio diagrams tonight and post a URL to the list to describe what I believe to be the situation trying to be avoided and the way in which it is avoided with the flow control stuff in BEEP. -Gabe -- Gabe Wachob gwachob@wachob.com Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Mar 11 23:49:24 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 XAA06920 for ; Mon, 11 Mar 2002 23:49:23 -0500 (EST) 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 g2C4e4i04617; Mon, 11 Mar 2002 20:40:04 -0800 (PST) Received: from kalia.dbc.mtview.ca.us (dhcpd253 [64.168.10.253] (may be forged)) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2C4dji04599 for ; Mon, 11 Mar 2002 20:39:45 -0800 (PST) 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 g2C4lCg17785; Mon, 11 Mar 2002 20:47:12 -0800 (PST) From: Marshall Rose To: beepwg@lists.beepcore.org Cc: jhw@wetware.com, beepwg@lists.beepcore.org Subject: Re: [BEEPwg] rfc 3081, queueing, implementations Message-Id: <20020311204712.74f71072.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: Mon, 11 Mar 2002 20:47:12 -0800 Content-Transfer-Encoding: 7bit hi. i think that the basic problem is that you are reading too many things into the tcp mapping specification. the notion of priorities, if you choose to implement it, is a local mechanism, not an end-to-end mechanism. hence, there is no need for any kind of negotiation mechanism. in the beepcore-tcl implementation, for example, the application can tell the beep layer the "relative weight" of the incoming bandwidth that should be reserved for each channel. the implementation itself uses this in conjunction with a round-robin algorithm in order to determine what goes next and how much (with channel zero always getting taken care of first). one could generalize this approach by adding a priority in addition to the relative weight. if your familiar with the way the SRV algorithm works, you'd understand the generalization. this is probably overkill, but it may get implemented anyway. other implementations are free to provide whatever local mechanism that's convenient, useful, etc. the only requiremen that the tcp mapping specification makes is that you have to be able to convey to the other side the window size. how you choose the window size is up to the implementation and the application making use of it. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Mar 12 00:54:25 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 AAA07718 for ; Tue, 12 Mar 2002 00:54:24 -0500 (EST) 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 g2C5j3i04979; Mon, 11 Mar 2002 21:45:03 -0800 (PST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2C5iEi04963 for ; Mon, 11 Mar 2002 21:44:14 -0800 (PST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g2C5r8Y10148; Tue, 12 Mar 2002 00:53:09 -0500 Message-Id: <200203120553.g2C5r8Y10148@minotaur.nge.isi.edu> To: james woodyatt cc: Gabe Wachob , BEEP WG Reply-To: mankin@isi.edu Subject: Re: [BEEPwg] rfc 3081, queueing, implementations (TSV's view) In-reply-to: Your message of Mon, 11 Mar 2002 19:10:32 -0800. Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII From: Allison Mankin 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: Tue, 12 Mar 2002 00:53:08 -0500 Hi, A missing point in the discussion has been that the receiver doles out the window to the sender for each channel, using SEQ Frames for each of the sender's channels. Consider a path from Sender (S) to Receiver (R) of 100 Mbps. Consider a simple example of three unidirectional (that is, S is only a data sender and R only a data receiver) channels, C1, C2 and C3. Assume that S always has data ready to send on each of the channels (for the many applications of BEEP that are not like this, TCP/BEEP flow control issues don't cause any concern). If R wants C1 to have 20 Mbps, it opens the window for S in C1 using SEQ Frames and advancing the ackno/window the 20 Mbits each second. S must stop sending data in channel C1 when C1's window is full and it can't send into C1 again till the next SEQ Frame for C1 is received from R. In concept, this means C1 will average 20 Mbits per second over time. (Meanwhile R offers C2 and C3 windows using SEQ Frames for them). This is a most simplified example. Windows don't map neatly to rates (equations such as those described in draft-ietf-tsvwg-tfrc-03.txt are needed). The example also oversimplifies by assuming the available capacity from S to R stays at 100 Mbps in a real network path, whereas available capacity for the underlying TCP connection is dynamic, as TCP adapts to congestion and to other flows sharing resources with it. The windows for C1, C2 and C3 really need to add up to the TCP Congestion Window (CWND), the lowered window size that the TCP level sender obeys, based on the TCP connection's estimates about other flows and congestion. When CWND is lower than the sum of R's BEEP-level windows for C1, C2 and C3, the channels may get unfair amounts of capacity. The TCP connection might have a real 10 Mbps due to congestion. R offers C1 20 Mbps, and this leaves C2 and C3 unserved for some time period. If S round-robins through its channels, they can avoid starvation, but performance could be unfair or unpredictable. If S and R are too clever with window tuning and priorities, the results could be dismal. Another way to state Marshall's mail on this thread a little earlier is to recommend simplicity in the use of the BEEP TCP mapping's flow control features. > In particular, implementations should > not allow a given channel to monopolize the underlying transport > window (e.g., slow readers should get small windows). I think this should say "slow readers should offer small windows". IESG review missed this point before :) > > In addition, where possible, implementations should support transport > layer APIs that convey congestion information. These APIs allow an > implementation to determine its share of the available bandwidth, and > also be notified of changes in the estimated path bandwidth. Note > that when a BEEP session has multiple channels that are > simultaneously exchanging large messages, implementations without > access to this information may have uncertain fairness and progress > properties during times of network congestion. The above paragraph is (I hope) explained more by this mail. An API such as it recommends is found in RFC 3124 (The Congestion Manager), which came out after RFC 3081 was ready to be approved. Using the CM API, S could query its TCP socket to make decisions on when to stop sending into each channel based on CWND directly (perhaps weighted proportionally to the channels' windows given it by R). I'd be interested to know if this approach could be taken by the implementations that are being developed. Allison _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Mar 12 01:11: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 BAA07985 for ; Tue, 12 Mar 2002 01:11:19 -0500 (EST) 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 g2C623i05108; Mon, 11 Mar 2002 22:02:03 -0800 (PST) Received: from kalia.dbc.mtview.ca.us (dhcpd253 [64.168.10.253] (may be forged)) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2C61Vi05096 for ; Mon, 11 Mar 2002 22:01:31 -0800 (PST) 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 g2C6A6g17936; Mon, 11 Mar 2002 22:10:06 -0800 (PST) From: Marshall Rose To: mankin@isi.edu Cc: gwachob@wachob.com, beepwg@lists.beepcore.org Subject: Re: [BEEPwg] rfc 3081, queueing, implementations (TSV's view) Message-Id: <20020311221006.71f852a9.mrose@dbc.mtview.ca.us> In-Reply-To: <200203120553.g2C5r8Y10148@minotaur.nge.isi.edu> References: <200203120553.g2C5r8Y10148@minotaur.nge.isi.edu> 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: Mon, 11 Mar 2002 22:10:06 -0800 Content-Transfer-Encoding: 7bit > > In particular, implementations should > > not allow a given channel to monopolize the underlying transport > > window (e.g., slow readers should get small windows). > > I think this should say "slow readers should offer small windows". > IESG review missed this point before :) right you are. > > In addition, where possible, implementations should support transport > > layer APIs that convey congestion information. These APIs allow an > > implementation to determine its share of the available bandwidth, and > > also be notified of changes in the estimated path bandwidth. Note > > that when a BEEP session has multiple channels that are > > simultaneously exchanging large messages, implementations without > > access to this information may have uncertain fairness and progress > > properties during times of network congestion. > > The above paragraph is (I hope) explained more by this mail. An API such > as it recommends is found in RFC 3124 (The Congestion Manager), which came > out after RFC 3081 was ready to be approved. Using the CM API, S could > query its TCP socket to make decisions on when to stop sending into > each channel based on CWND directly (perhaps weighted proportionally to the > channels' windows given it by R). > > I'd be interested to know if this approach could be taken by the > implementations that are being developed. is there a url with implementation pointers for the CM? if so... /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Mar 12 01:18:16 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 BAA08072 for ; Tue, 12 Mar 2002 01:18:15 -0500 (EST) 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 g2C691i05160; Mon, 11 Mar 2002 22:09:01 -0800 (PST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2C68Wi05148 for ; Mon, 11 Mar 2002 22:08:32 -0800 (PST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g2C6HWY10181; Tue, 12 Mar 2002 01:17:32 -0500 Message-Id: <200203120617.g2C6HWY10181@minotaur.nge.isi.edu> To: Marshall Rose cc: mankin@isi.edu, gwachob@wachob.com, beepwg@lists.beepcore.org Reply-To: mankin@isi.edu Subject: Re: [BEEPwg] rfc 3081, queueing, implementations (TSV's view) In-reply-to: Your message of Mon, 11 Mar 2002 22:10:06 -0800. <20020311221006.71f852a9.mrose@dbc.mtview.ca.us> From: Allison Mankin 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: Tue, 12 Mar 2002 01:17:32 -0500 > > I'd be interested to know if this approach could be taken by the > > implementations that are being developed. > > is there a url with implementation pointers for the CM? if so... http://nms.lcs.mit.edu/software/CM/ (implementation) http://nms.lcs.mit.edu/projects/cm/ (papers etc). _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Mar 12 02:01: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 CAA10249 for ; Tue, 12 Mar 2002 02:01:19 -0500 (EST) 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 g2C6q3i05420; Mon, 11 Mar 2002 22:52:03 -0800 (PST) Received: from xomi.pair.com (xomi.pair.com [209.68.2.14]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g2C6pEi05402 for ; Mon, 11 Mar 2002 22:51:15 -0800 (PST) Received: (qmail 25578 invoked by uid 3039); 12 Mar 2002 07:00:16 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 12 Mar 2002 07:00:16 -0000 From: Gabe Wachob X-Sender: To: Allison Mankin cc: james woodyatt , BEEP WG Subject: Re: [BEEPwg] rfc 3081, queueing, implementations (TSV's view) In-Reply-To: <200203120553.g2C5r8Y10148@minotaur.nge.isi.edu> Message-ID: 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: Mon, 11 Mar 2002 23:00:16 -0800 (PST) Allison- Very interesting stuff, of course. I put together some documentation exploring (for personal understanding as well as to show to others) using "immediately emptied" buffers where the data is consumed immediately upon receipt into a channel. Thus, SEQ messages always end up sending SEQ frames with window sizes equal to the entire buffer size for the channel. http://beepnik.wiredobjects.com/bandwidth/ The gist of the demo (pictures) is that effectively the relatively size of the buffer a channel has determines the relative bandwidth that a channel gets. Thats well understood (but not well documented with easy-to-understand examples w/barney-like even-the-kids-get-it pictures). So thats my baseline - I'm making some assumptions (esp. about constant bandwidth) that you point out are not realistic, but I'm wondering how much that modfies my results.. I'm looking for feedback on the document linked above. More comments inline: On Tue, 12 Mar 2002, Allison Mankin wrote: > Consider a path from Sender (S) to Receiver (R) of 100 Mbps. Consider > a simple example of three unidirectional (that is, S is only a data > sender and R only a data receiver) channels, C1, C2 and C3. Assume > that S always has data ready to send on each of the channels (for the > many applications of BEEP that are not like this, TCP/BEEP flow control > issues don't cause any concern). I believe my document makes the same assumptions (at least for most of the time steps in my demo). > If R wants C1 to have 20 Mbps, it opens the window for S in C1 using > SEQ Frames and advancing the ackno/window the 20 Mbits each second. Well, it would only "advance" the window when it received data, so it would only advance the window at most at the rate it received data, no? In other words, wouldn't advancing the window 20mbit/sec would only happen if data was coming in at 20mbit sec? > The windows > for C1, C2 and C3 really need to add up to the TCP Congestion Window (CWND), > the lowered window size that the TCP level sender obeys, based on the TCP > connection's estimates about other flows and congestion. Right, because then you are going to run into TCP congestion, in which case managing the channel windows gets less useful because the relationship between elapsed time and size of the window is thrown off (not constant) and buffer size doesn't map directly to bandwidth... Or am I completely off? > When CWND is lower than the sum of R's BEEP-level windows for C1, C2 > and C3, the channels may get unfair amounts of capacity. The TCP > connection might have a real 10 Mbps due to congestion. R offers C1 20 Mbps, > and this leaves C2 and C3 unserved for some time period. But R isn't offering bandwidth, its offering buffer space (window), isn't it? This is where I start to get lost. I think I understand why you want to avoid triggering TCP congestion protocols, but I'm not following the part about unfairness between channels. -Gabe -- Gabe Wachob gwachob@wachob.com Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Mar 12 06:09: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 GAA19140 for ; Tue, 12 Mar 2002 06:09:13 -0500 (EST) 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 g2CAvEi06697; Tue, 12 Mar 2002 02:57:14 -0800 (PST) Received: from loreto.kahleassociates.com (kahle-gw.accessone.net [198.182.115.194]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g2CAuBi06685 for ; Tue, 12 Mar 2002 02:56:11 -0800 (PST) Received: (qmail 26232 invoked from network); 12 Mar 2002 11:08:42 -0000 Received: from unknown (HELO losfrailes) (192.168.1.101) by 0 with SMTP; 12 Mar 2002 11:08:42 -0000 Subject: Re: [BEEPwg] rfc 3081, queueing, implementations (TSV's view) From: "Randolph S. Kahle" To: mankin@isi.edu Cc: james woodyatt , Gabe Wachob , BEEP WG , "John D. Mitchell" In-Reply-To: <200203120553.g2C5r8Y10148@minotaur.nge.isi.edu> References: <200203120553.g2C5r8Y10148@minotaur.nge.isi.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Message-Id: <1015931131.1955.45.camel@losfrailes> Mime-Version: 1.0 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: 12 Mar 2002 04:05:31 -0700 Content-Transfer-Encoding: 7bit I think I am getting confused about the purpose of the BEEP protocol. Maybe someone can re-ground me. It seems that the discussion in this thread is focused on adding complexity to a protocol that creates channels of communication on top of a single TCP/IP connection. What is the point of this complexity? Why not keep BEEP as simple and clean as possible, open up multiple TCP/IP connections and allow the work that is being done on IP routing and the TCP/IP protocol handle these complexities? What application level problems does this complexity address or solve? -- Randy On Mon, 2002-03-11 at 22:53, Allison Mankin wrote: > Hi, > > A missing point in the discussion has been that the receiver doles out > the window to the sender for each channel, using SEQ Frames for > each of the sender's channels. > > Consider a path from Sender (S) to Receiver (R) of 100 Mbps. Consider > a simple example of three unidirectional (that is, S is only a data > sender and R only a data receiver) channels, C1, C2 and C3. Assume > that S always has data ready to send on each of the channels (for the > many applications of BEEP that are not like this, TCP/BEEP flow control > issues don't cause any concern). > > If R wants C1 to have 20 Mbps, it opens the window for S in C1 using > SEQ Frames and advancing the ackno/window the 20 Mbits each second. > S must stop sending data in channel C1 when C1's window is full and it > can't send into C1 again till the next SEQ Frame for C1 is received from R. > In concept, this means C1 will average 20 Mbits per second over time. > (Meanwhile R offers C2 and C3 windows using SEQ Frames for them). > > This is a most simplified example. Windows don't map neatly to rates > (equations such as those described in draft-ietf-tsvwg-tfrc-03.txt are > needed). The example also oversimplifies by assuming the available > capacity from S to R stays at 100 Mbps in a real network path, whereas > available capacity for the underlying TCP connection is dynamic, as TCP > adapts to congestion and to other flows sharing resources with it. The windows > for C1, C2 and C3 really need to add up to the TCP Congestion Window (CWND), > the lowered window size that the TCP level sender obeys, based on the TCP > connection's estimates about other flows and congestion. > > When CWND is lower than the sum of R's BEEP-level windows for C1, C2 > and C3, the channels may get unfair amounts of capacity. The TCP > connection might have a real 10 Mbps due to congestion. R offers C1 20 Mbps, > and this leaves C2 and C3 unserved for some time period. If S round-robins > through its channels, they can avoid starvation, but performance could > be unfair or unpredictable. If S and R are too clever with window > tuning and priorities, the results could be dismal. Another way to > state Marshall's mail on this thread a little earlier is to recommend > simplicity in the use of the BEEP TCP mapping's flow control features. > > > In particular, implementations should > > not allow a given channel to monopolize the underlying transport > > window (e.g., slow readers should get small windows). > > I think this should say "slow readers should offer small windows". > IESG review missed this point before :) > > > > > > In addition, where possible, implementations should support transport > > layer APIs that convey congestion information. These APIs allow an > > implementation to determine its share of the available bandwidth, and > > also be notified of changes in the estimated path bandwidth. Note > > that when a BEEP session has multiple channels that are > > simultaneously exchanging large messages, implementations without > > access to this information may have uncertain fairness and progress > > properties during times of network congestion. > > The above paragraph is (I hope) explained more by this mail. An API such > as it recommends is found in RFC 3124 (The Congestion Manager), which came > out after RFC 3081 was ready to be approved. Using the CM API, S could > query its TCP socket to make decisions on when to stop sending into > each channel based on CWND directly (perhaps weighted proportionally to the > channels' windows given it by R). > > I'd be interested to know if this approach could be taken by the > implementations that are being developed. > > Allison > _______________________________________________ > 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 Tue Mar 12 08:58:33 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 IAA21885 for ; Tue, 12 Mar 2002 08:58:32 -0500 (EST) 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 g2CDn3i08262; Tue, 12 Mar 2002 05:49:03 -0800 (PST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2CDmii08250 for ; Tue, 12 Mar 2002 05:48:44 -0800 (PST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g2CDvfL10653; Tue, 12 Mar 2002 08:57:43 -0500 Message-Id: <200203121357.g2CDvfL10653@minotaur.nge.isi.edu> To: "Randolph S. Kahle" cc: mankin@isi.edu, james woodyatt , Gabe Wachob , BEEP WG , "John D. Mitchell" Reply-To: mankin@isi.edu Subject: Re: [BEEPwg] rfc 3081, queueing, implementations (TSV's view) In-reply-to: Your message of 12 Mar 2002 04:05:31 -0700. <1015931131.1955.45.camel@losfrailes> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII From: Allison Mankin 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: Tue, 12 Mar 2002 08:57:41 -0500 Randy, The BEEP TCP mapping already has the complexity - it comes with the territory - my mail and Gabe's did not make it up. My point was to explain the situation when flow control has to come into play and advise that only dead simple use of the flow control feature be made. And as I said, I expect a lot of BEEP usages aren't network-limited (don't have data ready to send all the time), in which case they don't have to think about flow control at all. > > I think I am getting confused about the purpose of the BEEP protocol. > > Maybe someone can re-ground me. > > It seems that the discussion in this thread is focused on adding > complexity to a protocol that creates channels of communication on top > of a single TCP/IP connection. > > What is the point of this complexity? > > Why not keep BEEP as simple and clean as possible, open up multiple > TCP/IP connections and allow the work that is being done on IP routing > and the TCP/IP protocol handle these complexities? > There was work on this, but it would have to avoid the performance negatives of those TCPs competing with each other and overcompeting along the path, and many other problems that HTTP found with multiple parallel TCPs. TLS use would be far less efficient as well. > What application level problems does this complexity address or solve? > It addresses the fact that BEEP is trying to make a threaded service on top of an unthreaded service (TCP) to get a lot of other application architecture benefits. Sometimes there's a cost. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Mar 12 11:50:39 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 LAA27001 for ; Tue, 12 Mar 2002 11:50:39 -0500 (EST) 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 g2CGfHi09170; Tue, 12 Mar 2002 08:41:17 -0800 (PST) Received: from kalia.dbc.mtview.ca.us (dhcpd253 [64.168.10.253] (may be forged)) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2CGeri09158 for ; Tue, 12 Mar 2002 08:40:53 -0800 (PST) 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 g2CGmUg18882; Tue, 12 Mar 2002 08:48:30 -0800 (PST) From: Marshall Rose To: mankin@isi.edu Cc: jhw@wetware.com, gwachob@wachob.com, beepwg@lists.beepcore.org, john@non.net Subject: Re: [BEEPwg] rfc 3081, queueing, implementations (TSV's view) Message-Id: <20020312084830.4ab2a0e3.mrose@dbc.mtview.ca.us> In-Reply-To: <200203121357.g2CDvfL10653@minotaur.nge.isi.edu> References: <1015931131.1955.45.camel@losfrailes> <200203121357.g2CDvfL10653@minotaur.nge.isi.edu> 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: Tue, 12 Mar 2002 08:48:30 -0800 Content-Transfer-Encoding: 7bit > > What application level problems does this complexity address or solve? > > > > It addresses the fact that BEEP is trying to make a threaded > service on top of an unthreaded service (TCP) to get a lot of other > application architecture benefits. Sometimes there's a cost. i agree! of course, what often goes unsaid (when this thread shows up twice a year), is that if you don't want the benefit, there really isn't a cost. if you want to implement a BEEP layer that doesn't do multiple channels, then you can hardcode all of this stuff quite simply... /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Mar 12 12:51:25 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 MAA28940 for ; Tue, 12 Mar 2002 12:51:25 -0500 (EST) 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 g2CHg5i09525; Tue, 12 Mar 2002 09:42:05 -0800 (PST) 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 g2CHfai09508 for ; Tue, 12 Mar 2002 09:41:36 -0800 (PST) Received: from san.rr.com (66-75-151-160.san.rr.com [66.75.151.160]) by smtp2.san.rr.com (8.11.4/8.11.4) with ESMTP id g2CHogM14584 for ; Tue, 12 Mar 2002 09:50:42 -0800 (PST) Message-ID: <3C8E3FF4.D04E25BF@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: beepwg@lists.beepcore.org Subject: Re: [BEEPwg] rfc 3081, queueing, implementations References: <20020311204712.74f71072.mrose@dbc.mtview.ca.us> 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: Tue, 12 Mar 2002 09:50:44 -0800 Content-Transfer-Encoding: 7bit And, for what it's worth, the beepcore-c implementation sends a SEQ and a frame each time the "core" library gets invoked. (Of course, it doesn't send SEQs if there's no windows needing opening, and it doesn't send frames if there's no frames with window to send them in.) The SEQ it sends is the one that would open the window the most. I.e., it sends the SEQ for the channel with the most available buffer space. The frame it sends is the frame on the highest-priority channel that can be sent right now, accounting for tuning resets, ordering of outgoing messages, and available window size. I'm not sure if the core-level priorities got reflected in the higher-level APIs (it's just a number you can change), but if not, the channels opened later get priority over those opened earlier, IIRC. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. To the user, everything works just as expected, assuming the user's expectations are correct. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Mar 12 15:18: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 PAA05248 for ; Tue, 12 Mar 2002 15:18:19 -0500 (EST) 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 g2CK93i10334; Tue, 12 Mar 2002 12:09:03 -0800 (PST) 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 g2CK89i10322 for ; Tue, 12 Mar 2002 12:08:09 -0800 (PST) Received: from kallisti.apple.com(wetware.wetware.com[199.108.16.1]) (1887 bytes) by wetware.wetware.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Tue, 12 Mar 2002 12:16:59 -0800 (PST) (Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Jan-4) Subject: Re: [BEEPwg] rfc 3081, queueing, implementations (TSV's view) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: mankin@isi.edu, gwachob@wachob.com, beepwg@lists.beepcore.org, john@non.net To: Marshall Rose From: james woodyatt In-Reply-To: <20020312084830.4ab2a0e3.mrose@dbc.mtview.ca.us> Message-Id: <18A1916E-35F6-11D6-8A23-000502DB38F5@wetware.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) 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: Tue, 12 Mar 2002 12:16:54 -0800 Content-Transfer-Encoding: 7bit On Tuesday, March 12, 2002, at 08:48 AM, Marshall Rose wrote: > [...] >>> What application level problems does this complexity address or solve? >>> >> >> It addresses the fact that BEEP is trying to make a threaded >> service on top of an unthreaded service (TCP) to get a lot of other >> application architecture benefits. Sometimes there's a cost. > > i agree! > > of course, what often goes unsaid (when this thread shows up twice a > year), is that if you don't want the benefit, there really isn't a > cost. if you want to implement a BEEP layer that doesn't do multiple > channels, then you can hardcode all of this stuff quite simply... Agreed. And I'm not complaining about the cost. Quite the opposite. I, for one, am keenly interested in this feature of the BEEP protocol, which is why I am being an annoying git and trying to make sure I adhere strictly to the letter and spirit of the protocol specification. I'll have a reaction to Allison Mankin's post later this evening when I have some free time again to write it. -- j h woodyatt _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 13 00:05:37 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 AAA19817 for ; Wed, 13 Mar 2002 00:05:36 -0500 (EST) 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 g2D4u5i13258; Tue, 12 Mar 2002 20:56:05 -0800 (PST) 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 g2D4tai13246 for ; Tue, 12 Mar 2002 20:55:36 -0800 (PST) Received: from kallisti.apple.com(wetware.wetware.com[199.108.16.1]) (4720 bytes) by wetware.wetware.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Tue, 12 Mar 2002 21:04:34 -0800 (PST) (Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Jan-4) Subject: Re: [BEEPwg] rfc 3081, queueing, implementations (TSV's view) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: Gabe Wachob , BEEP WG To: mankin@isi.edu From: james woodyatt In-Reply-To: <200203120553.g2C5r8Y10148@minotaur.nge.isi.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) 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: Tue, 12 Mar 2002 21:04:26 -0800 Content-Transfer-Encoding: 7bit On Monday, March 11, 2002, at 09:53 PM, Allison Mankin wrote: > > A missing point in the discussion has been that the receiver doles out > the window to the sender for each channel, using SEQ Frames for > each of the sender's channels. I had assumed we were all familiar with the specification. > Consider a path from Sender (S) to Receiver (R) of 100 Mbps. Consider > a simple example of three unidirectional (that is, S is only a data > sender and R only a data receiver) channels, C1, C2 and C3. Assume > that S always has data ready to send on each of the channels (for the > many applications of BEEP that are not like this, TCP/BEEP flow control > issues don't cause any concern). Your example is a generalization of the case that has me concerned. > If R wants C1 to have 20 Mbps, it opens the window for S in C1 using > SEQ Frames and advancing the ackno/window the 20 Mbits each second. > S must stop sending data in channel C1 when C1's window is full and it > can't send into C1 again till the next SEQ Frame for C1 is received > from R. > In concept, this means C1 will average 20 Mbits per second over time. > (Meanwhile R offers C2 and C3 windows using SEQ Frames for them). What if the sender (S) is where the application needs to make decisions about how much of the transport window each channel (C1, C2 and C3) should get relative to one another? How are those parameters communicated to the receiver (R) where they are to be used? What *are* the parameters? Obviously, the BEEP protocol (specifically the TCP mapping) leaves this to the application layer to decide. Hence, my concern-- stated in a previous message-- that without a standard facility to manage flow control, BEEP applications of this subclass will only be able to inter-operate effectively with peers that are constructed using implementations that sport compatible congestion management facilities. I gather from Marshall's post that this is not widely regarded as a problem. I can easily live with that. It helps to have a clarification of the intent of the working group. > This is a most simplified example. Windows don't map neatly to rates > (equations such as those described in draft-ietf-tsvwg-tfrc-03.txt are > needed). [...explanation of congestion management issues elided...] >> In particular, implementations should >> not allow a given channel to monopolize the underlying transport >> window (e.g., slow readers should get small windows). > > I think this should say "slow readers should offer small windows". > IESG review missed this point before :) That makes much more sense. I'd go a little further: In particular, implementations should permit applications to prevent a given channel from monopolizing the underlying transport window (e.g. slow readers should be able to offer small windows). I think this makes it clear that applications-- not the framework-- are responsible for balancing channel flows in the face of transport congestion. In fact, now that I think about it: every transport mapping will have some kind of "underlying transport window" for which congestion management may be a concern. (For example, I'll encounter the same basic issue should I go completely insane and try to implement a transport mapping for POSIX shared memory and semaphores.) Unfortunately [or not, depending on your viewpoint, I guess], there is no facility in the BEEP core itself to balance channel flows in the face of transport congestion, and the TCP mapping document leaves the matter entirely open to the implementation of the receiving peer. That doesn't seem to bother anyone else, so I guess I should shut up about it-- and be happy the specification is 1) a Proposed Standard, and 2) isn't going through any serious revision thrash at the moment. -- j h woodyatt "You're standing on sacred ground. Many strange and wonderful things have transpired right where you're standing." --unattributable _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 13 05:55:02 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 FAA02117 for ; Wed, 13 Mar 2002 05:55:01 -0500 (EST) 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 g2DAjOi15095; Wed, 13 Mar 2002 02:45:24 -0800 (PST) Received: from loreto.kahleassociates.com (kahle-gw.accessone.net [198.182.115.194]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g2DAhli15077 for ; Wed, 13 Mar 2002 02:43:47 -0800 (PST) Received: (qmail 4575 invoked from network); 13 Mar 2002 10:56:41 -0000 Received: from unknown (HELO losfrailes) (192.168.1.101) by 0 with SMTP; 13 Mar 2002 10:56:41 -0000 Subject: Re: [BEEPwg] rfc 3081, queueing, implementations (TSV's view) From: "Randolph S. Kahle" To: Marshall Rose Cc: mankin@isi.edu, jhw@wetware.com, gwachob@wachob.com, beepwg@lists.beepcore.org, john@non.net In-Reply-To: <20020312084830.4ab2a0e3.mrose@dbc.mtview.ca.us> References: <1015931131.1955.45.camel@losfrailes> <200203121357.g2CDvfL10653@minotaur.nge.isi.edu> <20020312084830.4ab2a0e3.mrose@dbc.mtview.ca.us> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Message-Id: <1016016806.750.29.camel@losfrailes> Mime-Version: 1.0 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: 13 Mar 2002 03:53:26 -0700 Content-Transfer-Encoding: 7bit > > It addresses the fact that BEEP is trying to make a threaded > > service on top of an unthreaded service (TCP) to get a lot of other > > application architecture benefits. Sometimes there's a cost. > > i agree! > > of course, what often goes unsaid (when this thread shows up twice a year), is that if you don't want the benefit, there really isn't a cost. if you want to implement a BEEP layer that doesn't do multiple channels, then you can hardcode all of this stuff quite simply... > Now I am even more confused than before. Are you saying that an implementation of the BEEP protocol can support only one channel and still be considered compliant? -- Randy _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 13 10:30:37 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 KAA08042 for ; Wed, 13 Mar 2002 10:30:37 -0500 (EST) 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 g2DFL7i17185; Wed, 13 Mar 2002 07:21:07 -0800 (PST) Received: from kalia.dbc.mtview.ca.us (dhcpd253 [64.168.10.253] (may be forged)) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2DFKni17173 for ; Wed, 13 Mar 2002 07:20:49 -0800 (PST) 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 g2DFTBh02178; Wed, 13 Mar 2002 07:29:11 -0800 (PST) From: Marshall Rose To: "Randolph S. Kahle" Cc: beepwg@lists.beepcore.org Subject: Re: [BEEPwg] rfc 3081, queueing, implementations (TSV's view) Message-Id: <20020313072910.7eaeed51.mrose@dbc.mtview.ca.us> In-Reply-To: <1016016806.750.29.camel@losfrailes> References: <1015931131.1955.45.camel@losfrailes> <200203121357.g2CDvfL10653@minotaur.nge.isi.edu> <20020312084830.4ab2a0e3.mrose@dbc.mtview.ca.us> <1016016806.750.29.camel@losfrailes> 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, 13 Mar 2002 07:29:10 -0800 Content-Transfer-Encoding: 7bit > Now I am even more confused than before. > > Are you saying that an implementation of the BEEP protocol can support > only one channel and still be considered compliant? a minimal, non-useful beep implementation does only channel 0. nowhere in the specs does it say that you have to let the other side start a channel. a special-purpose beep implementation (e.g., one built for doing only sacred or reliable syslog) does channel 0 and one channel for the "real work". because tuning channels are used serially, the implementation might also support tls and a couple of sasl profiles. as long as the implementations generate valid responses to the start requests, there's nothing out of compliance. the three beepcore implementations are intended for general-purpose use, so they don't follow this philosophy. as a result, they have a lot of mechanisms for supporting the details of multiple channels operating in parallel. a special-purpose implementation can hardcode the vast majority of this stuff. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 13 18:02: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 SAA23661 for ; Wed, 13 Mar 2002 18:02:19 -0500 (EST) 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 g2DMq9i19608; Wed, 13 Mar 2002 14:52:09 -0800 (PST) Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2DMpui19596 for ; Wed, 13 Mar 2002 14:51:57 -0800 (PST) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.1) for ; Wed, 13 Mar 2002 17:00:58 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: X-Mailer: Eudora [Macintosh version 5.1fc3] To: BEEP From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [BEEPwg] Working group shutdown 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, 13 Mar 2002 17:00:50 -0600 There's really been no progress on work items in this working group anymore, yet here it sits on my plate. :-) Is there any reason not to shut down the working group now? The mailing list will, of course, still be active, but I think we can get this out of the IETF's lap. Any objections? Anything going on with SCTP that we need to deal with as a working group? pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 13 18:40:32 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 SAA24656 for ; Wed, 13 Mar 2002 18:40:31 -0500 (EST) 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 g2DNV3i19885; Wed, 13 Mar 2002 15:31:03 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2DNURi19873 for ; Wed, 13 Mar 2002 15:30:27 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KFBA854COG0045PS@mauve.mrochek.com> for beepwg@lists.beepcore.org; Wed, 13 Mar 2002 15:39:33 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: [BEEPwg] Working group shutdown In-reply-to: "Your message dated Wed, 13 Mar 2002 17:00:50 -0600" To: Pete Resnick Cc: BEEP Message-id: <01KFBFEXTO1U0045PS@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed 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, 13 Mar 2002 15:37:53 -0800 (PST) Content-Transfer-Encoding: 7BIT > There's really been no progress on work items in this working group > anymore, yet here it sits on my plate. :-) Is there any reason not to > shut down the working group now? The mailing list will, of course, > still be active, but I think we can get this out of the IETF's lap. > Any objections? Anything going on with SCTP that we need to deal with > as a working group? Pete, I agree with this assessment and intended to send you a note about it. Unless there's some chance of the BEEP over SCTP document being resurrected almost immediately I'd much prefer to shut down the WG and do any SCTP binding work as an individual submission. Ned _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 13 19:18:28 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 TAA25560 for ; Wed, 13 Mar 2002 19:18:27 -0500 (EST) 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 g2E093i20130; Wed, 13 Mar 2002 16:09:03 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2DNxki20043 for ; Wed, 13 Mar 2002 15:59:46 -0800 (PST) Received: from livingroom.acm.org (pcp01480838pcs.ncstl01.de.comcast.net [68.82.70.12]) by mtaout03.icomcast.net (iPlanet Messaging Server 5.1 (built Feb 6 2002)) with ESMTP id <0GSX003HCSENCG@mtaout03.icomcast.net> for beepwg@lists.beepcore.org; Wed, 13 Mar 2002 19:08:47 -0500 (EST) From: Phillip Conrad Subject: Re: [BEEPwg] Working group shutdown In-reply-to: X-Sender: phillipconrad@mail.comcast.net To: Pete Resnick , BEEP Cc: conrad@acm.org Message-id: <5.1.0.14.2.20020313180507.045d6ec0@joda.cis.temple.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii; format=flowed 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, 13 Mar 2002 19:04:15 -0500 Content-Transfer-Encoding: 7BIT At 05:00 PM 3/13/2002 -0600, Pete Resnick wrote: >There's really been no progress on work items in this working group >anymore, yet here it sits on my plate. :-) Is there any reason not to shut >down the working group now? The mailing list will, of course, still be >active, but I think we can get this out of the IETF's lap. Any objections? >Anything going on with SCTP that we need to deal with as a working group? Pete, w.r.t to the BEEP WG shutdown, and items related to SCTP.... You and I had a "corridor conversation" about this at the London IETF... there's not much new to say here; my purpose in writing is just to make our conversation "public" in case anyone else wants to chime in before the final bell tolls for the BEEP WG... As I told you then, I'm still making forward progress (albeit at a low priority) on an implementation of the BEEP over SCTP mapping as per draft-mrose-beep-sctpmapping-01.txt, which expired on January 18 2002. I haven't had a chance to talk with Marshall yet (the sole co-author), but I believe the demise of per-stream flow control in SCTP will necessitate a revision of this draft. (Per stream flow control was removed in subsequent revisions of draft-ietf-tsvwg-addip-sctp-02.txt, which the current draft depends on). We'll need to add functionality to this mapping similar to that in the TCP mapping, which should be straightforward. On the other hand, this draft never "officially" became a working group item. If this is the only remaining open item, it may not be worth delaying the shutdown of the working group. The mapping can still be discussed on the mailing list, and if and when there is a final draft and interoperable implementations that there is a real need to standardize, I suppose it is "theoretically possible" to proceed from individual submission direct to RFC without going through an active working group (though I'm told this is a bit more difficult to accomplish). So, I won't raise an objection to WG shutdown unless Marshall or someone else feels its worth keeping the group open for this. Cheers, Phill Conrad ****************************** Phillip T. Conrad, Asst. Professor, CIS Dept, Temple University conrad@acm.org http://www.cis.temple.edu/~conrad http://netlab.cis.temple.edu -- >Pete Resnick >QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 >_______________________________________________ >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 Wed Mar 20 15:38:02 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 PAA14043 for ; Wed, 20 Mar 2002 15:38:01 -0500 (EST) 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 g2KKPBd24006; Wed, 20 Mar 2002 12:25:11 -0800 (PST) Received: from pwrm.com (h139-142-65-9.pml.com [139.142.65.9]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2KKOad23991 for ; Wed, 20 Mar 2002 12:24:36 -0800 (PST) Received: from HERMES.pml.com ([10.1.32.4]) by pwrm.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Mar 2002 12:35:18 -0800 Received: by HERMES.pml.com with Internet Mail Service (5.5.2655.55) id ; Wed, 20 Mar 2002 12:33:52 -0800 Message-ID: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D82@HERMES.pml.com> From: Doug Ransom To: "'beepwg@lists.beepcore.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D04E.8C51C480" X-OriginalArrivalTime: 20 Mar 2002 20:35:18.0462 (UTC) FILETIME=[BFA8C5E0:01C1D04E] Subject: [BEEPwg] Firewall Traversal 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, 20 Mar 2002 12:33:52 -0800 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D04E.8C51C480 Content-Type: text/plain; charset="iso-8859-1" I am trying to understand how peers might traverse a firewall. In the instant message scenario, would a peer need a continous tcp or beep connection to an outside proxy in order to receive messages from another peer? Doug Ransom Internet Technologies Domain Lead Power Measurement http://www.pwrm.com mailto:Doug.Ransom@pwrm.com MSN Messenger Doug.Ransom@pwrm.com ------_=_NextPart_001_01C1D04E.8C51C480 Content-Type: text/html; charset="iso-8859-1"
I am trying to understand how peers might traverse a firewall.  In the instant message scenario, would a peer need a continous tcp or beep connection to an outside proxy in order to receive messages from another peer?
 
 

Doug Ransom
Internet Technologies Domain Lead
Power Measurement http://www.pwrm.com
mailto:Doug.Ransom@pwrm.com

MSN Messenger Doug.Ransom@pwrm.com

 
------_=_NextPart_001_01C1D04E.8C51C480-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 20 15:39:12 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 PAA14093 for ; Wed, 20 Mar 2002 15:39:11 -0500 (EST) 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 g2KKT2d24054; Wed, 20 Mar 2002 12:29:02 -0800 (PST) Received: from pwrm.com (h139-142-65-9.pml.com [139.142.65.9]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2KKSJd24040 for ; Wed, 20 Mar 2002 12:28:19 -0800 (PST) Received: from HERMES.pml.com ([10.1.32.4]) by pwrm.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Mar 2002 12:39:01 -0800 Received: by HERMES.pml.com with Internet Mail Service (5.5.2655.55) id ; Wed, 20 Mar 2002 12:37:35 -0800 Message-ID: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D83@HERMES.pml.com> From: Doug Ransom To: "'beepwg@lists.beepcore.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D04F.11202E40" X-OriginalArrivalTime: 20 Mar 2002 20:39:01.0463 (UTC) FILETIME=[44940670:01C1D04F] Subject: [BEEPwg] Streaming data 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, 20 Mar 2002 12:37:35 -0800 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D04F.11202E40 Content-Type: text/plain; charset="iso-8859-1" When sending some data in beep, does the size of the data need to be known ahead of time? There may be cases where I would like to stream bytes as the information is generated to reduce the memory requirements of the sender. Doug Ransom Internet Technologies Domain Lead Power Measurement http://www.pwrm.com mailto:Doug.Ransom@pwrm.com MSN Messenger Doug.Ransom@pwrm.com ------_=_NextPart_001_01C1D04F.11202E40 Content-Type: text/html; charset="iso-8859-1"
When sending some data in beep, does the size of the data need to be known ahead of time?  There may be cases where I would like to stream bytes as the information is generated to reduce the memory requirements of the sender.  
 
Doug Ransom
Internet Technologies Domain Lead
Power Measurement http://www.pwrm.com
mailto:Doug.Ransom@pwrm.com

MSN Messenger Doug.Ransom@pwrm.com

------_=_NextPart_001_01C1D04F.11202E40-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 20 16:24: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 QAA15371 for ; Wed, 20 Mar 2002 16:24:12 -0500 (EST) 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 g2KLE3d24739; Wed, 20 Mar 2002 13:14:03 -0800 (PST) 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 g2KLDld24727 for ; Wed, 20 Mar 2002 13:13:47 -0800 (PST) Received: from kallisti.apple.com(wetware.wetware.com[199.108.16.1]) (3432 bytes) by wetware.wetware.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Wed, 20 Mar 2002 13:23:39 -0800 (PST) (Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Jan-4) Subject: Re: [BEEPwg] Firewall Traversal Content-Type: multipart/alternative; boundary=Apple-Mail-1--302491146 Mime-Version: 1.0 (Apple Message framework v481) Cc: "'beepwg@lists.beepcore.org'" To: Doug Ransom From: james woodyatt In-Reply-To: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D82@HERMES.pml.com> Message-Id: X-Mailer: Apple Mail (2.481) 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, 20 Mar 2002 13:23:34 -0800 --Apple-Mail-1--302491146 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Wednesday, March 20, 2002, at 12:33 PM, Doug Ransom wrote: > > I am trying to understand how peers might traverse a firewall.=A0 In = the=20 > instant message scenario, would a peer need a continous tcp or beep=20 > connection to an outside proxy in order to receive messages from=20 > another peer? The answer is "yes," "no," or "maybe" --depending on the sort of=20 firewall. If the firewall is not a network-layer filtering firewall, and it=20 doesn't transparently route Internet packets, then by its definition:=20 you need a proxy for your instant messaging application. If the firewall is a network-layer filtering firewall, and it *does*=20 transparently route Internet packets, then by its definition: you do not=20= need a proxy for your instant messaging application. (You may need to=20= apply appropriate policies.) If the firewall is a network-layer filtering firewall *and* it is=20 integrated with a network address translation function, then your=20 instant messaging application may need an application layer gateway in=20= the firewall, or it may need a rendezvous service residing elsewhere on=20= the network. What sort of firewall are you talking about? -- j h woodyatt --Apple-Mail-1--302491146 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wednesday, March 20, 2002, at 12:33 PM, Doug Ransom wrote: ArialI am trying to understand how peers might traverse a firewall.=A0 In the instant message scenario, would a peer need a continous tcp or beep connection to an outside proxy in order to receive messages from another peer? The answer is "yes," "no," or "maybe" --depending on the sort of firewall. If the firewall is not a network-layer filtering firewall, and it doesn't transparently route Internet packets, then by its definition: you need a proxy for your instant messaging application. If the firewall is a network-layer filtering firewall, and it *does* transparently route Internet packets, then by its definition: you do not need a proxy for your instant messaging application. (You may need to apply appropriate policies.) If the firewall is a network-layer filtering firewall *and* it is integrated with a network address translation function, then your instant messaging application may need an application layer gateway in the firewall, or it may need a rendezvous service residing elsewhere on the network. What sort of firewall are you talking about? -- j h woodyatt < --Apple-Mail-1--302491146-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 20 16:27:03 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 QAA15407 for ; Wed, 20 Mar 2002 16:27:02 -0500 (EST) 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 g2KLH2d24772; Wed, 20 Mar 2002 13:17:02 -0800 (PST) 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 g2KLGfd24760 for ; Wed, 20 Mar 2002 13:16:41 -0800 (PST) Received: from kallisti.apple.com(wetware.wetware.com[199.108.16.1]) (2044 bytes) by wetware.wetware.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Wed, 20 Mar 2002 13:26:33 -0800 (PST) (Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Jan-4) Subject: Re: [BEEPwg] Streaming data Content-Type: multipart/alternative; boundary=Apple-Mail-2--302316989 Mime-Version: 1.0 (Apple Message framework v481) Cc: "'beepwg@lists.beepcore.org'" To: Doug Ransom From: james woodyatt In-Reply-To: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D83@HERMES.pml.com> Message-Id: <23E5DC5E-3C49-11D6-85CE-000502DB38F5@wetware.com> X-Mailer: Apple Mail (2.481) 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, 20 Mar 2002 13:26:28 -0800 --Apple-Mail-2--302316989 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Wednesday, March 20, 2002, at 12:37 PM, Doug Ransom wrote: > When sending some data in beep, does the size of the data need to be=20= > known ahead of time?=A0 There may be cases where I would like to = stream=20 > bytes as the information is generated to reduce the memory = requirements=20 > of the sender.=A0=A0 No. Unless the Content-Length MIME header is used, the receiving peer=20= has no indication of the size of a BEEP message until the last frame of=20= it arrives. -- j h woodyatt --Apple-Mail-2--302316989 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wednesday, March 20, 2002, at 12:37 PM, Doug Ransom wrote: ArialWhen sending some data in beep, does the size of the data need to be known ahead of time?=A0 There may be cases where I would like to stream bytes as the information is generated to reduce the memory requirements of the = sender.=A0=A0 No. Unless the Content-Length MIME header is used, the receiving peer has no indication of the size of a BEEP message until the last frame of it arrives. -- j h woodyatt < --Apple-Mail-2--302316989-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 20 16:29: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 QAA15440 for ; Wed, 20 Mar 2002 16:29:30 -0500 (EST) 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 g2KLJ2d24808; Wed, 20 Mar 2002 13:19:02 -0800 (PST) Received: from tod.codefactory.se (h21232164028.kommunicera.umea.se [212.32.164.28]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2KLILd24791 for ; Wed, 20 Mar 2002 13:18:21 -0800 (PST) Received: from daniel by tod.codefactory.se with local (Exim 3.35 #1 (Debian)) id 16nncW-0000jP-00; Wed, 20 Mar 2002 22:27:44 +0100 To: Doug Ransom Cc: "'beepwg@lists.beepcore.org'" Subject: Re: [BEEPwg] Streaming data References: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D83@HERMES.pml.com> X-Face: $z6G{rTuG?OLsBU;ehk7{uPNqBQ@U#i<)czx)J}TUbz+Z`FR3adwU5p[t<1o1:?oLC5vl`i(9vI|r=6p9dh5CT(zvj1Mo/.r"@S+3CBBoy.cw]Zr'&-S<.-KBv5yLn.@wSun6D"(jZ1S@PWq1-#2dDZc\MS,GB{s`Bu6sN From: Daniel Lundin In-Reply-To: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D83@HERMES.pml.com> Message-ID: <87it7rrktr.fsf@tod.codefactory.se> Lines: 16 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=latin-iso8859-1 Content-Transfer-Encoding: 8bit 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: 20 Mar 2002 22:27:44 +0100 Content-Transfer-Encoding: 8bit Doug Ransom writes: > When sending some data in beep, does the size of the data need to be known ahead of time?  No, that is not necessary. A single message can consist of multiple frames, where only the payload size of the current frame being sent has to be known and wether there are more frames following. Both are specified in the frame header. Section 2.2 of RFC 3080 describes the message and frame syntax more clearly, and more specifically, Section 2.2.1(.1) describes the frame header. -- Daniel Lundin | daniel@codefactory.se CodeFactory AB | http://www.codefactory.se/ _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 20 16:29:35 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 QAA15454 for ; Wed, 20 Mar 2002 16:29:35 -0500 (EST) 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 g2KLJ5d24824; Wed, 20 Mar 2002 13:19:05 -0800 (PST) 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 g2KLIhd24796 for ; Wed, 20 Mar 2002 13:18:43 -0800 (PST) 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 EF55513A39; Wed, 20 Mar 2002 16:28:39 -0500 (EST) To: Doug Ransom Cc: "'beepwg@lists.beepcore.org'" Subject: Re: [BEEPwg] Streaming data References: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D83@HERMES.pml.com> From: Jered Floyd In-Reply-To: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D83@HERMES.pml.com> Message-ID: <87d6xzudx4.fsf@questionably-configured.permabit.com> Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) 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: 20 Mar 2002 16:28:39 -0500 Doug Ransom writes: > When sending some data in beep, does the size of the data need to be known > ahead of time? There may be cases where I would like to stream bytes as the > information is generated to reduce the memory requirements of the sender. The size of a frame needs to be known before that frame may be sent (and if more data is to follow), but the size of a full message need not be known in advance. --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 20 16:30:03 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 QAA15497 for ; Wed, 20 Mar 2002 16:30:03 -0500 (EST) 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 g2KLK3d24858; Wed, 20 Mar 2002 13:20:03 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2KLJCd24836 for ; Wed, 20 Mar 2002 13:19:12 -0800 (PST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2KLSv320896; Wed, 20 Mar 2002 13:28:57 -0800 (PST) Received: from ELEAR-W2K1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id g2KLT4K12082; Wed, 20 Mar 2002 13:29:04 -0800 (PST) Message-Id: <5.1.0.14.2.20020320132758.053ea9b0@lint.cisco.com> X-Sender: elear@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Doug Ransom From: Eliot Lear Subject: Re: [BEEPwg] Firewall Traversal Cc: "'beepwg@lists.beepcore.org'" In-Reply-To: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D82@HERMES.pml.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 20 Mar 2002 13:28:59 -0800 I presume you mean a firewall that disallows incoming TCP and all UDP. This sounds like a good MIDCOM application. Eliot At 12:33 PM 3/20/2002 -0800, Doug Ransom wrote: >I am trying to understand how peers might traverse a firewall. In the >instant message scenario, would a peer need a continous tcp or beep >connection to an outside proxy in order to receive messages from another peer? > > > >Doug Ransom >Internet Technologies Domain Lead >Power Measurement http://www.pwrm.com >mailto:Doug.Ransom@pwrm.com > >MSN Messenger Doug.Ransom@pwrm.com > _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 20 16:37:06 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 QAA15698 for ; Wed, 20 Mar 2002 16:37:05 -0500 (EST) 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 g2KLR3d25385; Wed, 20 Mar 2002 13:27:03 -0800 (PST) Received: from pwrm.com (h139-142-65-9.pml.com [139.142.65.9]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2KLQUd25373 for ; Wed, 20 Mar 2002 13:26:30 -0800 (PST) Received: from HERMES.pml.com ([10.1.32.4]) by pwrm.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Mar 2002 13:37:12 -0800 Received: by HERMES.pml.com with Internet Mail Service (5.5.2655.55) id ; Wed, 20 Mar 2002 13:35:46 -0800 Message-ID: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D8B@HERMES.pml.com> From: Doug Ransom To: "'beepwg@lists.beepcore.org'" Subject: RE: [BEEPwg] Firewall Traversal MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D057.31D96EF0" X-OriginalArrivalTime: 20 Mar 2002 21:37:12.0442 (UTC) FILETIME=[655D25A0:01C1D057] 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, 20 Mar 2002 13:35:46 -0800 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D057.31D96EF0 Content-Type: text/plain; charset="iso-8859-1" I am talking about a typical firewall with NAT or PAT that I would expect to see at most organizations. It seems to me that if the peers require a continous connection to the proxy that this could be costly -- the proxy would need a lot of open connections for a lot of clients. Does that scale well? [Doug Ransom] From: james woodyatt [mailto:jhw@wetware.com] Sent: Wednesday, March 20, 2002 1:24 PM To: Doug Ransom Cc: 'beepwg@lists.beepcore.org' Subject: Re: [BEEPwg] Firewall Traversal On Wednesday, March 20, 2002, at 12:33 PM, Doug Ransom wrote: I am trying to understand how peers might traverse a firewall. In the instant message scenario, would a peer need a continous tcp or beep connection to an outside proxy in order to receive messages from another peer? The answer is "yes," "no," or "maybe" --depending on the sort of firewall. If the firewall is not a network-layer filtering firewall, and it doesn't transparently route Internet packets, then by its definition: you need a proxy for your instant messaging application. If the firewall is a network-layer filtering firewall, and it *does* transparently route Internet packets, then by its definition: you do not need a proxy for your instant messaging application. (You may need to apply appropriate policies.) If the firewall is a network-layer filtering firewall *and* it is integrated with a network address translation function, then your instant messaging application may need an application layer gateway in the firewall, or it may need a rendezvous service residing elsewhere on the network. What sort of firewall are you talking about? -- j h woodyatt ------_=_NextPart_001_01C1D057.31D96EF0 Content-Type: text/html; charset="iso-8859-1"
I am talking about a typical firewall with NAT or PAT that I would expect to see at most organizations. 
 
It seems to me that if the peers require a continous  connection to the proxy that this could be costly -- the proxy would need a lot of open connections for a lot of clients.   Does that scale well?
 

[Doug Ransom]  
From: james woodyatt [mailto:jhw@wetware.com]
Sent: Wednesday, March 20, 2002 1:24 PM
To: Doug Ransom
Cc: 'beepwg@lists.beepcore.org'
Subject: Re: [BEEPwg] Firewall Traversal

On Wednesday, March 20, 2002, at 12:33 PM, Doug Ransom wrote:


I am trying to understand how peers might traverse a firewall.  In the instant message scenario, would a peer need a continous tcp or beep connection to an outside proxy in order to receive messages from another peer?


The answer is "yes," "no," or "maybe" --depending on the sort of firewall.


If the firewall is not a network-layer filtering firewall, and it doesn't transparently route Internet packets, then by its definition: you need a proxy for your instant messaging application.


If the firewall is a network-layer filtering firewall, and it *does* transparently route Internet packets, then by its definition: you do not need a proxy for your instant messaging application. (You may need to apply appropriate policies.)


If the firewall is a network-layer filtering firewall *and* it is integrated with a network address translation function, then your instant messaging application may need an application layer gateway in the firewall, or it may need a rendezvous service residing elsewhere on the network.


What sort of firewall are you talking about?



--

j h woodyatt <jhw@wetware.com>

------_=_NextPart_001_01C1D057.31D96EF0-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 20 16:38:02 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 QAA15718 for ; Wed, 20 Mar 2002 16:38:01 -0500 (EST) 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 g2KLS2d25767; Wed, 20 Mar 2002 13:28:02 -0800 (PST) Received: from pwrm.com (h139-142-65-9.pml.com [139.142.65.9]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2KLRNd25397 for ; Wed, 20 Mar 2002 13:27:23 -0800 (PST) Received: from HERMES.pml.com ([10.1.32.4]) by pwrm.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Mar 2002 13:38:05 -0800 Received: by HERMES.pml.com with Internet Mail Service (5.5.2655.55) id ; Wed, 20 Mar 2002 13:36:39 -0800 Message-ID: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D8C@HERMES.pml.com> From: Doug Ransom To: "Beepwg (E-mail)" Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D057.51A785F0" X-OriginalArrivalTime: 20 Mar 2002 21:38:05.0439 (UTC) FILETIME=[84F3D8F0:01C1D057] Subject: [BEEPwg] XATP vs. BEEP 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, 20 Mar 2002 13:36:39 -0800 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D057.51A785F0 Content-Type: text/plain; charset="iso-8859-1" Are XATP http://xatp.org/ and BEEP attempting to solve the same set of problems? Doug Ransom Internet Technologies Domain Lead Power Measurement http://www.pwrm.com mailto:Doug.Ransom@pwrm.com MSN Messenger Doug.Ransom@pwrm.com ------_=_NextPart_001_01C1D057.51A785F0 Content-Type: text/html; charset="iso-8859-1"
Are XATP http://xatp.org/ and BEEP attempting to solve the same set of problems?

Doug Ransom
Internet Technologies Domain Lead
Power Measurement http://www.pwrm.com
mailto:Doug.Ransom@pwrm.com

MSN Messenger Doug.Ransom@pwrm.com

 
------_=_NextPart_001_01C1D057.51A785F0-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 20 16:43:05 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 QAA15892 for ; Wed, 20 Mar 2002 16:43:04 -0500 (EST) 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 g2KLX3d25854; Wed, 20 Mar 2002 13:33:03 -0800 (PST) Received: from tod.codefactory.se (h21232164028.kommunicera.umea.se [212.32.164.28]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2KLWLd25837 for ; Wed, 20 Mar 2002 13:32:22 -0800 (PST) Received: from daniel by tod.codefactory.se with local (Exim 3.35 #1 (Debian)) id 16nnqa-0000jX-00; Wed, 20 Mar 2002 22:42:16 +0100 To: Doug Ransom Cc: "'beepwg@lists.beepcore.org'" Subject: Re: [BEEPwg] Firewall Traversal References: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D82@HERMES.pml.com> X-Face: $z6G{rTuG?OLsBU;ehk7{uPNqBQ@U#i<)czx)J}TUbz+Z`FR3adwU5p[t<1o1:?oLC5vl`i(9vI|r=6p9dh5CT(zvj1Mo/.r"@S+3CBBoy.cw]Zr'&-S<.-KBv5yLn.@wSun6D"(jZ1S@PWq1-#2dDZc\MS,GB{s`Bu6sN From: Daniel Lundin In-Reply-To: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D82@HERMES.pml.com> Message-ID: <87eliesypz.fsf@tod.codefactory.se> Lines: 15 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=latin-iso8859-1 Content-Transfer-Encoding: 8bit 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: 20 Mar 2002 22:42:16 +0100 Content-Transfer-Encoding: 8bit Doug Ransom writes: > I am trying to understand how peers might traverse a firewall.  In the instant message > scenario, would a peer need a continous tcp or beep connection to an outside proxy in order > to receive messages from another peer? The TUNNEL profile might be worth a look. It provides application level BEEP proxying, typically with some form of authorization depending on your application. -- Daniel Lundin | daniel@codefactory.se CodeFactory AB | http://www.codefactory.se/ _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 20 17:03:05 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 RAA16642 for ; Wed, 20 Mar 2002 17:03:03 -0500 (EST) 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 g2KLr2d26050; Wed, 20 Mar 2002 13:53:02 -0800 (PST) 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 g2KLq1d26038 for ; Wed, 20 Mar 2002 13:52:01 -0800 (PST) Received: from kallisti.apple.com(wetware.wetware.com[199.108.16.1]) (1210 bytes) by wetware.wetware.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Wed, 20 Mar 2002 14:01:54 -0800 (PST) (Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Jan-4) Subject: Re: [BEEPwg] Firewall Traversal Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "'beepwg@lists.beepcore.org'" To: Doug Ransom From: james woodyatt In-Reply-To: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D8B@HERMES.pml.com> Message-Id: <14001FE3-3C4E-11D6-85CE-000502DB38F5@wetware.com> X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by qawoor.dbc.mtview.ca.us id g2KLq1d26038 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, 20 Mar 2002 14:01:49 -0800 Content-Transfer-Encoding: 8bit On Wednesday, March 20, 2002, at 01:35 PM, Doug Ransom wrote: > > [...] It seems to me that if the peers require a continous connection > to the proxy that this could be costly -- the proxy would need a lot of > open connections for a lot of clients.   Does that scale well? I'm given to understand that the proprietary AOL instant messenger application is built to this architecture. I'm not sure that answers your question, though... -- j h woodyatt _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 20 18:09: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 SAA18458 for ; Wed, 20 Mar 2002 18:09:13 -0500 (EST) 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 g2KMx4d26434; Wed, 20 Mar 2002 14:59:04 -0800 (PST) Received: from pwrm.com (h139-142-65-9.pml.com [139.142.65.9]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2KMwYd26422 for ; Wed, 20 Mar 2002 14:58:34 -0800 (PST) Received: from HERMES.pml.com ([10.1.32.4]) by pwrm.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Mar 2002 15:09:17 -0800 Received: by HERMES.pml.com with Internet Mail Service (5.5.2655.55) id ; Wed, 20 Mar 2002 15:07:51 -0800 Message-ID: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D8E@HERMES.pml.com> From: Doug Ransom To: "Beepwg (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D064.0EF5A090" X-OriginalArrivalTime: 20 Mar 2002 23:09:17.0146 (UTC) FILETIME=[425813A0:01C1D064] Subject: [BEEPwg] Searching for BEEP 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, 20 Mar 2002 15:07:50 -0800 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D064.0EF5A090 Content-Type: text/plain; charset="iso-8859-1" The choice of the acronym "Beep" is unfortunate. Using google I have found web services that beep, protocols that use beeps (morse code) etc. Is it too late to change the name? Doug Ransom Internet Technologies Domain Lead Power Measurement http://www.pwrm.com mailto:Doug.Ransom@pwrm.com MSN Messenger Doug.Ransom@pwrm.com ------_=_NextPart_001_01C1D064.0EF5A090 Content-Type: text/html; charset="iso-8859-1"
The choice of the acronym "Beep" is unfortunate.  Using google I have found web services that beep, protocols that use beeps (morse code) etc.
 
Is it too late to change the name?

Doug Ransom
Internet Technologies Domain Lead
Power Measurement http://www.pwrm.com
mailto:Doug.Ransom@pwrm.com

MSN Messenger Doug.Ransom@pwrm.com

 
------_=_NextPart_001_01C1D064.0EF5A090-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 20 18:34: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 SAA19047 for ; Wed, 20 Mar 2002 18:34:20 -0500 (EST) 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 g2KNO3d26629; Wed, 20 Mar 2002 15:24:03 -0800 (PST) Received: from kalia.dbc.mtview.ca.us (kalia.dbc.mtview.ca.us.ietf53.cw.net [166.63.189.88]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2KNMxd26609 for ; Wed, 20 Mar 2002 15:23:00 -0800 (PST) Received: from kalia.dbc.mtview.ca.us (localhost [127.0.0.1]) by kalia.dbc.mtview.ca.us (8.11.6+3.4W/8.11.6) with SMTP id g2KNVwd09091; Wed, 20 Mar 2002 15:31:58 -0800 (PST) From: Marshall Rose To: beepwg@lists.beepcore.org Cc: Doug.Ransom@pwrm.com Subject: Re: [BEEPwg] Searching for BEEP Message-Id: <20020320153158.45d812d1.mrose@dbc.mtview.ca.us> In-Reply-To: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D8E@HERMES.pml.com> References: <3C552E6ED5B7DC4F8BF603C030BB70BF3E2D8E@HERMES.pml.com> 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, 20 Mar 2002 15:31:58 -0800 Content-Transfer-Encoding: 7bit > The choice of the acronym "Beep" is unfortunate. Using google I have found > web services that beep, protocols that use beeps (morse code) etc. try http://beepcore.org/ > Is it too late to change the name? yes it is too late. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Mar 20 21:58: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 VAA23279 for ; Wed, 20 Mar 2002 21:58:47 -0500 (EST) 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 g2L2mCd28001; Wed, 20 Mar 2002 18:48:12 -0800 (PST) Received: from xomi.pair.com (xomi.pair.com [209.68.2.14]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g2L2l5d27984 for ; Wed, 20 Mar 2002 18:47:05 -0800 (PST) Received: (qmail 89580 invoked by uid 3039); 21 Mar 2002 02:56:57 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Mar 2002 02:56:57 -0000 From: Gabe Wachob X-Sender: To: Daniel Lundin cc: Doug Ransom , "'beepwg@lists.beepcore.org'" Subject: Re: [BEEPwg] Firewall Traversal In-Reply-To: <87eliesypz.fsf@tod.codefactory.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by qawoor.dbc.mtview.ca.us id g2L2l5d27984 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, 20 Mar 2002 18:56:57 -0800 (PST) Content-Transfer-Encoding: 8bit The TUNNEL profile is not directly intended for this purpose - as I read it, its meant for creating a tunnel across a series of hops and doesn't itself say anything about how to traverse a firewall or anything about "rendezvous" (proxy) peers. Thats not to say the TUNNEL profile wouldn't be useful in constructing a spec to do this, I just didn't see the TUNNEL profile doing this out of the box... -Gabe On 20 Mar 2002, Daniel Lundin wrote: > Doug Ransom writes: > > > I am trying to understand how peers might traverse a firewall.  In the instant message > > scenario, would a peer need a continous tcp or beep connection to an outside proxy in order > > to receive messages from another peer? > > The TUNNEL profile might be worth a look. It provides application level BEEP > proxying, typically with some form of authorization depending on your > application. > > > > -- Gabe Wachob gwachob@wachob.com Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Sun Mar 24 04:50:05 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 EAA12105 for ; Sun, 24 Mar 2002 04:50:04 -0500 (EST) 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 g2O9c5d10348; Sun, 24 Mar 2002 01:38:05 -0800 (PST) Received: from mx.infradig.com (c17802.fitzg1.qld.optusnet.com.au [210.49.37.156]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2O9bDd10336 for ; Sun, 24 Mar 2002 01:37:13 -0800 (PST) Received: from localhost ([127.0.0.1]) by localhost with ESMTP id <3C9DA07F.00000015@infradig.com> for ; Sun, 24 Mar 2002 09:46:39 GMT From: Andrew Davison Organization: Infradig Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en MIME-Version: 1.0 To: beepwg@lists.beepcore.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3C9DA07F.00000015@infradig.com> X-Authenticated-Sender: Subject: [BEEPwg] Beep mapping to TCP 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: Sun, 24 Mar 2002 19:46:39 +1000 Content-Transfer-Encoding: 7bit i can understand the use of SEQ frames where a sender wants to write large amounts of data and/or pipeline many messages, but in a simple 1 request to 1 response scenario the response gives an implicit ack, surely, so no SEQs would be required while that situation lasts? _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Sun Mar 24 11:23: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 LAA15251 for ; Sun, 24 Mar 2002 11:23:47 -0500 (EST) 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 g2OGD3d13066; Sun, 24 Mar 2002 08:13:03 -0800 (PST) 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 g2OGCBd13054 for ; Sun, 24 Mar 2002 08:12:11 -0800 (PST) Received: from kalia (dhcpd253 [64.168.10.253] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g2OG7Wc03009; Sun, 24 Mar 2002 08:07:32 -0800 (PST) From: Marshall Rose To: beepwg@lists.beepcore.org Cc: andrew@infradig.com Subject: Re: [BEEPwg] Beep mapping to TCP Message-Id: <20020324082102.616f04a1.mrose@dbc.mtview.ca.us> In-Reply-To: <3C9DA07F.00000015@infradig.com> References: <3C9DA07F.00000015@infradig.com> 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: Sun, 24 Mar 2002 08:21:02 -0800 Content-Transfer-Encoding: 7bit > i can understand the use of SEQ frames where a sender wants to write > large amounts of data and/or pipeline many messages, but in a simple 1 > request to 1 response scenario the response gives an implicit ack, > surely, so no SEQs would be required while that situation lasts? in order for this to work, you'd have to be able to know that there would never be another channel opened on the session except for the one you have now. beep doesn't let you negotiate it, so this is unknowable. if you want to implement beep with only one channel, that's fine. just have your protocol engine send a SEQ everytime it receives a frame. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Mar 26 10:38:29 2002 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07153 for ; Tue, 26 Mar 2002 10:38:28 -0500 (EST) 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 g2QDs6d29953; Tue, 26 Mar 2002 05:54:06 -0800 (PST) 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 g2QDrJd29937 for ; Tue, 26 Mar 2002 05:53:19 -0800 (PST) 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 1754B13A39; Tue, 26 Mar 2002 09:03:47 -0500 (EST) To: beepwg@lists.beepcore.org, beepcore-java-users@lists.sourceforge.net From: Jered Floyd Message-ID: <87adsvo27x.fsf@questionably-configured.permabit.com> Lines: 71 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [BEEPwg] new commercial-grade BEEP implementation now available 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: 26 Mar 2002 09:03:46 -0500 Permabit is pleased to introduce PermaBEEP for Java, a commercial-grade implementation of the Blocks Extensible Exchange Protocol (BEEP). PermaBEEP is a toolkit that speeds and simplifies development of applications that depend on network communications. [Features] CONFORMANCE: PermaBEEP provides a full implementation of the BEEP specification and complies with all applicable standards. PERFORMANCE: PermaBEEP is designed for efficiency, avoiding unnecessary memory copies and object instantiation. SCALABILITY: PermaBEEP supports non-blocking extensions to the Java I/O model (this predates the JDK 1.4 java.nio framework) to support hundreds of active BEEP channels without a large number of threads. COMPLETENESS: PermaBEEP simplifies payload handling with its full-featured MIME parsing and composition tools, along with a lightweight parser for the "application/beep+xml" MIME type XML subset. More details are available in the on-line documentation and release notes. [Availability] Please visit http://www.permabit.com/permabeep/ to download the software. Version 0.8 of PermaBEEP for Java has been well tested but under limited conditions. We encourage you to report any problems encountered when testing in your development environment. Note that some planned features have not yet been implemented and that some interfaces may be changed in subsequent releases. Additional information is available on the PermaBEEP project pages at http://www.permabit.com/permabeep/. [Licensing] PermaBEEP is available under two licenses, one for open source applications and the other for proprietary commercial applications. The open source license is similar to that of the Sleepycat Berkeley DB software, permitting use of PermaBEEP at no charge only in compatible open source applications. For all other applications, please contact sales@permabit.com to obtain licensing terms and pricing. [Acknowledgements] Permabit extends its thanks to the BEEP Community, and in particular to Dr. Marshall T. Rose, for designing BEEP and championing it as a standards-track protocol. Permabit also thanks Huston Franklin and other Invisible Worlders for developing beepcore-java, which brought us far enough into BEEP that we decided to write a new implementation. [About Permabit] Permabit, an innovative developer of networked storage software, offers a distributed data repository that economically blends security, scalability, and reliability, uniquely addressing a wide range of applications. A privately held company, Permabit is based in Cambridge Massachusetts. Permabit and PermaBEEP are trademarks of Permabit, Inc. All other trademarks are property of their respective owners. For more information, please contact Bob Condon at +1 617-252-9600 or visit our web site, www.permabit.com. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Sun Mar 31 12:53: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 MAA27088 for ; Sun, 31 Mar 2002 12:53:19 -0500 (EST) 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 g2VHfDd19518; Sun, 31 Mar 2002 09:41:13 -0800 (PST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g2VHPEd19405 for ; Sun, 31 Mar 2002 09:25:14 -0800 (PST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA93518 for ; Sun, 31 Mar 2002 11:30:20 -0600 Received: from d04nm207.raleigh.ibm.com (d04nm207.raleigh.ibm.com [9.27.5.152]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2VHaDx291362 for ; Sun, 31 Mar 2002 12:36:13 -0500 From: "Ward Harold" Reply-To: wharold@us.ibm.com To: beepwg@lists.beepcore.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: X-MIMETrack: Serialize by Router on D04NM207/04/M/IBM(Release 5.0.9a |January 7, 2002) at 03/31/2002 12:36:12 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [BEEPwg] Using XML-RPC in BEEP; comments please 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: Sun, 31 Mar 2002 11:36:11 -0600 I've morphed the SOAP profile into one that supports XML-RPC. Yes, I know many "web service" types wish XML-RPC would just cease to be but given that SOAP continues to accumulate bulk while XML-RPC has remained simple enough for a single engineer to fully implement in a long weekend and functional enough to do valuable work I personally hope they don't get their wish. Here's the I-D abstract: XML-RPC is a Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transfered between clients and servers. The message specifies a procedure to be invoked by the server and contains the parameters to use in the invocation. Procedure parameters can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures. XML-RPC bindings describe how a specific transport protocol transfers XML-RPC formatted messages between clients and servers. This document specifies a binding to the Blocks Extensible Exchange Protocol core (BEEP). Here's the link to the I-D itself: http://www.ietf.org/internet-drafts/draft-harold-beep-xmlrpc-00.txt Comments appreciated. -- ... WkH _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg