Re: HTTP Session Extension draft

At 10:31 AM 7/6/95, Jeffrey Mogul wrote:
>    Well the first thing to keep in mind is that those same busy servers
>    are keeping 1000 records for closed connections that are in the
>    time-wait state.
>
>Not necessarily.  My simulations, using traces from several busy servers,
>show that with certain choices of server parameters, the peak number of
>TIME_WAIT entries is well below 1000.  That is, the use of sessions
>can actually reduce the number of TIME_WAIT entries by an order of
>magnitude (compared to non-session HTTP).  More details in my SIGCOMM
>paper, or look at
>    http://www.research.digital.com/wrl/publications/abstracts/95.4.html

Now, how does that relate to the multitude of non-Unix servers on the
Internet? Please remember that WWW <> Unix and HTTP <> Unix and TCP/IP <>
Unix. There are LOTS of implementations of WWW software that have
absolutely nothing to do with Unix, Unix kernel settings, Unix kernel
performance, Unix IP stacks, or anything else to do with Unix. The reason
this is an issue is that you cannot predicate protocol decisions solely on
the implementation of IP stacks on Unix hosts.

Rationalizing protocol extensions based on the assumption that
Unix-oriented measures are sufficient justification is not acceptable. The
second most widely used HTTP server on the Internet is Mac-based, according
to GA Tech's latest WWW survey, behind NCSA httpd and ahead of CERN httpd.
You can bet that non-Unix TCP/IP stacks have radically different resource
constraints and performance issues.

>The reason is that the number of TIME_WAIT entries is directly related
>to the number of TCP connections used.  If you use sessions (what I
>called in my paper "persistent connections"), you need to create fewer
>TCP connections for the same number of retrievals.  So you end up
>with fewer TIME_WAIT entries.

This is irrelevant on platforms with a limited number of TCP/IP streams
that can be formed. People discussing this issue are right to refer to
"irresponsible use" of TCP/IP connections.

>    Note that I am not advocating irresponsible use of sessions, although
>    it would make sense to me that a clinet might request a session for
>    every HTTP request that it makes under the assumtion that 90% of HTML
>    pages have some images on them. And if they dont, you just close the
>    connection as soon as you have recevied it anyway.
>
>I don't understand how the term "irresponsible" applies here at all.
>I frankly don't see any situations where the use of persistent
>connections can cause any problems (under the assumption that any
>party can terminate a connection whenever it wants to free up the
>resources).

IF that is built into the protocol, that's fine. But as was pointed out
earlier today, unilateral termination of a persistent session can lead to
race conditions and in effect eliminates persistence altogether in resource
constrained situations.

A related, somewhat important piece to this puzzle is the need for HTTP
clients to implement a retry scheme when servers report that they are
resource constrained with a 50x error code. As far as I know, no clients in
widespread use implement retries when a server reports that it is too busy
or is unable to service a request due to resource constraints. Implementing
this portion of the standard in WWW clients will go a long way towards
eliminating the potential race conditions that can arise when a server
terminates a session after a client has issued a new request but before the
server received it. The client will simply retry.

>I also suspect that much of the benefit comes NOT from imbedded
>images, but from subsequent requests for HTML pages (i.e., the
>user clicks, reads, and clicks again).

The last thing I want to do with a resource-constrained server is
re-implement the nightmare of hundreds of blinking cursors in otherwise
idle telnet sessions. The HTTP protocol is primarily connectionless
(stateless) for reasons of efficiency from the server's perspective. I
think a persuasive argument can be made for keeping a stream open while all
of the required parts of a single "page" are transmitted. Allowing an
individual to monopolize a scarce resource for longer periods of time, on
the off chance that a human might select another link to your site from the
page he just received, IS irresponsible.

--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Chuck Shotton                               StarNine Technologies, Inc.
chuck@starnine.com                             http://www.starnine.com/
cshotton@biap.com                                  http://www.biap.com/
                 "Shut up and eat your vegetables!"

Received on Thursday, 6 July 1995 11:28:51 UTC