Subject: Re: status of T/TCP

From: Joe Touch <[email-masked]>
Date: Wed, 16 Sep 1998 12:55:51 -0700 (PDT)

> From [email-masked] Wed Sep 16 11:56:46 1998
> Date: Wed, 16 Sep 1998 11:52:40 -0700
> From: [email-masked] (Jim Gettys)
> To: Craig Partridge <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked], [email-masked],
>         [email-masked], [email-masked], [email-masked]
> Subject: Re: status of T/TCP
> 
> 
> 
> > 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]
> > Subject: Re: status of T/TCP
> > -----
...
> > 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
> > 
...
> > But has someone done the careful study for the Web? 
> > 
> 
> 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).

30ms is related to motion video; anything more instant than that
is lost in the frame refresh, which is lost in the persistence of vision.

Tolerable delays depend on whether the brain is otherwise busy,
which opens that loop up for other tasks. Clicking on a single light
is around 100ms, multi-colored (click if it's red, where the light
has to both go ON and go RED) takes ~300ms, and on up for more 
complicated tasks.

If the response takes less time than the brain's processing, you're fine.

> 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.

This is from click to render; includes OS delays, request/response,
and the rendering on the local end, BTW.

> 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. 

BTW - some of this latency is the modem being too clever about
buffering and compressing. Shutting it down might decrease the latency.
Another part is the use of large packets - it might be better to have
smaller packets with additional overhead. The overall transaction latency
would increase, but the time to first portion of response would decrease.

> 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.  

BTW2 - why are you doubling the RTT? 

I have a chart of the BW required to send a web page in 100 ms, 
counting only transmission delay, at:

	http://www.isi.edu/lowlat/

> 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

Another is to send things ahead of time; we do this in 'background' 
to reduce the response latency. In the end, source anticipation is 
the only way to reduce the latency (and it does 'get it back', in 
a sense)

Joe

---

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

> From: Joe Touch <[email-masked]>
> Date: Wed, 16 Sep 1998 12:55:51 -0700 (PDT)
> To: [email-masked], [email-masked]

Sure.  The right thing to do (if HTTP did not have such verbose request
response headers) would be to turn off all modem compression, and
send the HTML content compressed.  Deflate compression does very
much better than anything in modems.

> BTW2 - why are you doubling the RTT?

The difference between the two round trip times to open a conventional
TCP connection vs. T/TCP.  Conventional TCP takes two...  I want to
get one of them back...

>         http://www.isi.edu/lowlat/

Yup.  This is why changing the content is important: stylesheets and
good data compression to reduce the number of bits transferred is also
essential to help interactivity of the Web. If I get more useful
information / bit transferred, it can make a tremendous difference.
Simple data compression can get you a factor of three or more on
the HTML, XML, or text transferred; stylesheets can get rid of large numbers
of unneeded GIF's, and can similarly be compressed.  For many/most
web pages, there is probably a factor of three or more to be had; for
those currently guilty of "GIF abuse" due to HTML's deficiency without
stylesheets, the improvement may be another factor of two or more (depending
on how agressive people are at using style sheets rather than GIF's
for common things.

> the only way to reduce the latency (and it does 'get it back', in

How do you anticipate a new user's first visit to a web site (without
burning infinite bandwidth?

In any case, I think this discussion has shown that the latency is
a real issue for interactive applications, given the Internet, whether
the requirement is 30 or 300 milliseconds...  

I can fix some of the problems at the applications layer, and you can 
fix some of it in the network protocol (or do you want us to invent our 
own protocol? :-) ). Our fixes in the web currenly beginning deployment 
include pipelining, stylesheets, and transfer coding (deflate compression). 
Fully exploited, these can make a major difference for the interactive 
behavior of the applications (making your numbers at the URL above obsolete). 

I still want T/TCP for the additional round trip I'd get back, along with 
all the other reasons I stated originally.

Wouldn't matter so much if we weren't working hard at the application 
level, but we are; I predict that what wasn't noticable in the past will 
start becoming a significant part of the latency budget.

In any case, I don't think this conversation should continue here,
as it has little bearing on general TCP implementation.
				- Jim