Subject: Re: status of T/TCP

From: [email-masked] (Jim Gettys)
Date: Wed, 16 Sep 1998 10:29:14 -0700

> Sender: [email-masked]
> From: [email-masked]
> Date: Fri, 4 Sep 1998 09:44:58 -0700
> To: [email-masked], [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> Subject: Re: status of T/TCP
> -----
>   *>
>   *> Furthermore, the case that T/TCP was originally designed for (HTTP)
>   *> has been more or less resolved by changing the application layer
> 
> According to Jim Gettys, this is an hypothesis which has not been
> proven and may be open some doubt.  I have been looking for resources
> (read "graduate student") to run a test, but perhaps someone else
> will do it.  Jim has a test scenario.
> 
> Bob Braden
> 
>

I suppose I should watch this list more often, but life's been
a bit busy.

I've always been a fan of T/TCP (if the problems that have been raised
can be resolved).

There are several reasons why:
	1) initial latency is too high. RTT's matter.  Much of the work
	in HTTP/1.1 is to allow pipelining, to reduce the number of RTT's
	required for operation; but the TCP open is one I can't get around.
	2) the distribution of traffic in the Web is not what you might think.
	Some of it is quite "trasaction oriented" in nature.
	3) HTTP/1.1, when implemented well, can greatly reduce (in terms
	of # of packets) the length of a packet train of a TCP connection).
	4) Style sheets will change the content over the next few years.

Lets look at these separately:

First: Initial connection latency.

Some people blithly wave their hands at the savings in latency on connection
open...

I do not; the Web is an interactive application, which is currently
most used over high latency paths (28.8 modems are the bulk of the
world out there, so 170ms is optimistically the best you ever see,
even for local documents). The RTT between MIT and the main AltaVista
site, for example, is around 80 milliseconds as I measure it this instant;
any/all of these times are multiples of human perceptible delay.

Wireless networks (GSM, etc) look to be in the 800ms range.

So right there, I immediately see lots of good reasons to save round trips
at connection open.  These are delays that immediately impact human
percieved performance.

Second: transactional behavior.

The patterns of of access to a web server is a complex function. But a 
fair fraction of this traffic (due to extensive client caching) is a single 
HTTP request followed by a single response, even on pages which are 
graphically complex.  I'll as our Web characterization group to try to 
get a better pointer to data showing what this distribution looks like. 
And commonly, in the cases that are not transactional in nature, you want 
behavior that devolves to normal TCP.  You can't predict in advance what 
behavior is likely.

Another common idiom I expect to see as HTTP/1.1 is deployed and implemented 
well (not clear current implementations typically do this, though) is 
an initial handshake request/response, followed by a second (the cache 
validation case) request/response piplines, which would be one or more
back to back packets and similar behavior from the server.  If everything
is cached, you'll get just a few packets of payload in each direction before
the connection goes idle (waiting for the next user click that may never
come).

Note that our SIGCOM paper does not model this often transactional
behavior seen in the Web; please don't believe that our Microscape site
bears much resemblance to reality (it is about a factor of 2 more
complex than a number of fancy corporate home pages).

Third: 

HTTP/1.1, implemented well, can greatly reduce (in terms of # of packets) 
the length of a packet train of a TCP connection). This will result in 
more of the traffic looking "transactional" in nature (while increasing, 
maybe doubling, the mean size of packets).

See our SIGCOM paper of a year ago.

Fourth:

Roughly as HTTP/1.1 rolls out, stylesheets are also deploying.  As our 
SIGCOM paper showes, it will have a possibly great impact on most Web 
surfing. This can significantly change the nature of the content.  There 
are two possibilities:
	1) people will exploit style sheets to improve 
	interactive feel.  This will shorten the length of a transaction
	to a server, in some cases, pretty dramatically, by getting rid
	of most "junk GIF's", replacing it with stylesheets (which are
	more compact to begin with, and	can be further compressed 
	greatly with deflate compression).
	2) Web site designers will use the fact that more useful
	content can be sent in the same amount of time to put more junk on
	a web page.  I have heard it asserted that web site designers design
	to human tolerance time, rather than speed.
If 1) is true, we'll see very different traffic, more transactional in 
nature.  If 2) is true, things won't change so much.  I don't know
which is going to happen; most likely a combination.

See our SIGCOM paper (and other tidbits) for some of the background, which 
can be found at: http://www.w3.org/Protocols/HTTP/Performance/

So I was, and still am, a fan of T/TCP.  I believe that HTTP/1.1 does NOT
reduce the need for it, for the reasons given. I pose to this list: can it be
fixed?  If it can be fixed, I think it is good stuff.
				- Jim Gettys

---

From: Craig Partridge <[email-masked]>
Date: Wed, 16 Sep 1998 10:45:44 -0700

