Transcript CM architecture

An Integrated Congestion
Management Architecture for
Internet Hosts
Hari Balakrishnan
MIT Lab for Computer Science
http://wind.lcs.mit.edu/~hari/
Two Questions
Internet
Router
Shared infrastructure and overload causes congestion
• Q: Why has the Internet not crumbled
under its own load in recent years?
• A: Soundness of TCP congestion
control + friendly TCP workload
• Q: Can we remain sanguine about the
future outlook?
Problem #1: The Web!
r1
r2
r3
Internet
Server
r-n
Client
• Multiple reliable streams
• Individual objects are small
• So what?
Far too inefficient!
Far too aggressive!
Problem #2: Application
Heterogeneity
Server
u1 r1
u2
r2
u3
r3
u-m r-n
Internet
Client
• New applications (e.g., real-time streams)
– The world isn’t only about HTTP or even
TCP!
• So what?
Applications do not adapt to congestion
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 adaptive applications
“Solution” #1: Persistent
Connections
r1
r2
r3
Server
r-n
Put everyone on same
ordered byte stream
Client
While this fixes some of the problems of independent
connections, it really is a step in the wrong direction!
1. Far too much coupling between objects
2. Far too application-specific
3. Does not enable application adaptation
“Solution” #2: Web
Accelerators
• Is your Web experience too slow?
• Chances are, it’s because of pesky
TCP congestion control and those
annoying timeouts
• Web accelerators will greatly speed up
your transfers…
• By just “adjusting” TCP’s congestion
control!
“Solution” #3: Integrated TCP
Sessions
r1
r2
r3
Server
r-n
Client
• Independent TCP connections, but shared control parame
[BPS+98, Touch98]
• Shared congestion windows, round-trip estimates
• But, this approach doesn’t accommodate non-TCP traffic
What is the World Heading
Toward?
Server
u1 r1
u2
r2
u3
r3
Internet
u-m r-n
Client
• The world won’t be just HTTP
• The world won’t be just TCP
Logically different streams (objects) should be kept
separate, yet efficient congestion management must be
performed.
What We Really Need…
HTTP
TCP1
Congestion
Manager
Audio
Video1
TCP2
Video2
UDP
IP
An integrated approach to end-to-end
congestion management for the Internet
using the CM
Congestion Manager
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)
• Design motivated by end-to-end
argument and Application Level
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-besteffort networks
• Scheduler to apportion bandwidth
between flows
CM’s Rate-based Control is TCPfriendly
• Throughput goes as 1/sqrt(p) for AIMD scheme
• nr2 = K { (nr/nd) + 1 }, where nr = # recd and nd = #
dropped
Receiver Feedback
• Implicit: hints from application
• Explicit: CM probes
• Probe every half RTT using lossresilient protocol
– Low overhead
• Tracks loss rate, RTT estimate
• But why do we need feedback?
Why Feedback?
• Loss rate increases with feedback
infrequency
0.6
Loss probability
0.5
0.4
0.3
0.2
0.1
0
0
1
2
3
4
5
x times per RTT
6
7
Handling Infrequent
Feedback
• Exponential aging: reduce rate by half, every
silent RTT
– Continues transmissions at safe rate without clamping
apps 90
• Which RTT to use? Average? Minimum?
Sequence number
80
70
60
50
40
30
20
10
0
0
2
4
6
8
10
Time (s)
12
14
16
Better than Best-effort
Networks
• Future networks will not treat all flows
equally
• Per-host aggregation incorrect
• Solution: flow segregation based on
loss rates
• [Evaluation in-progress]
CM Scheduler
• Currently HRR scheduler for rate
allocation
• Uses receiver hints to apportion
bandwidth between flows
• Experiments show it working well
• Exploring other scheduling algorithms
for delay management as well
– Useful for real-time streams
The CM API
• Goal: To enable easy application
adaptation
• Four guiding principles:
– Put the application in control
– Accommodate traffic heterogeneity
– Accommodate application heterogeneity
– Learn from the application
Put the application in
control
• Application decides what to transmit as
late as possible
• CM does not buffer any data
– cm_send() style API not useful
• Request/callback/notify API
– cm_request(nsend);
– app_notify(can_send);
– cm_notify(nsent);
• Query function: cm_query(&rate,
Accommodate traffic
heterogeneity
•
•
•
•
•
•
TCP bulk transfers
Short transactions
Real-time flows at continuum of rates
Layered streams
[And other unanticipated apps]
cm_open(minrate);
Accommodate 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
Learn from the application
• cm_notify(nsent) upon transmission
• cm_update(nrecd, duration,
loss_occurred, rtt)
– Hint to CM (implicit feedback)
– Called by TCP on ACK reception, RTP
applications on RTCP feedback, etc.
• cm_close() to clean up flow state
Application 1: Web/TCP
Web server uses change_rate() to pick convenient source encod
CM Web Performance
450
Sequence number
TCP Newreno
400
350
300
250
200
250
150
With CM
100
200
50
0
0
2
4
6
8
10
12
14
16
Time (s)
CM greatly improves
performance predictability
and consistency
150
100
50
0
0
2
4
6
8
10
12
14
16
Application 2: Layered
Streaming Audio
450
Sequence number
400
350
Competing TCP
300
TCP/CM
250
200
150
Audio/CM
100
50
0
0
5
10
15
Time (s)
20
25
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