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

Gennaro Boggia, Antonio BarbuzziAssistant Professor, PhD studentTelematics Lab - Politecnico di Bari

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

Paolo DiniResearch AssociateIP Technologies Area - CTTC

CTTC Weekly Seminar – March 9, 2009 – Experimental Analysis of TCP spurious retransmission time-out in 3G/3.5G networks 2

OutlineOutline

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


OutlineOutline





connections





COST Action IC0703 – Data Traffic Monitoring and AnalysisCOST 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


COST Action IC0703 – Data Traffic Monitoring and AnalysisCOST 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


Telematics Lab - General DescriptionTelematics 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.


Main Research AreasMain 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


PeoplePeople

Pietro Camarda

Gennaro Boggia

Domenico Striccoli

Luigi Alfredo Grieco

Antonio Barbuzzi

Roberto Dell’Aquila

Giammarco Zacheo

Rossella Fortuna

Francesco Capozzi

Claudia Cormio

Alessandro D’Alconzo

Giuseppe Piro

Maria Rita Palattella

Roberta Laraspata

Carla Passiatore

Full Professor

Assistant Professor

PhD Students

Visiting Researcher

Post-Doc


International CooperationInternational Cooperation

FTW at Vienna (Austria)

Nokia Siemens Network at Aalborg (Denmark)

CTTC at Barcelona (Spain)

VTT at Oulu (Finland)

INRIA at Sophia Antipolis (France)


Some projectsSome 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.


OutlineOutline





connections





Recalling TCP behaviorRecalling 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


SRTO: definitionSRTO: 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

Sender

Receiver

RTO

Seq.

Num

b. 1

Seq.

Num

b. 15

00

Seq.

Num

b. 1

500

Ack. Numb. 1500

Ack. Numb. 3000


Effects of SRTOEffects of SRTO

Retransmitted segments generate 3DUPACKs and a spurious fast retransmit

Transmission of new segments are delayed

SenderRTO

Seq.

Num

b. 1

00 Ack. Numb. 600

Receiver

Seq.

Num

b. 6

00Se

q.Nu

mb.

110

0Se

q.Nu

mb.

160

0

Seq.

Num

b. 1

00

Seq.

Num

b. 6

00

Seq.

Num

b. 1

100

Seq.

Num

b. 1

600

…

- A. Gurtov, R. Ludwig, Responding to Spurious Timeouts in TCP, In Proc. of IEEE INFOCOM, Mar. 2003

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)


Some remarks on SRTOSome 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.


SRTO in 3G/3.5G networkSRTO 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


How to reveal a SRTOHow 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


OutlineOutline





connections





TestbedTestbed

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

3G core network

Internet

MobileStation

WiredHost

M HW


Loopback Avoidance (I)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


Loopback Avoidance (II)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


Loopback Avoidance (III)Loopback Avoidance (III)

Fake Eth0 IP.src Real ppp0 IP.dst

Real Eth0 IP.src Real ppp0 IP.dst

Real Eth

0 IP.sr

c Rea

l ppp0 I

P.dst

Real Eth0 IP.src Fake ppp0 IP.dst

Fake ppp0 IP.src Real Eth0 IP.dst

Real ppp0 IP

.src

Real E

th0 IP.dst

Real ppp0 IP.src Real Eth0 IP.dst

Real ppp0 IP.src

Fake Eth0 IP.dst

Kernel SpaceOutside

POSTROUTING PREROUTING POSTROUTING PREROUTING

eth0 ppp0


Access to TCP Internals States: Web100 + patchAccess 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


Execution of the tests: iperfExecution 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.


Some detailsSome 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)


An algorithm for distinguish SRTOs and NRTOsAn 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


OutlineOutline





connections


Analysis of the experimental results



Commercial Network - Download Case (I)Commercial Network - Download Case (I)


Commercial Network - Download Case (II)Commercial Network - Download Case (II)


Commercial Network - Upload Case (I)Commercial Network - Upload Case (I)


Commercial Network - Upload Case (II)Commercial Network - Upload Case (II)


Packet LossesPacket Losses


A Comparison of Different Network OperatorsA Comparison of Different Network Operators

Mean RTT

[s]

Mean Download Bandwidth

[Kbps]

Mean

Num. RTOs

Mean

Num. SRTOs

Net#1

Barcelona

2.392 790.55 2 0.9

Net#2

Vienna

1.213 1360.9 1.2 0.8

Net#3

Bari

3.603 544.5 38 19


OutlineOutline





connections





Conclusions and Future WorkConclusions 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+


Thanks for your kind attention!Thanks for your kind attention!

Questions?

Paolo Dini Research AssociateIP [email protected]

Gennaro Boggia, Antonio Barbuzzi Assistant Professor, PhD StudentTelematics LabPolitecnico di [email protected]; [email protected]

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

Documents

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