CoDel present by Van Jacobson to the IETF-84 Transport Area Open - - PowerPoint PPT Presentation

▶
codel
SMART_READER_LITE
LIVE PREVIEW

CoDel present by Van Jacobson to the IETF-84 Transport Area Open - - PowerPoint PPT Presentation

Feb 18, 2023 203 likes •577 views

Kathie Nichols CoDel present by Van Jacobson to the IETF-84 Transport Area Open Meeting 30 July 2012 Vancouver, Canada 2 3 Sender Receiver 4 Sender Receiver 5 Sender Receiver Queue forms at a bottleneck Theres probably

slide-1
SLIDE 1

Kathie Nichols’

CoDel

present by Van Jacobson to the IETF-84 Transport Area Open Meeting 30 July 2012 Vancouver, Canada

slide-2
SLIDE 2

2

slide-3
SLIDE 3

3

slide-4
SLIDE 4

Sender Receiver 4

slide-5
SLIDE 5

Sender Receiver 5

slide-6
SLIDE 6

Sender Receiver

  • Queue forms at a bottleneck
  • There’s probably just one bottleneck

(each flow sees exactly one) ➡ Choices: can move the queue (by making a new bottleneck) or control it.

5

slide-7
SLIDE 7

Time Queue length

Good Queue / Bad Queue

6

slide-8
SLIDE 8

Time Queue length Time Queue length

Good Queue / Bad Queue

6

slide-9
SLIDE 9

Time Queue length Time Queue length

Good Queue / Bad Queue

  • Good queue goes

away in an RTT, bad queue hangs around. ➡ queue length min()

  • ver a sliding window

measures bad queue ... ➡ ... as long as window is at least an RTT wide.

7

slide-10
SLIDE 10

Time Queue length Time Queue length

Good Queue / Bad Queue

  • Good queue goes

away in an RTT, bad queue hangs around. ➡ tracking min() in a sliding window gives bad queue ... ➡ ... as long as window is at least an RTT wide.

8

slide-11
SLIDE 11

Time Queue length Time Queue length

Good Queue / Bad Queue

  • Good queue goes

away in an RTT, bad queue hangs around. ➡ tracking min() in a sliding window gives bad queue ... ➡ ... as long as window is at least an RTT wide.

8

slide-12
SLIDE 12

How big is the queue?

  • Can measure size in bytes

– interesting if worried about overflow – requires output bandwidth to compute delay

  • Can measure packet’s sojourn time

– direct measure of delay – easy (no enque/deque coupling so works with any packet pipeline).

9

slide-13
SLIDE 13

Sojourn Time

  • Works with time-varying output bandwidth

(e.g., wireless and shared links)

  • Better behaved than queue length – no high

frequency phase noise

  • Includes everything that affects packet so

works for multi-queue links

10

slide-14
SLIDE 14

1 2 3 4 5 6 Q size (ms.) 24.5 25.0 25.5 26.0 1 2 3 4 5 6 Time (sec.) Q delay (ms.)

Two views of a Queue

Top graph is sojourn time, bottom is queue size. (one ftp + web traffic; 10Mbps bottleneck; 80ms RTT; TCP Reno)

11

slide-15
SLIDE 15

1 2 3 4 5 6 Q size (ms.) 24.5 25.0 25.5 26.0 1 2 3 4 5 6 Time (sec.) Q delay (ms.)

Two views of a Queue

Top graph is sojourn time, bottom is queue size. (one ftp + web traffic; 10Mbps bottleneck; 80ms RTT; TCP Reno)

11

slide-16
SLIDE 16

Two views of a Queue

Top graph is sojourn time, bottom is queue size. (one ftp + web traffic; 10Mbps bottleneck; 80ms RTT; TCP Reno)

0.0 0.5 1.0 1.5 2.0 2.5 Q size (ms.) 25.00 25.05 25.10 25.15 25.20 0.0 0.5 1.0 1.5 2.0 Time (sec.) Q delay (ms.)

12

slide-17
SLIDE 17

Multi-Queue behavior

13

slide-18
SLIDE 18

a) Measure what you’ve got b) Decide what you want c) If (a) isn’t (b), move it toward (b)

Controlling Queue

14

slide-19
SLIDE 19

a) Measure what you’ve got b) Decide what you want c) If (a) isn’t (b), move it toward (b)

Controlling Queue

  • Estimator
  • Setpoint
  • Control loop

15

slide-20
SLIDE 20

