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

[Jacob Heitz <[e-mail]>]

Peter Warren wrote:
> This may be somewhat tangential, but it seemed a good opportunity to let
> you and the list know about the results of some analysis I've been doing on
> Web downloads over a (relatively) highly asymmetric ADSL link (1.5Mbps
> forward channel, 64Kbps return).
> 
> It is true that ACKing every packet creates more return traffic and may
> thus slow things down: I won't deal with that issue here. Rather, I've
> discovered something rather alarming for the ACK-every-other-packet case
> over this asymmetric link. (Perhaps this has already been seen and
> discussed...)
> 
> 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.

The final packet should include the FIN, which should get ACKed
without delay.

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

If you figure out how to do this in Win95/98, please let me know how.

> * The ACK delays can combine with the return channel queuing delays to
> exceed the Web server's retransmission timeout (RTO). Result: server times
> out, retransmits packet it *thinks* is lost, drops into slow-start phase.
> (In my example download of a single 18-part Web page, this happened *7*
> times! This makes a bad situation worse, so that even my narrow, 64Kbps
> return channel is not fully utilized: the average return channel throughput
> for this example was only 54 Kbps!)
> 
> It may be that ACKing every packet over this link would be even worse - I
> haven't tested that (I'm using Win95 client- don't know if there's a way to
> change that option). But I thought I should report this interaction, lest
> we conclude that ACKing every other packet is always best for asymmetric
> links. More testing should be done on this.
> 
> I have packet flow diagrams, queue level plots, and bitrate plots which
> illustrate this behavior, derived from packet traces of a Web page download
> across a controlled network. They show the same page downloaded over the
> 1.5 Mbps/64Kbps ADSL link as well as a 4Mbps/384Kbps link. The pathology
> related to the delayed ACKs is clear in the former, but is alleviated in
> the latter, due to the reduced asymmetry.
> 
> I can make these graphs available to anyone interested. (A color printer,
> pref. hi-res, is best, as each TCP connection is assigned a different
> color. However, each connection's packet flow is then separated out onto a
> separate page after the combined flow plot, so B&W is okay, too.)
> 
> = Peter
> 
> Peter G. Warren
> Performance Analysis Group
> Advanced Systems Laboratory
> GTE Laboratories
> 40 Sylvan Rd., Waltham, MA 02254
> [phone]

-- 
/*******************************************************************\
* Jacob Heitz         Tel:[phone]/Fax:2859                     *
* Ascend->Engineering->Software->Alameda   mailto:[e-mail] *
\*******************************************************************/