>any/all of these times are multiples of human perceptible delay.

Jim:

Do you have good human factors studies on this topic?

Last time I went into the human factors literature (c. 1993) I discovered
that the best work in the field indicated:

    * round-trip delays of 600ms were generally quite acceptable

    * that round-trip delays of 300ms were almost always acceptable

Now these studies are from the 1960s and involve voice.  Further, the
authors of one of the studies (who was still doing work 30 years later)
warned me that people appear to get trained to lower delays (as one
improves one's network, one increases expectations).

But has someone done the careful study for the Web?  

Craig

PS: I'd characterize the study as the following -- try to simulate infinite
bandwidth [i.e. load data from local memory or, if one must, a fast file
system] and experiment with varying delays between mouse click and when
a page actually displays.  Allow users to click on a button to ask for
faster response when they are dissatisfied.  (This roughly matches the
old experiments, and avoids problems of technology limitations -- which
bedeviled a lot of the telephone delay studies -- lots of folks thought
they were measuring human response to delay only to discover they were
measuring human response to echo-canceller failures).

---

From: "Perry E. Metzger" <[email-masked]>
Date: Wed, 16 Sep 1998 14:38:06 -0400

> I've always been a fan of T/TCP (if the problems that have been raised

I don't really see how they can. Although some people seem to have
derided Charles' draft, I think the security issues are real. It is
far harder to bring down a TCP based server than a T/TCP based
one. The three way handshake is what saves a TCP based host -- you
have to be in two-way communication to attack a host (you can't spoof
sequence numbers provided you do something like RFC 1948
stuff). T/TCP, for all its charms, can't stop you from being attacked
with forged packets precisely because it will never require a three
way handshake.

Is this such a big deal, though? I have a fast link, and rarely notice
or care about the initial handshake issue on my web
browsing. Certainly the DNS lookups that have to be done swamp any
benefit I'll get from T/TCP. Is another 60 or 100ms such a big deal?

The problem with HTTP used to be the floods of tiny connections it
induced and what they did to the network. Now that we have that
problem licked with HTTP 1.1, the rest seems to be cosmetic, and as
I've noted, that cosmetic issue seems almost lost in the noise of
other things.

Perry

---

From: [email-masked] (Jim Gettys)
Date: Wed, 16 Sep 1998 11:52:40 -0700

> From: Craig Partridge <[email-masked]>
> Date: Wed, 16 Sep 1998 10:45:44 -0700
> To: [email-masked] (Jim Gettys)
> Cc: [email-masked], [email-masked], [email-masked], [email-masked],
>         [email-masked], [email-masked]

I don't have good research at my hands to point you to.

Acceptable of course, depends on the applicatation; it may not be a human
on the other end.

I have a bit of "first hand" experience in the area due to my previous life:

30 milliseconds is roughly the limit of human perception; anything
faster than this is "instantaneous".  This is true for refresh
on a TV screen, or rubberbanding a mouse (my own experimental experience
is once X mouse tracking reached 30HZ, the rubber band "felt" attached
to the mouse).

I don't know about you, but I want things "instantly" on my screen
after I click.   My performance goal is always therefore in the 50-30
millisecond range.

Note that speed of light (in glass) becomes an issue in the Internet, 
at the best of times; taking this number and multiplying by a factor of 
two easily gets up to the hundreds of milliseconds of even the very old 
data you quote above. 2X the 82 milliseconds between me and AltaVista 
becomes 160ms. More commonly, with 28.8 modems, the RTT is in the 170ms 
range, to the first hop; 2X is then 340ms, which even by your number is 
becoming an issue.   Add these two, and you get something in the 500ms
range. 

Another example: my machine at MIT to Inria's web server (in France): 
RTT is ~125 milliseconds.  (And we have our own line to Inria) 2X this 
is 250 milliseconds.  If I were at home on my dialup line, I bet I'd measure 
an RTT of around 300milliseconds (170 + 125).  2X this is 600 milliseconds.

I hope this demonstrates that, even given the "acceptable" delays of 300-600
milliseconds you quote that it is pretty trivial to burn this time up
in today's internet (and tomorrow's too).  I personally believe that
"fast enough" is considerably less than your numbers.  

So I'd like to take the 2X down to 1X of the RTT for the initial latency. 

And I don't want to use my ENTIRE latency budget for getting things "fast 
enough" on round trips that aren't necessary.  How about time to do something 
useful at the server end?  Or to transfer bytes over the wire for some 
real content so that something appears on my screen. Latency is additive; 
and you don't ever get it back.

One alternative, of course, is to always have a web proxy up stream
of you, with a connection open to your browser to get back the RTT over
the slowest hop; but I'd like to get it back everywhere.
				- Jim