1 / 21

CADPC/PTP in a nutshell

CADPC/PTP in a nutshell. Michael Welzl http://www.welzl.at , michael.welzl@uibk.ac.at Distributed and Parallel Systems Group Institute of Computer Science University of Innsbruck. Outline. Problem identification The PTP signaling protocol The CADPC congestion control mechanism

gwayne
Télécharger la présentation

CADPC/PTP in a nutshell

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Outline • Problem identification • The PTP signaling protocol • The CADPC congestion control mechanism • Simulation results • Conclusion

  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. 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 packetsrate should not depend on round trip time ... yes it does :-)

  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. Forward Packet Stamping: how it works

  7. Forward Packet Stamping: how it works

  8. Forward Packet Stamping: how it works

  9. CADPC: a new CC mechanism • “Congestion Avoidance withDistributedProportional 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. Some simulation results Many more can be found in: Michael Welzl, „Scalable Performance Signalling and Congestion Avoidance“, Kluwer Academic Publishers 2003.

  11. CADPC vs. TCP

  12. 10 x TFRC 10 x CADPC Smoothness

  13. Startup enhancement

  14. Heterogeneous RTTs + Robustness

  15. CADPC vs. TCP-friendly CC. mechanisms Throughput Loss Avg. Queue Length Fairness

  16. CADPC vs. 3 TCP(+ECN) flavors

  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. 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. 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. 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. The End ... • Publications • CADPC+PTP ns code • PTP Linux code (router kernel patch + end system implementation) • Future updates http://www.welzl.at/ptp

More Related