Subject: [BEEPwg] BEEP mapping for SST?

From: David Kramer <[email-masked]>
Date: Tue, 26 Jun 2007 14:46:27 -0700

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  
BEEP.  Here is the abstract from the research paper (<http://www.brynosaurus.com/pub/net/sst-abs.html 
 >):
> Internet applications currently have a choice between stream and  
> datagram transport abstractions. Datagrams efficiently support small  
> transactions and streams are suited for long-running conversations,  
> but neither abstraction adequately supports applications like HTTP  
> that exhibit a mixture of transaction sizes, or applications like  
> FTP and SIP that use multiple transport instances. Structured Stream  
> Transport (SST) enhances the traditional stream abstraction with a  
> hierarchical hereditary structure, allowing applications to create  
> lightweight child streams from any existing stream. Unlike TCP  
> streams, these lightweight streams incur neither 3-way handshaking  
> delays on startup nor TIME-WAIT periods on close. Each stream offers  
> independent data transfer and flow control, allowing different  
> transactions to proceed in parallel without head-of-line blocking,  
> but all streams share one congestion control context. SST supports  
> both reliable and best-effort delivery in a way that semantically  
> unifies datagrams with streams and solves the classic “large  
> datagram” problem, where a datagram's loss probability increases  
> exponentially with fragment count. Finally, an application can  
> prioritize its streams relative to each other and adjust priorities  
> dynamically through out-of-band signaling. A user-space prototype  
> shows that SST is TCP-friendly to within 2%, and performs comparably  
> 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  
> demand for multiplexing logical streams onto a secure channel. MUX   
> [23] and BEEP  [44] similarly multiplex logical streams onto one TCP  
> stream, layering their own flow control atop TCP’s. These protocols  
> exacerbate TCP’s drawbacks, however, by totally ordering many  
> unrelated activities so that one lost packet blocks everything  
> behind it.
>
It seems to me that the author is slightly mis- (or under-) informed  
about BEEP, since he confuses BEEP (RFC 3080) with the TCP mapping  
(RFC 3081).

Rather than SST and BEEP being at odds with each other, I think there  
is a lot of potential synergy.  After I read the SST paper I got very  
excited about the possibility of creating an SST mapping of BEEP.  SST  
would eliminate the need for BEEP to multiplex multiple channels over  
a single stream and provide greater efficiency, while BEEP could  
provide helpful application protocol structure that SST doesn't, such  
as profiles and MIME.

I am curious if anyone else on the list has taken a look at SST or  
considered mapping BEEP onto it.  The mapping looks like it would  
pretty straightforward, except that I'm not sure how one would  
implement session transport tuning such as TLS on SST.  If each BEEP  
channel were a substream then it seems you would need to have a unique  
TLS session for each channel rather than the session.

Since SST is not an industry standard (or even an RFC) at this time I  
wonder if the BEEP and SST folks could collaborate to ensure that SST  
becomes the premiere BEEP mapping.  There might still be time to  
convince the SST folks to take changes that would make it easier to  
map BEEP to it, or perhaps this working group could define extensions  
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  
of UDP, so the usual tricks that allow bi-directional UDP traffic to  
pass through multiple NATs might also be used to allow BEEP  
connections to be made between two peers that are both behind NAT.

-David

_______________________________________________
BEEPwg mailing list
[email-masked]
http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg