Persistent connections: aborting requests in progress.

One important benefit of persistent connections (what some people call
"keepalive", although I think that is quite the wrong term) is that
they allow "pipelining": that is, the client can send several requests
without waiting for replies.  This avoids lots of round-trip delays,
especially when retrieving a set of inlined images.  (It may also apply
when doing predictive prefetching.) Venkata Padmanbhan's experiments
last summer showed that a large part of the latency improvement
provided by persistent connections comes from pipelining, not just from
avoiding the extra SYN round-trip.

When I gave my talk at SIGCOMM last month, John Wroclawski of MIT
insisted that if the HTTP protocol allows pipelining, it really needs
to provide a means for aborting requests in progress in case the user
hits the "stop" button.  Otherwise, the user would have to wait for the
upload of (potentially) huge files.

For example, suppose that I have clicked on a page which turns out to
have a huge (1 Mbyte) image, and I'm on the wrong end of a 14.4Kbaud
modem line.  I want to stop loading this image, so I hit the "Stop"
button on my browser.

In HTTP 1.0, since each request is a TCP connection, I can just close
the TCP connection, and within one RTT those bits will never darken my
doorstep again (where "doorstep" means "network path between the server
and me").

In a persistent-connection HTTP (P-HTTP), I could close the connection,
but it would then mean paying an extra round trip (to exchange SYNs)
before I could do anything else.

That may not be excessive (after all, a round-trip is likely to be
quite a bit shorter than the time it takes a user to decide to abort a
request in progress), but perhaps the HTTP 1.x (x >= 1) protocol could
be changed to support an asynchronous abort mechanism.  It would
probably have to use the TCP Urgent Pointer mechanism, as is done in
the Telnet protocol to handle similar events.

Since the protocol currently does not have a way for the server to
abort the transmission of a response once it has started it, presumably
we would also need to use the Urgent Pointer mechanism to do that.

I suspect some TCP implementations may not support Urgent Pointer
(although I think it is mandatory for Telnet), in which case we might
have to make the abort mechanism an optional feature of HTTP.

Any comments?  By which I mean, (a) does anyone know of a real TCP
implementation that doesn't handle URG correctly, and (b) does anyone
think it is worth adding this complexity to some future version of
HTTP, to avoid having to reopen the TCP connection if the user "stops"
a retrieval?

-Jeff

Received on Monday, 11 September 1995 15:35:51 UTC