Dan,
[you wrote:]
>I agree that acking every packet gets the window open faster and that is
>good, but we should check with the asymmetric folks and see if this causes
>any problems in the return path.
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 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.
* 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
(617) 466-4142
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:44 EST