Re: MTU of the Internet?

["Jay R. Ashworth" <jra () scfn thpl lib fl us>]

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