Effect of IW and Initial RTO changes Ilpo J arvinen, Aki Nyrhinen, - - PowerPoint PPT Presentation

effect of iw and initial rto changes
SMART_READER_LITE
LIVE PREVIEW

Effect of IW and Initial RTO changes Ilpo J arvinen, Aki Nyrhinen, - - PowerPoint PPT Presentation

Effect of IW and Initial RTO changes Ilpo J arvinen, Aki Nyrhinen, Aaron Yi Ding, Markku Kojo Department of Computer Science University of Helsinki IETF79 / Beijing Nov 11th 2010 Introduction Simulation study to evaluate effects of


slide-1
SLIDE 1

Effect of IW and Initial RTO changes

Ilpo J¨ arvinen, Aki Nyrhinen, Aaron Yi Ding, Markku Kojo

Department of Computer Science University of Helsinki

IETF79 / Beijing Nov 11th 2010

slide-2
SLIDE 2

Introduction

Simulation study to evaluate effects of recently proposed changes:

Initial Window change from 3 packets to 10 packets Initial RTO change from 3 seconds to 1 second

Focus on (typical) slow/moderate bit-rate wireless links like environments Initially presented IW10 results in the last ICCRG meeting @ Maastricht

IETF79 / Beijing Nov 11th 2010 2

slide-3
SLIDE 3

Test setup

Links (bw/one-way propagation delay)

EGDE 160kbps/250ms, BDP = 7 pkts (6.7) HSPA 2Mbps/70ms, BDP = 24 pkts (23.3) LTE 50Mbps/15ms, BDP = 125 pkts

No wireless errors, nor allocation / error related delays considered 11ms propagation delay from sender to wireless link Buffer (FIFO) sizes

BDP (Bandwidth Delay Product) 2 · BDP 50 Packets (EDGE only)

Workload: A burst of 1, 2, 6 or 18 simultaneous downstream TCP flows (total 180kB) competing against a similar later starting burst (another 180kB), 100 replications ns2 TCP SACK in use

IETF79 / Beijing Nov 11th 2010 3

slide-4
SLIDE 4

Summary of IW10 Effects

With small number of TCP flows, IW10 improves performance With larger number of flows, IW10 tends to decrease performance - Regardless of IW, too many flows clearly results in suboptimal performance Fairness for later starting traffic improves with IW10 Fairness within both bursts worse with IW10

IETF79 / Beijing Nov 11th 2010 4

slide-5
SLIDE 5

IRTO: LTE (50Mbps/15ms, BDP=125 Packets)

No changes No spurious RTOs RTOs with IW10 when # of flows is 6+6 or 18+18

But not in the beginning for the flow that completes last (not for the SYN nor the first packet) ⇒ IRTO has no effect

IETF79 / Beijing Nov 11th 2010 5

slide-6
SLIDE 6

IRTO: HSPA (2Mbps/70ms, BDP≈23 Packets)

1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 Elapsed time of the longest flow (s) (median, quartiles, min-max) Later Starting Burst IW3 IRTO3 BDP IW3 IRTO1 BDP IW10 IRTO3 BDP IW10 IRTO1 BDP IW3 IRTO3 2BDP IW3 IRTO1 2BDP IW10 IRTO3 2BDP IW10 IRTO1 2BDP 6+6 flows 18+18 flows

Observations When overloaded, small improvement for the longest cases among later starting traffic Opposite effect for the first starting burst (the shortest cases delayed) No changes due to IRTO1 with 1+1 or 2+2 flows

IETF79 / Beijing Nov 11th 2010 6

slide-7
SLIDE 7

IRTO: EDGE (160kbps/250ms, BDP≈7 Packets)

14 16 18 20 22 24 26 28 30 32 34 1 2 3 4 Elapsed time of the longest flow (s) (median, quartiles, min-max) RTOs 50 Packets Buffer Later Starting Burst IW3 IRTO3 IW3 IRTO1 IW10 IRTO3 IW10 IRTO1 1+1 flows, el. time 2+2 flows, el. time 1+1 flows, RTOs 2+2 flows, RTOs

