1

TCP Noordwijk: optimize TCP-based transport over DAMA in satellite networks

C. Roseti University of Rome “Tor Vergata” via del Politecnico 1, 00133, Rome, Italy

E. Kristiansen European Space Agency Keplerlaan 1, NL-2200 AG Noordwijk, The Netherlands

TCP Noordwijk is a new transport protocol designed to optimize performance in a controlled environment whose characteristics are fairly known and managed, such as a DVB-RCS link between I-PEPs. Main requirements in the protocol design were the optimization of the web traffic performance, while keeping good performance for large file transfers, and efficient bandwidth utilization over DAMA schemes. To achieve such goals, TCP Noordwijk proposes a novel sender-only modification to the standard TCP algorithms based on a burst transmission. The new protocol has been implemented in the Network Simulator Ns-2 and its performance are therefore compared to those of TCP congestion control mechanisms used in the I-PEP: Van Jacobson’s Slow Start and Congestion Avoidance algorithms, and TCP Vegas. In addition, a prototype implementation of TCP Noordwijk is used for preliminary trials over a real DVB-RCS link.

Nomenclature ACK = Acknowledgements CRA = Constant Rate Assignment DAMA = Demand Assignment Multiple Access DVB = Digital Video Broadcast DVB-RCS = DVB – Return Channel by Satellite GW = Satellite Gateway I-PEP = Interoperable – Performance Enhancing Proxy NCC = Network Control Centre RBDC = Rate Based Dynamic Capacity RTT = Round Trip Time SCPS-TP = Space Communications Protocol Standards-Transport Protocol ST = Satellite Terminal TCP = Transmission Control Protocol VBDC = Volume Based Dynamic Capacity

I. Introduction CP was designed for congested wired network and, as largely reported in the literature1,2, some of the assumptions made in the design phase fail in the point-to-point geostationary satellite link. Specifically, TCP

congestion control3,4 is designed neither for satellite link nor for web traffic, which composes most of the today’s network load; this leads to very poor performance. Moreover, modern satellite standards envisage the use of DAMA mechanisms that may introduce variable effective RTTs and well above the propagation delay, and the available bandwidth may vary strongly and abruptly5,6.

A DVB-RCS satellite communication system7,8 is considered in this paper as a reference scenario. Furthermore, I-PEP protocol stack9, defined within Satlabs working group10 to both improve performance and guarantee inter-

T

2

operability among terminals from different vendors, is assumed at the edges of the satellite links. The transport protocol between I-PEPs is CCSDS SCPS-TP11, which implements two alternative congestion control algorithms: Van Jacobson Slow Start and Congestion Avoidance3,4, referred herein as the standard TCP, and TCP Vegas14.

In this framework, a novel transport protocol TCP-compatible and TCP friendly, namely TCP Noordwijk, has been designed with the aim of avoiding the two major shortfalls of congestion control based approaches in case of short transfers (e.g. HTTP traffic) over DAMA:

• Ineffective bandwidth utilization; • Wasteful window adjustment over asymmetric links with bandwidth changes.

Compatibility with TCP is guaranteed by only sender-side modifications, while receiver functionalities are kept unaltered. In addition, TCP Noordwijk replaces TCP congestion control mainly based on Slow Start and Congestion Avoidance algorithms with a rate control scheme where the traditional “TCP sliding window” concept is replaced by the “wave” concept13,14. The key idea is to send data into bursts (waves) sized and spaced on the basis of in-band information convoyed by the ACK flow.

TCP Noordwijk has been implemented on the Network Simulator Ns-215 as well as on a software prototype based on the Mitre SCPS implementation16. Therefore, simulation results have been compared to outcomes of trials over real satellite links. Performance analysis is concerned connection throughput, resource utilization, fairness among TCP Noordwijk connections and friendliness of TCP Noordwijk respect to the standard TCP.

