u innsbruck informatik - 1 cadpc/ptp in a nutshell michael welzl , [email protected]...

U Innsbruck Informatik - U Innsbruck Informatik - 11

CADPC/PTP in a nutshellCADPC/PTP in a nutshell

Michael WelzlMichael Welzlhttp://www.welzl.at, , [email protected]

Distributed and Parallel Systems GroupDistributed and Parallel Systems Group

Institute of Computer ScienceInstitute of Computer Science

University of InnsbruckUniversity of Innsbruck


OutlineOutline

• Problem identification

• The PTP signaling protocol

• The CADPC congestion control mechanism

• Simulation results

• Conclusion


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


The CADPC/PTP SolutionThe 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 :-)


The Performance Transparency The Performance Transparency Protocol (PTP)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!


Forward Packet Stamping: how it Forward Packet Stamping: how it worksworks


CADPC: a new CC mechanismCADPC: 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


Some simulation resultsSome simulation results

Many more can be found in:

Michael Welzl, „Scalable Performance Signalling and Congestion Avoidance“, Kluwer Academic Publishers

2003.


CADPC vs. TCPCADPC vs. TCP


SmoothnessSmoothness

10 x TFRC 10 x CADPC


Startup enhancementStartup enhancement


Heterogeneous RTTs + RobustnessHeterogeneous RTTs + Robustness


Throughput Loss

Avg. Queue Length Fairness

CADPC vs. TCP-friendly CC. CADPC vs. TCP-friendly CC. mechanismsmechanisms


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


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 :)


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


Related workRelated 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


ConclusionConclusion

• 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 !!!


The End ...The End ...

• Publications

• CADPC+PTP ns code

• PTP Linux code (router kernel patch + end system implementation)

• Future updates

http://www.welzl.at/ptp

u innsbruck informatik - 1 cadpc/ptp in a nutshell michael welzl , [email protected]...

Documents