TCP In the IPSEC Environment

Dr. Prakash Chitre
Comsat Laboratories,
a Division of ViaSat
22300 Comsat Drive
Clarksburg, MD 20871
/ Manish Karir
CSHCN,
University of Maryland,
College Park, MD 20742
/ Michael Hadjitheodosiou
CSHCN,
University of Maryland,
College Park, MD 20742

Abstract

Satellite based networks can transport data for diverse set of applications. Most Internet applications which use Transmission Control Protocol (TCP) need special handling for efficient operation at high speeds. Recently, support for IPSEC is getting widespread in IPv4 networks and it is likely to be mandatory in future IPv6 networks. However when IPSEC is used, TCP headers will be encrypted. High speed TCP connections can suffer from poor performance over networks with high latency, which is the case for geosynchronous satellite links. Performance enhancing proxies (PEP) serve to optimize protocol performance over satellite links by examining and suitably processing TCP headers. Since IPSEC obscures the TCP headers which proxies rely upon, the two technologies are incompatible. This paper describes the salient points of TCP over satellite links, performance enhancing proxies, and describes in detail the TCP enhancements necessary for its efficient operation in the combined IPSEC and satellite environment. The standardization for such a TCP profile being carried out in the Telecommunications Industry Association (TIA) under their Satellite Communications Division will be briefly described. The performance comparison of the different TCP enhancements is also discussed.

1  Introduction

With the rapid growth of the diverse applications using the Internet, a number of new issues have arisen. One major problem has to do with the performance of high speed Transmission Control Protocol (TCP) inside IPSEC packets over satellite links. In future, there is likely to be a proliferation of the use of IPSEC. With the encapsulation of TCP packet in the IPSEC packet, the IP header will be in the clear, but the TCP packet will be encrypted. As a result, the satellite network will have to transport the IP packets without any access to the TCP packet. Without the TCP Performance Enhancement Proxy (PEP) function, the TCP protocol will degrade significantly over high speed satellite links. The causes of very low throughput for high speed TCP connections over satellite links are well known and are briefly described in Section 2. The current common implementation of TCP adversely impacts its performance for a variety of reasons, such as the low window size, slow start procedure, the congestion control method, etc. The current TCP PEP solutions are described briefly in Section 3. However, the TCP PEP solutions to overcome these problems are not feasible if TCP headers can not be accessed at the satellite network. There are two possible solutions: (a) the co-location of the IPSEC and TCP PEP functionality, (b) proliferation of a “better” TCP profile (procedures). However the possibility of co-location is not guaranteed and hence the need for a more efficient TCP profile (procedures).

The Telecommunications Industry Association (TIA) under their Satellite Communications Division has recently set up a TR 34.1 Working Group to investigate the issues and standardize a TCP Protocol with suitable new features to work efficiently over high speed satellite links. The new features will be selected from a number of IETF RFCs which have been proposed over the last few years. These procedures range from the scaling of the window size, modified slow start procedures, the Explicit Congestion Notification (ECN), better congestion control techniques. Some of the more recent innovations such as TCP Westwood are also being investigated. These new enhancements are described in Section 4 . The performance improvement as a result of these procedures is also described. The standards group is chartered to select a minimum number of modifications to provide an efficient operation of the TCP protocol over links characterized by large bandwidth*delay parameter.

2  Standard Profile for TCP

TCP is the main protocol that provides reliable transmission of data over the Internet. It is used widely for different applications such as file transfer, web access, e-mail. In a typical satellite network environment, TCP is an end-to-end protocol running on user client and server machines exchanging data and acknowledgement packets. Internet routers and satellite terminals will perform the IP routing. TCP protocols have well documented performance problems in satellite networks described briefly below.

·  The combination of limited window size and the relatively large satellite propagation delay results in a very limited throughput irrespective of the satellite link speeds. For example, with the 8 kbyte of default window size, the maximum throughput per TCP connection will be 128 kbps. The long propagation delays also cause longer duration of the Slow Start phase during which the TCP sender may not use the available bandwidth.

·  The congestion window, cwnd, cannot exceed a certain maximum value, rwnd , provided by the TCP receiver. Thus, the transmission rate of the sender is bounded. Note that the higher the round trip time, RTT, the lower is the bound on the transmission rate for the sender.

·  The TCP protocol was initially designed to work in networks with low link error rates, i.e., all segment losses were mostly due to network congestions. As a result, the TCP sender decreases its transmission rate. However, this causes unnecessary throughput degradation if segment losses occur due to link errors.

3  Current TCP PEP Solutions

In order for satellite networks to deal with the performance issues discussed in the previous section, TCP PEPs are placed on each end of a satellite link. Note that this usually does not correspond to the end points of the TCP connection, but may be a network in the middle, or the first or the last hop of a connection. The end-to-end TCP connection is split into three concatenated TCP connections. The TCP protocol is terminated at the satellite terminal before traversing the long delay satellite path and a different protocol is introduced between the source and destination earth terminals. The original TCP protocol is reintroduced between the the destination terminal and the host. The different versions of TCP PEP differ in the specifics of the protocol introduced over the satellite link. Typically, that protocol uses larger window size, larger initial window size, faster slow-start algorithm, faster window ramp-up after window decrease, reduction in acknowledgement traffic.

However, TCP PEP solutions are feasible only if the TCP header is accessible at the earth terminals. If the IPSEC has been applied to the IP packet before it arrives at the earth terminal, the PEP functionality can not be performed. One solution is to integrate the IPSEC and PEP functions. However, there is no guarantee that the host computer or the intervening network node will not implement IPSEC. As a result, the only feasible solution is really to standardize the TCP profile which works very efficiently for high values of the link rate and delay products.

4  TCP Enhancements for Satellite Networks

4.1  Proposed TCP Enhancements

Various modifications and enhancements have been proposed to alleviate the problems encountered by TCP over large bandwidth*delay product links. In this section some of these proposals are discussed.

·  New Reno [1]: In a typical implementation of TCP Reno, the TCP data sender only retransmits a packet after a retransmit timeout has occurred, or after three duplicate ACKs. A single timeout might result in the retransmission of several data packets, however Reno will only retransmit a single data packet. Therefore, when multiple data packets have been dropped from a single window of data, a non-SACK implementation of TCP will not know which packets to retransmit, and will retransmit all of them. However, in the absence of SACK, the ACK for a retransmitted packet will acknowledge some but not all of the packets transmitted before the timeout event. In TCP Reno, a partial ACK takes TCP out of Fast Recovery, however, in New Reno, partial ACKs do not take TCP out of fast recovery; partial ACKs received during fast recovery are treated as an indication that the packet immediately following the ACKed packet has been lost and retransmitted. Thus when multiple packets are lost within the same window, New Reno can recover without a retransmission timeout [this is good because in satellite losses are generally bursty].

·  ECN [2]: The implicit feedback mechanism of TCP makes it very slow to respond to congestion at PEP gateways. ECN provides a way to convey information regarding congestion before it actually occurs. A TCP implementation would then take ECN information into consideration when transmitting packets. The recommendations in [2] state that TCP source should halve both the congestion window and the slow start threshold on receiving an ECN message.

·  TCP Westwood [3]: TCP Westwood is a scheme that attempts to control the window using end-to-end rate estimation, in a manner that is transparent to routers and destinations. TCP Westwood continuously estimates the packet rate of the connection by monitoring the ACK reception rate. This estimated rate is then used to compute the congestion window and the slow start threshold settings after congestion. This makes TCP Westwood more robust to the problems in the satellite channel.

·  Window Scaling [4]: The window scaling option of TCP allows the effective size of the offered window to be increased to 30bits. Network applications can be easily modified to take advantage of these larger windows. During initial connection setup, both ends of a TCP connection negotiate a scaling factor which they will use for the duration of the connection to scale up the window size.

·  SACK/FACK [5,6,7]: Selective Acknowledgements is an option present in TCP that can enable it to retransmit only missing packets, rather than the whole window. With selective acknowledgments, the data receiver can inform the sender about all segments that have arrived successfully, so the sender only needs to retransmit the segments that have actually been lost. SACK also keeps track of the estimated number of packets outstanding between the sender and the receiver and only sends new or retransmitted data when the estimated number of packets is less than the congestion window. The SACK option field contains SACK blocks, where each SACK block reports sets of data that has been received. The FACK algorithm[8] works in conjunction with SACK. The FACK algorithm keeps track of the forward most data held by the receiver and therefore provides a more accurate view of the state of the network for the retransmission procedure.

