User 2 Allocation x2User 2 Allocation x2

(1)

Scalable High

Scalable High - - Speed Congestion Control Speed Congestion Control with with

Explicit Traffic Signaling Explicit Traffic Signaling

Max Mühlhäuser Max Mühlhäuser max@informatik.tu

max@informatik.tu--darmstadt.dedarmstadt.de TU Darmstadt Michael Welzl

Michael Welzl michael

michael.welzl@uibk.ac..welzl@uibk.ac.atat University

University ofof InnsbruckInnsbruck TU Darmstadt

(2)

Outline Outline

• What?

• Why?

• How?

• Conclusion + future work

(3)

Out Out - - of of - - band signaling to support CC band signaling to support CC ? ?

• Yes, that‘s right

– several reasons against in-band ... I‘ll explain offline

• Idea similar to ATM ABR Explicit Rate Feedback, but:

– scalable

– efficient (lightweight) – designed for packet nets

– a generic signaling framework

• Various endpoint adaptation mechanisms possible

– I found a good one :)

(4)

Outline Outline

• What?

• Why?

• How?

• Conclusion + future work

(5)

Reasons against TCP Reasons against TCP

• TCP over wireless:

– checksum error -> packet drop misinterpretation

• TCP over “long fat pipes“: (large bandwidth*delay product)

– long time to reach equilibrium, MD = dramatic!

• TCP stability issues:

– equilibrium, not a stable point - fluctuations lead to regular packet drops & reduced throughput

– not feasible for streaming multimedia apps

– Stability depends on delay, capacity, load and AQM [Steven Low]

• ...wild claims:

– AIMD is definitely not necessary for stability

– TCP-friendly congestion control is like building a slow Porsche – we can do better than TCP!

suits the user + is fair!

(6)

User 1 Allocation x1

Fairness Line

Efficiency Line

Starting Point

AIMD

Desirable

Starting Point

AIAD MIMD

Underload

Overload

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

Fairness Line

Efficiency Line

Starting Point

AIMD

Desirable

Starting Point

AIAD MIMD

Underload

Overload

(7)

AIMD / asynchronous RTTs AIMD / asynchronous RTTs

USER2

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

(8)

AIMD in

AIMD in practice (TCP) practice (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-2 simulator

• TCP Tahoe

• “equal“ RTT

• 1 bottleneck link

Quote from a colleague:

„That‘s what my (9 months old) daugther

does when I give her a pen“

(9)

Outline Outline

• What?

• Why?

• How?

• Conclusion + future work

(10)

The signaling protocol: PTP The signaling protocol: PTP

• Framework:

“generic“ ECN - to carry traffic information (standardized Content Types, e.g. queue length, ..)

•

Stateless & simple -> scalable!

– all calculations: end nodes

• Only every 2nd router needed for full functionality

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

(11)

Endpoint Mechanism Design Algorithm

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

(12)

The ATM ABR best match: CAPC The ATM ABR best match: CAPC

• “Congestion Avoidance with Proportional Control“ (Barnhart, 1994)

• Uses load factor LF: Input Rate IR / Target Rate R0

– R0 e.g. 95% of nominal bandwidth, d = 1 - LF (available bandwidth)

• “As long as the incoming rate is greater than R0, the desired rate, ERS will diminish at a rate that is proportional to the amount by

which R0 is exceeded. Conversely, whenever the incoming rate is less than R0, ERS will increase.“

• for each new cell entering the queue:

LF<=1: ERX = min(ERU, 1 + dRup) ... else ERX = max(ERF, 1 + dRdn) ERS = ERS*ERX

• constants: Rup, Rdn define the speed of rate increase / decrease, ERU, ERF = upper / lower bound

• different default values for LAN and WAN!

hint for RTT dependance!

(13)

Conversion for packet nets: CADPC Conversion for packet nets: CADPC

• “Congestion Avoidance with Distributed Proportional Control“

• Only ask for current load, do calculations at sender

– implementation in diagram based simulator trivial – rates leave fairness line if RTT‘s are not equal :(

• Idea:

– relate user‘s current rate to the state of the system! (also in LDA+)

Thought: in the Chiu-Jain-diagram, if the rate increase factor is indirectly proportional to the user‘s current rate, the rates will equalize.

• From:

– erx = 1 + d* rup = 1 + rup * (1 - traffic/r0)

• To:

– erx = 1 + rup * (1 - myRate/d)

• dependence on rup not desirable

– rate changes should be proportional to the current load -> use d instead of rup!

relate

traffic : target rate relate

user‘s rate : available bandwidth

(14)

CADPC vector diagram analysis

(15)

CADPC synchronous case analysis CADPC synchronous case analysis

•

Final formula per user:

d = 1 - traffic / r0;

erx = 1 + d * (1 - myRate/d);

ers = ers*erx;





























−

− +

=

+

∑

= 0 1

) ( 1

) 1 (

1 ) ( )

1 (

r t x t d x

t x t

x _n

j j i i

• Combined:

i

x

_i

(t) = rate of user i, n users

1 user, r0=1:

logistic equation

=> stable!

 



 

 + − −

=

+ ∑

= n j

j i

i

t x t r r x t x t

x

1 0

0

1 ( ) ( )

) ( )

1 • after some straight- (

forward derivations:

(16)

CADPC synchronous case analysis /2 CADPC synchronous case analysis /2

• Equilibrium: assume x(t+1) = x(t)

• leads to: x(t) = r

₀

/(n+r

₀

)

• traffic (n users): nx(t) = nr

₀

/(n+r

₀

)

Convergence of equilibrium with increasing number of users:

0 0,2 0,4 0,6 0,8 1 1,2

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29

r₀ = 1

(17)

... the simplest ns code ever :) ... the simplest ns code ever :)

