An%20Integrated%20Congestion%20Management%20Architecture%20for%20Internet%20Hosts

1
An Integrated Congestion Management Architecture
for Internet Hosts

• Hari Balakrishnan
• MIT Lab for Computer Science
• http//inat.lcs.mit.edu/hari

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

3
Problem 1 The Web!
r1
r2
r3
Server
Client
r-n

• Multiple reliable streams
• Individual objects are small
• So what?
• Far too inefficient!
• Far too aggressive!

4
Problem 2 Application Heterogeneity
u1
r1
u2
r2
u3
r3
Server
Client
u-m
r-n

• New applications (e.g., real-time streams)
• The world isnt only about HTTP or even TCP!
• So what?
• Applications do not adapt to congestion
• Long-term Internet stability is threatened

5
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

6
Solution 1 Persistent Connections
r1
Put everyone on same ordered byte stream
r2
r3
Server
Client
r-n
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
7
Solution 2 Web Accelerators

• Is your Web experience too slow?
• Chances are, its because of pesky TCP congestion
  control and those annoying timeouts
• Web accelerators will greatly speed up your
  transfers
• By just adjusting TCPs congestion control!
• Who cares if the Internet is stable or not?

8
Solution 3 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

9
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) should be
kept separate, yet efficient congestion
management must be performed.
10
What We Really Need
HTTP
Video1
Audio
Video2
TCP1
TCP2
UDP
IP

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

11
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 Framing (ALF)

12
CM Features

• Algorithms and protocols
• Adaptation API
• Applications performance

13
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

14
CMs Rate-based Control is TCP-friendly

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

15
Receiver Feedback

• Implicit hints from application
• Explicit CM probes
• Probe every half RTT using loss-resilient
  protocol
• Low overhead
• Tracks loss rate, RTT estimate
• But why do we need feedback?

16
Why Feedback?

• Loss rate increases with feedback infrequency

Loss probability
x times per RTT
17
Handling Infrequent Feedback

• Exponential aging reduce rate by half, every
  silent RTT
• Continues transmissions at safe rate without
  clamping apps
• Which RTT to use? Average? Minimum?

Sequence number
Time (s)
18
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

19
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

20
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

21
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, srtt)

22
Accommodate traffic heterogeneity

• TCP bulk transfers
• Short transactions
• Real-time flows at continuum of rates
• Layered streams
• And other unanticipated apps
• cm_open(minrate)

23
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
  change_rate(newrate)

24
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

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