·  Byte Counting [9]: This is a modification to the algorithm for increasing TCP’s congestion window. Instead of increasing the congestion window by the number of ACKs that arrive at the data sender, the congestion window is increased based on the number of bytes acknowledged by the arriving ACKs. This algorithm aims at improving the performance of TCP by reducing the negative impact of delayed ACKs on the congestion window.

·  Delayed ACK after slow start [10]: During the slow start phase of TCP, the congestion window is increased on the basis of received ACKs. Therefore, the delayed ACK procedure can have significant impact on the performance of TCP, this can the particularly harmful in a high bandwidth-delay product environment. Therefore it has been recommended that the delayed ACK mechanism only be used after the slow start phase of TCP for satellite networks.

·  Large Initial Window [11]: This modification to TCP aims at improving the performance of TCP over a high delay link. Due to the large delay in receiving ACKs, the performance of TCP suffers due to the slow start algorithm. Therefore, this modification, aims at mitigating that impact by using a larger initial window for slow start than 1. By using a larger initial window, more packets can be sent during the first RTT of data transmission that will trigger more ACKs, thereby allowing the congestion window to grow more rapidly.

·  TCP Peach [12]: TCP-Peach is a new flow control scheme for satellite networks. It is an end-to-end solution whose main objective is to improve the throughput performance in satellite networks. The TCP-Peach assumes that all the routers on the connection path apply some priority mechanism and uses low priority segments, called dummy segments transmitted by senders to probe the availability of network resources on the connection path:

·  In the beginning of a new connection, when the sender has no information about the current traffic load in the network.

·  When a segment loss is detected, and the sender has no information about the nature of the loss, i.e., whether it is due to network congestion or link errors.

TCP-Peach is composed of two new algorithms, namely Sudden Start and Rapid Recovery, as well as the two traditional TCP algorithms, Congestion Avoidance and Fast Retransmit.. Dummy segments are treated as low-priority segments and accordingly they do not affect the delivery of actual data traffic. Simulation experiments have shown that TCP-Peach outperforms other TCP schemes for satellite networks in terms of goodput. An important feature of TCP-Peach is that it only requires modifications in the end user behavior and that it is compatible with traditional TCP implementations. If the receiver implements the SACK option, straightforward modification of TCP-Peach could provide goodput performance improvement.

·  TCP Peach Plus [13]: TCP-PeachPlus was introduced as an improvement over TCP-Peach [12]. In TCP Peach Plus implementations a new type of low priority segment NIL segment is used to probe the availability of network resources as well as recover from loss segments due to link errors. Two new algorithms: Jump Start and Quick Recovery are adopted in TCP-PeachPlus to recover rapidly from multiple segment losses within one window of data. TCP PeachPlus offers better perfrormance than TCP-Peach and achieves better fairness as well.

·  T/TCP [14]: T/TCP is backwards-compatible extension of TCP focusing on providing efficient transaction-oriented services in addition to virtual-circuit service. The term "transaction" is used for an elementary request/response packet sequence. The goal of T/TCP is to allow each transaction, i.e., each request/response sequence, to be efficiently performed as a single incarnation of a TCP connection. Standard TCP imposes two performance problems for transaction-oriented communication. First, a TCP connection is opened with a "3-way handshake", which must complete successfully before data can be transferred. The 3-way handshake adds an extra RTT (round trip time) to the latency of a transaction. The second performance problem is that closing a TCP connection leaves one or both ends in TIME-WAIT state for a time 2*MSL, where MSL is the maximum segment lifetime (defined to be 120 seconds). TIME-WAIT state severely limits the rate of successive transactions between the same (host,port) pair, since a new incarnation of the connection cannot be opened until the TIME-WAIT delay expires. T/TCP solves these two performance problems for transactions, by bypassing the 3-way handshake and shortening the delay in TIME-WAIT state.