Franco Davoli, Giuseppe Spanò,

Stefano Vignola, Sandro Zappatore

CNIT - Italian National Consortium for Telecommunications

National Multimedia Communications Laboratory, Via Diocleziano 328, Napoli, Italy

and

Department of Communications, Computer and Systems Science (DIST)

University of Genoa, Via Opera Pia 13, Genova, Italy

(franco.davoli, giuseppe.spano, stefano.vignola, sandro.zappatore)@cnit.it

Performance Measurements and Comparison of Modified TCP Control Algorithmsover Rain-Faded Satellite Channels

Introduction and Objectives• Quite a few TCP modifications have been proposed, analyzed and

implemented, to cope with large bandwidth-delay product and error-prone networks, where the standard mechanisms of congestion control present problems.

• For many of such implementations, patches to the Linux kernel are available, which can be used to effectively configure the modified TCP and to use it in real world tests.

• However, in most cases the performance has been evaluated by simulation, and there are rather few works on measurements effected on real satellite networks or on emulated laboratory environments.

• The main goal of the paper is to compare some modified TCP congestion control algorithms in a laboratory setting, by performing repeatable experiments, involving traffic generators, routers, and an accurate satellite channel emulation with recorded fading data.

Laboratory setting

Laboratory setting Laboratory setting (cont’d)(cont’d)

• We have emulated the satellite link by using the facilities offered by the CNIT National Laboratory for Multimedia Communications in Naples, Italy.

• The LAN consists of a set of hosts devoted to generate TCP traffic. According to the specific test, up to ten connections can be running at the same time.

• All packets produced feed the router # 1 (CISCO 3640), which conveys them to a serial V.35 interface, adopting a HDLC protocol at the data link layer. The synchronous data flow is input to a Fairchild SM290 modem (modem # 1), operating in quadrature phase-shift keying (QPSK), at an information rate of 2048 kbit/s, with 3/4 sequential FEC.

• The outgoing modulated signal is applied to a Channel Simulator (here used as a simple programmable attenuator) and then added to a Gaussian noise, produced by a noise generator. Both the attenuation and noise variance are suitably changed, to reproduce the effects of real world fading as concerns the bit error probability observed at the receiver end.

Laboratory settingLaboratory setting (cont’d)(cont’d)

• The link budget was derived according to the Italsat satellite characteristics (G/T=23 dB at the receiver, under the adopted parameter values).

• After a delay of 250 ms, the corrupted signal feeds the receiver portion of a second modem, which interfaces with the router # 2.