How much ‘bad’ queue do we want?

  • Can’t let the link go idle (need one or two

MTU of backlog)

  • More than this will give higher utilization at

low degree of multiplexing (1-3 bulk xfers) at the cost of higher delay

  • Can the trade-off be quantified?

16

slide-21
SLIDE 21

20 40 60 80 100 75 80 85 90 95 100

Utilization vs. Target for a single Reno TCP

Target (% of RTT) Bottleneck Link Utilization (% of max)

17

slide-22
SLIDE 22

20 40 60 80 100 0.70 0.75 0.80 0.85 0.90 0.95 1.00

Power vs. Target for a Reno TCP

Target (as % of RTT) Average Power (Xput/Delay)

18

slide-23
SLIDE 23

20 40 60 80 100 0.70 0.75 0.80 0.85 0.90 0.95 1.00

Power vs. Target for a Reno TCP

Target (as % of RTT) Average Power (Xput/Delay)

18

slide-24
SLIDE 24

5 10 15 20 25 30 0.93 0.94 0.95 0.96 0.97 0.98 0.99 1.00

Power vs. Target for a Reno TCP

Target (as % of RTT) Average Power (Xput/Delay)

19

slide-25
SLIDE 25

5 10 15 20 25 30 0.93 0.94 0.95 0.96 0.97 0.98 0.99 1.00

Power vs. Target for a Reno TCP

Target (as % of RTT) Average Power (Xput/Delay)

19

slide-26
SLIDE 26

20

slide-27
SLIDE 27
  • Setpoint target of 5% of nominal RTT (5ms

for 100ms RTT) yields substantial utilization improvement for small added delay.

20

slide-28
SLIDE 28
  • Setpoint target of 5% of nominal RTT (5ms

for 100ms RTT) yields substantial utilization improvement for small added delay.

  • Result holds independent of bandwidth and

congestion control algorithm (tested with Reno, Cubic & Westwood).

20

slide-29
SLIDE 29
  • Setpoint target of 5% of nominal RTT (5ms

for 100ms RTT) yields substantial utilization improvement for small added delay.

  • Result holds independent of bandwidth and

congestion control algorithm (tested with Reno, Cubic & Westwood). ➡ CoDel has no free parameters: running- min window width determined by worst- case expected RTT and target is a fixed fraction of same RTT.

20

slide-30
SLIDE 30

Algorithm & Control Law

(see I-D, CACM paper and Linux kernels >= 3.5)

21

slide-31
SLIDE 31
  • provides isolation - protects low rate CBR

and web for a better user experience. Makes IW1 0 concerns a non-issue.

  • gets rid of bottleneck bi-directional traffic

problems (‘ack-compression’ burstiness)

  • improves flow mixing for better network

performance (reduce HoL blocking)

Eric Dumazet has combined CoDel with a simple SFQ (256-1024 buckets with RR service discipline). Cost in state & cycles is small and improvement is big.

➡ Since we’re adding code, add fqcodel, not codel.

22

slide-32
SLIDE 32
  • thanks to Jim Gettys and the ACM, have

dead-tree publication to protect ideas

  • un-encumbered code (BSD/GPL dual-license)

available for ns2, ns3 & linux

  • in both simulation and real deployment,

CoDel does no harm – it either does nothing

  • r reduces delay without affecting xput.

Where are we?

23

slide-33
SLIDE 33

What needs to be done

  • Still looking at parts of the algorithm but

changes likely to be 2nd order.

  • Would like to see CoDel on both ends of

every home/small-office access link but:

  • We need to know more about how traffic

behaves on particular bottlenecks (wi-fi, 3G cellular, cable modem)

  • There are system issues with deployment

24

slide-34
SLIDE 34

Deployment Issues

RTR/AP Cable Modem Headend

Home Gateway

25

slide-35
SLIDE 35

Deployment Issues

RTR/AP Cable Modem Headend

Home Gateway

Protocol stack Device Driver Device

Linux kernel

26

slide-36
SLIDE 36

Deployment Issues

RTR/AP Cable Modem Headend

Home Gateway

Protocol stack Device Driver Device

Linux kernel

Phone CPU 3G Modem RAN SGSN ?

Cellphone

27

slide-37
SLIDE 37

Our thanks to:

  • Jim Gettys
  • CoDel early experimenters,

particularly Dave Taht

  • Eric Dumazet
  • ACM Queue
  • Eben Moglen

28