Re: Where to estimate "link speed", and why not
Jeffrey C. Sedayao (sedayao@argus.intel.com)
Thu, 11 May 95 0:50:18 PDT
> As for a client-supplied link-speed estimate, I'll just point out
> that this is something that the server may be in a better position
> to estimate than the client. First, it may be the server's end of
> the connection is the performance bottleneck (the client is on a T1
> and the server is at the end of a 14.4). Since server load is often
> the determining factor in response time, the server is usually in a
> better position to judge 'how fast' the request will be satisfied.
> The server may have more history of the response time for other
> clients from the same domain.
> I'm not sure I agree. I think part of the problem is that we are
> discussing "link speed", as if the term really meant anything. In
> fact, what we really care about is response time.
I don't agree either. Response time is critical. At Intel, we have had
a number of people complain that WWW performance is FASTER with a 14.4
dial up line at home than going through a proxy server over one of our
corporate Internet connections (T1 lines). It's not surprising if you
consider all of the delay that a proxy server can impose while it is
spawning processes, looking through caches, doing at least two
more DNS lookups, etc. A little math shows that for small objects
some delay can easily drag down the throughput of a T1 to worse
than that of a 14.4 dialup.
> Link speed does affect response time, but so does a lot of other
> stuff. For example, link congestion, link error rate, and server
> loading. And, since the Internet seems to have a diameter of
> ca. 10-15 hops, and my recent experience suggests that it is often
> the internal "high-bandwidth" links that are the most flakey, I
> do not believe that it is possible to calculate response time from
> the characteristics of a few links in the path, any more than it
> is possible to predict the weather in Peoria by observing butterfly
> flight patterns in Palo Alto (well, perhaps I exaggerate).
> I've also noticed that the path taken from our Internet demarcation
> point to any specific Internet site varies quite frequently.
> 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.
That's an interesting proposition. It might get thrown off by
initial object retrieval, though. The first time a server would get a
request from a client, it could go through a series of DNS lookups that it
wouldn't do on subsequent requests after it cached that lookup. Note
that doing reverse and forward DNS mappings could result in a whole
mess of round trips between a server's and a client's network. Then
again, some servers save time by not doing any DNS queries with
requests.
> For example, my browser could keep a recent history of (object size,
> response time, server) measurements. One would probably want to
> apply some filtering to the results (perhaps estimating mean and
> variance), but the goal would be to try to predict how to set
> the "mxb" value (or perhaps a more complex indicator of preferences).
One could verify the usefulness of response by correlating the
response time of a particular request against previous requests. Has
anyone done this on large scale (or be willing to do this)?
> Since the client will not have specific estimation information about
> a server it has never used before (or not used recently), this means
> that the technique will not work as well for the "front page" of a
> server. Clients could be conservative in this case (e.g., always
> sending a low value for "mxb" in the absence of specific information).
> But another implication is that Web set designers should perhaps engineer
> the front page for low latency rather than high glitz.
That's a good suggestion, although with image caching, getting a bunch of
images on the first page that are repeated throughout a server can save
time later.
> Clearly, a client that is connected by a 14.4 tail circuit is going
> to have a different default policy than one on a T3 link. But I would
> imagine that this could be "learned" very quickly by the browser software,
> and no user would ever have to configure a specific link-speed value.
> One more thing against putting the onus on the server: it doesn't scale
> well. Clients (in the aggregate) have far more CPU power and memory;
> let them do the job.
I definitely agree with this statement.
> -Jeff
--
Jeff Sedayao
Intel Corporation
sedayao@argus.intel.com