Re: Keep-Alive Notes

    An example - imagine that you hit two pages simultanously with 100
    inlined images each. One returns a timeout of 300 secs and the
    other returns 30 secs.  If you do not have the resources to fill
    both channels then it might be a good idea to concentrate on the
    one that will close within 30 secs.

    Therefore at least the timeout does convey useful information.

Let's examine this a little deeper.  I'll pretend to accept your
rather optimistic assumption that the client code is actually
sophisticated enough to manage its resources that carefully.
So if the servers are imposing a "session-length" timeout, then
it is indeed useful for a client to use whichever session will
time out sooner.

But: why does anyone thing it makes sense for a server to set
a session-length timeout of this kind?

Of course, the timeout value returned in this header might be
an idle-connection timeout (as I modelled in my SIGCOMM paper).
But this does not seem to be the current intent; I quote from
Roy's notes:

    The actual parameters of the Keep-Alive exchange are still unknown
    and open for experimentation.  The initial idea of using "max" and
    "timeout" to indicate session-length preference (on requests) and
    actuals (on responses) is optional.
    
and observe that if the client and server have different interpretations
of the meaning of this timeout, then it's almost certainly useless!

Getting back to the question of "why would the server set a session-length
timeout" instead of an idle timeout: what could the server gain from
deciding at the beginning of a connection how many seconds it should
run?

Let's say the value returned is 300 seconds.
If the client opens the connection and retrieves 2 files, then
goes idle for 298 seconds, the server really ought to have the option
to close the connection after, say, 17 seconds, when it realizes
that it has run out of connection (or thread) resources.  But then
this means that the "300 second" value it gave to the client is at
best an upper bound, not a promise that the client can rely on.

So now consider the case where the server returns "300 seconds"
at the beginning of the connection, but the user has become VERY
interested in the material on the server, and after 299.99 seconds
is still furiously making requests.  Let's further suppose that
in this case, the server has sufficient resources to continue
servicing this client.  Then the last thing that we want is for
the client to say "oops, time is up", and close the connection
(and then, presumably, immediately open another one).  So using
the value as an upper bound is pretty pointless, anyway.

One could argue, I suppose, that if the server keeps returning
"300 seconds" in subsequent responses, the client can keep using
the connection indefinitely ... and if the server load increases,
the server can ratchet down the timeout value to let the client
know that "soon" it will have to drop the connection.  But as
long as the protocol allows the client to simply reopen another
connection immediately, all this means is that an aggressive client
will consume MORE server resources (PCB table slots, CPU cycles)
rather than fewer.

I also believe that, in most cases, the load on the server varies
significantly at a timescale shorter than the 1-second granularity
of this timeout value.  (I have some traces to support this belief.)
This means that it's not a particular useful technique to set the
timeout really small, since by the time the client figures out
what is happening, the server's situation may have changed.

If we want a mechanism that allows a server to throttle the request
rate of an aggressive client, we should address that issue directly.
For example (this is just an off-the-cuff idea), the server could
return a "try again in N seconds" error code, close the TCP connection,
and then refuse to accept a new connection from that client until
the N seconds has elapsed.  Or the server could keep the connection
open, but simply delay reading from it (which means that the TCP
flow-control mechanism would force the client to stop sending).

In summary: unless and until we have a consensus on what the
"timeout" value in the (badly-named) Keepalive header means,
and how it could be of use, I strongly object to putting it
into the spec.

-Jeff

Received on Thursday, 12 October 1995 10:47:49 UTC