North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: MTU of the Internet?
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 [email protected] 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
|