[e2e] TCP in outer space

[Fred Baker]

you miss my point. Yes, getting rid of RTTs is useful. But, let's take the 
shortest case I can come up with, which by the way happens to be the 
median. A while back, I collected a set of traces from http sessions I 
originated, for the purpose of understanding their characteristics. This is 
the median among them:

---------------------------------------------------------------------
13:16:11.043507 fred-hm-dhcp1.cisco.com.2236 > 209.132.212.174.80:
         S 584460:584460(0) win 8192 <mss 1460> (DF) [tos 0x10] (ttl 128, 
id 5890)
13:16:11.105452 209.132.212.174.80 > fred-hm-dhcp1.cisco.com.2236:
         S 1400895366:1400895366(0) ack 584461 win 33580 <mss 1460> (DF) 
(ttl 236, id 39079)
---------------------------------------------------------------------
13:16:11.105628 fred-hm-dhcp1.cisco.com.2236 > 209.132.212.174.80:
         . ack 1 win 8760 (DF) [tos 0x10] (ttl 128, id 6402)
13:16:11.107306 fred-hm-dhcp1.cisco.com.2236 > 209.132.212.174.80:
         P 1:478(477) ack 1 win 8760 (DF) [tos 0x10] (ttl 128, id 6658)
13:16:11.195499 209.132.212.174.80 > fred-hm-dhcp1.cisco.com.2236:
         . ack 478 win 33580 (DF) (ttl 236, id 39080)
---------------------------------------------------------------------
13:16:11.206240 209.132.212.174.80 > fred-hm-dhcp1.cisco.com.2236:
         P 1:118(117) ack 478 win 33580 (DF) (ttl 236, id 39081)
13:16:11.360045 fred-hm-dhcp1.cisco.com.2236 > 209.132.212.174.80:
         . ack 118 win 8643 (DF) [tos 0x10] (ttl 128, id 6914)
---------------------------------------------------------------------
13:16:11.496928 209.132.212.174.80 > fred-hm-dhcp1.cisco.com.2236:
         FP 118:1120(1002) ack 478 win 33580 (DF) (ttl 236, id 39082)
13:16:11.500262 fred-hm-dhcp1.cisco.com.2236 > 209.132.212.174.80:
         . ack 1121 win 7641 (DF) [tos 0x10] (ttl 128, id 7170)
---------------------------------------------------------------------
13:16:11.582104 fred-hm-dhcp1.cisco.com.2236 > 209.132.212.174.80:
         P 478:820(342) ack 1121 win 7641 (DF) [tos 0x10] (ttl 128, id 8706)
13:16:11.583767 fred-hm-dhcp1.cisco.com.2236 > 209.132.212.174.80:
         F 820:820(0) ack 1121 win 7641 (DF) [tos 0x10] (ttl 128, id 8962)
13:16:11.658022 209.132.212.174.80 > fred-hm-dhcp1.cisco.com.2236:
         R 1400896487:1400896487(0) win 33580 (DF) (ttl 236, id 39086)
13:16:11.661120 209.132.212.174.80 > fred-hm-dhcp1.cisco.com.2236:
         R 1400896487:1400896487(0) win 0 (DF) [tos 0x10] (ttl 92, id 39087)
---------------------------------------------------------------------

This shows a Syn/Syn-Ack pair as the first round trip, the transmission and 
acknowledgement of an HTTP GET as the second round trip, the response to 
that GET as the third round trip, and closing the session as the fourth 
round trip.

My comment was that changing four round trips into three is a change, but 
T/TCP doesn't change four into one, or even three into one. It might make 
the three be one and a half, if the application assists, but I see in a 
number of traces the application taking ten seconds or more to reply to the 
GET with data. I would expect that it would send the SYN-ACK back and 
follow it with data, not piggy-back the data into the SYN-ACK.

You also see in the above what I observed about the third step in the 
handshake. It doesn't occupy time.



At 03:59 PM 4/12/2001 -0700, Jim Gettys wrote:

> > Sender: end2end-interest-admin at postel.org
> > From: Fred Baker <fred at cisco.com>
> > Subject: Re: [e2e] TCP in outer space
> > -----
>material elided...
> >
> > But it really only gets rid of one round trip in a session that generally
> > requires at least three or four, which seems like a pretty small
> > optimization. An HTTP request for a web page could carry the HTTP GET data
> > on the SYN packet, and the data coming in reply could be on the SYN-ACK,
> > but if there is any loss at all in the network you are going to see some
> > level of retransmission anyway, and the mean web page (10K, I'm told) is
> > still going to take several segments and at least a couple of round trips.
> > Email is a much deeper kettle of fish; sure, you could carry the EHELO on
> > the SYN packet, but how much would that help with the succession of "From",
> > "To", "Data", and "end of data" messages that SMTP carries?
> >
>
>You are falling for the classic mean versus median disease....
>
>The mean and median are very different.
>
>In fact, things tend to be bimodal in the web: small HTML documents,
>and then large images or other transfers.
>
>So you'd get, me thinks, good benefit from all this.
>
>Not to mention the reduction in human perceptible latency: you
>can't figure out what to fetch until you have the HTML in your hands,
>which will tend to be the short initial transaction....
>                                 - Jim
>
>--
>Jim Gettys
>Technology and Corporate Development
>Compaq Computer Corporation
>jg at pa.dec.com