Re: Where to estimate "link speed", and

Jeffrey Mogul says:

>So I would argue that "link speed" is a pointless concept.  What we
>should really measure is "recent response time", and it should be
>measured *by the client* because only this way can one factor in
>both the full network behavior and the server's behavior.  I do
>not believe that the server can easily map its notion of "load"
>to the actual perceived response time, since (1) the server's load
>may be hard to measure, (2) the server application may not see the
>queueing delays required to open connections, send packets, etc.

This is -exactly- what I was attempting to say.  I didn't
want the measurement to be the theoretical speed, since
it rarely occurs.  What I wanted was an actual -measurement-
of the real-time transmissions.  Mr. Mogul has stated it
much more clearly than I.

Of course, I was thinking about keeping running averages,
but there are problems: conditions can change constantly.
But Mr. Mogul's idea of having the client rate the response
time on each server based on its first connection (for the
session, I assume, but it could also be for the day or
perhaps just for the hour) is much better.  One possible
variation I might give is having a "benchmark" page on
each server (again, optional... kind of like "robots.txt")
which would be a very small file with which the client
could automatically check the response time without
input from the user.  This would allow the "front page"
to still have a high-bandwidth version, as it would be
accessed -after- the benchmark page.  If the response
time is excellent, the higher bandwidth pages would be
sent.

If there is no benchmark page on the server, the client
would have to base it's response time estimates on
the front page.

I still think there would need to be a user-overide.
Again, something very simple.  But necessary, I think,
because people might be patient enough to receive
large documents over slow-response-time connections.
Or might not want large documents when they do have
the necessary connection.

But I agree with Mr. Mogul that we are not looking
for the speed of your modem or T1 line.  We are looking
at the, um, "in-situ" response (can't think of a better
term), which takes into account a good deal more. And it
is the client side that should perform the task.

David Levine
dlevine@ssf4.jsc.nasa.gov
or
lunar@sunsite.unc.edu

Received on Wednesday, 10 May 1995 14:24:41 UTC