myths
R. Jain, Digital Equipment, 1992
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:
- lack of link speed
- lack of CPU power
- lack of memory
and that with the advent of cheap links, CPU and/or memory congestion would .become a non-problem.
New myths include:
- 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.
Implication: congestion management schemes need to be
designed to cater to varying needs of different applications.
- *
because of the above, prior reservation will be required in place of
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.
- open-loop scheme will replace closed-loop feedback due to lg quantities of
data being
sent. Open loop schemes are not good for long-term overload & will have
to be supplemented with closed-loop schemes (or modified).
- rate control should be used in place of window schemes See above.
- source-based congestion control which require feedback to src too slow;
router based schemes will be necessary. Source-based schemes will be
necessary where router processing speed important or for long-duration
overload.
- backpressure will be ideal for congestion control. Backpressure okay for
short-lived overload but can lead to standstill if congestion long-lived.
- 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.
.
Window-based flow control vs. Rate-based.
Window:
- * (-)
was good for when memory was a bottleneck; memory isn't a bottleneck now;
instead we're rate-limited
- * (-)
can create bursty traffic
- * (-)
some traffic will require a guarantee
Rate based:.
- * (-)
require the burst size and the interburst interval; most analysis of
rate-based schemes ignore this.
- * (-)
hop-by-hop schemes; end nodes cannot enforce scheme alone; this point
sometimes ignored
- * (-)
can introduce significant packet delay when net close to saturated (>60%);
to fix this,
rate-based must become window-based after some point; ex: supplement rate
w/large window limit.
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.
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:
- Examples: DECbit, slow-start
-
(-)
delay involved; session could be over before traffic reduced/increased
-
(-)
source may not cooperate
-
(-)
additional packets may be injected
- (+)
can achieve efficiency
-
(-)
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.
Router-based:.
- Examples: random-drop, fair-queueing, backpressure
-
(+)
necessary to achieve fairness
-
(-)
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.
-
(-)
unless sources scale traffic, congestion will continue -> must give sources
feedback somehow.
(isn't this the same as sources misbehaving in source-based scheme?)
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 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.
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:
-
+
good if app needs a bandwidth or delay guarantees
- +
makes resource mgt easy
-
-
any bw allocated but not used is wasted
-
-
bad for unpredictable, bursty traffic
-
-
setup overhead involved; not justified for short-lived sessions
Walk-in:.
-
-
resource mgt hard
-
+
ideal for highly dynamic sessions
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.