Download presentation
Presentation is loading. Please wait.
Published byRandolf Hines Modified over 8 years ago
1
29/09/2016 Passive Detection of TCP Congestion Events Shane Alcock and Richard Nelson University of Waikato, Hamilton New Zealand
2
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 2 TCP Congestion Control Many TCP congestion control algorithms exist Reno, New Reno, Vegas, Compound TCP, BIC, CUBIC..... How do they really perform? Most evaluation is done in simulation or experimental networks Little emphasis on measurement of real-world TCP flows Passive measurements provide a wealth of potential information Round Trips Window Size LOSS
3
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 3 TCP Congestion Events First we must detect and categorise congestion events Events that affect the value of the congestion window Successful acknowledgments Packet loss RTO vs Fast Retransmit End of fast recovery Reverting the window in response to spurious retransmits F-RTO and D-SACK algorithms
4
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 4 Previous Work tcpflows -- Jaiswal et al. (2004) Based solely on RFC specifications Did not account for differences between OS implementations Rewaskar et al. (2006) Showed tcpflows was inaccurate due to OS variability Separate state machines for each supported OS No software updates since late 2004 Inaccurate for contemporary traffic Difficult to use – relies on archaic tcpdump output format
5
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 5 Our Goal Develop up-to-date congestion event detection software Support modern systems and TCP features Account for OS differences as much as possible Efficient Accurate Software library tcpcsm – TCP Congestion State Machine Based on libtrace trace processing library
6
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 6 Basic Approach TCP sender uses ACKs to infer congestion events Packet header trace provides the same information Replicate the congestion state for the sender No Event RTO Fast Retransmit Dat a Cumulative ACK Retransmit Duplicate ACK Cumulative ACK
7
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 7 Variation in TCP Stacks Each operating system implements TCP differently Windows XP will fast retransmit after only 2 duplicate ACKs One solution: a separate state machine for each OS Rewaskar et al (2006) Requires a lot of maintenance Inefficient Doesn't cope with optional OS features Linux supports F-RTO but is disabled by default
8
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 8 Passive Monitor Typically not located at either of the endpoints Placed to capture large quantities of traffic involving many users Endpoin t Passive Monitor Networ k
9
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 9 Passive Monitor Duplicate segments Red segment is duplicated in first cloud Sende r Receive r Networ k Passive Monitor
10
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 10 Passive Monitor Segment reordering Blue and red segments are swapped in first cloud Sende r Receive r Networ k Passive Monitor
11
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 11 Passive Monitor Packet loss before reaching the monitor Blue segment is lost in the first cloud and retransmitted Sende r Receive r Networ k Passive Monitor
12
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 12 Packet Ordering
13
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 13 Identifying RTO Events
14
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 14 Identifying RTO Events Attempting to estimate the RTO timer is a bad idea! Accurate and reliable RTT estimation is very difficult Delay variations in the path affect our view of packet timing Operating systems calculate RTO timer differently Our approach – don't bother! All non-RTO retransmissions are preceded by obvious signs Duplicate ACKs, SACK If we rule out all other causes of retransmit, it must be an RTO
15
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 15 Dealing With OS Variation Ignore RTO timers Major source of OS variation Each OS implements a different subset of TCP features Feature implementation does not differ much between stacks Deal with everything using a single state machine Additional branches for different TCP features and extensions OS fingerprinting for remaining ambiguous cases
16
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 16 TCP Features SACK Fast Retransmit Linux specific Fast retransmit in response to a SACK Not standardised – RFC 3517 is closest Forward RTO (F-RTO) RFC 5682 Detects spurious RTO events and resets congestion window Enabled by default in Windows Vista Duplicate SACK RFC 3708 Also detects spurious RTO events
17
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 17 Validation Validation method similar to Rewaskar et al. 13 different congestion scenarios Manual trace analysis using tcptrace to establish ground truth Compare events identified by tcpcsm against ground truth TBIT Client FreeBSD Router Trace Capture Vista tcpdump Target Servers Linux 2.6....
18
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 18 Validation Tested tcpcsm against 7 different OS configurations Solaris 10, FreeBSD 5, FreeBSD 7, Linux 2.6, Windows XP, Windows Vista (unpatched), Windows Vista SP2 Passed 84 of 91 test scenarios Also tested Rewaskar's tool on supported systems Solaris 10, FreeBSD 5, Linux 2.6, Windows XP Passed 35 of 52 test scenarios (tcpcsm passed 50) Failures RTO events for FreeBSD 5 Windows XP fast retransmits Reordering and partial ACK scenarios
19
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 19 Validation F-RTO bug in Windows Vista Initial release of Vista did not implement F-RTO correctly Difficult for tcpcsm to detect correctly 5 out of 7 test failures were due to this bug Fixed in a Vista Service Pack
20
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 20 Applications Application Flow Control in YouTube Video Streams S. Alcock and R. Nelson, CCR vol. 42 no. 1 (April 2011) YouTube implements additional flow control on top of TCP Flow control interacts poorly with TCP on congested paths Increased congestion, packet loss Results acknowledged by Google
21
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 21 Summary Evaluation of TCP behaviour using passive traces First step: detecting congestion events tcpcsm: passive detection of TCP congestion events Single state machine but copes with OS variation Does not attempt to estimate RTO Supports modern systems and TCP features Validated against multiple congestion scenarios and systems Very accurate, especially compared to previous tools
22
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 22 Summary http://research.wand.net.nz/software/tcpcsm.php contact@wand.net.nz salcock@cs.waikato.ac.nz
23
© THE UNIVERSITY OF WAIKATO TE WHARE WANANGA O WAIKATO 23 WAND Network Research Group Department of Computer Science The University of Waikato Private Bag 3105 Hamilton, New Zealand www.crc.net.nz www.wand.net.nz www.waikato.ac.nz
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.