choke packets

The previous congestion control algorithm is fairly subtle. It uses a roundabout means to tell
the source to slow down. Why not just tell it directly? In this approach, the router sends a
choke packet back to the source host, giving it the destination found in the packet. The
296
original packet is tagged (a header bit is turned on) so that it will not generate any more choke
packets farther along the path and is then forwarded in the usual way.
When the source host gets the choke packet, it is required to reduce the traffic sent to the
specified destination by X percent. Since other packets aimed at the same destination are
probably already under way and will generate yet more choke packets, the host should ignore
choke packets referring to that destination for a fixed time interval. After that period has
expired, the host listens for more choke packets for another interval. If one arrives, the line is
still congested, so the host reduces the flow still more and begins ignoring choke packets
again. If no choke packets arrive during the listening period, the host may increase the flow
again. The feedback implicit in this protocol can help prevent congestion yet not throttle any
flow unless trouble occurs.
Hosts can reduce traffic by adjusting their policy parameters, for example, their window size.
Typically, the first choke packet causes the data rate to be reduced to 0.50 of its previous rate,
the next one causes a reduction to 0.25, and so on. Increases are done in smaller increments
to prevent congestion from reoccurring quickly.
Several variations on this congestion control algorithm have been proposed. For one, the
routers can maintain several thresholds. Depending on which threshold has been crossed, the
choke packet can contain a mild warning, a stern warning, or an ultimatum.
Another variation is to use queue lengths or buffer utilization instead of line utilization as the
trigger signal. The same exponential weighting can be used with this metric as with u, of
course.