Congestion control in overlay networks
This presentation is the property of its rightful owner.
Sponsored Links
1 / 37

Congestion Control in Overlay Networks PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Congestion Control in Overlay Networks. R. Srikant University of Illinois. Acknowledments. Congestion Control: Joint work with Huaizhong Han, Chris Hollot, Srinivas Shakkaottai and Don Towsley Modelling: Joint work with Supratim Deb. Causes of Congestion.

Download Presentation

Congestion Control in Overlay Networks

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Congestion control in overlay networks

Congestion Control in Overlay Networks

R. Srikant

University of Illinois



  • Congestion Control: Joint work with Huaizhong Han, Chris Hollot, Srinivas Shakkaottai and Don Towsley

  • Modelling: Joint work with Supratim Deb

Causes of congestion

Causes of Congestion

  • Low bandwidth at access and peering points

  • Routing Issues:

    • “Get out of my network as quickly as possible” (Hot Potato)

    • Agree over a glass of beer, “I will send you my traffic and you send me yours”

Inefficient routing

Inefficient Routing

  • Routing algorithm may choose a path with lower bandwidth

100 kbps



1 Mbps

Overlay network

Overlay Network

  • Both paths are used

100 kbps



1 Mbps



  • Source Routing

  • Where to place the overlay routers?

  • Out-of-sequence delivery of packets requires packet reassembly (Flashget, BitTorrent)

  • How to do flow splitting and congestion control?

Resource allocation single path

Resource Allocation – Single Path

  • Associate a utility function with each user

  • Strictly concave, increasing functions

  • Maximize system utility, i.e., the sum of the utilities of all the users

User 1



User 0

User 2

Kelly s system problem

Kelly’s System Problem

subject to

Resource allocation overlay

Resource Allocation – Overlay


subject to link capacity constraints.

  • s(r) denotes the source-destination of route r.

Link price formulation

Link Price Formulation

  • Associate a price function with each link: fl(yl), where yl is the arrival rate into the link:

    where yl is the arrival rate at link l.

Kmt solution

KMT Solution

  • Special case: Ui(zi)=wi log zi.

  • qr is the path price (loss or delay)

  • zj is the total rate of the user associated with route r

Rtt and implementation

RTT and Implementation

  • The rate at which acks are received,


    is only available with a delay (RTT)

  • Not easy to separate qr: requires memory of xr from one RTT ago

Overlay tcp

Overlay TCP

  • Generalization of Vinnicombe’s scalable TCP:

  • The loss or mark rate xr(t-Tr)qr is available

  • The sum of the current rates zj is also available

Window implementation

Window Implementation

  • Recall xr = Wr/Tr

  • Receive ack, increase window by rwj

  • Receive mark, decrease window by r zj

Network block diagram

Network Block Diagram


y (link rates)

x (source rates)




q (path prices)

p (link prices)

What happens here in overlay networks?



  • There is coupling among the routes in the multipath case

Multi-path users



Single-path users

Stability condition

Stability Condition

  • Each route’s increase/decrease parameter r depends on the RTT of all other routes sharing the same S-D pair

  • If all routes for an S-D pair have the same RTT, reduces to the single-path stability condition

Single path case condition is not sufficient

Single-path case condition is not sufficient



Arrivals and departures

Arrivals and Departures

  • Congestion time scale: Number of file transfers (connections) in the network is constant

  • Connection-level time scale: File transfer requests (connections) arrive and depart. Resource allocation is performed instantaneously

Connection level model roberts and massouli

Connection-Level Model(Roberts and Massouli)

  • Connections arrive according to a Poisson process of rate i for S-D pair i

  • Each connection for S-D pair i is a file whose size is drawn independently from an exponential distribution with mean 1/i

  • Also works for mixtures of exponential distributions (high file-size variance)

Connection level stability

Connection-level stability

  • Both links have capacity=1






Necessary condition for stability

Necessary Condition for Stability

  • For each link l, the total load on the link should be less than its capacity:

    r: l2 rr < cl


    r: s(r)=I r = i

    where r=r/r

  • Split the load between S-D pairs along various paths such that the load on each link is less than its capacity (Multicommodity flow problem)

Is the necessary condition sufficient

Is the necessary condition sufficient?

  • Yes! Overlay TCP automatically splits the flows in the appropriate manner

  • There may more than one way to split the traffic among the paths

  • Extension of the Bonald-Massoulie result to the multipath case



  • Are deterministic models valid?

    • Not all sources respond to congestion signals (non-adaptive real-time sources)

    • Most file transfers are too short; stability analysis doesn’t make sense

    • The congestion feedback process is probabilistic

    • Inability to precisely model window flow control

  • The real network has a lot of randomness

Congestion control in overlay networks


  • In our model

    the congestion feedback (losses or marks) M(k) is a function of the arrival rate at the link

  • However, typically the feedback is usually based on the queue length

Queue based vs rate based model

Queue-based vs Rate-based Model

  • Give very different results regarding stability

  • Can construct examples where one model is stable for large RTT and the other is stable for small RTT!

  • Question: Which model is appropriate to describe the Internet?

  • Are there parameter choices under which a queue-based system produces a rate-based limit?

Large flows model

Large Flows Model

  • Single link: N flows with identical RTT d

  • Capacity of the link is Nc (Shakkottai-S., Baccelli-MacDonald-Reynier, Tinnamakornsrisuphap-Makowski)

  • Source updates rate every c time-units

  • Link processes packets N times faster

Discrete time stochastic models

Discrete-Time Stochastic Models

  • Consider N proportionally fair controllers over a single link.

  • In the Nth system, the dynamics of the rth source is given by

  • Mr is a random variable that is a function of the queue-length: b(k)

Random early marking rem

Random Early Marking (REM)

Congestion control in overlay networks



Model at the link

Model at the Link

  • Each source generates packets according to Poisson(xr/N) in each link time slot

  • Each packet is marked or dropped independently according to REM or RED

  • Number of marked packets in each link time slot is Poisson(xr f(br)/N)

Large number of sources limit

Large Number of Sources Limit

  • Under appropriate conditions

    converges in an appropriate sense to

Main result

Main Result

  • If f(b)=1-exp(- b), then M(k) is a function of the rate

  • If f(b)=1-exp(- b/N), then M(k) is a function of the (scaled) queue length

  • Why? b=O(1) in the first case and is O(N) in the second case



  • A stable TCP for overlay networks

  • Two different models depending on the parameter scaling in the AQM scheme

  • Which scaling is more appropriate? One scaling leads to queue delays that are of the order of RTTs and the other one leads to queue delays that are negligible compared to the RTTs



  • How often do routing problems lead to congestion?

  • Are overlay networks feasible?

  • Should queueing delays be small compared to RTT?

  • Login