Implementation and Validation of TCP Options and ... · Results: CUBIC 0 2000 4000 6000 8000 10000...

Implementation and Validation of TCP Options andCongestion Control Algorithms for ns-3

Maurizio Casoni, Carlo Augusto Grazia, Martin Klapez,Natale Patriciello

Department of Engineering Enzo FerrariUniversity of Modena and Reggio Emilia

Casteldefels, 14 May 2015WNS3 ’15

N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 1 / 23

Talk overview

1 IntroductionHistory timeState of the Art

2 Background on congestion control

3 Results

4 Conclusions


Section 1

Introduction


TCP Options recap

whatTCP Options: defined in RFC 793, Window Scale and Timestampspresented in RFC 1323

whyTo improve performance over large bandwidth*delay product pathsand to provide reliable operation over very high-speed paths

whereNS-3 TCP implementation under src/internet


TCP variants recap

whatCongestion control algorithms for high-delay links still missing anative implementation for ns-3 (Hybla, Highspeed, ...). Otherwell-known variant (Bic, Cubic, ...) are in ns-2 but not ported in ns-3

whyThe purpose for adding these versions is to update internet module totoday’s standard

whereNS-3 TCP implementation under src/internet


Important TCP options

Window scaleEnable the peers to utilize more than 65535 bytes for the slidingwindow

TimestampsBetter RTT estimation, protection for wrap-around sequence number

SACKSelective ACK: explicit knowledge about the segments lost in thenetwork (Breaking news: wns3 2015 poster...)


Most used TCP congestion control algorithms

CUBIC/BICDefault algorithm in Linux (BIC from 2.6.8 to 2.6.19, CUBIC from2.6.19 to date)

HighspeedEvolution of NewReno to address its issues in Fast Long-DistanceNetworks

HyblaEvolution of NewReno to remove its performance dependency fromRTT


Section 2

Background on congestion control


TCP BIC

What is TCP BIC?It views the congestion avoidance as a search problem. Thecongestion window is updated thanks to a binary search, performedfrom the actual value up to the highest measured value

Why TCP BIC?Forerunner of CUBIC, Linux default congestion control algorithm for2 years


TCP CUBIC

What is TCP CUBIC?Less aggressive and more systematic derivative of BIC, in which thewindow is a cubic function of time since the last congestion event,with the inflection point set to the window prior to the event.

Why TCP CUBIC?Linux default congestion control algorithm since 2006.


TCP Highspeed

What is TCP Highspeed?AIMD parameters changes in function of the current window value.The window will grow faster than standard TCP and also recoverfrom losses more quickly.

Why TCP Highspeed?Often chosed as a reference benchmark for newer algorithms


TCP Hybla

What is TCP Hybla?The key idea is to obtain for long RTT connections the sameinstantaneous transmission rate of a reference TCP connection withlower RTT

Why TCP Hybla?Often chosed as a reference benchmark for satellite-based network


TCP Noordwijk

What is TCP Noordwijk?

A burst-based TCP variant for satellite networks, designedto:

Optimize transmission of short objectGuarantee a fair behavior with competing flowsOperate efficiently over DVB-RCS schemes

Why TCP Noordwijk?

Some interesting ideas for high-delay networks


Section 3

Results


Results: Window scale

0

0.2

0.4

0.6

0.8

1

1.2

0 10 20 30 40 50 60

Thro

ughput (M

b/s

)

Time (s)WinScale disabledWinScale enabled

Please note, the max cwnd is determined by the TCP Tx/Rxbuffer!


Results: BIC

0

500

1000

1500

2000

2500

0 50 100 150 200 250 300 350

Siz

e (

KB

)

Time (s)

Bic cWndBic ssThresh

700

750

800

850

900

950

1000

1050

1100

1150

1200

80 100 120 140 160 180

Siz

e (

KB

)Time (s)

Bic cWndBic ssThresh


Results: CUBIC

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

0 50 100 150 200 250 300 350

Siz

e (

KB

)

Time (s)

Cubic cWndCubic ssThresh

3500

4000

4500

5000

5500

6000

6500

7000

140 145 150 155 160 165 170 175 180

Siz

e (

KB

)Time (s)

Cubic cWndCubic ssThresh


Results: Highspeed

0

100

200

300

400

500

600

700

800

900

0 50 100 150 200 250 300 350

Siz

e (

KB

)

Time (s)

HighSpeed-100msNewReno-100ms

0

50

100

150

200

250

300

350

400

450

0 50 100 150 200 250 300 350

TxD

ata

(M

B)

Time (s)

HighSpeed-100msNewReno-100ms


Results: Hybla

0

1000

2000

3000

4000

5000

6000

0 50 100 150 200 250 300 350

Siz

e (

KB

)

Time (s)

Hybla-25msHybla-100ms

Hybla-350msNewReno-25ms

0

50

100

150

200

250

300

350

400

450

0 50 100 150 200 250 300 350

TxD

ata

(M

B)

Time (s)

Hybla-25msHybla-100ms

Hybla-350msNewReno-25ms

NewReno-100msNewReno-350ms


Results: Noordwijk

0

2

4

6

8

10

0 50 100 150 200 250 300 350

Thro

ughput (M

bit/s

)

Time (s)

Noordwijk flow 0Noordwijk flow 1

0

50

100

150

200

250

300

350

400

450

0 50 100 150 200 250 300 350

TxD

ata

(M

B)

Time (s)

Noordwijk flow 0Noordwijk flow 1

Noordwijk aggregateNewReno single flow


Section 4

Conclusions


Conclusions

RecapPresented (and validated) TCP Options infrastructurePresented (and validated) TCP congestion control algorithms

Validation MethodComparison between simulation results with the theoretically expectedbehaviors

Lesson learnedVarious aspect of TCP still missing testing/validationCritical aspect in the TCP layer design


Future Works

Directions to take

Re-design some part of the internet module to easilyextends the TCP (and UDP) testing platform (GSoC’15 accepted)Test TCP for RFC-complianceCompare ns-3 and real implementations


Any questions ?

[email protected]

Why not a comparison with a real stack?

DCEAt the time, DCE was missing the cwnd/ssth tracing capabilities

Real networkTwo computer connected with an ethernet cable.

side-effects between queue and shaping with tcheavy-optimized TCP (SACK, persistent tables, and so on)really unfair comparison

Implementation and Validation of TCP Options and ... · Results: CUBIC 0 2000 4000 6000 8000 10000...

Documents

Transcript of Implementation and Validation of TCP Options and ... · Results: CUBIC 0 2000 4000 6000 8000 10000...