- From: Mark Stemm <stemm@cs.berkeley.edu>
- Date: Wed, 20 May 1998 11:06:20 -0700
- 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 UTC