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
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 2 / 23
Section 1
Introduction
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 3 / 23
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
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 4 / 23
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
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 5 / 23
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...)
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 6 / 23
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
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 7 / 23
Section 2
Background on congestion control
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 8 / 23
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
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 9 / 23
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.
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 10 / 23
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
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 11 / 23
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
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 12 / 23
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
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 13 / 23
Section 3
Results
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 14 / 23
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!
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 15 / 23
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
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 16 / 23
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
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 17 / 23
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
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 18 / 23
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
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 19 / 23
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
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 20 / 23
Section 4
Conclusions
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 21 / 23
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
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 22 / 23
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
N.Patriciello (UNIMORE) WNS3 ’15 14 May 2015 23 / 23
Any questions ?
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