Advanced Topics in Congestion Control - PowerPoint PPT Presentation

Advanced topics in congestion control l.jpg
Download
1 / 76

  • 237 Views
  • Updated On :
  • Presentation posted in: Travel / Places

Advanced Topics in Congestion Control . Slides originally developed by S. Kalyanaraman (RPI) based in part upon slides of Prof. Raj Jain (OSU), Srini Seshan (CMU), J. Kurose (U Mass), I.Stoica (UCB). Overview. Queue Management Schemes: RED, ARED, FRED, BLUE, REM

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

Advanced Topics in Congestion Control

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


Advanced topics in congestion control l.jpg

Advanced Topics inCongestion Control

Slides originally developed by S. Kalyanaraman (RPI) based in part upon slides of Prof. Raj Jain (OSU), Srini Seshan (CMU), J. Kurose (U Mass), I.Stoica (UCB)


Slide2 l.jpg

Overview

  • Queue Management Schemes:

    • RED, ARED, FRED, BLUE, REM

  • TCP Congestion Control (CC) Modeling,

  • TCP Friendly CC

  • Accumulation-based Schemes: TCP Vegas, Monaco

  • Static Optimization Framework Model for Congestion Control

  • Explicit Rate Feedback Schemes (ATM ABR: ERICA)


Slide3 l.jpg

Readings

  • Refs: Chap 13.21, 13.22 in Comer textbook

  • Floyd and Jacobson "Random Early Detection gateways for Congestion Avoidance"

  • Ramakrishnan and Jain, A Binary Feedback Scheme for Congestion Avoidance in Computer Networks with a Connectionless Network Layer,

  • Padhye et al, "Modeling TCP Throughput: A Simple Model and its Empirical Validation"

  • Low, Lapsley: "Optimization Flow Control, I: Basic Algorithm and Convergence"

  • Kalyanaraman et al: "The ERICA Switch Algorithm for ABR Traffic Management in ATM Networks"

  • Harrison et al: "An Edge-based Framework for Flow Control"


Queuing disciplines l.jpg

Queuing Disciplines

  • Each router must implement some queuing discipline

  • Queuing allocates bandwidth and buffer space:

    • Bandwidth: Which packet to serve next (scheduling)

    • Buffer: Which packet to drop next (buffer mgmt)

  • Queuing also affects latency

Traffic

Sources

Traffic

Classes

Class A

Class B

Class C

Drop

Scheduling

Buffer Management


Typical internet queuing l.jpg

Typical Internet Queuing

  • FIFO and Drop-tail

    • Simplest choice

    • Used widely in the Internet

  • FIFO (first-in-first-out)

    • Implies single class of traffic

  • Drop-tail

    • Arriving packets get dropped when queue is full regardless of flow or importance

  • Important distinction:

    • FIFO: Scheduling discipline

    • Drop-tail: Buffer management policy


Fifo and drop tail problems l.jpg

FIFO and Drop-tail Problems

  • FIFO Issues: In a FIFO discipline, the service seen by a flow is convoluted with the arrivals of packets from all other flows!

    • No isolation between flows: full burden on e2e control

    • No policing: send more packets  get more service

  • Drop-tail Issues:

    • Routers are forced to have have large queues to maintain high utilizations

    • Larger buffers => larger steady state queues/delays

    • Synchronization: End hosts react to same events because packets tend to be lost in bursts

    • Lock-out: A side effect of burstiness and synchronization is that a few flows can monopolize queue space


Design objectives l.jpg

Design Objectives

  • Keep throughput high and delay low (i.e. knee)

  • Accommodate bursts

  • Queue size should reflect ability to accept bursts rather than steady-state queuing

  • Improve TCP performance with minimal hardware changes


Queue management ideas l.jpg

Queue Management Ideas

  • Synchronization, lock-out:

    • Random drop: Drop a randomly chosen packet

    • Drop front: Drop packet from head of queue

  • High steady-state queuing vs. burstiness:

    • Early drop: Drop packets before queue full

    • Do not drop packets “too early” because queue may reflect only burstiness and not true overload

  • Misbehaving vs. Fragile flows:

    • Drop packets proportional to queue occupancy of flow

    • Try to protect fragile flows from packet loss (e.g. color them or classify them on the fly)

  • Drop packets vs. Mark packets:

    • Dropping packets interacts w/ reliability mechanisms

    • Mark packets: Need to trust end-systems to respond!


Packet drop dimensions l.jpg

Packet Drop Dimensions

Aggregation

Single class

Per-connection state

Class-based queuing

Drop position

Tail

Head

Random location

Overflow drop

Early drop


Random early detection red l.jpg

Random Early Detection (RED)

Min thresh

Max thresh

Running Average Queue Length

P(drop)

1.0

maxP

minth

maxth

Running Avg Q Length


Random early detection red11 l.jpg

Random Early Detection (RED)

  • Maintain running average of queue length avgQ

    • Low pass filtering

  • If avgQ < minthdo nothing

    • Low queuing, send packets through

  • If avgQ > maxth, drop packet

    • Protection from misbehaving sources

  • Else mark (or drop) packet in a manner proportional to queue length & bias to protect against synchronization

    • Pb = maxp(avgQ - minth) / (maxth - minth)

    • Further, bias Pb by history of unmarked packets

    • Pdrop = Pb/(1 - count*Pb)


Red issues l.jpg

RED Issues

  • Issues:

    • Breaks synchronization well

    • Extremely sensitive to parameter settings

    • Wild queue oscillations upon load changes

    • Fail to prevent buffer overflow as #sources increases

    • Does not help fragile flows (e.g. small window flows or retransmitted packets)

    • Does not adequately isolate cooperative flows from non-cooperative flows

  • Isolation:

    • Fair queuing achieves isolation using per-flow state

    • RED penalty box: Monitor history for packet drops, identify flows that use disproportionate bandwidth


Variant ared feng kandlur saha shin 1999 l.jpg

Variant: ARED (Feng, Kandlur, Saha, Shin 1999)

  • Adaptive RED

  • Motivation: RED extremely sensitive to number of sources and parameter settings

  • Idea: Adapt maxp to load

    • If avgQ < minth, decrease maxp

    • If avgQ > maxth, increase maxp

  • No per-flow information needed


Variant fred ling morris 1997 l.jpg

Variant: FRED (Ling & Morris 1997)

  • Flow RED

  • Motivation: Marking packets in proportion to flow rate is unfair (e.g. adaptive vs. non-adaptive flows)

  • Idea

    • A flow can buffer up to minq packets w/o being marked

    • A flow that frequently buffers more than maxq packets gets penalized

    • All flows with backlogs in between are marked according to RED

    • No flow can buffer more than avgcq packets persistently

      • Where avgcq = average per-flow buffer use

  • Need per-active-flow accounting


Variant blue feng kandlur saha shin 1999 l.jpg

Variant: BLUE (Feng, Kandlur, Saha, Shin 1999)

  • BLUE = ??? (2nd & 3rd authors at IBM)

  • Motivation: Wild oscillation of RED leads to cyclic overflow & underutilization

  • Algorithm:

    • On buffer overflow, increment marking probability

    • On link idle, decrement marking probability


Variant stochastic fair blue l.jpg

1

1

1

1

Variant: Stochastic Fair Blue

  • Motivation: Protection against non-adaptive flows

  • Algorithm

    • L hash functions map a packet to L bins (out of NxL )

    • Marking probability associated with each bin is

      • Incremented if bin occupancy exceeds threshold

      • Decremented if bin occupancy is 0

    • Packets marked with min {p1, …, pL}

h1

h2

hL-1

hL

nonadaptive

adaptive


Stochastic fair blue continued l.jpg

Stochastic Fair Blue continued

  • Idea

    • A non-adaptive flow drives marking prob to 1 at allL bins it is mapped to

    • An adaptive flow may share some of its L bins with non-adaptive flows

    • Non-adaptive flows can be identified and penalized with reasonable state overhead (not necessarily per-flow)

    • Large numbers of bad flows may cause false positives


Rem athuraliya low 2000 l.jpg

REMAthuraliya & Low 2000

  • REM = Random Exponential Marking

    • Decouple congestion & performance measure

    • “Price” adjusted to match rate and clear buffer

    • Marking probability exponential in `price’

REM

RED

1

Avg queue


Comparison of aqm performance l.jpg

RED

min_th = 10 pkts

max_th = 40 pkts

max_p = 0.1

Comparison of AQM Performance

REM

queue = 1.5 pkts

utilization = 92%

g = 0.05, a = 0.4, f = 1.15

DropTail

queue = 94%


The decbit scheme l.jpg

The DECbit Scheme

  • Basic ideas:

    • Mark packets instead of dropping them

    • Special support at routers and e2e

  • Scheme:

    • On congestion, router sets congestion indication (CI) bit on packet

    • Receiver relays bit to sender

    • Sender adjusts sending rate

  • Key design questions:

    • When to set CI bit?

    • How does sender respond to CI?


Setting ci bit l.jpg

Setting CI Bit

Queue length

Current time

Time

Previous cycle

Current cycle

Averaging interval

AVG queue length = [(previous busy+idle) + current interval]/[averaging interval]


Decbit routers l.jpg

DECbit Routers

  • Router tracks average queue length:

    • Regeneration Cycle: Queue goes from empty to non-empty to empty

    • Average from start of previous cycle

  • If average > 1  router sets bit for flows sending more than their share

  • If average > 2  router sets bit in every packet

  • Threshold is a trade-off between queuing and delay

  • Optimizes power = (throughput / delay)

  • Compromise between sensitivity and stability

  • Acks carry bit back to source


Decbit source l.jpg

DECbit Source

  • Source averages across acks in window

    • Congestion if > 50% of bits set

    • Will detect congestion earlier than TCP

  • Additive increase, multiplicative decrease

    • Decrease factor = 0.875

    • Increase factor = 1 packet

    • After change, ignore DECbit for packets in flight (vs. TCP ignore other drops in window)

  • No slow start


Alternate congestion control models l.jpg

Alternate Congestion Control Models

  • Loss-based: TCP “Classic”, TCP Reno, …

  • Accumulation-based schemes: TCP Vegas, Monaco

    • Use per-flow queue contribution (backlog) as a congestion estimate instead of loss rate

  • Explicit rate-based feedback

    • Controller at bottleneck assigns rates to each flow

  • Packet Pair congestion control [Not covered]

    • WFQ at bottlenecks isolates flows, and gives fair rates

    • Packet-pair probing discovers this rate and sets source rate to that.


Tcp reno jacobson 1990 l.jpg

Fast retransmission/fast recovery

TCP Reno (Jacobson 1990)

window

time

CA

SS

SS: Slow Start

CA: Congestion Avoidance


Tcp vegas brakmo peterson 1994 l.jpg

TCP Vegas (Brakmo & Peterson 1994)

window

  • Accumulation-based scheme

  • Converges, no retransmission

  • … provided buffer is large enough for no loss.

time

CA

SS


Slide27 l.jpg

Accumulation: Single Queue

  • Flow i at router j

  • Arrival curve Aij(t)

  • Service curve Sij(t)

    • Cumulative

    • Continuous

    • Non-decreasing

  • If no loss, then

bit

Aij(t)

delay

Sij(t)

b2

b1

qij(t1)

time

t1

t2

27


Slide28 l.jpg

  • We have

  • Accumulationof flow i

  • Then

Accumulation: Series of Queues

Model as a single queue

1

j

j+1

J

ingress

egress

dj

fi

μij

Λi,j+1

μi

Λi

28


Slide29 l.jpg

Queue vs. Accumulation Behavior

  • Queue qij(t) -- info of flow i queued in a FIFO router j

  • Accumulation ai(t) -- info of flow i queued in a set of FIFO routers 1, …, J

  • The collective queuing behavior of a set of FIFO routers looks similar to that of one single FIFO router

29


Slide30 l.jpg

1

j

j+1

J

dj

fi

μij

Λi,j+1

μi

Λi

time

1

j

j+1

J

30

Accumulation: Distributed, Time-shifted Sum


Slide31 l.jpg

1

j

j+1

J

dj

fi

μij

Λi,j+1

μi

Λi

Control Policy

  • Control objective: keep

    • If , no way to probe increase of available bw;

  • Control algorithm:

31


Slide32 l.jpg

Two Accumulation-Based Schemes

  • Monaco

    • Accumulation estimation: out-of-band / in-band

    • Congestion response:

      • Additive Increase/Additive Decrease (AIAD)

  • Vegas

    • Accumulation estimation: in-band

    • Congestion response:

      • Additive Increase/Additive Decrease (AIAD)

32


Slide33 l.jpg

1

j

j+1

J

dj

fi

μij

Λi,j+1

μi

Λi

out-of-band

in-band ctrl pkt

Accumulation vs. Monaco Estimator

time

1

j

j+1

J


Slide34 l.jpg

Accumulation vs. Monaco Estimator

1

jf

jf+1

Jf

djf

fi

data

μij

Λi,j+1

μi

ctrl

Λi

Jb

jb+1

jb

djb

1

ctrl

out-of-bd ctrl

classifier

FIFO

in-band ctrl,

data pkt

34


Slide35 l.jpg

Monaco

  • Congestion estimation:

    • Out-of-band and in-band control packets

  • Congestion response:

    • If qm < α, cwnd(k+1) = cwnd(k) + 1;

    • If qm > β, cwnd(k+1) = cwnd(k) – 1; [1 = α < β = 3]

35


Slide36 l.jpg

cwnd

congestion

avoidance

slow start

Time

TCP Vegas

  • Congestion estimation:

    • Defineqv = ( cwnd / rttp – cwnd / rtt ) * rttp;

    • where rttp is estimate of round trip propagation delay

  • Congestion response:

    • if qv < α, cwnd(k+1) = cwnd(k) + 1;

    • if qv > β, cwnd(k+1) = cwnd(k) – 1;[1 = α < β = 3]

36


Slide37 l.jpg

Vegas Accumulation Estimator

  • The physical meaning of qv

    • rtt= rttp + rttq[ rttq is queuing time ]

    • qv= ( cwnd / rttp – cwnd / rtt ) * rttp

    • = ( cwnd / rtt ) * ( rtt – rttp )

    • = ( cwnd / rtt ) * rttq[ if rtt is typical ]

    • = sending rate * rttq[ Little’s Law ]

    • = packets backlogged[ Little’s Law again ]

  • So vegas maintains α ~ β number of packets queued inside the network

  • It adjusts sending rate additivelyto achieve this

37


Slide38 l.jpg

1

jf

jf+1

Jf

djf

fi

data

μij

Λi,j+1

μi

Λi

Jb

jb+1

jb

djb

1

ack

Accumulation vs. Vegas Estimator

  • Backlogv

38


Slide39 l.jpg

Vegas vs. Monaco Estimators

  • Vegas accumulation estimator

    • Ingress-based

    • Round trip (forward data path and backward ack path)

    • Sensitive to ack path queuing delay

    • Sensitive to round trip propagation delay measurement error

  • Monaco accumulation estimator

    • Egress-based

    • One way (only forward data path)

    • Insensitive to ack path queuing delay

    • No need to explicitly know one way propagation delay


Slide40 l.jpg

Queue, Utilization w/ basertt Errors

40


Tcp modeling l.jpg

TCP Modeling

  • Given the congestion behavior of TCP can we predict what type of performance we should get?

  • What are the important factors

    • Loss rate

      • Affects how often window is reduced

    • RTT

      • Affects increase rate and relates BW to window

    • RTO

      • Affects performance during loss recovery

    • MSS

      • Affects increase rate


Overall tcp behavior l.jpg

Overall TCP Behavior

  • Let’s focus on steady state (congestion avoidance) with no slow starts, no timeouts and perfect loss recovery

  • Some additional assumptions

    • Fixed RTT

    • No delayed ACKs

Window

Time


Derivation l.jpg

4w/3

w = (4w/3+2w/3)/2

2w/3

2w/3

Area = 2w2/3

Derivation

window

  • Each cycle delivers 2w2/3 packets

  • Assume: Each cycle delivers 1/p packets = 2w2/3

    • Delivers 1/p packets followed by a drop

      => Loss probability = p/(1+p) ~ p if p is small.

  • Hence

t


Alternate derivation l.jpg

Alternate Derivation

  • Assume: Loss is a Bernoulli process with probability p

  • Assume: p is small

  • wn is the window size after nth RTT


Slide45 l.jpg

Law

  • Equilibrium window size

  • Equilibrium rate

  • Empirically constant a ~ 1

  • Verified extensively through simulations and on Internet

  • References

    • T.J.Ott, J.H.B. Kemperman and M.Mathis (1996)

    • M.Mathis, J.Semke, J.Mahdavi, T.Ott (1997)

    • T.V.Lakshman and U.Mahdow (1997)

    • J.Padhye, V.Firoiu, D.Towsley, J.Kurose (1998)


Implications l.jpg

Implications

  • Applicability

    • Additive increase, multiplicative decrease (Reno)

    • Congestion avoidance dominates

    • No timeouts, e.g., SACK+RH

    • Small losses

    • Persistent, greedy sources

    • Receiver not bottleneck

  • Implications

    • Reno equalizes window

    • Reno discriminates against long connections

    • Halving throughput => quadrupling loss rate!


Refinement padhye firoin towsley kurose 1998 l.jpg

Refinement(Padhye, Firoin, Towsley & Kurose 1998)

  • Renewal model including

    • FR/FR with Delayed ACKs (b packets per ACK)

    • Timeouts

    • Receiver window limitation

  • Source rate

  • When p is small and Wr is large, reduces to


Tcp friendliness l.jpg

TCP Friendliness

  • What does it mean to be TCP friendly?

    • TCP is not going away

    • Fairness means equal shares

    • Any new congestion control must compete with TCP flows

      • Should not clobber TCP flows and grab bulk of link

      • Should also be able to hold its own, i.e. grab its fair share, or it will never become popular


Binomial congestion control l.jpg

Binomial Congestion Control

  • In AIMD

    • Increase: Wn+1 = Wn + 

    • Decrease: Wn+1 = (1- ) Wn

  • In Binomial

    • Increase: Wn+1 = Wn + ( / Wnk)

    • Decrease: Wn+1 = Wn -  Wnl

    • k=0 & l=1 AIMD

    • l < 1 results in less than multiplicative decrease

    • Good for multimedia applications


Binomial congestion control continued l.jpg

Binomial Congestion Control continued

  • Rate ~ 1/ (loss rate)1/(k+l+1)

  • If k+l=1 rate ~ 1/p0.5

    • TCP friendly

    • AIMD (k=0, l=1) is the most aggressive of this class

    • SQRT (k=1/2,l=1/2) and IIAD (k=1,l=0)

    • Good for applications that want to probe quickly and can use any available bandwidth


Static optimization framework l.jpg

Static Optimization Framework

Duality theory  equilibrium

  • Source rates xi(t) are primal variables (i is a flow)

  • Congestion measures pl(t) are dual variables, where pl(t) =prob of loss on link l at time t

  • Congestion control is optimization process over Internet

pl(t)

xi(t)

Feedback?


Overview equilibrium l.jpg

Overview: Equilibrium

  • Interaction of source rates xs(t) and congestionmeasures pl(t)

  • Duality theory

    • They are primal and dual variables

    • Flow control is optimization process

  • Example congestion measure

    • Loss (Reno)

    • Queueing delay (Vegas)


Overview equilibrium continued l.jpg

Reno, Vegas

DropTail, RED, REM

Overview: Equilibrium continued

  • Congestion control problem

  • Primal-dual algorithm

  • TCP/AQM protocols (F, G)

    • Maximize aggregate source utility

    • With different utility functions Us(xs)


Model l.jpg

x1

c1

c2

x2

x3

Model

  • Sources s

    • L(s) - links used by source s

    • Us(xs) - utility if source rate = xs

  • Network

    • Link l has capacity cl


Primal problem l.jpg

Primal Problem

  • Assumptions

    • Strictly concave increasing Us

  • Unique optimal rates xs exist

  • Direct solution impractical


Duality approach l.jpg

Primal-dual algorithm:

Duality Approach


Gradient algorithm l.jpg

Gradient Algorithm

  • Gradient algorithm

Theorem (Low, Lapsley, 1999)

Converges to optimal rates in an asynchronous

environment


Example l.jpg

  • Lagrange multiplier:

    p1 = p2 = 3/2

  • Optimal:x1 = 1/3

    x2 = x3 = 2/3

x1

1

1

x2

x3

Example


Example continued l.jpg

x1

1

1

x2

x3

Example continued

  • xs : proportionally fair (Vegas)

  • pl : Lagrange multiplier, (shadow) price, congestion measure

  • How to compute (x, p)?

    • Gradient algorithms, Newton alg, Primal-dual alg, …

  • Relevance to TCP/AQM ??

    • TCP/AQM protocols implement primal-dual algorithms over Internet


Example continued60 l.jpg

x1

Aggregate rate

1

1

x2

x3

Example continued

  • xs : proportionally fair (Vegas)

  • pl : Lagrange multiplier, (shadow) price, congestion measure

  • How to compute (x, p)?

    • Gradient algorithms, Newton alg, Primal-dual alg, …

  • Relevance to TCP/AQM ??

    • TCP/AQM protocols implement primal-dual algorithms over Internet


Active queue management aqm l.jpg

Reno, Vegas

DropTail, RED, REM

x(t+1) = F( p(t), x(t) )

p(t+1) = G( p(t), x(t) )

Active Queue Management (AQM)

  • Idea: provide congestion information by probabilistically marking packets

  • Issues

    • How to measure congestion (p and G)?

    • How to embed congestion measure?

    • How to feed back congestion info?


Red floyd jacobson 1993 l.jpg

RED (Floyd & Jacobson 1993)

  • Congestion measure: average queue length

    pl(t+1) = [pl(t) + xl(t) - cl]+

  • Embedding: p-linear probability function

marking

1

Avg queue


Rem athuraliya low 200063 l.jpg

REM (Athuraliya & Low 2000)

  • Congestion measure: price

    pl(t+1) = [pl(t) + g(al bl(t)+ xl(t) - cl )]+

  • Embedding: exponentialprobability function


Key features l.jpg

Match rate

Clear buffer

Sum prices

Key Features

  • Clear buffer and match rate

Theorem (Paganini 2000)

Global asymptotic stability for general utility function (in the absence of delay)


Aqm summary l.jpg

pl(t) G(p(t), x(t))

DropTailloss [1 - cl/xl(t)]+

REDqueue [pl(t) + xl(t) - cl]+

Vegasdelay [pl(t) + xl(t)/cl - 1]+

REMprice [pl(t) + g(albl(t)+ xl(t) - cl )]+

Reno, Vegas

DropTail, RED, REM

x(t+1) = F( p(t), x(t) )

p(t+1) = G( p(t), x(t) )

AQM Summary


Reno f p t x t l.jpg

Reno, Vegas

DropTail, RED, REM

Reno: F(p(t), x(t))

for every ack (ca)

{W += 1/W }

for every loss

{W := W/2 }

Primal-dual algorithm:

x(t+1) = F( p(t), x(t) )

p(t+1) = G( p(t), x(t) )


Reno implications l.jpg

Reno Implications

  • Equilibrium characterization

    Duality

  • Congestion measure p = loss

  • Implications

    • Reno equalizes window wi = ti xi

    • inversely proportional to delay ti

    • dependence for small p

    • DropTail fills queue, regardless of queue capacity


Reno gradient algorithm l.jpg

Reno & Gradient Algorithm

  • Gradient algorithm

  • TCP approximate version of gradient algorithm


Reno gradient algorithm69 l.jpg

Reno & Gradient Algorithm

  • Gradient algorithm

  • TCP approximate version of gradient algorithm


Vegas l.jpg

F:

G:

pl(t+1) = [pl(t) + xl(t)/cl - 1]+

Vegas

for every RTT

{ if W/RTTmin – W/RTT < a then W++

if W/RTTmin – W/RTT > a then W-- }

for every loss

W := W/2

queue size


Atm abr explicit rate feedback l.jpg

ATM ABR Explicit Rate Feedback

RM Cell

  • Sources regulate transmission using a “rate” parameter

  • Feedback scheme:

    • Every (n+1)th cell is an RM (control) cell containing current cell rate, allowed cell rate, etc

    • Switches adjust the rate using rich information about congestion to calculate explicit, multi-bit feedback

    • Destination returns the RM cell to the source

  • Control policy: Sources adjust to the new rate

Source

Destination


Erica design goals l.jpg

ERICA: Design Goals

  • Allows utilization to be 100% (better tracking)

  • Allows operation at any point between knee and cliff

  • The queue length can be set to any desired value (tracking)

  • Max-min fairness (fairness)

100%

Link

Utilization

Throughput

Time

Load

QueueLength

Delay

50

Load


Efficiency vs fairness osu scheme l.jpg

Efficiency vs. Fairness: OSU Scheme

  • Efficiency = high utilization

  • Fairness = Equal allocations for contending sources

  • Worry about fairness after utilization close to 100% utilization . Target Utilization (U) and Target Utilization Band (TUB).

overload region

worry about fairness here

99%95%91%

TotalLoad

TUB

U=

underload region

Time


Erica switch algorithm l.jpg

ERICA Switch Algorithm

  • Overload = Input rate/Target rate

  • Fair Share = Target rate/# of active VCs

  • This VC’s Share = VC’s rate /Overload

  • ER = Max(Fair Share, This VC’s Share)

  • ER in Cell = Min(ER in Cell, ER)

  • This is the basic algorithm.

  • Has more steps for improved fairness, queue management, transient spike suppression, averaging of metrics.


Tcp rate control l.jpg

TCP Rate Control

  • Step 1: Explicit control of window:

Congestion window

(CWND)

W

Actual Window =

Min(Cwnd, Wr)

  • Step 2: Control rate of acks (ack-bucket): Tradeoff ack queues in reverse path for fewer packets in forward path

r

pkts

W

acks

R

Time


Summary l.jpg

Summary

  • Active Queue Management (AQM): RED, REM, etc

  • Alternative models:

    • Accumulation-based schemes: Monaco, Vegas

    • Explicit Rate-based Schemes

  • TCP stochastic modeling

  • Static (Duality) Optimization Framework

  • Can manage TCP with very little loss


  • Login