scalable performance signalling and congestion avoidance
DESCRIPTION
Scalable Performance Signalling and Congestion Avoidance. PhD presentation Supervisor: Max Mühlhäuser 2nd supervisor: Jon Crowcroft Abteilung Telekooperation, TU Darmstadt, Nov. 18th 2002. Michael Welzl [email protected] University of Linz -> University of Innsbruck. Outline. - PowerPoint PPT PresentationTRANSCRIPT
U Innsbruck Informatik - U Innsbruck Informatik - 11
Scalable Performance Scalable Performance SignallingSignalling
and Congestion Avoidanceand Congestion Avoidance
Michael WelzlMichael [email protected]
University of Linz -> University of InnsbruckUniversity of Linz -> University of Innsbruck
PhD presentationPhD presentation
Supervisor: Max Mühlhäuser 2nd supervisor: Jon CrowcroftSupervisor: Max Mühlhäuser 2nd supervisor: Jon Crowcroft
Abteilung Telekooperation, TU Darmstadt, Nov. 18th 2002Abteilung Telekooperation, TU Darmstadt, Nov. 18th 2002
U Innsbruck Informatik - U Innsbruck Informatik - 22
OutlineOutline
• Problem identification / motivation
• Proposed solution
• Simulation results
• Conclusion
U Innsbruck Informatik - U Innsbruck Informatik - 33
Internet Congestion Control (Internet Congestion Control (CCCC))
• Necessary to keep the Internet stable– prevent congestion collapse
• must be scalable (bad? old) idea:• no extra work for routers: congestion detected via packet loss in TCP
• Later: some extra work for routers
– active queue management: RED, actual communication: ECN
RED ECN
here: PTP
here:CADPCBrowser, FTP…
TCP, UDP…
IP, ICMP…
OSI:
7432
Browser, FTP, ..
UDP, TCP…
IP, ICMP…IP, ICMP… IP, ICMP…
U Innsbruck Informatik - U Innsbruck Informatik - 44
Some problems with TCP(-like) CCSome problems with TCP(-like) CC
• Special links (becoming common!):– noisy (wireless) links– “long fat pipes“ (large bandwidth*delay product)
• Stability issues– Fluctuations lead to regular packet drops + reduced throughput
=> problematic for streaming media– Stability depends on delay, capacity, load, AQM
• Rate hard to control / trace / predict– Load based charging difficult
• Main reason: binary congestion notification (E)CN– when it occurs, it‘s (almost) too late
U Innsbruck Informatik - U Innsbruck Informatik - 55
Quality-of-Service Quality-of-Service CC CC
• Separate research areas up to now!!
• Common goals– efficiently use available bandwidth– provide “good“ QoS
• Theory– AIMD, self-clocking, ..
• Practice– Problem with Multimedia
QoS CC
TCP
TCP-friendlyResourceReservation
AdaptiveMultimedia
Best forboth worlds?
Guaranteed BandwidthAvailable Bandwidth
TCP Rate
U Innsbruck Informatik - U Innsbruck Informatik - 66
Proposed SolutionProposed Solution
• Totally different CC model– only rely on rare explicit bandwidth (=traffic) signaling
• Assumptions:
– extra forward signalling for CC = good idea ( common belief!!)
– router support
– mechanism must clearly outperform TCP to justify (even a little!) additional traffic
– timeouts necessary for loss of signalling packetsrate should not depend on round trip time RTT
U Innsbruck Informatik - U Innsbruck Informatik - 77
• Problem identification / motivation
• Proposed solution
– PTP framework
– CADPC
• Simulation results
• Conclusion
OutlineOutline
U Innsbruck Informatik - U Innsbruck Informatik - 88
PTP: the frameworkPTP: the framework
--> class
Transmission mode
ContentType(s)
PerformanceParameter
End node behaviour
Forward Packet Stamping
CT 2/3 AvailableBandwidth
CADPC
--> instance
U Innsbruck Informatik - U Innsbruck Informatik - 99
PTP: the signalling protocolPTP: the signalling protocol
• quasi “generic ECN” - to carry performance information(standardised Content Types, e.g. queue length, ..)– resembles ATM ABR and XCP
• Stateless + simple -> scalable!– all calculations @ end nodes
• Only every 2nd router needed for full functionality
• e.g. Available Bandwidth Determination:– nominal bandwidth (“ifSpeed“) + 2* (address + traffic counter
(“if(In/Out)Octets“) + timestamp) = available bandwidth
• two modes:– Forward Packet Stamping– Direct Reply (not for available bandwidth (byte counters))
No problems w/ wireless links
unless combined with packet loss!
U Innsbruck Informatik - U Innsbruck Informatik - 1010
Forward Packet Stamping: how it Forward Packet Stamping: how it worksworks
U Innsbruck Informatik - U Innsbruck Informatik - 1111
Forward Packet Stamping: how it Forward Packet Stamping: how it worksworks
U Innsbruck Informatik - U Innsbruck Informatik - 1212
Forward Packet Stamping: how it Forward Packet Stamping: how it worksworks
U Innsbruck Informatik - U Innsbruck Informatik - 1313
• Problem identification / motivation
• Proposed solution
– PTP framework
– CADPC
• Simulation results
• Conclusion
OutlineOutline
U Innsbruck Informatik - U Innsbruck Informatik - 1414
CADPC: a new CC CADPC: a new CC mechanismmechanism
• “Congestion Avoidance with Distributed Proportional Control“fully distributed convergence to max-min fairness
• Idea:– relate user‘s current rate to the state of the system (also in
LDA+)In the Chiu-Jain-diagram, if the rate increase factor is indirectly proportional to the user‘s current rate, the rates will equalise.
• From:– erx = 1 + d* rup = 1 + rup * (1 - traffic/r0)
• To:– erx = 1 + d * (1 - myRate/d)
• Final formula (normalised with Bottleneck capacity):x(t+1) = x(t)a(1-x(t)-traffic)+x(t)
relatetraffic : target rate
relateuser‘s rate : available
bandwidth
U Innsbruck Informatik - U Innsbruck Informatik - 1515
CADPC, contd.CADPC, contd.
• Only depends on old rate, smoothness factor and traffic– does not depend on RTT
• Feedback packets can be delayed => scalable• reasonable choice: 4 x RTT
• Control realises logistic growth– Asymptotically stable in simplified fluid model with synchronous
RTTs– Smooth convergence to a steady rate
• Initial convergence can be slow (depending on bg traffic)– startup enhancement: temporarily sacrifice stability
U Innsbruck Informatik - U Innsbruck Informatik - 1616
OutlineOutline
• Problem identification / motivation
• Proposed solution
• Simulation results
– Dynamic behaviour
– Long-term performance evaluation
• Conclusion
U Innsbruck Informatik - U Innsbruck Informatik - 1717
Unless otherwise mentioned...Unless otherwise mentioned...
Topology Dumbbell
CADPC update frequency 4 RTTs
CADPC smoothness factor a
0.5
Packet Sizes 1000 bytes
Bottleneck Link Bandwidth 10 Mbit/s
Bandwidth of all other links 1000 Mbit/s
Link delay 50 ms each
Queueing discipline Drop-tail
Duration Long-term: 160 seconds
All flows start after 0 seconds
Flow type Greedy, long-lived
TCP flavour TCP Reno
Bottleneck Queue Length 50 packets
U Innsbruck Informatik - U Innsbruck Informatik - 1818
CADPC vs. TCPCADPC vs. TCP
U Innsbruck Informatik - U Innsbruck Informatik - 1919
SmoothnessSmoothness
10 x TFRC 10 x CADPC
U Innsbruck Informatik - U Innsbruck Informatik - 2020
Startup enhancementStartup enhancement
U Innsbruck Informatik - U Innsbruck Informatik - 2121
Heterogeneous RTTs + RobustnessHeterogeneous RTTs + Robustness
U Innsbruck Informatik - U Innsbruck Informatik - 2222
Throughput Loss
Avg. Queue Length Fairness
CADPC vs. TCP-friendly CC. CADPC vs. TCP-friendly CC. mechanismsmechanisms
U Innsbruck Informatik - U Innsbruck Informatik - 2323
CADPC vs. 3 TCP(+ECN) flavorsCADPC vs. 3 TCP(+ECN) flavors
U Innsbruck Informatik - U Innsbruck Informatik - 2424
Further simulations (in the thesis)Further simulations (in the thesis)
• Dynamic:– Dependence on smoothness parameter a and packet size– Robustness against fast routing changes– Effect of mixing converged flows– Performance across highly asymmetric connections + noisy links
• Long-term (throughput, loss, average queue length, fairness):– Check valid parameter space: bandwidth, no. of flows, packet
size– Varying bottleneck bandwidth– Varying feedback delay– RED, REM and AVQ Active Queue Management– Behaviour with varying amount of web background traffic– Max-min fairness (scenario with 2 bottlenecks)
U Innsbruck Informatik - U Innsbruck Informatik - 2525
OutlineOutline
• Problem identification / motivation
• Proposed solution
• Simulation results
• Conclusion
U Innsbruck Informatik - U Innsbruck Informatik - 2626
– simulation results
– ns simulator code
Tangible OutcomesTangible Outcomes
• PTP– Framework– Protocol
• ns simulator code• Linux code
• CADPC– fluid-model
simulator
• vector diagram basedanalysis of TCP behaviour
T C P 2
T C P 1
1 .0000
1 .5000
2 .0000
2 .5000
3 .0000
3 .5000
4 .0000
4 .5000
5 .0000
5 .5000
6 .0000
6 .5000
7 .0000
7 .5000
8 .0000
8 .5000
9 .0000
9 .5000
10 .0000
2 .0000 4 .0000 6 .0000 8 .0000 10 .0000 12 .0000 14 .0000
U Innsbruck Informatik - U Innsbruck Informatik - 2727
CADPC AdvantagesCADPC Advantages
• high utilisation
• close to zero loss
• small bottleneck queue length
• very smooth rate
• fully distributed precise max-min-fairness
• rapid response to bandwidth changes (e.g. from routing)
• provable asymptotic stability (synchronous RTTs, fluid model)
some say it‘s impossible :)
U Innsbruck Informatik - U Innsbruck Informatik - 2828
CADPC Advantages /2CADPC Advantages /2
• Useful for asymmetric links
• Useful for noisy (wireless) links + “long fat pipes”
• Useful for QoS and load-based charging
DisadvantagesDisadvantages
• Requires router support
• Requires traffic isolation because…– not tcp-friendly– slowly responsive: bad results with web traffic
but: sticks to KISS principle
but: see future work...
U Innsbruck Informatik - U Innsbruck Informatik - 2929
IMHO:IMHO: considerable step towards considerable step towardsbetter congestion controlbetter congestion control
...b...based on drastic departure from ased on drastic departure from existing approachesexisting approaches
U Innsbruck Informatik - U Innsbruck Informatik - 3030
Future workFuture work
• So far, ...– only max-min-fairness supported– only greedy sources simulated
• Gradual deployment ideas:
– CADPC / PTP within a DiffServ class (QoS “in the small“):“we offer QoS + provide router support,you use CADPC and obtain a good result[and we can calculate your rate, too]“
– If CADPC works with non-greedy senders:edge2edge PTP signalling
• PTP supported traffic engineering (TCP over CADPC)• CADPC <=> TCP translation at edge routers?
U Innsbruck Informatik - U Innsbruck Informatik - 3131
The End ...The End ...
• Related publications
• PTP ns code
• PTP Linux code (router kernel patch + end system implementation)
• Future updates: thesis, CADPC code, ..
http://fullspeed.to/ptp
U Innsbruck Informatik - U Innsbruck Informatik - 3232
Additional informationAdditional information
U Innsbruck Informatik - U Innsbruck Informatik - 3333
The end2end argumentThe end2end argument
U Innsbruck Informatik - U Innsbruck Informatik - 3434
This thesis and the end2end This thesis and the end2end argumentargument
• „Lower-level layers, which support many independent applications, should provide only resources of broad utility across applications, while providing to applications usable means for effective sharing of resources and resolution of resource conflicts. (network transparency)“
[Active Networking and End-To-End Arguments, Comment by David P. Reed, Jerome H. Saltzer, and David D. Clark]
• Goals of this thesis:
– provide such means– use it!
U Innsbruck Informatik - U Innsbruck Informatik - 3535
AIMD BackgroundAIMD Background
U Innsbruck Informatik - U Innsbruck Informatik - 3636
U ser 1 A lloca tion x1
F a irnessL ine
E ffic iencyL ine
Use
r 2
Allo
catio
n x
2
StartingPoint
A IM D
D esirab le
StartingPoint
A IA D
M IM D
U nderload
O verload
AIMD in Theory (equal RTTs)AIMD in Theory (equal RTTs)
U ser 1 A lloca tion x1
F a irnessL ine
E ffic iencyL ine
Use
r 2
Allo
catio
n x
2
StartingPoint
A IM D
D esirab le
StartingPoint
A IA D
M IM D
U nderload
O verload
U Innsbruck Informatik - U Innsbruck Informatik - 3737
AIMD / asynchronous RTTsAIMD / asynchronous RTTs
U 2SE R
U ser 1-0 .050 0
0 .000 0
0 .050 0
0 .100 0
0 .150 0
0 .200 0
0 .250 0
0 .300 0
0 .350 0
0 .400 0
0 .450 0
0 .500 0
0 .550 0
0 .600 0
0 .650 0
0 .700 0
0 .750 0
0 .800 0
0 .850 0
0 .900 0
0 .950 0
1 .000 0
0 .000 0 0 .200 0 0 .400 0 0 .600 0 0 .800 0 1 .000 0
• fluid model• RTT: 7 vs. 2• AI=0.1, MD=0.5• Simul. time=175
U Innsbruck Informatik - U Innsbruck Informatik - 3838
T C P 2
T C P 1
1 .0000
1 .5000
2 .0000
2 .5000
3 .0000
3 .5000
4 .0000
4 .5000
5 .0000
5 .5000
6 .0000
6 .5000
7 .0000
7 .5000
8 .0000
8 .5000
9 .0000
9 .5000
10 .0000
2 .0000 4 .0000 6 .0000 8 .0000 10 .0000 12 .0000 14 .0000
AIMD in practise (TCP)AIMD in practise (TCP)
• ns simulator• TCP Reno• “equal“ RTT• 1 bottleneck link
U Innsbruck Informatik - U Innsbruck Informatik - 3939
CADPC DesignCADPC Design
U Innsbruck Informatik - U Innsbruck Informatik - 4040
Endpoint Mechanism Design Endpoint Mechanism Design AlgorithmAlgorithm(tm)(tm)
• find useful (closely related) ATM ABR mechanism
• start with simplifications, then expand the model
• A new mechanism must work for 2 users, equal RTT– simple analysis similar to Chiu/Jain (diagram + math)
• it must also work with heterogeneous RTTs– simulate using a simple Diagram Based Simulator(tm)
• it must also work with more users and in more realistic scenarios– simulate with ns
U Innsbruck Informatik - U Innsbruck Informatik - 4141
CADPC vector diagram analysisCADPC vector diagram analysis
U Innsbruck Informatik - U Innsbruck Informatik - 4242
CADPC synchronous case fluid CADPC synchronous case fluid analysisanalysis
• Final formula per user:
x(t+1) = x(t)a(1-x(t)-traffic)+x(t)
x(t) ... normalised rate at time ta... smoothness factor(should be 0 < a <= 1)traffic (normalised) ... from PTP
• Converges to: n/(n+1)
• Continuous-time version of synchronous case (traffic=nx):logistic growth x‘(t) = x(t)a(1-x(t)/c) [c = 1/(1+n)]asymptotically stable equilibrium point: c
00,2
0,6
1
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29