The reminder of this paper is as follows: Section II resumes TCP problems over DAMA and tracks requirements for the design of an optimized transport protocols; Section III provides details of TCP Noordwijk protocol: the general architecture, the key concepts; Section IV shows performance results coming from both simulation and trials; finally conclusions are resumed in the Section V.

II. TCP over DAMA

A. Reference scenario The target environment is a DVB-RCS system based on a star topology with a hub/gateway (GW/NCC) and

several Satellite Terminals (STs). A sketch of the overall scenario is represented in the Figure 1. I-PEP agents, installed at the edges of the satellite links, split end-to-end TCP connections into three separate sub-connections: a TCP connection between TCP sender and an I-PEP, a SCPS-TP connection between I-PEP and a further TCP connection between I-PEP and TCP receiver. Both standard TCP and TCP Vegas congestion control can be alternatively used in the SCPS-TP. STs can be connected to one or more applications PCs or servers through different access networks (e.g. LAN, WLAN). On the other side, GW is connected to the Internet making possible connectivity to either remote servers (e.g. Multimedia, FTP, Web, e-mail) or remote users.

In the satellite return link, bandwidth is shared among STs according to a DAMA scheme. In this study, three DAMA algorithms are considered: CRA, RBDC and VBDC7,8 as well as their possible combinations.

This paper addresses performance of TCP-based traffic over the link between I-PEPs delimited by the colored rectangle in Figure 1, and considered as the bottleneck of the whole link. To this purpose, terrestrial networks at both sides of the satellite networks are assumed to be broadband and with a relatively short delay.

Figure 1: Reference scenario

3

B. TCP problems over DAMA TCP is a reliable transport protocol based on a congestion control scheme aimed at preventing the collapse of the

congested terrestrial network. Specifically, TCP gradually probes the available bandwidth through a “window-based” approach by increasing its sending rate (congestion window size) on a time scale proportional to RTT. The Slow Start and Congestion Avoidance algorithms3,4 regulate the TCP window increase. TCP interprets both increases on RTT and packet losses as signals of network congestion, and consequentially reduces its sending rate.

In a DVB-RCS environment, packet loss is not meaningful, since a strong Forward Error Correction (FEC) is applied at the lower layers, while the use of DAMA schemes may introduce effective RTTs well above the satellite physical delay (already high). In practice, TCP and DAMA perform two control loops interacting with each other. With reference to Figure 2, TCP control loop starts with data coming from a TCP socket that feeds MAC buffer of the ST. Depending on the amount of stored bytes, DAMA control loop is activated: ST sends a capacity request to the NCC, which in turn responds with an allotment notification. At the end of DAMA control loop, if at least a part of the requested capacity is allocated, the ST is allowed to send data on the return link. As a consequence, the reception of the packet or ACK by the TCP socket on the other side determines the end of the TCP control loop.

Figure 2: TCP and DAMA control loops

CRA is a fixed allocation, available permanently for an ST irrespective of whether it is used. Then, the DAMA

control loop is absent and RTT is constant and equal to the physical satellite delay. To opposite, both VBDC and RBDC dynamically allocate capacity through the aforementioned DAMA control loop. VBDC request is a one-off request for a given volume of data, so the bandwidth utilization is 100%. Then, experienced RTT is typically increased of around 1 second due to the request/allocation cycle5,6. RBDC request is for a given data rate and is typically valid for some seconds. The impact of dynamic allocation on RTT is therefore less severe than for VBDC. In particular, the experienced RTT is similar to the one achieved in CRA, except for some extra delay on first request and on adjustment of requested rate.

C. Transport Protocol Requirements DVB-RCS links are controlled communication environments whose characteristics are fairly well known and

managed, such as a point-to-point satellite link between I-PEPs. Two of the basic assumptions made by the standard TCP fall in such a scenario:

• Losses are signals of network congestion – By considering point-to-point links, I-PEP buffers are most likely tailored to the traffic needs.

• RTT increases are proportional to the congestion – DAMA schemes introduce extra delay that may vary strongly and abruptly.