Observations With large buffer, number

  • f RTOs increase

Mostly spurious RTOs

⇒ Completion of the longest flow is delayed The same trend with larger number of flows When IW10 in use, the first starting burst is able to take advantage and completes unfairly early

IETF79 / Beijing Nov 11th 2010 7

slide-8
SLIDE 8

IRTO: EDGE (160kbps/250ms, BDP≈7 Packets)

10 12 14 16 18 20 22 24 26 28 Elapsed time of the longest flow (s) (median, quartiles, min-max) First Starting Burst IW3 IRTO3 BDP IW3 IRTO1 BDP IW10 IRTO3 BDP IW10 IRTO1 BDP IW3 IRTO3 2BDP IW3 IRTO1 2BDP IW10 IRTO3 2BDP IW10 IRTO1 2BDP 1+1 flows 2+2 flows 10 12 14 16 18 20 22 24 26 28 Elapsed time of the longest flow (s) (median, quartiles, min-max) Later Starting Burst IW3 IRTO3 BDP IW3 IRTO1 BDP IW10 IRTO3 BDP IW10 IRTO1 BDP IW3 IRTO3 2BDP IW3 IRTO1 2BDP IW10 IRTO3 2BDP IW10 IRTO1 2BDP 1+1 flows 2+2 flows

Observations Mostly the same regardless of IRTO IW10+IRTO1 becomes more fair

RTO occurred sooner for the later starting burst (a spurious

  • ne)

IETF79 / Beijing Nov 11th 2010 8

slide-9
SLIDE 9

RED Configuration

Cfg RED REDok Link EDGE HSPA/LTE EDGE HSPA LTE wq 0.002 0.002 0.2 0.02 0.001 maxp 0.1 0.1 0.65 0.65 0.1 thmin 3 5 3 3 5 thmax 9 20 40 50 125 buffer size 2 · BDP 2 · BDP 50 100 400 Large buffers with RED configuration were not tested

Not useful because of avg > thmax dropper

REDok config aimed to highly varying load

Thus vastly different from “default configuration” Aggressive enough to respond to slow start Parameters are link characteristics dependent

IETF79 / Beijing Nov 11th 2010 9

slide-10
SLIDE 10

Single Flow One-way Delay (FIFO, RED and IW3, IW10)

0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 One-way delay (s) CDF 1+1 flows, EDGE, IRTO3, IW3, BDP 1+1 flows, EDGE, IRTO3, IW10, BDP 1+1 flows, EDGE, IRTO3, IW3, 2BDP 1+1 flows, EDGE, IRTO3, IW10, 2BDP 1+1 flows, EDGE, IRTO3, IW3, RED 1+1 flows, EDGE, IRTO3, IW10, RED 1+1 flows, EDGE, IRTO3, IW3, 50 pkts 1+1 flows, EDGE, IRTO3, IW10, 50 pkts

IW10 slightly more aggressive RED similar to FIFO behavior (too slow to react) With BDP IW10 hurts itself due to self-congestion

Slightly smaller delays except for the highest end

IETF79 / Beijing Nov 11th 2010 10

slide-11
SLIDE 11

Single Flow One-way Delay (FIFO, REDok and IW3, IW10)

0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 One-way delay (s) CDF 1+1 flows, EDGE, IRTO3, IW3, BDP 1+1 flows, EDGE, IRTO3, IW10, BDP 1+1 flows, EDGE, IRTO3, IW3, 2BDP 1+1 flows, EDGE, IRTO3, IW10, 2BDP 1+1 flows, EDGE, IRTO3, IW3, REDok 1+1 flows, EDGE, IRTO3, IW10, REDok

Also REDok fails to control the delay increase IW10 imposes Maximum values with REDok:

IW10: 2.80s IW3: 2.06s

IETF79 / Beijing Nov 11th 2010 11

slide-12
SLIDE 12

6 Flows One-way Delay (FIFO, RED and IW3, IW10)

