Re: HTTP Session Extension draft

At 12:03 PM 7/6/95, Jeffrey Mogul wrote:
>    >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.

>Please tell me where I used the word "UNIX" in my message.  In fact,
>absolutely nothing in my simulations is UNIX-specific.
>The requirement that a TCP implementation maintain TIME_WAIT records
>is part of the TCP specification.

The assumption that thousands of TCP/IP connections are just laying around
for use is definitely a Unix assumption. I didn't say anything about
TIME_WAIT records, etc.

>    You can bet that non-Unix TCP/IP stacks have radically different resource
>    constraints and performance issues.
>
>That is a valid point.  The HTTP specification should certainly not
>require servers to keep connections open any longer than they want to.
>A server implementor should keep the relevant resource constraints
>in mind when setting server policies.

As long as we keep that in mind, I don't have a problem with it.
Unfortunately, I have to hop up on a stump occasionally and remind people
not to take a Unix-centric view of the Web. Your message (unfortunately?)
happened to be a good excuse for stump-hopping.

>True, I did not simulate a server that keeps only one connection open
>at a time.  Such a server would presumably not want to use sessions,
>so I didn't bother to simulate how sessions would affect it.

Well, that is a degenerate case and I am unaware of any HTTP server that
can only handle one connection at a time.

>    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.
>
>On the other hand, for servers that ARE able to maintain multiple TCP
>connections, the best way to signal "I'm resource constrained" is to
>use the TCP flow control mechanisms.  That is, if the client has an
>open connection and the server doesn't have the cycles to keep data
>flowing on it, the client is inherently blocked from sending more
>requests (unlike the case with current HTTP, where there is no flow
>control).  So for server systems whose limiting resource is CPU cycles,
>rather than TCP connections, sessions could be a big win.

But the current HTTP model DOES support blocking requests that cannot be
handled. That's what the "server busy" error code is all about. Clients are
refused, and explicitly told how long to wait before retrying. However,
client authors (Netscape) are slow to adopt this portion of the standard.

>    >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.
>
>Huh?  Nobody is asking for that.  The server does not have to commit
>any CPU cycles to the idle HTTP connections (beyond timer maintenance,
>which is actually cheaper on idle open connections than on TIME_WAIT
>connections).

I'm not concerned about CPU cycles. I am concerned about idle TCP/IP
connections. On a system with a finite number of connections, or with a
finite amount of memory allocated for TCP/IP buffer space, allowing idle
connections to hang around is a Bad Thing(tm).

>    The HTTP protocol is primarily connectionless
>    (stateless) for reasons of efficiency from the server's perspective.
>
>Statelessness does not imply efficiency.  Period.  Statelessness only
>affects the need to maintain state.

Efficiency of implementation, efficiency of resource utilization. Sorry, I
wasn't specific. CPU and network efficiency are not the issues at hand.
They can always be solved with bigger CPUs. There are fundamental limits in
many IP stacks that limit other aspects of a HTTP implementation and the
current connectionless model does a good job of supporting those limits.

>I have never seen a quantitative argument that statelessness improves
>efficiency of an HTTP server.  In fact, there is ample evidence to the
>contrary.  Statelessness costs us in CPU cycles, server memory, packets,
>and delay.

But it fairly distributes limited resources such as IP connections and
memory. Adjust your definition of "efficiency" to include these.

>HTTP is stateless, as far as I can tell, because it was the simplest
>way to get something going, and the original designers didn't know
>any better.

And the original designer wanted a protocol that could be implemented
across a wide variety of platforms. In a distributed, anonymous, wide area
system, maintaining connections is not required. They're nice to have's,
but not required. HTTP has been successful for a number of reasons, and it
hasn't failed because it is sessionless. Think about that for a bit. If we
wanted session-oriented client-server apps, why not just implement a bunch
of X Windows-based applications, use X servers for the client apps and be
done with the whole mess?

--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
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 13:04:18 UTC