Congestion Control

1
Congestion Control

• Andreas Pitsillides
• University of Cyprus

2
Congestion control problem

• growing demand of computer usage requires
• efficient ways of managing network traffic to
  avoid or limit congestion in cases where
  increases in bandwidth not desirable or possible.
  
• generally accepted that network congestion
  control problem remains critical issue and high
  priority,
• especially given growing size, demand, and speed
  (bandwidth) of increasingly integrated services
  network.
• One could argue that
• network congestion unlikely to disappear in near
  future.
• Furthermore congestion may become unmanageable
• unless effective, robust, and efficient methods
  for congestion control are developed.

3
Current scene

• despite vast research efforts, still no
  universally acceptable solutions
• control solutions for TCP transported traffic
• increasingly becoming ineffective,
• cannot easily scale up even with
• fixes (improved round trip time measurement,
  Slow-start and congestion avoidance, Fast
  retransmit, fast recovery algorithms, Improved
  congestion indication using delay (rather than
  loss) as feedback.
• new approaches (RED, ECN, MPLS)
• new architectures (diffserv, intserv,)

4
Current scene (cont.)

• non-TCP applications
• As demand for streaming applications increases,
  important to ensure can co-exist with current TCP
  
• streaming media should be subjected to similar
  rate controls as TCP traffic
• newly developed (also largely ad-hock) strategies
  are also not proven to be robust and effective
• examples include model based and equation based
  approaches.
• Even though based on a model, model is not
  dynamic, derived control strategy is ad-hock and
  not proven with regard to its properties.
• Asynchronous Transfer Mode (ATM)
• also witnessed similar approach, with performance
  of vast majority of congestion control schemes
  proposed for solution of Available Bit Rate
  (ABR) problem not proven analytically.

5
Why problem still not solved?

• In part, due to lack of structured approach, and
• lack of strong theoretical foundation in
  stabilising controlled systems,
• Most proposed schemes are developed using
  intuition and simple (ad-hock) non-linear
  designs.
• Using simulation, these simple schemes
  demonstrated to be robust in variety of
  scenarios.
• problem is that very little known why these
  methods work and very little explanation can be
  given when they fail.
• Since designed with significant non-linearities,
  based mostly on intuition (e.g. two-phaseslow
  start and congestion avoidancedynamic windows,
  binary feedback, )
• analysis of closed loop behaviour difficult, if
  at all possible, even for single control loop
  networks.

6
Why problem still not solved? (cont.)

• interaction of additional non-linear feedback
  loops can produce unexpected and erratic
  behaviour.
• Empirical evidence demonstrates poor performance
  and cyclic behaviour of the controlled TCP/IP
  Internet (also confirmed analytically).
• becomes worse
• as link speed increases (hence bandwidth-delay
  product, and thus feedback delay, increases)
• as demand on network for better quality of
  service increases.
• for WAN networks
• multifractal behaviour has been observed,
• suggested that this behaviourcascade effectmay
  be related to existing network controls.
• Clearly, more effective congestion control
  schemes are needed to prevent serious economic
  losses and possible "meltdown" of the Internet.

7
Two examples of existing disciplines with strong
theoretical foundation

• control systems theory
• rich experience in controlling complex systems,
• often concentrating (due to the difficulty) on
  single control loops to stabilise the whole
  system (by assuming if locally stable, then also
  globallysome theoretical foundation exists).
• traditionally linearising model to apply linear
  control systems theory ? new results in
  non-linear theory allow application
• Pricing theory
• has proven useful for stabilising complex
  interactions in human centred systems,
• aiming to balance supply and demand.
• Usually distributed algorithms, which through
  successive iterations reach stability

8
IDCC an example (with Petros Ioannou and L.
Rossides)

• Starting with a simple dynamic fluid flow model
• developed using packet flow conservation
  considerations and by matching the queue
  behaviour at equilibrium
• Design a non-linear adaptive robust controller
  (IDCC - integrated dynamic congestion controller)
  
• a specific problem formulation for handling
  multiple differentiated classes of traffic,
  operating at each output port of a switch is
  illustrated.
• following same spirit adopted by IETF Diff-Serv
  for Internet define three classes of aggregated
  behaviour.
• Premium, Ordinary, and Best Effort Traffic
  Services.
• analytical performance bounds derived, for
  provable controlled network behaviour.

9
Control concept
10
Dynamic model
For a packet buffer
For M/M/1 queue
11
Simulative comparison
12
Another dynamic fluid flow model
for TCP window
13
Developed Control strategy

• Premium Traffic Service (eq. 1, 2, 3)
• Ordinary Traffic Service (eq. 4)

14
Theoretical evaluation

• A1. Proof of stability of Premium Traffic control
  strategy
• Theorem A1. The control strategy described by the
  equations (1-3) guarantees that
• queue length is bounded
• allocated CapacityltServer Capacity
• queue length converges close to the reference
  value with time, with an error that depends on
  the rate of change of the traffic input rate.

15
Theoretical evaluation (cont.)

• A2. Proof of stability of the Ordinary Traffic
  control strategy
• Theorem A2. The control strategy given by
  equation (4) guarantees that
• queue length is bounded.
• When bandwidth becomes available the queue length
  approaches the reference value with time.

16
Simulative evaluation
17
Steady state and transient behavior
Switch 2 time evolution of Premium Traffic queue
length for a LAN and WAN for 140 load demand.
Note that as feedback information is local,
there is no deterioration in performance due to
increased WAN propagation delay.
Qureue length
Ref100
ref100
ref-50
18
Steady state and transient behavior (cont.)
Ref900
Ref600
Ref300
Switch 2 time evolution of Ordinary Traffic queue
length for (a) a LAN and (b) WAN for 140 load
demand. (control period varies between 32
celltimes?0.085 msec to 353 celltimes?0.94 msec)
19
Steady state and transient behavior (cont.)
Typical behaviour of the time evolution of the
common calculated allowed cell rate at Switch 2
for (a) LAN and (b) WAN.
20
Steady state and transient behavior (cont.)
Typical behavior of time evolution of
transmission rate of controlled sources using
Switch 2 for (a) LAN and (b) WAN configurations.
21
Network test configuration for demonstrating
fairness
3-hop traffic start transmitting at t0 the one
1-hop-a traffic at switch 0 is next started at
t0.2 the two 1-hop-b sources atswitch 1 are
started at t0.4 the three 1-hop-c sources are
started at t0.6
22
fairness - LAN
Allocation of bandwidth to Ordinary Sources for
LAN. All sources dynamically allocated their fair
share at all times.
23
fairness - WAN
Allocation of bandwidth to Ordinary Sources for
WAN. All sources dynamically allocated their fair
share at all times
24
fairness - WAN
Allocation of bandwidth to the Ordinary Sources
at Switch 2. Observe that the top 3 figures are
for local sources and the last one is for a 3 hop
source located about 12000 kms away from the
switch. All sources are allocated their fair
share
25
Behaviour of control

• Insensitivity of control to the value of the
  control update period
• 32 celltimes?0.085 msec to 353 celltimes?1 msec
• Robustness of control design constant to changing
  network conditions
• for diverse traffic demands ranging from 50-140
  and source location (feedback delays) up to about
  250 msec RTT, as well control periods ranging
  from 0.085 msec to 1 msec. For all simulations
  the behaviour of the network remains very well
  controlled, without any unacceptable degradation

26
IDCC properties

• provable stable and robust behaviour at each
  port,
• and by tightly controlling each output port,
  overall network performance expected to be
  tightly controlled.
• high utilisation with bounded delay and loss
  performance
• good steady state behaviour, with no observable
  oscillations
• good transient behaviour, i.e. fast rise and
  quick settling times
• Uses minimal information to control system and
  avoids additional measurements and noisy
  estimates
• Uses only one primary measure, namely queue
  length
• Does not require per connection state
  information, queuing, or servicing at the switch
• Does not require any state information about set
  of connections bottlenecked elsewhere in network
  (not even count)
• Computes Common Ordinary Traffic allowable
  transmission rate only once every Ts msec
  (control update period) thereby reducing
  processing overhead.
• controller fairly insensitive to value of Ts.

27
IDCC properties (cont.)

• Achieves max/min fairness in a natural way
  without additional computation or information
• can guarantee minimum agreeable service rate
  without additional computation
• works over wide range of network conditions, such
  as RTT (feedback) delays, traffic patterns, and
  controller control intervals, without change in
  control parameters
• works in integrated way with different services
  (e.g. Premium Traffic, Ordinary Traffic, Best
  Effort Traffic) without need for any explicit
  information about their traffic behaviour
• proposed control methodology and its performance
  is independent of size of queue reference values.
• network operator can be more or less aggressive
  and steer performance, in accordance with current
  network and user needs, using global
  consideration.
• Has simple implementation and low computational
  overhead
• features very small set of design constants,
• can be easily tuned from simple understanding of
  system behaviour

28
Conclusions for IDCC

• generic scheme for congestion control.
• uses integrated dynamic congestion control
  approach (IDCC).
• specific problem formulation for handling
  multiple differentiated classes of traffic,
  operating at each output port of a switch
  illustrated.
• derived from non-linear control theory using a
  fluid flow model.
• analytical performance bounds derived, for
  provable controlled network behaviour.
• divide traffic into three basic types of service,
  in same spirit as those adopted for Internet
  Diff-Serv i.e. Premium, Ordinary, and Best
  Effort.

29
Conclusions for IDCC (cont.)

• As shown earlier, proposed control algorithm
  possesses a number of important attributes
• works in integrated way with different services
• has simple implementation and low computational
  overhead,
• features a very small set of design constants
  that can be easily set (tuned) from simple
  understanding of system behaviour.
• These attributes make proposed control algorithm
  appealing for implementation in real, large-scale
  heterogeneous networks

30
further work for IDCC

• In this paper full explicit feedback was used in
  the simulations, signalled using RM cells in an
  ATM setting.
• challenging task is to investigate other explicit
  (e.g. single bit feedback as in ECN proposal for
  IP) and implicit (end-to-end) feedback and
  signalling schemes.
• A comparative analytic and simulative evaluation
  between the different feedback and signalling
  schemes is a topic for future research.

31
General Recommendations

• Advocate a structured and formal approach to
  designing congestion control systems
• could be from other fields with solid theoretical
  foundation, possibly drawn from stabilising
  (controlling) large scale, complex systems
• encourage collaboration with other disciplines
• Integrate with other control functions and study
  their interactions (e.e. with routing and CAC)
• A common simulative framework (CSF) and pilot
  test bed environment (e.g. ns 2 could be such a
  simulative test-bed)
• with well known and understood scenaria that test
  the properties of proposed algorithms
• e.g. dynamic properties, robustness, large scale
  deployment aspects, steady state behaviour, and
  so on