An End-System Architecture for Unified Congestion Management

1
An End-System Architecture for Unified
Congestion Management

• Hariharan S. Rahul, Hari Balakrishnan, Srinivasan
  Seshan
• MIT Lab for Computer Science
• http//inat.lcs.mit.edu/

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?
• Q Can we remain sanguine about the future
  outlook?

3
Not at all!

• Short flows dominate the Web
• Slow Start uses bandwidth inefficiently
• Multiple flows between same hosts
• Extremely aggressive and unfair to other apps
• Increasingly diverse apps and transports
• Poor or no application adaptation to congestion

4
Attempted Solutions

• Persistent Connections (P-HTTP,HTTP/1.1)
• Addresses the multiple short flows problem
• Undesirable coupling between objects
• Integrated TCP Sessions (TCP-Int)
• Addresses the multiple short flows problem
• Independent TCP connections share control
  parameters (window,RTT) BPS98, Touch98
• Both do not address application diversity

5
What We Really Need
HTTP
Video1
Audio
Video2
TCP1
TCP2
UDP
IP

• Shared control information across all apps and
  transports (bandwidth, loss, RTT)
• Integrated end-to-end congestion manager CM

6
Congestion Manager Features

• Ensures stable congestion behavior
• Enables application and transport adaptation to
  congestion via API
• Trusted intermediary between flows for bandwidth
  management
• Design motivated by end-to-end argument and
  Application Level Framing (ALF)

7
CM Components

• Adaptation API
• Algorithms and protocols
• Applications / Performance

8
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

9
Put the application in control

• Application decides what to transmit as late as
  possible
• No data buffering cm_send() style API not useful
• Request/callback/notify API

CM
App

• Query cm_query(rate, srtt)

10
Accommodate traffic heterogeneity

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

11
Accommodate application heterogeneity

• API should not force an application style
• Asynchronous transmitters (e.g., TCP)
• Request/callback/notify works well
• Synchronous transmitters
• Need rate change triggers from CM
  change_rate(newrate)

12
Learn from the application

• cm_notify(nsent) upon transmission
• cm_update(nrecd, duration, loss_occurred, rtt)
• Hint to CM (indirect feedback)
• Called by TCP on ACK reception, RTP applications
  on RTCP feedback, etc.
• cm_close() to clean up flow state

13
Webserver and TCP over CM
Application
Congestion Manager
Webserver uses change_rate to pick source encoding
14
CM Algorithms

• TCP friendly rate-based Additive-Increase/
  Multiplicative-Decrease control
• Loss-resilient feedback protocol
• Flow segregation for non-best-effort networks
• Scheduler to apportion bandwidth

15
CM TCP Performance
TCP Newreno
Flows using CM show good social behavior
Sequence number
With CM
Time (s)
CM greatly improves performance
predictability and consistency
16
Conclusions

• CM ensures proper, stable congestion behavior
• CM tells flows their rates
• Simple, yet powerful API enables adaptation
• Application is in control of what to send
• Improves performance consistency and
  predictability for individual applications
• Makes applications better network citizens

17
Future Work

• Aggregate statistics at domain/subnet level
• Receiver API, protocol for receiver hints
• Flow segregation in non-best-effort networks
• Congestion control for multicast traffic

18
Links to papers

• HotOS paper http//inat.lcs.mit.edu/papers/RBS99.
  ps
• Technical Report (MIT-LCS-TR-771)
• http//inat.lcs.mit.edu/papers/BRS99.ps
• Questions?