Re: my broken TCP is faster on broken networks

Marc Slemko (marcs@znep.com)
Sat, 12 Sep 1998 03:29:42 -0700 (PDT)


On Sat, 12 Sep 1998, Martin Mares wrote:

> > It is another vendors attempt to make their browser look "faster" than
> > others. Netscape always opens up 4 connections in parallel by default
> > and uses persistant transactions over each one. You can configure it
> > to use only one open connection.
>
> It seems people from Netscape should read the RFC's...

The people from Netscape don't use HTTP/1.1 in Navigator.

And there are valid issues with page layout in the current world meaning
that the optimal way to transfer files with the goal of getting all the
content across as quickly as possible is not the same as the optimal way
of getting something that the user wants to look at as quickly as
possible, even if the full transfer isn't complete.

This goes off into a huge number of areas including the problems with
HTML, possible compression of documents, both streaming and
pre-compressed, the ways to allow easier rendering, the benefits of
multiplexing requests over a single connection, HTTP-NG, where the heck
the W3C thinks it is going into an fantasy world of objects, etc.

But that is very off topic and has been discussed to death.

What it boils down to is that no one has shown any valid, documented
support for breaking congestion control in Linux, nor have they shown that
magical improvements will do anything except accomplish their goal of
"making _my_ page load faster!". Some of the suggestions I have seen here
"well hey, it doens't work very well IMHO now anyway so we may as well
just trash the whole concept of congestion control and let everyone fight
it out however they want" are beyond crazy.

Any such changes would require the proper research, presentation, and
discussion in the appropriate forums before deployment would make any
sense. The appropriate forum isn't here.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html