MTU of the Internet?

Mailman List Mirror (Read Only)
1

The state of the art in terms of deployed protocols right now is
persistent pipelined connections; most clients don't implement them
yet, but they are getting there.

explorer and navigator have both done this since their respective 3.0's.
however, they both still open N (where N defaults to 4) connections to the
same server rather than depending on persistence and limiting themselves
to 1 connection per server. so they will reuse their N connections for more
than one fetch if there are more than N objects to be fetched from some
server to fill out one "page". phil howard says this is a feature, but now
that the size of a graphic can be given in its enclosing page it is no longer
nec'y to get the graphic objects' headers before laying out the page, and
i think that for the good of the network and the origin servers it would be
nicer if these browsers could learn to serialize their fetching a LOT more.

  - if you are a proxy, this becomes even more critical. If
    you only use one connection to each origin server, if one
    client requests a huge document from that server, anyone else
    wanting to make requests to that server would have to wait
    for the transfer to finish.

proxies will use more than one (ours limits it to 100) connection per origin
server. all of these "slots" would have to be occupied by large transfers
for the above concern to manifest. in practice, there are some slots held
by large transfers while other slots get used by a lot of small transfers,
and it's only when there are too darn many clients that anybody has to wait.

> ... does seeing the GIFs fill in in parallel really make that
> much difference, if the total page fill time is going to be the same?

Yes, it does make a difference.

A real world nanog example? Cisco docs. You may have a 300k HTML
file with a bunch of graphics in it. You want to read something
partway down the file and it has an image you need to see. Do you
want to wait for the whole HTML to download, then for each image
to download until it gets to yours or do you want to be able to
start reading ASAP?

i can see your point here.

The basic idea is that humans are reading documents, and they take some
finite time to read and normally start at the top and work down.
The faster you can display the start of it, complete with the graphics,
etc. that are contained in that part, the faster the user can get on
with reading the document.

ok.

Persistent connections with pipelining come close to the peak of
efficiency from the network perspective (well, the perspective of
anything sitting on top of TCP), but not from the much harder user
perspective.

perhaps the right answer would be to limit the number of persistent
connections per host to something like 2, no matter what the maximum
number of connections is set to.

Dealing with this is one of the goals of HTTP-NG. See:

  http://www.w3.org/Protocols/HTTP-NG/

will do.

2

Phil Howard writes:
> By loading the images in parallel, with the initial part of the image files
> being a fuzzy approximation, you get to see about where every button is
> located, and in many cases you know exactly what it is, and you can click
> on them as soon as you know where to go.

By loading the images in parallel over multiple TCP connections, you
also totally screw the TCP congestion avoidance mechanisms, and hurt
the net as a whole, especially given how prevalent HTTP is these days.
Unfortunately, as has been seen here, very few people working with the
net these days actually understand the details of things the net
depends on, and TCP congestion avoidance is one of them.

HTTP 1.1 allows multiplexing in a single stream, and even (amazingly

Once again, HTTP/1.1 does _not_ allow multiplexing multiple transfers
simlultaneously in a single TCP connection. Multiple responses are
serialized.

enough) ends up working faster in practice than multiple TCP
connections.

I have seen nothing supporting that assertion for high latency, medium
(aka. the Internet on a good day) packet loss connections. The discussion
at:

  http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html

shows some interesting information about the wins of persistent
connections and piplining, however their tests only went as far as
including a 28.8k local dialup, which does not simulate the "average user"
going to the "average web site". If you are dropping packets and
congestion contol is coming into play, you may see more impact when using
one connection that is temporarily stalled than multiple connections, with
the hope that at least one will be sending at any time. I am not aware of
any research to support (or deny, for that matter) this view, however
AFAIK there is a general lack of published research on the interaction
between HTTP w/pipelined and persistent connections and the Internet.

As I noted before, total transfer time for all the responses that make up
one document in the client is not the metric that client vendors are
trying to optomize and is not what most users care about.

> The state of the art in terms of deployed protocols right now is
> persistent pipelined connections; most clients don't implement them
> yet, but they are getting there.

explorer and navigator have both done this since their respective 3.0's.

As I have already pointed out to Paul, but think it deserves to be
emphasized because it is not apparent to many, they do _not_ do pipelined
connections but only persistent connections. You can not do reliable
pipelined connections with HTTP/1.0. The difference between pipelined
persistent and non-pipelined persistent connections (in the case where
there are multiple requests to the same server in a row) is one RTT per
request plus a possible little bit from merging the tail of one response
with the head of another into one packet.

Also worthy of note is that the only widespread client that implements
HTTP/1.1 is MSIE4, and even it is botched badly, although not as badly as
4.0b2 was. (eg. it sometimes sent 1.1 requests but would only accept 1.0
responses)

3

Marc Slemko <marcs@znep.com> writes:

[...]

shows some interesting information about the wins of persistent
connections and piplining, however their tests only went as far as
including a 28.8k local dialup, which does not simulate the "average user"
going to the "average web site". If you are dropping packets and
congestion contol is coming into play, you may see more impact when using
one connection that is temporarily stalled than multiple connections, with
the hope that at least one will be sending at any time. I am not aware of
any research to support (or deny, for that matter) this view, however
AFAIK there is a general lack of published research on the interaction
between HTTP w/pipelined and persistent connections and the Internet.

If packets were being lost on the path somewhere beyond the dialup
user's ISP, which is usually the case, then having the dialup user go
through a proxy server would solve this problem. The client can open
up all the stream it wants to, doing all the nasty and anti-social
things that it pleases, and none of us elsewhere on the Internet will
care as long as the proxy server is well-behaved. The proxy server is
presumably more capable of dealing with packet loss because of its
lower RTT to the originating HTTP server.

Then once people get all the HTTP/1.1 stuff figured out, you only need
to upgrade the proxy server instead of upgrading each and every single
client browser.

And as an added bonus, there might be a cache hit.