Re: TCP rate control?

Keith McCloghrie (
7 Mar 88 09:09:00 PST


Your comments to Van state :

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

Your analysis of steady-state 50% packet loss, does not take into
account the retranamission timeout and backoff, ie. each packet
dropped by the net causes the next packet (on the dropped packet's
TCP connection) to be a retransmission which is inserted into the
network at a later time than it would have been if the original
packet had gotten through and been acked. Also, the returning
acks are themselves subject to be queued/dropped in the gateways.

But, I agree with the conclusion you are drawing : that the network
has a finite amount of buffering (say N packets), and so once there
are more than N active TCP connections, it is impossible to reach
the steady-state where one packet per connection is buffered in the
net; in this situation the network has only one way to compensate
which is to drop packets; and without a rate-based control, the senders
have no way to reduce their offered load below the one packet per
active connection.

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



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