[Phil Karn wrote:]
>One problem we do have with the existing TCP congestion control
>mechanism is that the sender will increase its congestion window all
>the way up to the offered window as long as no packets are lost, even
>if all those extra packets just pile up in a queue at the bottleneck
>router. Various ad-hoc methods involving real-time bandwidth/delay
>measurements have been tried to solve this problem, but they don't
>seem to work really well because of measurement noise (competing
>traffic, route changes, etc).
It seems to me that, since the sender uses incoming ACKs to clock out its
data packets, the rate of ACKs from the receiver will act as a break on the
data steam, no matter how big the effective TCP window is.
I have seen this in operation during a bulk transfer over an ADSL link
(1.5Mbps/64Kbps) where the receiver is set to advertize a 24KByte window
and the RTT is about 45 msec. In this case, the downstream ADSL modem
buffer is the bottleneck. (Here, the window is set wide enough to allow a
downstream rate of over 4Mbps, so the limiting factor is the downstream
ADSL link rate of 1.5Mbps). By looking at packet arrival times at the ADSL
modem vs. those at the receiver, I see that the downstream ADSL modem's
queue starts to fill up fairly quickly. However, at a certain point (one
second into the transfer), the increase stops, and the queue level drops
gradually at a constant rate until the end of the transfer. And I've
verified that *no* packets have been dropped, in either direction, and
there are no retransmissions nor duplicate ACKs. So the server did not
enter congestion avoidance nor slow-start at any point. I infer that it is
using the rate of returning ACKs to adjust its data rate. Am I overlooking
anything?
If this is true, then it seems it would do no harm for the receiver to
advertize the largest window possible, by default, rather than the paultry
8760 bytes we see commonly. I fully agree with Phil's comment:
> The receiver should not have
>to artificially limit its window because of network considerations --
>that's the function of congestion control on the transmitting end.
= 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:38 EST