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

This is not an academic institution. We do not as the founder of my Oxford 
College put it, have to 'care more for novelty than for truth'.

What failed in 1980 may have failed because it was a bad idea or because it was 
a good idea whose time has not yet come. Or it may have failed for no other 
reason than a different choice was made.


> -----Original Message-----
> From: Fred Baker [mailto:fred(_at_)cisco(_dot_)com] 
> Sent: Monday, September 17, 2007 5:14 AM
> To: Lars Eggert
> Cc: ext Tony Finch; Keith Moore; IETF-Discussion
> Subject: Re: session layers,was Re: Renumbering ... Should we 
> consider an association thatspans transports?
>
> Dumb question of the month. With the exception of the last 
> claim ("...can prioritize..."), this could just as easily 
> describe SCTP.  
> What here is new? And define "prioritize"?
>
> On Sep 17, 2007, at 2:02 AM, Lars Eggert wrote:
> > 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_______________________________________________
> > Ietf mailing list
> > Ietf(_at_)ietf(_dot_)org
> > https://www1.ietf.org/mailman/listinfo/ietf
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf