Congestion Manager and

its relevance to WebTP

Rajarshi Gupta

Acknowledgements

CM GROUP• Hari Balakrishnan

(MIT LCS)• Hariharan S Rahul

(MIT LCS)• Srinivasan Seshan

(IBM TJ Watson)

SOURCES• Paper in HotOS (March

99)• MIT LCS Tech Report• Presentation by Hari at

Bell Labs • http://inat.lcs.mit.edu/

projects/cm/

Congestion Management Challenges

• Heterogeneous traffic mix– Variety of applications and transports

• Multiple concurrent streams

• Separation from other tasks like loss recovery

• Stable control algorithms

• Enable applications <think WebTP>

Integrated TCP Sessions

r1r1

r-nr-n

r3r3

r2r2

• Independent TCP connections, but shared control parameters [BPS+98, Touch98]• Shared congestion windows, round-trip estimates• But, this approach doesn’t accommodate non-TCP traffic

ServerClient

What is the World Heading Toward?

• The world won’t be just HTTP• The world won’t be just TCP

Logically different streams (objects) kept separate, yet efficient congestion management

must be performed.

u1u1

u-mu-m

u3u3

u2u2r1r1

r2r2

r3r3

r-nr-n

Server

Internet

Client

What We Really Need…

An integrated approach to end-to-end congestion management for the Internet

IP

HTTP Video1

TCP1 TCP2 UDP

Audio Video2

CongestionManager

Jobs of a CM

• Reacts to congestion

• Probes carefully and passively for spare bandwidth

• Receives feedback from the receivers (losses, status)

• Apportions available capacity between active flows

CM Properties

• Ensures proper and stable congestion behavior

• Enables application and transport adaptation to congestion via API

• Trusted intermediary between flows for bandwidth management

• Per-host & per-domain statistics (bandwidth, loss rates, RTT)

• Motivated by e2e argument and ALF

CM Features

• Algorithms and Protocols

• Adaptation API

• Applications & performance

CM Features

• Algorithms and protocols

• Adaptation API

• Applications & performance

CM Algorithms

• Rate-based AIMD control

• Loss-resilient feedback protocol

• Exponential aging when feedback is infrequent

• Flow segregation to handle non-best-effort networks

• Scheduler to apportion bandwidth between flows

TCP-friendly(?) rate-based control

• Friendly: Throughput goes as 1/sqrt(p) for AIMD scheme• nr

2 = K { (nr/nd) + 1 }, where nr = # recd and nd = # dropped is necessary and sufficient for verifying TCP “friendliness”

Receiver Feedback

• Implicit: hints from application– Losses, ECN (e.g TCP/CM)

• Explicit: CM probes– Probe every half RTT using loss-resilient

protocol– Requires modification to receiver (CM)– Low overhead

• Tracks loss rate, RTT estimate

Why Feedback?Loss rate inversely prop to feedback frequency

0

0.1

0.2

0.3

0.4

0.5

0.6

0 1 2 3 4 5 6 7

x times per RTT

Loss

pro

bab

ility

Infrequent Feedback: Exponential aging• Reduce rate by half, every RTT. •Uses minimum RTT. SRTT too aggressive•Continues to transmit at safe rate without clamping apps

Better than Best-effort ?

• Future networks will not treat all flows equally

• Per-host aggregation incorrect

• Solution: flow segregation based on loss rates and aggregrated throughput

• [Evaluation in-progress]

• Use per-flow QoS parameters in CM

CM Scheduler

• Currently HRR scheduler for rate allocation

• Uses pre-configured weights and receiver hints to apportion bandwidth between flows

• Application allowed to send the number of bytes allowed by the CM

• Experiments show it working well

• Exploring other scheduling algorithms for delay management as well (real-time)

CM Features

• Algorithms and protocols

• Adaptation API

• Applications & performance

CM API Principles

• Goal: To enable easy application adaptation

• Four guiding principles:– Put the application in control (give it rate - it can

choose what to send)– Accommodate traffic heterogeneity– Accommodate application heterogeneity – Learn from the application (API should be

flexible enough to learn different info)

CM API Structure

• Data Structure– cm_entry– cm_id

• Query– cm_query

• Control– cm_open– cm_request– cm_notify– cm_update– cm_close

• Callback– app_notify– change_rate

Functioning of CM API

• Apps use cm_query to enquire about state

• App requests allocation using cm_request• CM responds with app_notify• App sends any data it pleases, up to allocation

• App informs CM of tx using cm_notify• App can give extra fedback with

cm_update• CM may change rate using change_rate

• API should not force particular application style

• Asynchronous transmitters (e.g., TCP)– Triggered by events other than periodic clocks– Request/callback/notify works well

• Synchronous transmitters– Maintain internal timer for transmissions– Need rate change triggers from CM

change_rate(newrate);

Application Heterogeneity

CM Features

• Algorithms and protocols

• Adaptation API

• Applications & performance

Application 1: Web/TCP

Web server uses change_rate() to pick source encoding

CM Web Performance

0

50

100

150

200

250

0 2 4 6 8 10 12 14 16

0

50

100

150

200

250

300

350

400

450

0 2 4 6 8 10 12 14 16

With CM

CM greatly improvesperformance predictabilityand consistency

TCP Newreno

Time (s)

Seq

uen

ce n

um

ber

0

50

100

150

200

250

300

350

400

450

0 5 10 15 20 25

Application 2: Layered Streaming Audio

Time (s)

Seq

uen

ce n

um

ber

Competing TCP

TCP/CM

Audio/CM

Wanted TCP/CM + Audio/CM to equal TCP

CM Conclusions

• CM ensures proper and stable congestion behavior– CM tells flows their rates

• Simple, yet powerful API to enable application adaptation– Application is in control of what to send

• Improves performance consistency and predictability for individual applications and makes them better network citizens ;-)

Proposed WebTP Architecture

Application

User-centric Optim., Data Model

MEASUREMENTS

Light-weight Connection Protocol

API

Congestion Mgr

API

$

IP

CM in WebTP

How it Fits in• Architecture diagram• ALF motivation• Learn from co-located

flows• Rate-based flow control• QoS and CoS• <discuss>

How it Doesn’t• Strictly sender-based• Too much API overhead

(AppCM FlowTP)• Need separate control

for reliability

• <discuss>