W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1998

Re: Non-order processing in persistent connections

From: Joe Touch <touch@isi.edu>
Date: Wed, 20 May 1998 11:21:09 -0700 (PDT)
Message-Id: <199805201821.LAA23215@rum.isi.edu>
To: stemm@cs.berkeley.edu, jg@pa.dec.com
Cc: joshco@microsoft.com, koen@win.tue.nl, ZhouKang@cheerful.com, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/135
> 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

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC