Experimental Analysis of TCP Spurious Retransmission Time-out in 3G/3.5G networks

1. Experimental Analysis of TCP Spurious Retransmission Time-out in 3G/3.5G networks Gennaro Boggia, Antonio Barbuzzi Assistant Professor, PhD student Telematics Lab - Politecnico di Bari Paolo Dini Research Associate IP Technologies Area - CTTC

2. Outline • Introduction to COST TMA (Data Traffic Monitoring and Analysis) • Collaboration between Poliba and CTTC • Presentation of Poliba’s Telematics lab • Statement of the Spurious Retransmission Time-Out problem in TCP connections • Testbed design and development • Experimental result analysis • Conclusions and future work

3. Outline • Introduction to COST TMA (Data Traffic Monitoring and Analysis) • Collaboration between Poliba and CTTC • Presentation of Poliba’s Telematics lab • Statement of the Spurious Retransmission Time-Out problem in TCP connections • Testbed design and development • Experimental result analysis • Conclusions and future work

4. COST Action IC0703 – Data Traffic Monitoring and Analysis • Understanding, developing and managing modern packet networks is difficult and expensive • Traffic monitoring and analysis has always been seen as a key methodology to understand telecommunication technology and operation • TMA COST Action aims at coordinating and promoting the development of common and novel monitoring tools and analysis platforms, so as to catalyze the emergence of a European de-facto standard for traffic monitoring

5. COST Action IC0703 – Data Traffic Monitoring and Analysis • Collaboration between IPTech (CTTC) and Telematics Lab (Poliba) • Experimental study of TCP over 3G/3.5G network • First identified problem: Spurious Retransmission Time-Out (SRTO) • Short Term Scientific Mission (STSM) • Antonio Barbuzzi - Title: Measurements of TCP performances over 3/3.5G wireless networks- Date: 11/01/2009 - 28/02/2009 (extended to 13/03/2009)- Home institution: Politecnico di Bari, Italy- Host institution: Centre Tecnològic de Telecomunicacions de Catalunya (CTTC), Spain

6. Telematics Lab - General Description • Telematics Lab is a research laboratory at the Electrical & Electronics Engineering Department (DEE) of Politecnico di Bari, the Technical University of Bari. • Its mission is the research on the most relevant technologies in the area of telecommunication networks.

7. Main Research Areas • Multimedia Systems • Multimedia Streaming using quality adaptive encoding schemes • Bandwidth estimation algorithms for Admission Control • QoS in wireless LAN/PAN • Feedback-based bandwidth allocation algorithms in wireless networks (IEEE 802.11, 802.15.3, etc.) • Active and Passive measurements in 3G • measurements to infer parameter settings in 3G network • performance analysis • Wireless Sensor Networks for detecting adverse events • energy efficient architectures for event detection • analytical modeling • Networked Control Systems • Architectures for real-time communications in factory environment • Wireless network for system control

8. People Full Professor PhD Students Pietro Camarda Antonio Barbuzzi Francesco Capozzi Claudia Cormio Assistant Professor Gennaro Boggia Rossella Fortuna Luigi Alfredo Grieco Roberta Laraspata Maria Rita Palattella Domenico Striccoli Carla Passiatore Post-Doc Giuseppe Piro Roberto Dell’Aquila Visiting Researcher Giammarco Zacheo Alessandro D’Alconzo

9. International Cooperation • FTW at Vienna (Austria) • Nokia Siemens Network at Aalborg (Denmark) • CTTC at Barcelona (Spain) • VTT at Oulu (Finland) • INRIA at Sophia Antipolis (France)

10. Some projects Some recent projects (most of them funded by Apulia Region) • COST Action IC0703, “Data Traffic Monitoring and Analysis: theory, techniques, tools and applications for the future networks,”. Chair: F. Ricciato, University of Salento, FTW (Vienna), 2007-2012. • Apulia Regional Strategic Proj., “PS 121 - Telecommunication Facilities and Wireless Sensor Networks in Emergency Management,” Chair: Prof. B. Maione, Politecnico di Bari, 2006-2009. • Apulia Reg. Strategic Proj., “PS 092 - Distributed Production to Innovative System – DIPIS,” Chiar: Prof. G. Visaggio, University of Bari, 2006-2009. • Apulian Reg. Operative Prog. 2000-2006, “Monitoring and Adaptive Control – Mobility of dangerous material,” Chair: Prof. G. Visaggio, University di Bari, 2007-2008. • Apulian Reg. Operative Prog. 2000-2006, “Terrestrial Digital Platform for Television Services with high Social Impact,” Actuator: CO.S.TE, 2007-2008. • Apulia Reg. Explorative Proj., “ICT Technologies for tracking food farming with RFID tags,” Chair: Prof. P. Camarda, Politecnico di Bari, 2007. • Apulia Reg. Explorative Proj., “ICT Technologies for tourist assistance based on an interactive virtual guide,” Chair: Prof. G. Piscitelli, Politecnico di Bari, 2007. • Apulian Reg. Operative Prog. 2000-2006, “Robotic Systems for Micro Assembly,” in cooperation with Masmec S.r.l – Italy. Chair. Prof. L. Salvatore, Politecnico di Bari, 2006-2007. • Apulian Reg. Operative Prog. 2000-2006, “Wireless Communication Systems for Industrial Automation,” in cooperation with Masmec S.r.l – Italy. Chair. Prof. P. Camarda, Politecnico di Bari, 2006-2007.

