1. U Innsbruck Informatik - 1 CADPC/PTP in a nutshell Michael Welzl http://www.welzl.at, michael.welzl@uibk.ac.at http://www.welzl.atmichael.welzl@uibk.ac.at http://www.welzl.atmichael.welzl@uibk.ac.at Distributed and Parallel Systems Group Institute of Computer Science University of Innsbruck

2. U Innsbruck Informatik - 2 Outline Problem identification The PTP signaling protocol The CADPC congestion control mechanism Simulation results Conclusion

3. U Innsbruck Informatik - 3 Some 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

4. U Innsbruck Informatik - 4 The CADPC/PTP 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 packets rate should not depend on round trip time... yes it does :-)

5. U Innsbruck Informatik - 5 The Performance Transparency Protocol (PTP) Basic idea: query routers for performance related information –designed to be as lightweight as possible Stateless + simple  scalable! –all calculations @ end nodes Only every 2nd router needed for full functionality PTP Available Bandwidth Determination: –packet queries for: nominal bandwidth (“ifSpeed“) + address + traffic counter (“if(In/Out)Octets“) + timestamp) 2 consecutive such packets: table of traffic + interval at all routers at receiver receiver calculates available bandwidth at bottleneck, informs sender Designed for flexibility - two modes: –Forward Packet Stamping, Direct Reply (not for available bandwidth (byte counters)) No problems w/ wireless links!

6. U Innsbruck Informatik - 6 Forward Packet Stamping: how it works

7. U Innsbruck Informatik - 7 Forward Packet Stamping: how it works

8. U Innsbruck Informatik - 8 Forward Packet Stamping: how it works

9. U Innsbruck Informatik - 9 CADPC: a new CC mechanism “Congestion Avoidance with Distributed Proportional Control“ fully distributed convergence to max-min fairness –each source increases/decreases the rate depending on its capacity share 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

10. U Innsbruck Informatik - 10 Some simulation results Many more can be found in: Michael Welzl, „Scalable Performance Signalling and Congestion Avoidance“, Kluwer Academic Publishers 2003.

11. U Innsbruck Informatik - 11 CADPC vs. TCP

12. U Innsbruck Informatik - 12 Smoothness 10 x TFRC10 x CADPC

13. U Innsbruck Informatik - 13 Startup enhancement

14. U Innsbruck Informatik - 14 Heterogeneous RTTs + Robustness

15. U Innsbruck Informatik - 15 Throughput Loss Avg. Queue LengthFairness CADPC vs. TCP-friendly CC. mechanisms

16. U Innsbruck Informatik - 16 CADPC vs. 3 TCP(+ECN) flavors

17. U Innsbruck Informatik - 17 CADPC 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 :)

18. U Innsbruck Informatik - 18 CADPC Advantages /2 Useful for asymmetric links Useful for noisy (wireless) links + “long fat pipes” Useful for QoS and load-based charging Disadvantages Requires router support Requires traffic isolation because… –not tcp-friendly –slowly responsive: bad results with web traffic

19. U Innsbruck Informatik - 19 Related work XCP: closely related; main difference: –CADPC/PTP: explicit extra signaling packets (e.g. only 1 probe message every 4 RTTs, no TCP-like ACKs for every packet) –XCP: routers examine every (payload) packet, TCP-like ACKs for every packet necessary FAST TCP: –no explicit help from routers; utilizes delay –good idea, but less efficient than utilizing traffic measurements (like ECN: reaction almost too late) –patent protected Scalable TCP, Highspeed TCP: –different increase decrease behavior –less efficient than above variants

20. U Innsbruck Informatik - 20 Conclusion Separate signaling protocol + RTT-independence + high efficiency make CADPC/PTP applicable in various domains Possibilities: –control of traffic aggregates (signaling between edge routers) –control of microflows within a DiffServ class  scalable fine-grain QoS –etc. ! This is where projects come into play !!!

21. U Innsbruck Informatik - 21 The End... Publications CADPC+PTP ns code PTP Linux code (router kernel patch + end system implementation) Future updates http://www.welzl.at/ptp