• Upon timeout (>= 2 RTTs), send a PTP packet

• Upon PTP packet arrival do:

– UpdateRTT – // normalize

traffic = traffic / bottleneckBW;

currentRate = currentRate / bottleneckBW;

newRate = currentRate*(2.0-currentRate-traffic);

// de-normalize

newRate = newRate * bottleneckBW;

from PTP

(18)

ns simulation: 25 TCP / 25 CADPC ns simulation: 25 TCP / 25 CADPC

tcp cadpc Bandwidth (byte / s)

Time (s) 0.0000

20.0000 40.0000 60.0000 80.0000 100.0000 120.0000 140.0000 160.0000 180.0000 200.0000 220.0000 240.0000 260.0000 280.0000 300.0000 320.0000 340.0000 360.0000 380.0000

0.0000 10.0000 20.0000 30.0000 40.0000 50.0000 60.0000

single bottleneck (dumbbell)

(19)

Results Results

• Implementation: r

₀

normalized to 1 -> calc -> de-normalize

• 1 PTP packet every 4 RTTs, no other acks!

– rate indeed converges to n/n+1

•

No

packet loss

• Very smooth rate, rapid convergence

– the higher the link bandwidth, the better!

• Not in the picture:

– rapid convergence to almost perfect fairness – bg traffic: rapid backoff and recovery

(20)

Outline Outline

• What?

• Why?

• How?

• Conclusion + future work

(21)

CADPC advantages CADPC advantages

• Better stability than TCP

– smooth rate advantageous for streaming media apps

• No problems with wireless links (no packet loss interpretation)

• Rare feedback - good in environments with long delay

– rapid convergence & reaction - good in environments with a high bw*delay product

• Rate calculation independent of RTT => independent of position

– scalable! if PTP = x% of generated traffic n, PTP scales O(n)

• Only (rare) PTP packets necessary to calculate rate

– Satellite environments:

do receiver's calculations at sat. base station and give earlier feedback – easier to differentiate pricing

– easier to implement metering => traffic shaping, policing, admission control, ..

(22)

Deployment plans Deployment plans

• Problem: PTP needs router support

– CADPC needs complete path information (every 2nd router)

• Possibilities:

– CADPC / PTP within a DiffServ class (QoS “in the small“):

“we offer QoS & provide router support, you use CADPC and get a good result

[and we can calculate your rate, too]“

– If CADPC works with non-greedy senders:

edge2edge PTP signaling (TCP over CADPC) PTP supported traffic engineering

– CADPC <=> TCP translation at edge routers?

(23)

Future work Future work

• More ns simulations

– CADPC vs. AIMD in vector diagram simulator:

CADPC is much less aggressive

– compare with TCP-friendly binary mechanisms – compare with other ER mechanisms (PCP, ALS)

User 2 Allocation x2User 2 Allocation x2

Scalable High

Scalable High - - Speed Congestion Control Speed Congestion Control with with

Explicit Traffic Signaling Explicit Traffic Signaling

Outline Outline

• What?

• Why?

• How?

• Conclusion + future work

Out Out - - of of - - band signaling to support CC band signaling to support CC ? ?

• Yes, that‘s right

• Idea similar to ATM ABR Explicit Rate Feedback, but:

• Various endpoint adaptation mechanisms possible

Outline Outline

• What?

• Why?

• How?

• Conclusion + future work

Reasons against TCP Reasons against TCP

• TCP over wireless:

• TCP over “long fat pipes“: (large bandwidth*delay product)

• TCP stability issues:

• ...wild claims:

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

AIMD / asynchronous RTTs AIMD / asynchronous RTTs

AIMD in

AIMD in practice (TCP) practice (TCP)

„That‘s what my (9 months old) daugther

does when I give her a pen“

Outline Outline

• What?

• Why?

• How?

• Conclusion + future work

The signaling protocol: PTP The signaling protocol: PTP

“generic“ ECN - to carry traffic information (standardized Content Types, e.g. queue length, ..)

•

• Only every 2nd router needed for full functionality

• Available Bandwidth Determination:

• two modes:

Endpoint Mechanism Design Algorithm

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

• it must also work with heterogeneous RTTs

• it must also work with more users and in more realistic scenarios

The ATM ABR best match: CAPC The ATM ABR best match: CAPC

• Uses load factor LF: Input Rate IR / Target Rate R0

• “As long as the incoming rate is greater than R0, the desired rate, ERS will diminish at a rate that is proportional to the amount by

which R0 is exceeded. Conversely, whenever the incoming rate is less than R0, ERS will increase.“

• for each new cell entering the queue:

LF<=1: ERX = min(ERU, 1 + d*Rup) ... else ERX = max(ERF, 1 + d*Rdn) ERS = ERS*ERX

Conversion for packet nets: CADPC Conversion for packet nets: CADPC

CADPC vector diagram analysis

CADPC vector diagram analysis

CADPC synchronous case analysis CADPC synchronous case analysis

•

d = 1 - traffic / r0;

erx = 1 + d * (1 - myRate/d);

∑

• Combined:

x

(t) = rate of user i, n users

 



 

 + − −

=

+ ∑

t x t r r x t x t

x

1 ( ) ( )

) ( )

1

• after some straight- (

forward derivations:

CADPC synchronous case analysis /2 CADPC synchronous case analysis /2

• Equilibrium: assume x(t+1) = x(t)

• leads to: x(t) = r

Endpoint Mechanism Design Algorithm ^(tm) ^(tm)

LF<=1: ERX = min(ERU, 1 + dRup) ... else ERX = max(ERF, 1 + dRdn) ERS = ERS*ERX

• traffic (n users): nx(t) = nr