In addition, TCP has been designed to cope well with long data transfers able to reach steady-state (Congestion Avoidance) by allowing a fair sharing of the available capacity among multiple connections. Instead, short transfers are usually completed within the Slow Start with a consequent underutilization of the available resources.

In order to design a transport protocol optimized for DVB-RCS, the following requirements have been then identified:

• The protocol must be compatible with I-PEP specification9; • The protocol must be interoperable with I-PEPs that comply with I-PEP specification, but do not support

the new transport protocol;

4

• The protocol must optimize web traffic performance, while keeping good performance for larger file transfer;

• The protocol must efficiently operate over all the supported DVB-RCS DAMA schemes.

III. TCP Noordwijk TCP Noordwijk is a TCP-compatible and TCP friendly protocol based on sender-only modifications. Its design

is particularly aimed at providing high transmission rates in satellite asymmetric link running DAMA algorithms, such as DVB-RCS systems. Furthermore, TCP Noordwijk is tailored to efficiently transmit short amount of data without compromising reliability scalability provided by the standard TCP.

These goals are achieved by replacing the classical “window-based” transmission with a “wave-based” transmission13,14. Specifically, the “wave” consists on a predetermined burst of packets sent back-to-back respecting the following conditions:

• The “wave” size is fixed within a given time interval. Transmission is completely regulated by two state variables: BURST and TX_TIMER. BURST regulates the “wave” size, while TX_TIMER represents the time interval, in which BURST can be neither slid nor changed.

• BURST and TX_TIMER are updated according to ACK-based measurements. ACK-based measurements and “wave” variations are asynchronously managed.

Management of the data transmission relies on the separation of the protocol functions into three components: ACK-based estimation component, Flow Control and Rate Control. The ACK-based estimation component manages the ACK reception and gathers information/statistics to forward to both Flow Control and Rate Control component.

The basic TCP Noordwijk sender algorithm is shown in Figure 3. At the beginning, sender transmits a burst with the initial size of BURST0=N0. As long as the Rate Control in not able to update both BURST and TX_TIMER variables, N0-sized bursts are allowed every TX_TIMER0=Δ0 seconds. This initial “blind” phase lasts at least 1 RTT, that is until the first ACK train is received by the ACK-based estimation component. N0 and Δ0 are set in order to optimize the transmission of short amount of data: e.g. N0≥web object size and N0/Δ0=target rate. As clearly shown in Figure 3, after any idle time TCPN sender recovers initial configuration. This behavior is tailored for typical web page downloads. Possible losses (Nloss) are detected by the ACK-based estimation component and are immediately retransmitted (Flow Control).

If there is not further data to transmit, sender enters in an idle state until new data is ready to be sent and the initial state (N0 and Δ0) is recovered. To opposite, if there are further packets to transmit, sender manages the transmission of Ni-sized burst every Δi seconds, as continuously computed by the Rate Control.

Figure 3: TCP Noordwijk sender behavior

5

A. ACK-based estimation component This component intercepts all the received ACKs and generates statistics useful for rate control. In addition,

possible packet losses are detected by either ACK missing or SACK signaling and are communicated to the flow control. In particular, the following parameters are continuously measured:

• ACK train dispersion; • RTT.

The ACK train dispersion (Δi)15,16 indicates the “service capacity” of the overall system. That is, the time needed to sender/receiver to process a burst of Ni packets: deliver data to the receiving application and send the corresponding ACKs. Dispersion value depends on both the DAMA processing delay and physical constraints. Then, sending of a burst of Ni packets every Δi seconds is equivalent to fully exploit the “service capacity” of the link, or in other words to fully exploit the bottleneck capacity.

On the other hand, RTT experienced for each burst varies accordingly the congestion level. Therefore, by comparing the measured RTT to the minimum RTT experienced throughout the connection, it is possible to estimate the congestion level.

B. Flow Control Flow Control controls timing of the burst transmission and manages retransmission of possible lost packets.

Losses are notified by the ACK-based estimation component (e.g. SNACK signaling, duplicate ACKs) or through timeout expiration. In the former, lost packets are instantaneously retransmitted at once. Furthermore, in order to not alter the overall rate the next burst size (Ni) is reduced by the amount of retransmitted packet. This means that the ACK-based estimation component notifies losses to both Flow Control and Rate Control component. To opposite, the Retransmission Time Out (RTO) algorithm is based on the standard “exponential backoff”4. When RTO expires retransmission starts from the first not acknowledged packet and the initial setting of both BURST and TX_TIMER are recovered. In case of consecutive RTO expiration, retransmission is repeated while Δ0 is doubled.

C. Rate Control Rate Control adapts the burst-based transmission to both the link capacity and its dynamic variations. This can

be achieved by a twofold way: • Increasing/decreasing the BURST size, keeping the TX_TIMER constant; • Increasing/decreasing the TX_TIMER interval time, keeping the BURST size constant.

Specifically, BURST and TX_TIMER are updated at each ACK train reception based on the following parameters:

• δi – averaged value of the ACK inter-arrival time; • Δi=δi⋅Ni – ACK train dispersion for the ith burst (Ni); • RTTmin – the minimum measured RTT; • ΔRTTi=RTTi-RTTmin –difference between the current RTT and the minimum RTT.

First, rate control envisages two different algorithms: Rate Tracking and Rate Adjustment. The former is run in absence of congestion, while an experienced congestion state leads to run the Rate Adjustment algorithm. The meter to detect congestion is the ΔRTTi value:

if ΔRTTi≤β → Rate Tracking if ΔRTTi>β → Rate Adjustment where β is the “congestion threshold” depending on both the running access scheme and the application

requirements. Dynamic access schemes with oscillatory trend in the allocated resources (i.e. RBDC) requires high β in order to prevent that variations in the “access delay” are misinterpreted as congestion. On the other hand, lower β values allow to limit the jitter experienced by applications. The effect of any change in the transmission parameters will be observed on the system with a given delay, proportional to RTT. For this reasons protocol iterations in either Rate Tracking or Rate Adjustment are performed once for every S received ACK-train. S is called “stability factor” and is representative of the system response time.

Rate Tracking algorithm aims at adapting transmission rate to the maximum allowed rate trough the following steps. Specifically, BURST size is gradually increased (logarithmic growth) up to the initial BURST size (N0) and TX_TIMER is fixed to the optimal value for N0-bursts: Δi=δi⋅N0.

Congestion experience (ΔRTTi>β) triggers the Rate Adjustment algorithm.In this case, BURST size is reduced according to the experienced congestion level, while keeping TX_TIMER unchanged.

6

IV. Performance analysis TCP Noordwijk protocol has been implemented on the Network Simulator Ns-215. Furthermore, the satellite

baseline module has been enriched with a DAMA MAC implementation including CRA, RBDC and VBDC access scheme7,8. The resulting simulation platform has been used with the twofold aim of validating TCP Noordwijk algorithms and evaluating its performance over different DAMA schemes, compared with standard TCP and TCP Vegas. All the simulated tests presented below envisage a point-to-point asymmetric link via satellite where the forward link capacity is 10 Mbit/s and the return link capacity is 2 Mbit/s.

In addition, a TCP Noordwijk prototype implementation has been developed based on the MITRE corporation software16: a SCPS static library and a SCPS transparent transport layer gateway. Such a prototype has been used to perform preliminary tests over a real DVB-RCS link.

A. TCP Noordwjik sender behavior A first set of simulation highlights the burst nature of the TCP Noordwijk transmission. Figure 4 and Figure 5

show TCP Noordwijk sender behavior by considering the following traffic schedule: • A target TCP Noordwijk transfer is performed over the return link for 10 seconds. Plots are concerned to

the transmission activity of this connection; • A second TCP Noordwijk transfer is run in the same direction for 1 second (the interval time from 2 to 3)

acting as competing traffic. Figure 4 shows the value of the BURST variable at regular time interval (equal to superframe duration). Instead,

details on transmission timing are provided in the Figure 5, where the blue circles indicate TCP packets, organized in burst as delivered from transport layer to the lower layer, the red dashes represent TCP Packets transmitted over the air interface and green crosses represent the received ACKs. For the sake of the clarity, Figure 5 is concerned only the first 5 seconds of the simulation.

At the start, both BURST and TX_TIMER variables are set to their initial values: N0=20 packets and Δ0=500 ms, for an overall transmission rate of 480 kbit/s. When the first ACK train is received, TCP sender runs Rate Tracking algorithm and TX_TIMER is updated in order to transmit at the maximum rate by keeping bursts of 20 packets. The achievement of the maximum rate is demonstrated by the uninterrupted transmission of packets through the air interface (Figure 5). In other words, the first packet of each burst is sent just after the last of the previous burst.

After 2 seconds, a new TCP Noordwijk connection is run to send only 2 bursts. In correspondence of such concurrent sending, bursts of the target connection are temporary buffered as is clearly deducible in Figure 5 by the gap from the delivery time of bursts and their effective transmission over the air interface. As a consequence, the overall RTT is increased triggering the Adjustment Rate algorithm. In fact, Figure 4 shows that after about 2,7 seconds (reception of the ACK train relative to the first delayed burst), TCP sender experiences the increased RTT and accordingly reduces the burst size.

After about 3,5 seconds, the reduction of the burst size and the end of the second connection lead to an RTT close again to the minimum RTT (see Figure 4), so that the tracking rate algorithm is restored and the burst size is gradually increased. Finally, since there is not more competing traffic, burst size grows until the initial value achieving then the maximum transmission rate.

Figure 4: Burst size variations

7

Figure 5: TCP Noordwijk sender behavior

B. TCP Noordwijk Performance One of the aims of TCP Noordwijk is to allow an optimal utilization of the available resources avoiding

inefficiencies of Slow Start approach of the standard TCP. In fact, depending on the initial Slow Start threshold (ssthresh), standard TCP needs of several RTT before getting the entire capacity. In the considered scenario, this means to underutilize the network capacity for considerable time interval: from few dozens to some hundreds of seconds.

Figure 6 envisages the case a long TCP transfer is performed over the return link accessed by either RBDC (Figure 6-a) or VBDC (Figure 6-b). TCP Noordwijk throughput (with a 5-seconds sampling) is then compared with both standard TCP and TCP Vegas one. In case of RBDC (Figure 6-a), TCP Noordwijk gets the whole bandwidth in few seconds. This is a great achievement compared with the about 40 seconds needed to standard TCP. On the other hand, TCP Vegas attempts to determine the optimal window by comparing current RTT with the minimum RTT. But, since it is not able to distinguish DAMA delay within the overall RTT, transmission rate is erroneously fixed to less then 200 kbit/s (1/10 of the available capacity). VBDC further degrades both standard TCP and TCP Vegas performance: the former achieves the maximum rate after 400 seconds while the latter stabilizes its rate at about 67 kbit/s (Figure 6-b). To opposite, TCP Noordwijk performance are maintained good by reaching the maximum rate after 20 seconds, while before the rate is however in the order of 1 Mbit/s.

(a) TCP transfer over return link - RBDC (b) TCP transfer over return link - VBDC

Figure 6: TCP throughput: comparison among TCP Noordwijk, standard TCP and TCP Vegas

The following tests considers a most complex simulation scenario where a single TCP Noordwijk is run over the return link for 700 seconds and at regular time intervals shares capacity with other flows running either TCP Noordwijk or standard TCP and transferring objects of different sizes. In particular, competitive connections are scheduled as resumed in the Table 1.

8

Connection start time (Seconds) Transport Protocol Object size (Mbytes)

50 TCP Noordwijk 0,1 100 TCP Noordwijk 0,5 150 TCP Noordwijk 1 200 TCP Noordwijk 2 250 TCP Noordwijk 10 350 Standard TCP 0,1 400 Standard TCP 0,5 450 Standard TCP 1 500 Standard TCP 2 550 Standard TCP 10

Table 1: Scheduling of the simulated traffic

With the proposed traffic scheduling, a large number of performance aspects of TCP Noordwijk can be analyzed in detail:

• Total throughput-utilization of the available capacity in case of multiple connections; • Short transfer optimization-attitude of privileging transfers of short objects; • Fairness-fair sharing of the available capacity among competitive TCP Noordwijk connections • Standard TCP friendliness-attitude to leave bandwidth to competitive standard TCP connections, while

preserving an optimal bandwidth utilization; • Scalability-avoid congestion collapse in case of multiple connections; this is evaluated by monitoring the

queue occupancy at the ST side (bottleneck).

Results envisage three different DAMA schemes: CRA (Figure 7), RBDC (Figure 8) and VBDC (Figure 9). For each case, simulation outcomes are organized into two graphs:

1. A throughput graph showing the throughput of all the single connections (narrow-dotted line represents

background TCP Noordwijk connection, thin lines represent competitive TCP Noordwijk connections, wide-dotted lines represent competitive standard TCP connections) along with the total throughput (tick line).

2. A graph showing the overall queue occupancy. Figure 7 concerns CRA. With reference to the throughput graph (Figure 6-a), it is evident that background TCP

Noordwijk connection quickly reduces its transmission rate in correspondence of competitive transfers. This generally allows to limit queue occupancy guaranteeing protocol scalability. In fact, along the whole simulation queue occupancy is always below 200 kbytes irrespective of duration of competitive connections (Figure 6-b). Spikes in queue occupancy rely on the bursty nature of TCP Noordwijk transmission and depend on both the initial burst size (N0) and the number of simultaneous connections. However, since the queue occupancy converge to a given value and communication environment is assumed controlled, the only precaution needed for using TCP Noordwijk is to tailor both the initial burst size and the buffer size on the basis of traffic prediction in the worst case.

When competitive transfers run TCP Noordwijk, after a first phase where the new connection is privileged (“blind” phase), the two connections aim to equally share the available bandwidth. This is particularly evident during the transfer of the 10-Mbytes object, where throughput of the two connection oscillates around similar values for about 50 seconds. Then, TCP Noordwijk presents a good fairness. From this point of view, background TCP Noordwijk connection tends to leave bandwidth to standard TCP connections as much as they need. TCP Noordwijk transfer behaves as a “low-priority” transfer (friendly with standard TCP). Finally, transfer times for the different sized object are reported into the Table 2. Since there are not additional delays due to DAMA, TCP Noordwijk acceleration in transfer short objects exclusively relies on the adopted burst-based rate control approach instead of standard slow start algorithm. In case of the longer transfers (i.e. 1-2 MBytes), gap between standard TCP and TCP Noordwijk is reduced, while standard TCP outperforms TCP Noordwijk in transferring a 10-Mbytes object. The rationale is that TCP Noordwik connections, after the initial “blind” phase, aim to equally share the bandwidth with the background connection, while the latter dynamically leaves to standard TCP connections all the bandwidth they need.

9

(a) TCP throughput (b) Queue occupancy

Figure 7: TCP Noordwijk performance over CRA

Object size (Mbytes) TCP Noordwijk Standard TCP 0,1 1,51 3,72 0,5 4,9 7,3 1 8,86 11,35 2 16,57 18,03

10 95,54 58,84 Table 2: Object transfer time –CRA

Figure 8 reports results obtained when RBDC is run as access scheme. TCP Noordwijk performance is not

affected by delay variability and throughput trends (Figure 8-a) are very similar to those seen in the CRA case. In definitive, the optimal bandwidth utilization, good fairness, optimization of the short transfers and friendliness with standard TCP are all confirmed.

(a) TCP throughput (b) Queue occupancy

Figure 8: TCP Noordwijk performance over RBDC

Even the delay variability introduced by RBDC further accelerates TCP Noordwijk transfers (see Table 3). This is due to the characteristics of RBDC scheme that initially introduces an high access delay, similar to VBDC, and then performs similar to CRA. TCP Noordwijk initially estimates an high minimum RTT and then experiences the presence of a concurrent connection later. Therefore, Rate Tracking is performed for a larger time period at the start and consequentially the initial acceleration is more long than in CRA. As a drawback, queue requirements are more severe. In the Figure 8-b, spikes in the queue occupancy are up to about 900 Kbytes.

To opposite, the variable RTT meaningfully impact on performance of standard TCP, which is slower in increasing its transmission rate, as demonstrated by the object transfer times listed in the Table 3.

10

Object size (Mbytes) TCP Noordwijk Standard TCP 0,1 1,51 5,32 0,5 3,59 14,35 1 6,04 17,46 2 15,92 37,68

10 83,51 111,29 Table 3: Object transfer time -RBDC

TCP Noordwijk ability in coping with variable RTT is confirmed also when VBDC runs as an access scheme. In

fact, Figure 9 and Table 4 present results enough similar to those achieved over RBDC: • TCP Noordwijk performance is resilient to the access delay and its variations, especially when

performing the transfer of short objects; • Standard TCP performance is made worse due to the higher access delay introduced by VBDC5.

The only difference is that TCP Noordwijk throughput is subject to oscillations when bandwidth is competed among multiple long connections. This leads to a total throughput in average slightly lower then the available capacity.

(a) TCP throughput (b) Queue occupancy

Figure 9: TCP Noordwijk performance over VBDC

Object size (Mbytes) TCP Noordwijk Standard TCP

0,1 1,51 8,52 0,5 5,94 18,58 1 8,48 27,33 2 18,36 43,04

10 93,29 138,26 Table 4: Object transfer time -VBDC

C. Preliminary trials over a real DVB-RCS link Two I-PEP gateways including TCP Noordwijk prototype implementation have been connected at the edges of a

DVB-RCS platform located in the ESRIN facilities of the European Space Agency (ESA). Both Hub and ST are based on Alcatel/EMS technologies. Hub operates in C-band and provides a two-way broadband access via the geostationary satellite Atlantic Bird 3 (5° West). For TCP Noordwijk tests, a bandwidth of 4 Mbit/s has been permanently granted in the forward link, while ST accesses 512 kbit/s of return link in either CRA or VBDC.

A 10 Mbytes iperf transfer has been performed from Hub to ST by alternatively running as a transport protocol TCP Noordwijk, standard TCP and TCP Vegas. Initial TCP Noordwijk parameters are the following: N0=20 packets and Δ0=650 milliseconds, giving an initial transmission rate of about 370 kbit/s. For each test run, the average throughput has been measured and results for CRA and VBDC are reported in the Table 5 and Table 6 respectively.

11

Transport Protocol Average Throughput (Mbit/s) TCP Noordwijk 3,53 Standard TCP 2,83

TCP Vegas 3,14 Table 5: TCP average throughput over CRA

Transport Protocol Average Throughput (Mbit/s)

TCP Noordwijk 2,19 Standard TCP 1,58

TCP Vegas 1,12 Table 6: TCP average throughput over VBDC

TCP Noordwijk outperforms the other TCP protocols over both CRA and VBDC. Specifically, in case of CRA,

the tracking rate algorithm allows TCP Noordwijk to achieve the maximum rate just after its initial blind phase. Of course, also performance of both standard TCP and TCP Vegas are quite good since RTT is constant. Performance degradation with respect to TCP Noordwijk are then due to the inefficiency of the Slow Start algorithm.

In the VBDC case, performance is strongly affected by RTT variations, especially as far as TCP Vegas is concerned. TCP Noordwijk, even though outperforms the others protocols, achieves an average throughput slightly higher than half of the available capacity. Unfortunately, the absence of details about VBDC algorithm and the short time available for tests, have not allowed a fine tuning of the protocol (i.e., β parameter). By the way, this preliminary test campaign in a real environment is more than encouraging.

V. Conclusions This paper presents a new transport protocol, named “TCP Noordwijk”, specifically designed to optimize TCP-

based transfers of short objects/files over DAMA access schemes. The reference scenario is a DVB-RCS satellite network where I-PEP transport protocol (SCPS-TP) achieves poor performance. Nevertheless, TCP Noordwijk is meant for all the controlled communication environments with an high bandwidth-delay product in which the classical Slow Start approach results inefficient to transmit short amount of data. Simulation results largely demonstrate TCP Noordwijk’s ability of providing optimum performance over DAMA schemes, in some senses also beyond the initial requirements. In fact, even though performance target was to optimize short transfers like web traffic, performance of long transfers are optimized in terms of throughput, resource utilization, and fairness. Furthermore, TCP Noordwijk behaves as a “low priority” TCP when running along with standard TCP. This makes TCP Noordwijk also suited for particular scenarios needing a service prioritization among different traffic classes: i.e. by considering a LAN of a corporation, applications for remote data backup, running over TCP Noordwijk, use only the bandwidth left free by Web traffic, running over standard TCP. Preliminary trials over real DVB-RCS links confirm performance benefits on using TCP Noordwijk, encouraging the development of a stable implementation to use in the real systems.

References 1Partridge, C., Shepard, T. J., TCP/IP Performance over Satellite Links, IEEE Network, Sep. 1997, pp. 44-49. 2Allman, M., Hayes, C., Kruse, H., Osterman, S., TCP Performance over Satellite Links, 5th Int. Conference on

Telecommunication SystemsModeling and Design, 1997, pp. 1-13. 3Stevens, W., TCP/IP Illustrated vol. 1, Addison Wesley, MA, USA, 1994. 4Stevens, W., TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, RFC 2001, Jan.1997. 5Roseti, C., Kristiansen, E., TCP behavior in a DVB-RCS environment, in Proceedings of 24th AIAA International

Communications Satellite Systems Conference (ICSSC), San Diego, Jun. 2006. 6Sooriyabandara, M., Fairhurst, G., Dynamics of TCP over BoD satellite Networks, International Journal of Satellite

Communications and Networking, Vol. 21, No. 4-5, Jul. 2005, pp. 427-449. 7ETSI, Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems, DVB-RCS standard, EN

301 790. 8ETSI, Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems; Guidelines for the use of

EN 301 790. TR 101 790, V. 1.2.1, 2003. 9Interoperable PEP (I-PEP) specification, Transport Extensions and Session Framework for Satellite Communications: Air

Interface Specification, Oct. 2005 10http://www.satlabs.org

12

11Space Communications Protocol Specification (SCPS)-Transport Protocol (SCPS-TP), Recommendation fro Space Data System Standards, CCSDS 714.0-B-1, Blue Book, Issue 1, Washington, D.C.:CCSDS, May 1999.

12Brakmo, L.S., O’Malley, S.W., Peterson, L.L., TCP Vegas: New Techniques for Congestion Detection and Avoidance, in Proceedings of SIGCOMM’94, Aug. 1994.

13Tsaussidis, V., Badr, H., Verma, R., Wave and Wait Protocol: An Energy-saving Transport Protocol for Mobile IP-Devices, in Proceedings of the 7th IEEE International Conference on Network Protocols, Toronto, Canada, 1999.

14Tsaussidis, V., Lahanas, A., Zhang, C. The Wave & Probe Communication Mechanisms, Journal of Supercomputing, Kluwer Academic Publisher, Vol. 20, N. 2, Sep. 2001.

15The Network Simulator Ns-2, http://www.isi.edu/nsnam/ns. 16http://www.mitre.org