• The return channel (i.e., the link connecting the outgoing signal from modem # 2 to the input of modem # 1) introduces again a delay of 250 ms, but it is not affected by errors.

• Fading attenuation values are taken from the results of the propagation experiment carried out in Ka band on the Olympus satellite by the CSTS (Centro Studi sulle Telecomunicazioni Spaziali) Institute, on behalf of the Italian Space Agency (ASI). The attenuation samples considered were 1-second averages, expressed in dB, of the signal power attenuation with respect to clear sky conditions. The adopted patterns are taken from data recorded at the Spino d’Adda (Northern Italy) station on September 21 and 23, 1992, respectively.

Fading Attenuation PatternsFading Attenuation Patterns

4

6

8

10

12

14

16

0 20 40 60 80 100 120 140 160 180 200 220 240 260

Time [s]

Fading [dB]

Fading pattern "A"

Fading pattern "B"

The pattern indicated as “B”, which corresponds to a quite severe fading, causes a temporary sync loss at the demodulator

TCP modificationsTCP modifications

• We have investigated the behaviour of 3 TCP modifications, and compared it with that of New Reno: TCP Westwood TCP Peach Complete Knowledge Satellite Transport Protocol (CK-STP)

• The first two introduce modifications to the congestion control mechanism; the third one only acts on the TCP New Reno parametrization, by assuming that the characteristics of the satellite bandwidth pipe are known at the transmitting station and losses are only due to channel errors.

TCP New RenoTCP New Reno

• New Reno is an improved version of TCP Reno that avoids waiting for a retransmit timer when multiple segments are lost from a window.

• The change concerns the sender's behaviour during Fast Recovery, when a partial ACK is received that acknowledges some, but not all of the segments that were outstanding. In New Reno, partial ACKs received during Fast Recovery are treated as an indication that the segment immediately following the acknowledged one in the sequence space has been lost, and should be retransmitted.

• Thus, when multiple segments are lost from a single window of data, New-Reno can recover without a retransmission timeout, retransmitting one lost segment per round-trip time until all of the lost segments from that window have been retransmitted.

TCP WestwoodTCP Westwood

• End-to-end, sender-side estimate of the bandwidth B available to a TCP connection and seen at the receiver, obtained by measuring and low-pass filtering the rate of returning ACKs.

• When 3 DUPACKs are received:– ssthresh = (B* RTTmin) / seg_size;– cwnd = ssthresh.

• When a coarse timeout expires:– ssthresh = (B* RTTmin) / seg_size;– cwnd = 1.

• When ACKs are successfully received, TCPW increases cwnd according to Reno's congestion control algorithm.

The main features of Westwood are the following:

TCP PeachTCP Peach

• TCP Peach implements Congestion Avoidance and Fast Retransmit (the same as Reno), and two new algorithms: Rapid Recovery and Sudden Start, which are based on the use of dummy segments, low priority segments generated by the sender as a copy of the last transmitted data packet.• If a router is congested, it discards dummy segments first, due to their low priority. On the contrary, the sender interprets the ACKs for dummy segments as the evidence that there are unused resources on the link and, accordingly, it can increase the transmission rate.

Complete Knowledge Satellite Transport Protocol (CK-STP)

• It follows the TCP New Reno implementation, with the adoption of the SACK option. "Complete Knowledge" refers to the assumed knowledge about the physical characteristics of the satellite link, in terms of propagation delay and channel bandwidth.

• It assumes that all losses over the satellite link are due exclusively to link errors. A constant transmission window set to the bandwidth-delay product is employed, in order to achieve the maximum channel bandwidth.

• With respect to the TCP implementation, the “slow start” phase is no longer entered, and for each received acknowledgement, the congestion window keeps its constant value. As far as the loss detection is concerned, the arrival of only one duplicate acknowledgement is necessary to trigger the recovery phase, which consists of retransmitting the lost data segments. Once the recovery phase has terminated, the protocol continues transmitting with the constant transmission window as set previously.

• The sender buffer is adjusted according to the bandwidth delay-product.

Complete Knowledge Satellite Transport Protocol Complete Knowledge Satellite Transport Protocol (CK-STP)(CK-STP)

Complete Knowledge Satellite Transport Protocol (CK-STP)

• We have used the original fading patterns over a longer time window (900 s), by replicating each sample 3 times, in order to have a longer time scale for observing the TCP reaction. Fading pattern A is milder, whereas B is quite severe, and produces a loss of receiver synchronization for over 100 seconds, starting at 400 s.

• All graphs are obtained by averaging the results of 5 repeated experiments (under the same fading pattern), in order to increase their statistical significance.

• In all kernel implementations adopted for the various protocols (except CK-STP) the sender buffer dimension has been left untouched, with respect to the native New Reno implementation for the Linux Kernel 2.4.18 (64 kbytes).

• The sender buffer is set at 320 kbytes for STP (independently of the number of connections).

Experimental measurementsExperimental measurements

Throughput (goodput) vs. time of the different TCP implementations with only one connection active over a noisy

satellite link (fading pattern A)

50

100

150

200

250

0 100 200 300 400 500 600 700 800 900

Time [s]

Throughput [kbyte/s]

Westwood New Reno STP Peach

Aggregate throughput vs. time of the different TCP implementations with 2 connections active over a noisy

satellite link (fading pattern A).

50

100

150

200

250

300

0 100 200 300 400 500 600 700 800 900

Time [s]

Throughput [kbyte/s]

Westwood New Reno STP Peach

Aggregate throughput vs. time of the different TCP implementations with 5 connections active over a noisy

satellite link (fading pattern A).

50

100

150

200

250

300

0 100 200 300 400 500 600 700 800 900

Time [s]

Throughput [kbyte/s]

Westwood New Reno STP Peach

Throughput vs. time of the different TCP implementations with only one connection active over a noisy satellite link

(fading pattern B).

50

100

150

200

250

0 100 200 300 400 500 600 700 800 900

Time [s]

Throughput [kbyte/s]

Westwood New Reno STP Peach

Aggregate throughput vs. time of the different TCP implementations with 2 connections active over a noisy

satellite link (fading pattern B).

50

100

150

200

250

0 100 200 300 400 500 600 700 800 900

Time [s]

Throughput [kbyte/s]

Westwood Reno SDR Peach

Aggregate throughput vs. time of the different TCP implementations with 5 connections active over a noisy

satellite link (fading pattern B).

50

100

150

200

250

0 100 200 300 400 500 600 700 800 900

Time [s]

Throughput [kbyte/s]

Westwood New Reno STP Peach

Throughput vs. time of three connections out of 5, measured during the realization of a single experiment with STP,

under fading pattern A.

10

20

30

40

50

60

70

80

90

100

0 100 200 300 400 500 600 700 800

Time [s]

Throughput [kbyte/s]

Throughput vs. time of three connections out of 5, measured during the realization of a single experiment with Westwood+,

under fading pattern A.

10

20

30

40

50

60

70

80

90

100

0 100 200 300 400 500 600 700 800

Time [s]

Throughput [kbyte/s]

Conclusions and future work• When a single connection is active, CK-STP achieves the best

performance. In this sense, it would be fruitfully employed within PEPs for the creation of a “bandwidth pipe”.

• In terms of fairness and aggregate throughput in different situations, TCP Westwood (which, by the way, is becoming a standard feature of recent Linux kernels) appears to offer the best performance.

• In the presence of multiple connections, the effect of TCP modifications becomes less evident, and the advantage of using modified algorithms may be hindered by the necessity of updating the operating system’s kernel of all the machines involved in the communication.

• The measurements are currently being repeated under the HB6 Ka payload link budget; some measurements will also be performed on the Ka/Ku band CNIT satellite network. Software tools have been already developed to make the laboratory test-bed remotely accessible as a web service.