=head1 Myths About Congestion Management in High-speed Networks
R. Jain, Digital Equipment, 1992

B<Summary.>
With the increasing heterogeneity of network links (and the resulting need 
to support a range of link speeds), congestion management has become a hot 
issue. The author lists the pros and cons of different congestion control 
and avoidance ideas. Old myths that have proven false over time
include the ideas that congestion is caused by:
=over 4
=item *
lack of link speed
=item *
lack of CPU power
=item *
lack of memory
=back
and that with the advent of cheap links, CPU and/or memory congestion would 
become a non-problem. 

New myths include:

=over 4

=item *

B<traffic will be video like: steady and predictable.> Future networks will 
carry a variety of applications: voice, audio, file transfer, email. The 
applications will vary in terms of loss-sensitivity and delay-sensitivity. 
I<Implication: congestion management schemes need to be> 
I<designed to cater to varying needs of different applications. >

=item * 

B<because of the above, prior reservation will be required in place of >
B<datagram service.>
Prior reservation may be useful for long, steady sessions but will reek for 
short or bursty sessions due to overhead and wasted bandwidth. 

=item *

B<open-loop scheme will replace closed-loop feedback due to lg quantities of >
B<data being>
B<sent.> Open loop schemes are not good for long-term overload & will have 
to be supplemented with closed-loop schemes (or modified). 

=item *

B<rate control should be used in place of window schemes> See above. 

=item *

B<source-based congestion control which require feedback to src too slow; >
B<router based schemes will be necessary.> Source-based schemes will be 
necessary where router processing speed important or for long-duration 
overload. 

=item *

B<backpressure will be ideal for congestion control.> Backpressure okay for 
short-lived overload but can lead to standstill if congestion long-lived. 

=item *

B<a single congestion management scheme will be sufficient.> There will be 
overload of all durations and applications with different sensitivities, so 
one scheme will not be sufficient. 

=back

=head1 More Detail

B<Window-based flow control vs. Rate-based.> 
Window: 
=over 4
=item * (-)
was good for when memory was a bottleneck; memory isn't a bottleneck now; 
instead we're rate-limited
=item * (-)
can create bursty traffic
=item * (-)
some traffic will require a guarantee
=back
Rate based:
=over 4
=item * (-)
require the I<burst size> and the I<interburst interval>; most analysis of 
rate-based schemes ignore this.
=item * (-)
hop-by-hop schemes; end nodes cannot enforce scheme alone; this point 
sometimes ignored
=item * (-)
can introduce significant packet delay when net close to saturated (>60%); 
B< to fix this, >
B<rate-based must become window-based after some point>; ex: supplement rate 
w/large window limit. 
=back

B<Open-loop of Feedback.> "Closed-loop" means that a congested resource 
sends feedback to the source which then adjusts the sending level. Some 
argue that because closed-loop
congestion controls require that the feedback travel back to the source, 
they take too long. The
alternative are open-loop schemes such as router-based, backpressure and 
prior reservation. The author examines these 3 schemes. 

B<Router-based vs. Source-based.> Rate-based control required for fairness & 
for rate guarantees. Source-based required for long periods of congestion. 
If router processing speed important, source-based is the way to go. If 
source disobedience is a problem, router-based is preferred. 

Source-based:
=over 4
=item *
Examples: DECbit, slow-start
=item (-)
delay involved; session could be over before traffic reduced/increased
=item (-)
source may not cooperate
=item (-)
additional packets may be injected
=item (+) 
can achieve efficiency
=item (-)
may not be fair; use network-layer to do feedback & transport-layer to do 
control; different network layer implementation may decrease/increase 
traffic at different rates. 
=back

Router-based:
=over 4
=item *
Examples: random-drop, fair-queueing, backpressure
=item (+)
necessary to achieve fairness
=item (-)
B<introduce complexity in routers> ; this is bad since high-speed routers 
only have a certain number of instructions per packet to spend before their 
bandwidth usage decreases.
=item (-)
unless sources scale traffic, congestion will continue -> must give sources 
feedback somehow.
(isn't this the same as sources misbehaving in source-based scheme?)
=back

B<Backpressure.>  Routers send an X-off when congested and stop accepting 
packets. Send an X-on when ready to accept packets. Datalink-level mechanism.
 Good for short-lived congestion (same as increasing # of buffers); can lead 
to standstill if long-lived. Can be very unfair: sources not even I<using> 
the congested node can be affected. Upshot: backpressure can be used for 
short-lived congestion but must be supplemented w/transport level mechanisms 
when overload is long-lived. 

B<Prior-reservation vs. Walk-in.> Reservation will be ideal for steady, long 
sessions but bad for bursty sessions. Since we will see traffic of all types,
 networks should have both types of  resource management schemes. 

Prior-reservation:
=over 4
=item +
good if app needs a bandwidth or delay guarantees
=item + 
makes resource mgt easy
=item -
B<any bw allocated but not used is wasted>
=item -
bad for unpredictable, bursty traffic
=item -
setup overhead involved; not justified for short-lived sessions
=back
Walk-in:
=over 4
=item -
resource mgt hard
=item +
ideal for highly dynamic sessions
=back

B<One Scheme vs. Many.> Rule of thumb: the longer the duration of the 
overload, the higher the layer at which control should be exercised. "Since 
every net can have overloads of all durations, every net needs a combination 
of controls at various levels. No one scheme can solve all congestion 
problems." 

Multiple competing schemes at one level make for unfairness.