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

Re: Non-order processing in persistent connections

From: Mark Stemm <stemm@cs.berkeley.edu>
Date: Wed, 20 May 1998 11:06:20 -0700
Message-Id: <35631B9C.62857745@cs.berkeley.edu>
To: Jim Gettys <jg@pa.dec.com>
Cc: Josh Cohen <joshco@microsoft.com>, koen@win.tue.nl, ZhouKang@cheerful.com, http-wg@cuckoo.hpl.hp.com
Jim Gettys wrote:
> 
> 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 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.
> 
> And it can be deployed alot faster than getting everyone to agree on fixing
> their TCPs (which should be done in any case).
> 
You couldn't grab the paper because power to the UCB campus was out for
most of yesterday...sigh. Anyway, it's back now.

I agree that SMUX has advantages in terms of increasing the size of
packets and decreasing the number of packets per transfer. It would be
interesting to quantify the effect that this has in reducing response
time or network congestion over our approach. However, I think I
disagree in terms of ease of deployment. It obviously takes more work to
upgrade the networking stack of a single host than upgrade a web server
or browser, but there are a lot less web servers than web clients in the
internet, and because our approach is limited to the stack at the sender
and is compatible with existing receivers, the total work necessary to
get our approach deployed is probably less. 

If deployment pain P= N*p, where N=number of hosts modified and p= pain
per host, TCP-INT has a larger p but much smaller N :).

		--Mark
Received on Wednesday, 20 May 1998 11:15:56 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:18 EDT