11. Outline • Introduction to COST TMA (Data Traffic Monitoring and Analysis) • Collaboration between Poliba and CTTC • Presentation of Poliba’s Telematics lab • Statement of the Spurious Retransmission Time-Out problem in TCP connections • Testbed design and development • Experimental result analysis • Conclusions and future work

12. Recalling TCP behavior As well known, TCP • uses a retransmission timer when expecting an acknowledgment (ACK) for a given segment • the ACK should arrive before the RTO (Retransmission TimeOut) • the RTO is evaluated as RTO = SRTT + 4 DEV where SRTT: estimated Round Trip Time; DEV = RTT standard deviation

13. SRTO: definition • A spurious timeout happens in case of a sudden delay spike on the link, where the round-trip time exceeds the expected value calculated for the retransmission timeout. • ACK is received after the retransmission of the segment Receiver Ack. Numb. 3000 Seq. Numb. 1500 Seq. Numb. 1500 Seq. Numb. 1 Ack. Numb. 1500 Sender RTO

14. Effects of SRTO • TCP retransmits the oldest outstanding segment (not lost, but delayed) • The retransmission is unnecessary (the segment has been received) • The sender interprets the received ACK as related to the retransmission • TCP retransmits all outstanding segments (slow start algorithm) • Retransmitted segments generate 3DUPACKs and a spurious fast retransmit • Transmission of new segments are delayed - A. Gurtov, R. Ludwig, Responding to Spurious Timeouts in TCP, In Proc. of IEEE INFOCOM, Mar. 2003

15. Some remarks on SRTO • Pronounced RTT variations can fire RTO even in absence of packet loss (i.e., a SRTO) • Standard TCP flavors are not able to distinguish between SRTOs and normal RTOs due to packet losses • An SRTO implies • unnecessary retransmission of segments which already arrived successfully at the receiver beforehand • unnecessary reduction of the congestion window • several 3 DUPACKs with consequent congestion window reduction • Frequent SRTOs can significantly degrades network performance and TCP throughput.

16. SRTO in 3G/3.5G network In a cellular network (3G/3.5G) a SRTO can be due to • mobility: the mobile terminal may experience handovers with consequent signaling and packet storage • propagation: a sudden change in radio conditions usually causing a spike in the RTT of stored packets (retransmissions at link layer) • priority: a sudden increase of high priority traffic (voice) reduces resources available for data traffic • configuration: some buffers in the core network can be overdimensioned • cell state: the mobile terminal switches to another channel

17. How to reveal a SRTO There are no algorithms (sender side) that reveal all possible SRTOs. To this aim, we need to look at both sender and receiver sides. • D-SACK option • duplicated segments are signaled • extension of the well-known TCP SACK option • the SRTO is revealed only when at reception of the first ACK of the retransmitted segment • Eifel Algorithm • it reveals SRTOs and can react to them • TCP timestamp option is used • it works if some ACKs are lost • F-RTO • no TCP options are required • sometimes SRTOs are not revealed • the segment transmission can go on without congestion window reduction

18. Outline • Introduction to COST TMA (Data Traffic Monitoring and Analysis) • Collaboration between Poliba and CTTC • Presentation of Poliba’s Telematics lab • Statement of the Spurious Retransmission Time-Out problem in TCP connections • Testbed design and development • Experimental result analysis • Conclusions and future work

19. Testbed 3G core network • The mobile station and the wired host are on the same physical machine • A single clock allows us to calculate the end to end delay (NTP would be an alternative) • To simplify the realization of the testbed in different environments (we don’t have always two machines) • Elimination of synchronization issues M H W Internet Wired Host Mobile Station

20. Loopback Avoidance (I) • Locally originated traffic with local IP address as destination would be delivered through the loopback interface • The original addresses of each interface is changed to a fictitious one. • Packets exiting from each interface need to have the real source address • A rule in the NAT table in the POSTROUTING chain change source IP to the real IP • Also a fictitious router is used for the Ethernet path • Packets coming to the interfaces need to have the fictitious IP as destination • A rule in the NAT table in PREROUTING chain changes the source IP to the fictitious one

