hope by hope choke packets

At high speeds or over long distances, sending a choke packet to the source hosts does not
work well because the reaction is so slow. Consider, for example, a host in San Francisco
(router A in Fig. 5-28) that is sending traffic to a host in New York (router D in Fig. 5-28) at
155 Mbps. If the New York host begins to run out of buffers, it will take about 30 msec for a
choke packet to get back to San Francisco to tell it to slow down. The choke packet
propagation is shown as the second, third, and fourth steps in Fig. 5-28(a). In those 30 msec,
another 4.6 megabits will have been sent. Even if the host in San Francisco completely shuts
down immediately, the 4.6 megabits in the pipe will continue to pour in and have to be dealt
with. Only in the seventh diagram in Fig. 5-28(a) will the New York router notice a slower flow
An alternative approach is to have the choke packet take effect at every hop it passes through,
as shown in the sequence of Fig. 5-28(b).

fig 5-28

 Here, as soon as the choke packet reaches F, F is
required to reduce the flow to D. Doing so will require F to devote more buffers to the flow,
since the source is still sending away at full blast, but it gives D immediate relief, like a
headache remedy in a television commercial. In the next step, the choke packet reaches E,
which tells E to reduce the flow to F. This action puts a greater demand on E's buffers but
gives F immediate relief. Finally, the choke packet reaches A and the flow genuinely slows
down.
The net effect of this hop-by-hop scheme is to provide quick relief at the point of congestion at
the price of using up more buffers upstream. In this way, congestion can be nipped in the bud
without losing any packets. The idea is discussed in detail and simulation results are given in
(Mishra and Kanakia, 1992).