Re: comments on draft-ietf-tcpsat-stand-mech-04.txt

[Peter Warren <[e-mail]>]

>Peter Warren wrote:
...
>> SUMMARY:
>> There is a pathological interaction among the ACK delays, the multi-part
>> structure of Web pages, and a highly asymmetric link, as follows:
>> * Each object in a multipart Web page may fit into an odd number of packets
>> with about .5 probability. If odd, the last packet of that object causes
>> the receiver to set its ACK timer and wait for next packet which won't
>> arrive. Timer must time out before ACK is sent.

[Jacob Heitz wrote:]
>The final packet should include the FIN, which should get ACKed
>without delay.

I should have mentioned that these connections were persistent ones; there
is no FIN at the end of each Web object transfer. Note that both major
browsers since at least v. 3.0, and all recent major Web servers, support
and use the Keep-alive persistent connection feature introduced by
Netscape. This is not new with HTTP 1.1: they have modified it somewhat for
1.1, but persistent connections are the most common type around today.

>> *  The multi-part page requires significantly more upstream traffic than a
>> bulk transfer (due to GET requests for each object), rapidly filling the
>> modem's return channel queue and thus increasing delay further.
>
>Try decreasing the tcp window size. 4k should be enough.

This might reduce the delayed ACK -> RTO exceeded problem I described, but
is somewhat roundabout, and requires more user tweaking than we should
expect. It requires the user to:
(1) know what the asymmetry of his link is;
(2) know that his performance problem is due to the effect I described,
rather than being due to a *too small* advertized TCP window, which is more
often the case (on less asymmetric links); and
(3) know how, and how much, to tweak his advertized window.

>Also your MSS should be LESS THAN 1460. Between 512 and 1300 should do.
>Only when you know for sure that your performance won't suffer, should
>you increase those numbers.

Why would reducing the MSS improve the situation? In highly asymmetric
links, we want to *maximize* the downstream data transfer, not reduce it,
since it is the *return* channel that is the bottleneck in this case.
(Incidentally, by "highly asymmetric" I mean where the forward:reverse
bandwidth asymmetry exceeds the data asymmetry, i.e., ratio of forward bits
to reverse bits. For example,  with MSS=1460, ACKing every 2 packets: bulk
FTP traffic is commonly about 40:1, whereas HTTP traffic overall averages
about 10:1 (from my measurements of large traffic traces, and from others'
studies). In my example ADSL link, 1.5Mbps/64Kbps, the bandwidth ratio is
over 23:1, which exceeds the bit ratio of my test Web page, which is
actually 8.5:1.) Reducing the MSS below 1460 will reduce the bit ratio of
this data even further, thus increasing the asymmetry mismatch between data
and link.

= Peter

Peter G. Warren
Performance Analysis Group
Advanced Systems Laboratory
GTE Laboratories
40 Sylvan Rd., Waltham, MA 02254
[phone]