0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 One-way delay (s) CDF 6+6 flows, HSPA, IRTO3, IW3, BDP 6+6 flows, HSPA, IRTO3, IW10, BDP 6+6 flows, HSPA, IRTO3, IW3, 2BDP 6+6 flows, HSPA, IRTO3, IW10, 2BDP 6+6 flows, HSPA, IRTO3, IW3, RED 6+6 flows, HSPA, IRTO3, IW10, RED

Again, RED reacts too slowly IW10 less aggressive due to self-congestion ⇒ more bursty

IETF79 / Beijing Nov 11th 2010 12

slide-13
SLIDE 13

6 Flows One-way Delay (FIFO, REDok and IW3, IW10)

0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 One-way delay (s) CDF 6+6 flows, HSPA, IRTO3, IW3, BDP 6+6 flows, HSPA, IRTO3, IW10, BDP 6+6 flows, HSPA, IRTO3, IW3, 2BDP 6+6 flows, HSPA, IRTO3, IW10, 2BDP 6+6 flows, HSPA, IRTO3, IW3, REDok 6+6 flows, HSPA, IRTO3, IW10, REDok

With REDok, traffic regulation works without heavy tail-drop ⇒ IW10 shows to be significantly more aggressive Maximum values with REDok:

IW10: 0.429s IW3: 0.296s

IETF79 / Beijing Nov 11th 2010 13

slide-14
SLIDE 14

One-Way Delay in Rest of Cases

Similar behavior observed:

Self-congestion ⇒ IW10 is less aggressive

Except for the very highest end (in some of the cases)

With low enough load, IW10 is slightly more aggressive

IRTO1 only slightly “shifts” curves

Only happening when IRTO1 has some effect in the first place Quite insignificant in numbers

Actual shape of the delay curves vary per queue size and type, however, those differences are out of scope here

IETF79 / Beijing Nov 11th 2010 14

slide-15
SLIDE 15

Conclusions

Smaller initial RTO performs better when effective e2e RTT smaller than 1 second More controversial when e2e RTT is larger IW10, while improving elapsed times, imposes higher queuing delay than IW3

However, if self-congesting, IW3 is more aggressive in terms of queuing delay AQM (RED) failed to control the increase in the queuing delay

IETF79 / Beijing Nov 11th 2010 15

slide-16
SLIDE 16

Questions?

IETF79 / Beijing Nov 11th 2010 16

slide-17
SLIDE 17

Backup slides

IETF79 / Beijing Nov 11th 2010 17

slide-18
SLIDE 18

RED config (detailed ns2)

Queue/RED set bytes_ true Queue/RED set queue_in_bytes_ true Queue/RED set gentle_ false Queue/RED set setbit_ false Queue/RED set use_mark_p_ false Queue/RED set mean_pktsize_ 1500 Queue/RED set idle_pktsize_ 1500 Queue/RED set q_weight_ $wq Queue/RED set thresh_ $minth Queue/RED set maxthresh_ $maxth Queue/RED set linterm_ [expr 1.0/$maxp] Queue/RED set wait_ false

IETF79 / Beijing Nov 11th 2010 18

slide-19
SLIDE 19

6 Flows Elapsed Times (FIFO, RED, REDok and IW)

1 2 3 4 5 6 7 8 Elapsed time of the longest flow (s) (median, quartiles, min-max) HSPA, Later Starting Burst IW3IRTO3 BDP 2BDP RED REDok IW10IRTO3 BDP 2BDP RED REDok IW10IRTO1 BDP 2BDP RED REDok 1+1 flows 2+2 flows 6+6 flows 18+18 flows

IETF79 / Beijing Nov 11th 2010 19

slide-20
SLIDE 20

6 Flows Fairness (FIFO, RED, REDok and IW)

0.75 0.8 0.85 0.9 0.95 1 Jain’s fairness index between the bursts (median, quartiles, min-max) HSPA IW3IRTO3 BDP 2BDP RED REDok IW10IRTO3 BDP 2BDP RED REDok IW10IRTO1 BDP 2BDP RED REDok 1+1 flows 2+2 flows 6+6 flows 18+18 flows

IETF79 / Beijing Nov 11th 2010 20