TCP rate control?


Phil Karn (karn@ka9q.bellcore.com)
Sun, 6 Mar 88 01:44:18 EST


Van,

It was fun to talk to you in San Diego. Now I'm sorry I didn't go to
the earlier IETF meetings.

Many thanks for the patient explanations of your TCP congestion control
techniques; I'm continuing to implement them in my own TCP. However, I
still think something further may still be required, at least on the
(admittedly pathological) packet radio links I use.

My reasoning goes as follows.

You never allow the congestion window to decrease below one MSS. You
argue that letting it go lower would increase header overhead, wasting
link (and network) bandwidth when it can least be spared. I agree.
However, this limits your ability to throttle the connection's bandwidth
further should even one MSS-sized packet per connection be too much.

To see this, consider the case of 10 simultaneous FTP/TCP transfers
taking place through a common bottleneck link. The gateway feeding this
link has only 5 packet buffers. Even if the ten TCPs have their
congestion windows permanently set to 1 packet, there will be room for
only half of their packets in the buffer queue at any one time, and
there will be a steady-state 50% packet loss. True, the link itself
will be efficiently utilized, but the upstream links will be carrying
lots of retransmissions. Even if these links aren't themselves
congested this seems undesirable.

Here's another way to look at the problem. Assume the link bandwidth is
10 packets/second. Then the maximum queuing delay that can be imposed
on the sending TCPs by the gateway is 5 packets / 10 packets/sec = 1/2
sec. Since the bandwidth required by any one TCP is the window size (1
packet in this case) divided by the round trip time (1/2 sec -- we'll
assume that the smaller acks encounter negligible delay) each of the ten
TCPs will still attempt to generate two packets per second, for a total
offered load of 20 packets per second. This is twice the link's
capacity, so half of the generated packets will be dropped.

So it seems that some sort of rate control timing is necessary. In
other words, if packets are still being lost even with a 1-packet
window, then the sending TCP should insert increasing amounts of delay
between incoming ACKs and outgoing data packets. I suppose there are
lots of ways this could be done (I'll probably have the retransmission
timer do double-duty) but as you point out it's important to adjust
the delays so as to produce linear changes in the offered load.

If I heard correctly, certain gateways on the Internet can only buffer
two packets at a time, so perhaps this scheme would help in places other
than my pathological 1200 baud packet radio channels.

Comments? Rebuttals? (I'd be happy if you proved me wrong so I could
avoid implementing this!)

Phil



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:41:30 GMT