Re: Non-order processing in persistent connections

> From http-wg-request@hplb.hpl.hp.com Tue May 19 12:20:30 1998
> Date: Tue, 19 May 1998 12:11:41 -0700
> From: jg@pa.dec.com (Jim Gettys)
> To: Mark Stemm <stemm@CS.Berkeley.EDU>
> Cc: Josh Cohen <joshco@microsoft.com>, koen@win.tue.nl, ZhouKang@cheerful.com,
>         http-wg@cuckoo.hpl.hp.com
> Subject: Re: Non-order processing in persistent connections
> 
> 
> Clearly a good thing...  Congestion and loss recovery should clearly
> be done on a host pair basis, and that existing TCPs don't is clearly
> wrong...

There is an in-depth discussion of this issue in RFC 2140, BTW. :-)

The methods in the Infocom paper are only one way to mux connections;
there are policy issues to be considered. There is also the opportunity to 
share state among different hosts on the same LAN, described in the RFC.

> There are still several other things I suspect that SMUX does that your 
> modified TCP does not (I couldn't access your web site this instant; got 
> a DNS lookup failure on the site for your paper): SMUX can pack more than 
> one fragment into a single packet.  As there are quite a few web objects 
> (and HTTP protocol requests) that are quite small, this saves quite a 
> few packets.  It also serves as a record marking protocol, which can be 
> useful in many applications.

This can be considered detrimental. Keeping the data separated allows emerging
integrated services mechanisms to apply. How would the OS schedule a packet
that is part video, part audio, and part HTML? 

> And it can be deployed alot faster than getting everyone to agree on fixing
> their TCPs (which should be done in any case).

An HTTP solution requires everyone agreeing to fix their web browsers
to be compatible; the state sharing on TCP works wherever deployed (it
is backward compatible even when activated).

As a result, the TCP solution is easier to incrementally deploy and gain incremental
benefit.

Joe

Received on Wednesday, 20 May 1998 11:22:34 UTC