On Sun, Feb 08, 1998 at 10:37:28AM -0800, Paul A Vixie wrote: two things which I wanted to comment on.
tcp without congestion avoidance is always faster than tcp with congestion avoidance. whether you take away congestion avoidance by running lots of short lived connections in parallel, or whether you actually dyke out the code that avoids congestion, the result is the same: other tcp's will back off and give you more of the channel.
this is another example of a cooperative protocol suite trying to survive in a competitive world. that tcp only behaves well if all other tcp's behave well, where "behaves well" means "shares paths fairly" creates an automatic incentive on the part of some designers to not "behave well" so they can get more than their fair share.
Yup. _I phone_. I used to run a 40 port ISP on a 64k uplink. It worked _just_ fine... until VocalTec took over.
I'll throw in one more subjective measure. When Netscape first came out some of the CS people at Virginia Tech wondered about the perception, and did some tests with willing college student subjects using Mosaic (which at the time supported HTTP keepalives, and used them to connect to the server once for all transfers) and Netscape (multiple connections, no keepalives). ... On the more complex pages Mosaic downloaded and displayed the page faster, in wall clock time, but the users always preferred Netscape. The observation is that many people don't wait for a full download, they click on picture links, for instance, when they are half down....so having them all half down allows someone to proceed with browsing, rather than having half fully there, and half not visable.
which means the server gets a lot of RSTs and a lot of data which is committed into the path ends up being thrown away. seems like if we wanted things to go faster, we would waste less bandwidth by sending only data which was useful and not creating a huge number of retrans- missions by effectively turning off tcp congestion avoidance.
Alas, the problem is that "faster" isn't what we really want here. In the quest for "efficiency", we've forgotten that what is _really_ desired is "effectiveness" (not "do the thing fast", but "do the _right_ thing"), and the problem is that what "the right thing" _is_ depends almost entirely on the design on the page. If there aren't sufficient structural clues in the markup, the server _cannot_ accurately guess what's most necessary to get out there quickly, and will be right, at best, 50% of the time. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com