Congestion Manager and its relevance to WebTP

1
Congestion Manager and its relevance to WebTP

• Rajarshi Gupta

2
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/

3
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 ltthink WebTPgt

4
Integrated TCP Sessions
r1
r2
r3
Server
Client
r-n

• Independent TCP connections, but shared control
  parameters BPS98, Touch98
• Shared congestion windows, round-trip estimates
• But, this approach doesnt accommodate non-TCP
  traffic

5
What is the World Heading Toward?
u1
r1
u2
r2
u3
r3
Server
Client
u-m
r-n

• The world wont be just HTTP
• The world wont be just TCP

Logically different streams (objects) kept
separate, yet efficient congestion management
must be performed.
6
What We Really Need
HTTP
Video1
Audio
Video2
TCP1
TCP2
UDP
IP

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

7
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

8
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

9
CM Features

• Algorithms and Protocols
• Adaptation API
• Applications performance

10
CM Features

• Algorithms and protocols
• Adaptation API
• Applications performance

11
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

12
TCP-friendly(?) rate-based control

• Friendly Throughput goes as 1/sqrt(p) for AIMD
  scheme
• nr2 K (nr/nd) 1 , where nr recd and nd
  dropped is necessary and sufficient for
  verifying TCP friendliness

13
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

14
Why Feedback?

• Loss rate inversely prop to feedback frequency

• 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

Loss probability
x times per RTT
15
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

16
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)

17
CM Features

• Algorithms and protocols
• Adaptation API
• Applications performance

18
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)

19
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

20
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

21
Application Heterogeneity

• 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)

22
CM Features

• Algorithms and protocols
• Adaptation API
• Applications performance

23
Application 1 Web/TCP
Web server uses change_rate() to pick source
encoding
24
CM Web Performance
TCP Newreno
Sequence number
With CM
Time (s)
CM greatly improves performance
predictability and consistency
25
Application 2 Layered Streaming Audio
Competing TCP
TCP/CM
Sequence number
Audio/CM
Time (s)
Wanted TCP/CM Audio/CM to equal TCP
26
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 -)

27
Proposed WebTP Architecture
MEASUREMENTS
Application User-centric Optim., Data Model
API
API
Light-weight Connection Protocol

Congestion Mgr
IP
28
CM in WebTP

• How it Fits in
• Architecture diagram
• ALF motivation
• Learn from co-located flows
• Rate-based flow control
• QoS and CoS
• ltdiscussgt

• How it Doesnt
• Strictly sender-based
• Too much API overhead (App?CM ?FlowTP)
• Need separate control for reliability
• ltdiscussgt