Scalable Performance Performance Signalling Signalling Scalable - - PowerPoint PPT Presentation

U Innsbruck Informatik U Innsbruck Informatik -

• 1

1

Scalable Scalable Performance Performance Signalling Signalling and Congestion and Congestion Avoidance Avoidance

PhD PhD presentation presentation Supervisor Supervisor: Max Mühlhäuser 2nd : 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 Michael Welzl 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 Internet Congestion Control Control ( (CC CC) )

• 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

RED ECN

here: PTP here:CADPC

Browser, FTP…

TCP, UDP… IP, ICMP…

OSI: 7 4 3 2

Browser, FTP, ..

UDP, TCP… IP, ICMP…

IP, ICMP… IP, ICMP…

• Later: some extra work for routers

– active queue management: RED, actual communication: ECN

U Innsbruck Informatik U Innsbruck Informatik -

• 4

4

Some Some problems problems with with TCP( TCP(-

• like

like) CC ) 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 -

• 5

5

Quality Quality-

• of
• f-
• Service

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

Guaranteed Bandwidth Available Bandwidth TCP Rate QoS CC TCP TCP-friendly Resource Reservation Adaptive Multimedia Best for Best for both both worlds? worlds?

U Innsbruck Informatik U Innsbruck Informatik -

• 6

6

Proposed Proposed Solution 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 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: PTP: the the framework framework

• -> class

Transmission mode Content Type(s) Performance Parameter End node behaviour Forward Packet Stamping CT 2/3 Available Bandwidth CADPC

• -> instance

U Innsbruck Informatik U Innsbruck Informatik -

• 9

9

PTP: PTP: the the signalling signalling protocol 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 -

• 10

10

Forward Packet Forward Packet Stamping Stamping: : how how it it works works

U Innsbruck Informatik U Innsbruck Informatik -

• 11

11

Forward Packet Forward Packet Stamping Stamping: : how how it it works works

U Innsbruck Informatik U Innsbruck Informatik -

• 12

12

Forward Packet Forward Packet Stamping Stamping: : how how it it works works

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

• “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)

relate traffic : target rate relate user‘s rate : available bandwidth

U Innsbruck Informatik U Innsbruck Informatik -

• 15

15

CADPC, CADPC, contd 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 -

• 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 Unless otherwise

• therwise mentioned

mentioned... ...

4 RTTs CADPC update frequency 0.5 CADPC smoothness factor a 50 packets Bottleneck Queue Length TCP Reno TCP flavour Greedy, long-lived Flow type 0 seconds All flows start after Long-term: 160 seconds Duration Drop-tail Queueing discipline 50 ms each Link delay 1000 Mbit/s Bandwidth of all other links 10 Mbit/s Bottleneck Link Bandwidth 1000 bytes Packet Sizes Dumbbell Topology

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 Startup enhancement enhancement

U Innsbruck Informatik U Innsbruck Informatik -

• 21

21

Heterogeneous Heterogeneous RTTs RTTs + + Robustness Robustness

U Innsbruck Informatik U Innsbruck Informatik -

• 22

22

CADPC vs. CADPC vs. TCP TCP-

• friendly

friendly CC.

• CC. mechanisms

mechanisms

Throughput

• Avg. Queue Length

Loss Fairness

U Innsbruck Informatik U Innsbruck Informatik -

• 23

23

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

U Innsbruck Informatik U Innsbruck Informatik -

• 24

24

Further Further simulations simulations (in (in the the thesis 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 -

• 25

25

Outline Outline

• Problem identification / motivation
• Proposed solution
• Simulation results
• Conclusion

U Innsbruck Informatik U Innsbruck Informatik -

• 26

26

– simulation results – ns simulator code

• PTP

– Framework – Protocol

• ns simulator code
• Linux code
• CADPC

– fluid-model simulator

• vector diagram based

analysis of TCP behaviour

TCP 2 TCP 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

Tangible Tangible Outcomes Outcomes

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

• 28

28

CADPC Advantages /2 CADPC Advantages /2

• Useful for asymmetric links
• Useful for noisy (wireless) links + “long fat pipes”
• Useful for QoS and load-based charging

Disadvantages Disadvantages

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

• 29

29

IMHO: IMHO: considerable considerable step step towards towards better better congestion congestion control control ...b ...based ased on

• n drastic

drastic departure departure from from existing existing approaches approaches

U Innsbruck Informatik U Innsbruck Informatik -

• 30

30

Future Future work 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 -

• 31

31

The The End ... 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 -

• 32

32

Additional Additional information information

U Innsbruck Informatik U Innsbruck Informatik -

• 33

33

The The end2end end2end argument argument

U Innsbruck Informatik U Innsbruck Informatik -

• 34

34

This This thesis thesis and and the the end2end end2end argument argument

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

• 35

35

AIMD Background AIMD Background

U Innsbruck Informatik U Innsbruck Informatik -

• 36

36 User 1 Allocation x1 Fairness Line Efficiency Line User 2 Allocation x2

Starting Point

AIMD Desirable

Starting Point

AIAD MIMD Underload Overload

AIMD in AIMD in Theory Theory ( (equal equal RTTs RTTs) )

User 1 Allocation x1 Fairness Line Efficiency Line User 2 Allocation x2

Starting Point

AIMD Desirable

Starting Point

AIAD MIMD Underload Overload

U Innsbruck Informatik U Innsbruck Informatik -

• 37

37

AIMD / AIMD / asynchronous asynchronous RTTs RTTs

U 2

SER

User 1

• 0.0500

0.0000 0.0500 0.1000 0.1500 0.2000 0.2500 0.3000 0.3500 0.4000 0.4500 0.5000 0.5500 0.6000 0.6500 0.7000 0.7500 0.8000 0.8500 0.9000 0.9500 1.0000 0.0000 0.2000 0.4000 0.6000 0.8000 1.0000

• fluid model
• RTT: 7 vs. 2
• AI=0.1, MD=0.5
• Simul. time=175

U Innsbruck Informatik U Innsbruck Informatik -

• 38

38

AIMD in AIMD in practise practise (TCP) (TCP)

TCP 2 TCP 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

• ns simulator
• TCP Reno
• “equal“ RTT
• 1 bottleneck link

U Innsbruck Informatik U Innsbruck Informatik -

• 39

39

CADPC Design CADPC Design

U Innsbruck Informatik U Innsbruck Informatik -

• 40

40

Endpoint Endpoint Mechanism Mechanism Design Design Algorithm Algorithm(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 -

• 41

41

CADPC CADPC vector vector diagram diagram analysis analysis

U Innsbruck Informatik U Innsbruck Informatik -

• 42

42

CADPC CADPC synchronous synchronous case case fluid fluid analysis analysis

• Final formula per user:

x(t+1) = x(t)a(1-x(t)-traffic)+x(t) x(t) ... normalised rate at time t a... 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

0,2 0,6 1 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29