Re: session layers, was Re: Renumbering ... Should we consider an associ

On 2007-9-14, at 21:54, ext Tony Finch wrote:
> On Fri, 14 Sep 2007, Keith Moore wrote:
> > I actually don't think that having multiple concurrent TCP  
> > connections
> > between two peers is a bad thing.   sure we could have a transport
> > protocol that provided multiple streams, but why bother when  
> > concurrent
> > TCP connections works pretty well?
> I agree, except that "pretty well" is a bit crappy when every  
> connection
> has to re-establish authentication and encryption - which is what  
> drives
> some protocols to implement their own multiplexing.
>
> > mumble. I don't have a problem with multiple TCP connections, but  
> > OTOH
> > I think that using TCP close for framing is bad application  
> > design. so
> > I don't view persistent connections in HTTP as a workaround, I  
> > view it
> > as fixing a design flaw in HTTP/1.0.
> I agree, especially because some software has problems telling the
> difference between clean and dirty closes. However there's a latency /
> efficiency trade-off, and TCP pushes you towards pipelining multiple
> transactions down a few connections even when a more natural design
> might have greater concurrency. mumble.
You might be interested in Bryan Ford's SST paper from this year's  
SIGCOMM:
Structured Streams: a New Transport Abstraction. Bryan Ford. ACM  
SIGCOMM 2007, August 27-31, 2007, Kyoto, Japan. http:// 
www.brynosaurus.com/pub/net/sst-abs.html
Abstract: 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.
Lars

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf