Transcript presentation source - Networks and Mobile Systems

The Internet Congestion Manager
Hari Balakrishnan
MIT Laboratory for Computer Science
http://wind.lcs.mit.edu/
CM team
Dave Andersen, Deepak Bansal, Dorothy
Curtis, Bodhi Priyantha, Srinivasan Seshan
Motivation
• End-systems implement many functions
–
–
–
–
–
–
Reliability
In-order delivery
Demultiplexing
Message boundaries
Connection abstraction
Congestion control
Of these, congestion control MUST be
done for all communications
State of Congestion Control
“Multimedia Transmissions Drive Net
Toward Gridlock”
Sara Robinson
New York Times
8/23/99
Two Issues
• Adaptation
– Enable applications to learn about network
conditions and adapt
• Concurrent flows
– Efficiently multiplex streams and share
paths
Congestion Manager (CM): A new end-system
architecture for congestion management
Adaptation
Application
Transport
Network
Link
• Little information transferred
across layers to applications
• More & more non-TCP applications
• Available bandwidth
• Round-trip times
• Loss information
Physical networks
CM exports a simple adaptation API
Concurrent Flows
• Overload causes congestion
Additive-Increase &
Multiplicative-Decrease (AIMD)
“Slow start”
• Concurrent streams compete, causing
aggressive network behavior!
CM abstracts all congestion-related
information into one place
Time
What Can We Do?
• Inside-the-network smarts
–
–
–
–
RED and variants
Fair queueing and variants
Differentiated services
Integrated services
• End-system architecture
– Leverage a decade of experience
– Interact well with router mechanisms
The Big Picture
HTTP
Per-”macroflow” TCP1
statistics
(cwnd,rtt,…)
API
Congestion
Manager
Audio
Video1
TCP2
Video2
UDP
IP
All congestion management tasks performed in CM
Apps learn and adapt using API
The CM Architecture
Application
(TCP, http, video, etc.)
Application
API
Congestion
Controller
API
Hints
Dispatch
Scheduler
Responder
Prober
Sender
CM
protocol
Congestion
Detector
Receiver
Problems
• How does CM control when and whose
transmissions occur?
– Keep application in control of what to
send
• How does CM discover network state?
– What information is shared?
– What is the granularity of sharing?
Key issues: API and information sharing
Transmission API
• Buffered-send
– Does not allow apps to “pull back” data
App
cm_send(
Rate change
,dst)
Pull out and re-encode (hard!)
CM
IP
Packet queue
to dst
Lesson: move buffering into the application
Transmission API (cont.)
• Callback-based send
App
send( )
cm_request()
cmapp_send() based on
allowed rate
Schedule requests,
not packets
CM
IP cm_notify(nsent)
Enables apps to adapt “at the last instant”
Transmission API (cont.)
• Request API works for asynchronous sources
wait for (some_events) {
get_data(); /* e.g., from a file, image capture, etc. */
send();
/* call cm_request() and send on callback */
}
• But what about synchronous sources (e.g.,
audio with constant sampling rate)?
do_every_t_ms { /* timer loop */
get_data();
send();
/* oops, waiting for send callback wrecks timing */
}
• Solution: rate-change callback
cmapp_update(rate, srtt)
Feedback about Network
State
• Monitoring successes and losses
– Application hints
– Probing system
• Notification API (application hints)
– Application calls cm_update(nsent,
nrecd, congestion indicator, rtt)
Probing System
• Receiver modifications necessary
– Support for separate CM header
– Uses sequence number to detect losses
– Sender can request count of packets received
• Receiver modifications detected/negotiated
via handshake
– For incremental deployment
IP header
IP payload
CM header
IP payload
Congestion Controller
• Responsible for deciding when to send
a packet
• Window-based AIMD with traffic
shaping (“TCP-friendly”)
• Exponential aging when feedback low
– Halve window every RTT (use min RTT)
• Can plug in other algorithms
– Selected on a “macroflow” granularity
CM Scheduler
• Responsible for deciding who should
send a packet
• Currently hierarchical round robin
• Hints from application or receiver
– Used to prioritize flows
• Plug in other algorithms
– Selected on a “macroflow” granularity
– Prioritization interface may be different
How will apps use the CM?
• TCP
– Asynchronous callback API
• HTTP
– Rate callbacks to decide content
• Congestion controlled UDP
– Buffered API
• Conferencing applications
– Synchronous API for real-time streams
– Combination of others for other streams
TCP/CM
1. cm_open
TCP
(reliability,
conn. mgmt.)
7. cm_close
2. cm_request
4. send
6. cm_update
3. cmapp_send
on ACK
CM
5. cm_notify
IP
Steps 2-6 occur multiple times
Sequence number
CM Web Performance
TCP Newreno
Time (s)
CM greatly improves
predictability
and consistency
With CM
Layered Streaming Audio
Sequence number
450
400
350
Competing TCP
300
TCP/CM
250
200
150
Audio/CM
100
50
0
0
5
10
15
Time (s)
20
25
Audio adapts to available bandwidth
Combination of TCP & Audio compete equally with
normal TCP
Status & Future
• Implementation in progress (Linux)
–
–
–
–
•
•
•
•
TCP/CM + Web server
Layered audio server
Congestion-controlled UDP sockets
Modify clients to reflect user preferences
Handling diffserv and traffic splitters
Aggregation: per-host, per-subnet,…
Feedback frequency analysis
Aging of congestion information
Deployment Issues
• In the long-term, change senders and
receivers to use the CM
• In the short-term, change only
senders e easier deployment
– Requires receiver app feedback (e.g.,
TCP ACKs)
• CM protocol and headers negotiable
e incremental deployment
• IETF working group to be formed
Summary
• CM enables proper and stable
congestion behavior
• Simple API to enable application to
learn and adapt to network state
• Improves consistency and
predictability of network transfers
• Provides benefit even when deployed
at senders alone