U Innsbruck Informatik U Innsbruck Informatik - - 1 1 Scalable Performance Performance Signalling Signalling Scalable and Congestion Avoidance Avoidance and Congestion PhD PhD presentation presentation Supervisor: Max Mühlhäuser 2nd Supervisor : Max Mühlhäuser 2nd supervisor supervisor: Jon : Jon Crowcroft Crowcroft Abteilung Telekooperation, TU Darmstadt, Nov. 18th 2002 Abteilung Telekooperation, TU Darmstadt, Nov. 18th 2002 Michael Welzl Michael Welzl michael.welzl@uibk.ac.at michael.welzl@uibk.ac.at University of Linz University of Linz - -> University of Innsbruck > University of Innsbruck
U Innsbruck Informatik U Innsbruck Informatik - - 2 2 Outline Outline • Problem identification / motivation • Proposed solution • Simulation results • Conclusion
U Innsbruck Informatik U Innsbruck Informatik - - 3 3 Internet Congestion Control Control ( (CC CC) ) Internet Congestion • 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 OSI: here:CADPC 7 Browser, FTP, .. Browser, FTP… here: PTP 4 UDP, TCP… TCP, UDP… 3 IP, ICMP… IP, ICMP… IP, ICMP… IP, ICMP… RED ECN 2 • Later: some extra work for routers – active queue management: RED, actual communication: ECN
U Innsbruck Informatik U Innsbruck Informatik - - 4 4 Some problems problems with with TCP( TCP(- -like like) CC ) CC Some • 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 - - 5 5 Service ↔ ↔ CC Quality- -of of- -Service CC Quality • Separate research areas up to now!! Guaranteed Bandwidth Available Bandwidth • Common goals TCP Rate – efficiently use available bandwidth – provide “good“ QoS • Theory – AIMD, self-clocking, .. • Practice – Problem with Multimedia Best for Best for both both worlds? worlds? Adaptive TCP-friendly Multimedia Resource Reservation TCP QoS CC
U Innsbruck Informatik U Innsbruck Informatik - - 6 6 Proposed Solution Solution Proposed • 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 packets rate should not depend on round trip time RTT
U Innsbruck Informatik U Innsbruck Informatik - - 7 7 Outline Outline • Problem identification / motivation • Proposed solution – PTP framework – CADPC • Simulation results • Conclusion
U Innsbruck Informatik U Innsbruck Informatik - - 8 8 PTP: the the framework framework PTP: --> instance Forward Packet Stamping CADPC Transmission mode End node behaviour Available CT 2/3 Bandwidth Performance Content Parameter Type(s) --> class
U Innsbruck Informatik U Innsbruck Informatik - - 9 9 PTP: the the signalling signalling protocol protocol PTP: • 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 No problems w/ wireless links unless combined • Only every 2nd router needed for full functionality with packet loss! • 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))
U Innsbruck Informatik - U Innsbruck Informatik - 10 10 Forward Packet Stamping Stamping: : how how it it works works Forward Packet
U Innsbruck Informatik U Innsbruck Informatik - - 11 11 Forward Packet Stamping Stamping: : how how it it works works Forward Packet
U Innsbruck Informatik - U Innsbruck Informatik - 12 12 Forward Packet Stamping Stamping: : how how it it works works Forward Packet
U Innsbruck Informatik - U Innsbruck Informatik - 13 13 Outline Outline • Problem identification / motivation • Proposed solution – PTP framework – CADPC • Simulation results • Conclusion
U Innsbruck Informatik - U Innsbruck Informatik - 14 14 CADPC: a new new CC CC mechanism mechanism CADPC: a • “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: relate – erx = 1 + d* rup = 1 + rup * (1 - traffic/r0) traffic : target rate • To: relate – erx = 1 + d * (1 - myRate/d) user‘s rate : available bandwidth • Final formula (normalised with Bottleneck capacity): x(t+1) = x(t)a(1-x(t)-traffic)+x(t)
U Innsbruck Informatik - U Innsbruck Informatik - 15 15 CADPC, contd contd. . CADPC, • 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 - 16 16 Outline Outline • Problem identification / motivation • Proposed solution • Simulation results – Dynamic behaviour – Long-term performance evaluation • Conclusion
U Innsbruck Informatik - U Innsbruck Informatik - 17 17 Unless otherwise otherwise mentioned mentioned... ... Unless 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 - 18 18 CADPC vs. TCP CADPC vs. TCP
U Innsbruck Informatik - U Innsbruck Informatik - 19 19 Smoothness Smoothness 10 x TFRC 10 x CADPC
U Innsbruck Informatik - U Innsbruck Informatik - 20 20 Startup enhancement enhancement Startup
U Innsbruck Informatik - U Innsbruck Informatik - 21 21 Heterogeneous RTTs RTTs + + Robustness Robustness Heterogeneous
U Innsbruck Informatik - U Innsbruck Informatik - 22 22 CADPC vs. TCP TCP- -friendly friendly CC. CC. mechanisms mechanisms CADPC vs. Throughput Loss Avg. Queue Length Fairness
U Innsbruck Informatik - U Innsbruck Informatik - 23 23 CADPC vs. 3 TCP(+ECN) flavors flavors CADPC vs. 3 TCP(+ECN)
U Innsbruck Informatik - U Innsbruck Informatik - 24 24 Further simulations simulations (in (in the the thesis thesis) ) Further • 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 - 25 25 Outline Outline • Problem identification / motivation • Proposed solution • Simulation results • Conclusion
U Innsbruck Informatik - U Innsbruck Informatik - 26 26 Tangible Outcomes Outcomes Tangible TCP 2 10.0000 9.5000 9.0000 8.5000 • PTP 8.0000 7.5000 – Framework 7.0000 – Protocol 6.5000 6.0000 • ns simulator code 5.5000 5.0000 • Linux code 4.5000 4.0000 3.5000 3.0000 • CADPC 2.5000 2.0000 – fluid-model simulator 1.5000 • vector diagram based 1.0000 TCP 1 analysis of TCP behaviour 2.0000 4.0000 6.0000 8.0000 10.0000 12.0000 14.0000 – ns simulator code – simulation results
U Innsbruck Informatik - U Innsbruck Informatik - 27 27 CADPC Advantages CADPC Advantages • high utilisation • close to zero loss • small bottleneck queue length • very smooth rate some say it‘s • fully distributed precise max-min-fairness impossible :) • rapid response to bandwidth changes (e.g. from routing) • provable asymptotic stability (synchronous RTTs, fluid model)
Recommend
More recommend
