From beepwg-bounces@dbc.mtview.ca.us Tue Jun 26 17:52:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3IxA-0007dQ-Eu for beep-archive@lists.ietf.org; Tue, 26 Jun 2007 17:52:04 -0400 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3IxA-0007qV-0w for beep-archive@lists.ietf.org; Tue, 26 Jun 2007 17:52:04 -0400 Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id l5QLkZ2B031812; Tue, 26 Jun 2007 14:46:38 -0700 Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) l5QLkXYN031809 for ; Tue, 26 Jun 2007 14:46:33 -0700 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (Postfix) with ESMTP id AF975A5174E for ; Tue, 26 Jun 2007 14:46:27 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 9DC52400B5 for ; Tue, 26 Jun 2007 14:46:27 -0700 (PDT) X-AuditID: 11807126-a18ccbb0000007dd-75-468189338409 Received: from [17.221.41.212] (int-si-a.apple.com [17.128.113.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay8.apple.com (Apple SCV relay) with ESMTP id 7C35A4008B for ; Tue, 26 Jun 2007 14:46:27 -0700 (PDT) Message-Id: From: David Kramer To: beepwg@lists.beepcore.org Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v890.2) Date: Tue, 26 Jun 2007 14:46:27 -0700 X-Mailer: Apple Mail (2.890.2) X-Brightmail-Tracker: AAAAAA== X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id l5QLkXYN031809 Subject: [BEEPwg] BEEP mapping for SST? X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by drakken.dbc.mtview.ca.us id l5QLkZ2B031812 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Hello BEEP working group, I was reading about Structured Stream Trasport (SST): http://pdos.csail.mit.edu/uia/sst/ And it appears to be attempting to address some of the same issues as =20 BEEP. Here is the abstract from the research paper (): > Internet applications currently have a choice between stream and =20 > datagram transport abstractions. Datagrams efficiently support small =20 > transactions and streams are suited for long-running conversations, =20 > but neither abstraction adequately supports applications like HTTP =20 > that exhibit a mixture of transaction sizes, or applications like =20 > FTP and SIP that use multiple transport instances. Structured Stream =20 > Transport (SST) enhances the traditional stream abstraction with a =20 > hierarchical hereditary structure, allowing applications to create =20 > lightweight child streams from any existing stream. Unlike TCP =20 > streams, these lightweight streams incur neither 3-way handshaking =20 > delays on startup nor TIME-WAIT periods on close. Each stream offers =20 > independent data transfer and flow control, allowing different =20 > transactions to proceed in parallel without head-of-line blocking, =20 > but all streams share one congestion control context. SST supports =20 > both reliable and best-effort delivery in a way that semantically =20 > unifies datagrams with streams and solves the classic =93large =20 > datagram=94 problem, where a datagram's loss probability increases =20 > exponentially with fragment count. Finally, an application can =20 > prioritize its streams relative to each other and adjust priorities =20 > dynamically through out-of-band signaling. A user-space prototype =20 > shows that SST is TCP-friendly to within 2%, and performs comparably =20 > to a user-space TCP and to within 10% of kernel TCP on a WiFi network. > In fact, in the research paper specifically mentions BEEP: > The popularity of SSL [17] and SSH tunneling [55] attest to the =20 > demand for multiplexing logical streams onto a secure channel. MUX =20 > [23] and BEEP [44] similarly multiplex logical streams onto one TCP =20 > stream, layering their own flow control atop TCP=92s. These protocols =20 > exacerbate TCP=92s drawbacks, however, by totally ordering many =20 > unrelated activities so that one lost packet blocks everything =20 > behind it. > It seems to me that the author is slightly mis- (or under-) informed =20 about BEEP, since he confuses BEEP (RFC 3080) with the TCP mapping =20 (RFC 3081). Rather than SST and BEEP being at odds with each other, I think there =20 is a lot of potential synergy. After I read the SST paper I got very =20 excited about the possibility of creating an SST mapping of BEEP. SST =20 would eliminate the need for BEEP to multiplex multiple channels over =20 a single stream and provide greater efficiency, while BEEP could =20 provide helpful application protocol structure that SST doesn't, such =20 as profiles and MIME. I am curious if anyone else on the list has taken a look at SST or =20 considered mapping BEEP onto it. The mapping looks like it would =20 pretty straightforward, except that I'm not sure how one would =20 implement session transport tuning such as TLS on SST. If each BEEP =20 channel were a substream then it seems you would need to have a unique =20 TLS session for each channel rather than the session. Since SST is not an industry standard (or even an RFC) at this time I =20 wonder if the BEEP and SST folks could collaborate to ensure that SST =20 becomes the premiere BEEP mapping. There might still be time to =20 convince the SST folks to take changes that would make it easier to =20 map BEEP to it, or perhaps this working group could define extensions =20 to BEEP (channel transport tuning?) to make it easier to map to SST. Another interesting aspect of SST is that it can be implemented on top =20 of UDP, so the usual tricks that allow bi-directional UDP traffic to =20 pass through multiple NATs might also be used to allow BEEP =20 connections to be made between two peers that are both behind NAT. -David _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg