Performance Issue 3: TCP over Satellite [3]

There are three factors that most affect throughput for TCP/IP over a satellite channel. They are 

• Long Feedback Delay.  

• Large Bandwidth‐Delay Product. 

• Transmission Errors. 

Similar to the mobile networks, TCP in satellite also cannot recognize that corruption and not network  congestion caused it to reduce its sending rate. Additional factors that serve to reduce throughput in‐ clude asymmetric routing and variable RTTs. Before we start with the performance issues of TCP used  for satellites let us understand the congestion control mechanisms for satellites. It has two phases: 

• The Slow‐Start Algorithm. Slow‐start, as the name implies, causes a TCP sender to gradually in‐ crease the amount of data injected into the network following connection establishment, the  restart of an idle connection, or a TCP connection time‐out. 

• The Fast Retransmit Algorithm. Fast retransmit enables a TCP sender to rapidly recover from a  single lost packet, or one that is delivered out of sequence, without shutting down the CWND.  When a TCP receiver detects the loss of a packet, it acknowledges subsequent packets with the  ACK number of the last correctly received packet. When the TCP sender receives three duplicate  ACKs, it then retransmits the lost packet. The receiver responds with a cumulative ACK for all  packets received up to that point. 

2.3.1 Performance Enhancement for TCP over Satellite [32] 

• Large Windows 

Large windows are required for other large bandwidth‐ delay networks such as ATM, Gigabit  Ethernet, and Packet SONET, so that just about all commercially available TCP implementations now  support the large window options. 

• Delayed ACKs 

Instead of generating an ACK for each received segment, a TCP receiver may choose to generate an  ACK for every second segment that arrives or, if a second segment does not arrive, wait for a time‐ out period of up to 500 ms before generating the ACK. 

• Larger Initial Window 

Slow‐start uses an initial window size of one. Starting off with a larger initial  window size of three  or four segments will allow more segments to flow into the network, generating more ACKs, and  will decrease the time it takes to complete the slow‐start process. 

• TCP SACK [25] 

TCP selective acknowledgments enable a TCP receiver to inform the sender of what specific seg‐ ments were lost so that the TCP sender can retransmit them.  

2.3.2  IPSEC over Satellite Links: A New Flow Identification Method [54] 

Acknowledgment based transport protocols such as TCP have low performance in satellite links, which  are characterized by high latencies and high bit error rates. Low performance of TCP in satellite links is  due to the fact that TCP packet losses are assumed to be the cause of congestion in the network, which  turns out to be an invalid assumption for satellite links. 

Proposed solution: TCP performance enhancing proxies (PEPs) are widely used to overcome the  limitations of TCP over satellite links. However, when end‐to‐end security mechanisms, such as IPSEC,  are used, TCP PEP mechanisms can not be used. IPSEC encrypts and/or authenticates the packet header  fields that the PEP needs to read or modify. However, mechanisms to integrate IPSEC with TCP PEPs are  also proposed. 

One such method is described in some detail below. A cryptographic hash of flow identification informa‐ tion is generated and stored in the IP header. The TCP sequence number is also stored in the IP header.  Using the hash value and sequence numbers, the PEP is able to match packets and corresponding ac‐ knowledgements to regulate the flow. This approach is applicable to PEP mechanisms that need read  access to the IP and TCP headers. 

2.3.3  TCP‐Peach [61] 

Current TCP protocols have lower throughput performance in satellite networks mainly due to the ef‐ fects of long propagation delays and high link error rates.  

Solution proposed:  TCP‐Peach is introduced for satellite networks. TCP‐Peach is composed of  two new algorithms, namely Sudden Start and Rapid Recovery, as well as the two traditional TCP algo‐ rithms, Congestion Avoidance and Fast Retransmit. The new algorithms are based on the novel concept 

of using dummy segments to probe the availability of network resources without carrying any new in‐ formation to the sender. Dummy segments are treated as low‐priority segments and accordingly they do  not affect the delivery of actual data traffic. Simulation experiments show that TCP‐Peach outperforms  other TCP schemes for satellite networks in terms of good put. It also provides a fair share of network  resources. [61]. 

2.3.4 Split TCP Connections in Satellites [3] 

Satellite systems offer greater challenges to TCP when switching from wired to wireless networks espe‐ cially due to higher data rates and high altitude satellites with longer delays and for handling broadband  Internet applications. In these scenarios, transmission control protocol (TCP) plays a critical role. Here,  the splitting the TCP connection in two or more segments with one segment connecting terrestrial  nodes across the satellite network is implemented. 

  An evolution of this idea: placing a TCP proxy on board the satellite that further subdivides the  end‐to‐end connection into separate TCP connections between ground and space. In this method we  need to focus upon the efficient use of buffer resources on board the satellite, while at the same time  enhancing TCP performance. Simulations show that an on‐board proxy provides a number of distinct  advantages and can enhance throughput up to threefold for both TCP New Reno and TCP Westwood, in  some scenarios, with relatively modest on‐board buffering requirements. The main points of concern in  this method are: the on‐board split proxy concept, the buffer management strategy.   

2.3.5 Network Striping for Satellites: Split TCP  

Several satellite systems currently in operation or under development claim to support broadband  Internet applications. In these scenarios, transmission control protocol (TCP) plays a critical role. Unfor‐ tunately, when used with satellite links, TCP suffers from a number of well‐known performance prob‐ lems, especially for higher data rates and high altitude satellites with longer delays. In response to these  difficulties, the satellite and Internet research communities have developed a large gamut of solutions 

ranging from architectural modifications to changes in the TCP protocol. Among these, one approach  requiring minimal modifications involves splitting the TCP connection in two or more segments with one  segment connecting terrestrial nodes across the satellite network. Evolution of this basic idea would be 

to place a TCP proxy on board the satellite that further subdivides the end‐to‐end connection into 

separate TCP connections between ground and space; this is the main principle of the spilt TCP for sat‐ ellites. The main contributions of this protocol are: the on‐board split proxy concept, the buffer man‐ agement strategy, and enhancement of TCP performance. 

  Split TCP explanation: The classical “split” TCP concept is extended to a solution where the split  occurs on board of satellite. Here, a forwarding (proxy) agent [11] [14] on the satellite maintains two  separate split TCP connections for each end point of the TCP session. By splitting the TCP connection on  board, the benefits are:  

1) We increase the speed of error recovery  2) We reduce the propagation delay on each link.