21. Loopback Avoidance (II) • The host needs to know the MAC address of the Ethernet router • Static entry in the MAC table • The Ethernet router needs to know the MAC address of the laptop • We can’t control this router  • Incoming ARP requests are modified to have fictitious IP addresses • Outgoing ARP replies are modified to have real IP addresses • The packets needs to flow through the internet • Routing table’s rule sent packets with real UMTS IP address destination through the Ethernet card and vice versa. • Alternative solutions: • Raw sockets (but would require a userspace TCP implementation) • The use of two different hosts

22. Loopback Avoidance (III) ppp0 eth0 Fake Eth0 IP.src  Real ppp0 IP.dst Real Eth0 IP.src  Fake ppp0 IP.dst Fake ppp0 IP.src  Real Eth0 IP.dst Real ppp0 IP.src  Fake Eth0 IP.dst POSTROUTING PREROUTING Kernel Space Outside POSTROUTING PREROUTING Real ppp0 IP.src  Real Eth0 IP.dst Real ppp0 IP.src  Real Eth0 IP.dst Real Eth0 IP.src  Real ppp0 IP.dst Real Eth0 IP.src  Real ppp0 IP.dst

23. Access to TCP Internals States: Web100 + patch • The Web100 software implements instruments in the Linux TCP/IP stack. • kernel patch adding the instruments • suite of "userland" libraries and tools for accessing the kernel instrumentation. • we have developed a python script to save all the tcp parameters exposed by web100 in a asynchronous way • Instantaneous values of Cwnd, SampleRTT, Smoothed RTT, RTO, etc • Access to RTO events needs to be synchronous • Patch in the TCP retransmit timer handler to record sequence number, wcid, timestamps of each RTO

24. Execution of the tests: iperf • The TCP flows are generated using Iperf • “Iperf is a commonly used network testing tool that can create TCP and UDP data streams and measure the throughput of a network that is carrying them” (wikipedia) • Causes for rate limitation: • Application (low rate or burst traffic generation) • Limited Receiver Buffer (erroneous settings) • Full Receiver Buffer (the application empties the buffer too slowly, because it has to write receiver data on the disk, or it’s engaged in other jobs) • Network Limitation (bandwidth, packet loss) • Using iperf our tests should be limited only by the network.

25. Some details • UMTS Rel. 5 • Linux kernel 2.6.27-web100 kernel • TCP Reno with default parameters • Sack • Dsack • Timestamp Option • Windows Scaling Option, • $ cat /proc/sys/net/ipv4/tcp* • 1h TCP/IP Flow • The traffic of each interface is dumped. To reduce discarded packets: • Snaplen limited to Layer2 header (14-16B)+ IP Header (20B) + TCP header (20B) + TCP Option Header (40B)

26. An algorithm for distinguish SRTOs and NRTOs Given the sequence number and the timestamp TRTO of a RTO, how to distinguish between NRTO e SRTO? Find IP.id of the segment that caused the RTO on the Sender Side (A) Find the correspondent segment (having the same TCP.seq and IP.id) on the receiver (B). If lost  NRTO Find IP.id of the correspondent ACK on B Find the timestamp T5 of the received ACK on A. If lost  NRTO If T5 > TRTO SRTO else  NRTO

27. Outline • Introduction to COST TMA (Data Traffic Monitoring and Analysis) • Collaboration between Poliba and CTTC • Presentation of Poliba’s Telematics lab • Statement of the Spurious Retransmission Time-Out problem in TCP connections • Testbed design and development • Analysis of the experimental results • Conclusions and future work

28. Commercial Network - Download Case (I)

29. Commercial Network - Download Case (II)

30. Commercial Network - Upload Case (I)

31. Commercial Network - Upload Case (II)

32. Packet Losses

33. A Comparison of Different Network Operators

34. Outline • Introduction to COST TMA (Data Traffic Monitoring and Analysis) • Collaboration between Poliba and CTTC • Presentation of Poliba’s Telematics lab • Statement of the Spurious Retransmission Time-Out problem in TCP connections • Testbed design and development • Experimental result analysis • Conclusions and future work

35. Conclusions and Future Work • SRTO is only a problem in a congested cell (Bari experiment) • Identification of the location of the congestion • Radio interface • Wired interfaces • Radio access network • Core network • Network configuration problem or technology limitation? • Use of extreMe cellUlar System Architeture (MUSA) • High number of RTOs due to the UMTS uplink • RLC retransmissions do not succeed in hiding channel losses to TCP • Scarce utilization of uplink radio resource by TCP • Behavior of other implementations of TCP • Cubic • Westwood+

36. Thanks for your kind attention! • Questions? Gennaro Boggia, Antonio Barbuzzi Assistant Professor, PhD Student Telematics Lab Politecnico di Bari boggia@poliba.it; a.barbuzzi@poliba.it Paolo Dini Research Associate IP Technologies CTTC paolo.dini@cttc.es