Download iNAT: End-to-end congestion management for the NGI

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Net bias wikipedia , lookup

Remote Desktop Services wikipedia , lookup

IEEE 1355 wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Internet protocol suite wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

TCP congestion control wikipedia , lookup

Transcript
End-to-end Congestion
Management for the NGI
Hari Balakrishnan
MIT Laboratory for Computer Science
http://nms.lcs.mit.edu/
DARPA NGI PI Meeting
October 2, 2000
Srinivasan Seshan (CMU), Frans Kaashoek (MIT)
Dave Andersen, Deepak Bansal, Dorothy Curtis, Nick Feamster
iNAT Project: Motivation
• Increasing heterogeneity in the Internet
– Nodes: Mobiles, devices, sensors,...
– Links: Optical, wireless,...
– Services & applications: Web, telepresence,
streaming, remote device control
• Need a general solution for applications to
discover resources and deal with mobility
• Need a general framework for learning about
and adapting to changing network conditions
iNAT Approach
• Intelligent naming
– Resource discovery: Intentional Naming System
(INS) using expressive names and self-configuring
name resolver overlay network
– Mobility: Via dynamic name updates and secure
connection migration (check out demo!)
• Adaptive transmission
– End-system congestion management and
adaptation framework for the NGI
– Congestion Manager software and algorithms
The Problem
• End-to-end congestion management is essential
– Reacting when congestion occurs
– Probing for spare bandwidth when it doesn’t
– The future isn’t about just TCP!
• Many applications are inherently adaptive, but they
don’t adapt today
– Enable applications to learn about network conditions
• Many applications use concurrent flows between
sender and receiver, which has adverse effects
– Enable efficient multiplexing and path sharing
Congestion Manager (CM): A new end-system
architecture for congestion management
The Big Picture
HTTP
Per-”macroflow” TCP1
statistics
(cwnd,rtt,…)
API
Congestion
Manager
Audio
Video1
TCP2
Video2
UDP
IP
Flows aggregated into macroflows to share congestion state
All congestion management tasks performed in CM
Apps learn and adapt using API
CM Architecture
Sender
Receiver
Application
(TCP, HTTP, RTP, etc.)
API
Congestion
Controller
Stable controls
Deciding when
to send
feedback
cm_update(feedback) API
Hints
Dispatch
Scheduler
Sharing macroflow
bandwidth
Deciding who
can send
Prober
Application
Responder
CM
protocol
Congestion
Detector
Transmission API
• Traditional kernel buffered-send has problems
– Does not allow app to “pull back” data
App
Rate change
cm_send( ,dst)
Can’t pull out and re-encode
CM
IP
Packets queued
to dst
Lesson: move buffering into the application
Transmission API (cont.)
• Callback-based send
App
send( )
cm_request()
CM
IP
cmapp_send() based on
allowed rate
Schedule requests,
not packets
Enables apps to adapt “at the last instant”
Benefits of macroflow sharing
• Shared learning
– Avoids overly aggressive behavior
– Good for Internet stability and fairness
• Adoption incentives
– More consistent performance of concurrent
downloads
– Avoids independent slow-starts and improves
response times
– Beats persistent-connection HTTP on interactive
performance by allowing parallel downloads
Sequence number
CM Web Performance
TCP Newreno
With CM
Time (s)
CM greatly improves
predictability and consistency
of downloads
CM applications
• TCP over CM
• Congestion-controlled UDP
• HTTP server
– Uses TCP/CM for concurrent connections
– cm_query() to pick content formats
• SCTP: Stream Control Transport Protocol
• Real-time streaming applications
– Synchronous API for audio (e.g., vat)
– Callback API for video (scalable MPEG-4 delivery
system)
Congestion Control for
Streaming Applications
• CM provides a flexible framework for per-macroflow
congestion control algorithms
• TCP-style additive-increase/multiplicative decrease
(AIMD) is ill-suited for streaming media
MD causes large, drastic rate changes
Slow start
Time
• Goal: Smooth rate reductions
TCP-friendliness
• Throughput vs. loss-rate equation for AIMD:
l  K  size / (sqrt(p)  RTT)
• Important for safe deployment and
competition with TCP connections
• Two different approaches:
– Increase/Decrease rules
• Increase: w(t+R)  I(w); e.g., w+1 or 2w
• Decrease: w(t+dt)  D(w), e.g., w/2
– Loss-rate monitoring (e.g., TFRC)
• Estimate loss rate, p, and set rate  f(p)
Binomial Algorithms
• I(w) and D(w) are nonlinear functions
– I: w(t+R)  w + a / wK
– D: w(t+ dt)  w - b wL
• Generalize linear algorithms
– AIMD (K=0, L=1); MIMD (K=-1, L=1)
• When L < 1, reductions are smaller than
multiplicative-decrease
• Are there interesting TCP-friendly binomial
algorithms?
The (K,L) space
I: w(t+R)  w + a / wK
D: w(t+ dt)  w - b wL
MIMD
L
1 AIMD
Unstable
(L > 1)
Less aggressive than AIMD
(K+L > 1)
SQRT (K=L=0.5)
IIAD (K=1, L=0)
MIAD
0 AIAD
K
More aggressive than AIMD
Unstable
TCP-friendly
(-1 < K+L < 1)
(K+L < -1)
K+L = 1
Window Evolution
w(t)
dw/dt = a / (wK RTT)
AIMD
Trade-off between increase aggressiveness
and decrease magnitude
TCP-friendliness rule: K+L = 1
t
Binomial Algorithms Benefit
Layered MPEG-4 Delivery
CM Linux Implementation
App stream
Stream requests, updates
cmapp_*()
libcm.a
System calls (e.g., ioctl)
TCP
Control socket for callbacks
CM macroflows, kernel API
Congestion
controller
ip_output()
User-level library;
implements API
UDP-CC
Scheduler
Prober
cm_notify()
IP
ip_output()
Server performance
CPU seconds
45
for 200K pkts
40
cmapp_send()
35
30
Buffered UDP-CC
25
TCP, no delack
20
TCP/CM, no delack
15
TCP/CM, w/ delack
10
TCP, w/ delack
5
0
0
200
400
600
800
1000
1200
Packet size (bytes)
1400
1600
Status
• CM Linux alpha code release this week
http://nms.lcs.mit.edu/projects/cm/
• Sender-only CM soon to be up for proposed
standard in IETF ECM working group
WG document: draft-ietf-ecm-cm-02.txt
Mailing list: [email protected]
• On-going work:
–
–
–
–
–
Evaluation of “slowly responsive” algorithms
Macroflow formation for diffserv
Congestion control vs. feedback frequency
CM scheduler algorithms
Using binomial algorithms on high-speed paths
Summary
• Congestion Manager (CM) framework
provides end-to-end adaptation platform for
NGI applications and protocols
• CM enables:
– Adaptive applications using application-level
framing (ALF) ideas
– Efficient multiplexing and stable control of
concurrent flows by sharing path information
– Per-macroflow congestion control algorithms,
including binomial algorithms for streaming media
• Download it!