ITU-R REPORT S 2148-2009 Transmission control protocol (TCP) over satellite networks《卫星网络的传输控制协议(TCP)》.pdf

1、 Report ITU-R S.2148(09/2009)Transmission control protocol (TCP)over satellite networksS SeriesFixed-satellite serviceRep. ITU-R S.2148 ii Foreword The role of the Radiocommunication Sector is to ensure the rational, equitable, efficient and economical use of the radio-frequency spectrum by all radi

2、ocommunication services, including satellite services, and carry out studies without limit of frequency range on the basis of which Recommendations are adopted. The regulatory and policy functions of the Radiocommunication Sector are performed by World and Regional Radiocommunication Conferences and

3、 Radiocommunication Assemblies supported by Study Groups. Policy on Intellectual Property Right (IPR) ITU-R policy on IPR is described in the Common Patent Policy for ITU-T/ITU-R/ISO/IEC referenced in Annex 1 of Resolution ITU-R 1. Forms to be used for the submission of patent statements and licensi

4、ng declarations by patent holders are available from http:/www.itu.int/ITU-R/go/patents/en where the Guidelines for Implementation of the Common Patent Policy for ITU-T/ITU-R/ISO/IEC and the ITU-R patent information database can also be found. Series of ITU-R Reports (Also available online at http:/

5、www.itu.int/publ/R-REP/en) Series Title BO Satellite delivery BR Recording for production, archival and play-out; film for television BS Broadcasting service (sound) BT Broadcasting service (television) F Fixed service M Mobile, radiodetermination, amateur and related satellite services P Radiowave

6、propagation RA Radio astronomy RS Remote sensing systems S Fixed-satellite service SA Space applications and meteorology SF Frequency sharing and coordination between fixed-satellite and fixed service systems SM Spectrum management Note: This ITU-R Report was approved in English by the Study Group u

7、nder the procedure detailed in Resolution ITU-R 1. Electronic Publication Geneva, 2010 ITU 2010 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without written permission of ITU. Rep. ITU-R S.2148 1 REPORT ITU-R S.2148 Transmission control protocol (TCP)

8、over satellite networks (2009) TABLE OF CONTENTS Page 1 Introduction 3 2 Satellite system reference models. 3 2.1 Point-to-point links . 3 2.2 VSAT networks 3 2.2.1 Star topology 3 2.2.2 Mesh topology 4 2.3 Broadband access 4 3 TCP limitations over satellite links 5 3.1 Bandwidth-delay product 5 3.2

9、 Slow start and congestion avoidance 6 3.3 Fast retransmit and fast recovery 7 3.4 Effect of bit errors on TCP throughput. 8 3.5 Asymmetric networks. 8 3.6 Advice to designers. 9 4 TCP enhancement methodologies 9 4.1 Variations of baseline TCP. 9 4.2 Segment splitting methodologies 16 4.2.1 Two-segm

10、ent splitting methodology . 16 4.2.2 Three-segment splitting methodology . 17 4.2.3 Discussion 19 4.3 Caching and spoofing . 19 4.3.1 Caching 19 4.3.2 Spoofing . 19 4.3.3 Spoofing and caching. 19 5 Performance enhancing proxies . 20 5.1 TCP spoofing 21 5.2 TCP splitting. 21 5.3 Other PEP mechanisms.

11、 21 5.4 Implications of using PEP 22 5.4.1 End-to-end security 22 5.4.2 End-to-end reliability . 22 6 Other transmission control protocols 22 6.1 Space communication protocol specification transport protocol (SCPS-TP) 22 6.2 Xpress transport protocol 22 6.3 Stream control transmission protocol . 23

12、6.4 Comparison between transmission control protocols . 24 7 Conclusion 24 2 Rep. ITU-R S.2148 List of acronyms ACK Acknowledgement ATM Asynchronous transfer mode ARQ Automatic repeat request BDP Bandwidth-delay product BER Bit-error ratio cwnd Congestion window (variable in TCP) DACK Delayed acknow

13、ledgement ECN Explicit congestion notification FIN Final segment (in a TCP connection) GSO Geostationary-satellite orbit GW Gateway HEO High-Earth orbit IETF Internet engineering task force IP Internet protocol IPSEC IP security protocol ISP Internet service provider LAN Local area network LEO Low-E

14、arth orbit MEO Medium-Earth orbit MPLS Multiprotocol label switching MTU Maximum transmission unit PAWS Protect against wrapped sequence(s) PEP Performance enhancing proxy RAM Random access memory RBP Rate-based pacing RFC Request for comments (issued by the IETF) RTT Round trip time RTTM RTT measur

15、ement SACK Selective acknowledgment SCPS-TP Space communication protocol specification transport protocol SCTP Stream control transmission protocol SYN Synchronous start segment (used to establish a TCP connection) T/TCP TCP for transactions TCP Transmission control protocol UDP User datagram protoc

16、ol VSAT Very small aperture terminal XTP Express transport protocol Rep. ITU-R S.2148 3 1 Introduction This Report presents reference models of networks including a satellite link, to carry IP packets, followed by a description of the limitations of transmission control protocol (TCP) over satellite

17、 links, as well as, various methodologies to overcome the limitations. 2 Satellite system reference models 2.1 Point-to-point links Figure 1 provides a reference model for a network carrying IP packet transmissions. The network consists of a satellite link and associated terrestrial networks between

18、 two end-users. The satellite link is bidirectional and consists of link AB (from earth station A to earth station B with an information bit rate, RAB) and of link BA (from earth station B to earth station A with an information bit rate, RBA). The terrestrial networks can employ various data link la

19、yer protocols (e.g., asynchronous transfer mode (ATM), frame relay, MPLS). FIGURE 1 Reference model for a point-to-point link including a satellite link Report 2148-01Satellite systemLink BA ( )RBALink AB ( )RABTerrestrialnetworkUser 1Earthstation AEarthstation BTerrestrialnetworkUser 2Satellite lin

20、kNOTE 1 The reference model above considers only one satellite hop. Throughout this Report the techniques that segment the TCP connection to improve TCP performance over satellite links are described for one satellite hop. However an end-to-end connection may include several satellite hops. In this

21、case, such techniques will have to be implemented over each individual satellite link. 2.2 VSAT networks 2.2.1 Star topology Figure 2 depicts the standard star configuration in which signals from various remote users connect to a gateway earth station which in turn connects to terrestrial network. 4

22、 Rep. ITU-R S.2148 FIGURE 2 Star topology Report 2148-02C NCCCCommunity NCommunity 1Internetbackbone2.2.2 Mesh topology Figure 3 illustrates a mesh configuration whereby any pair of earth stations can be connected directly via satellite. FIGURE 3 Mesh topology Report 2148-03Community NCommunity 12.3

23、 Broadband access Even if not completely similar to very small aperture terminal (VSAT) networks, broadband access networks generally use the same topologies (i.e. star or mesh). Rep. ITU-R S.2148 5 3 TCP limitations over satellite links The TCP cannot distinguish the performance degradation caused

24、by link errors from congestion. It assumes that any loss in the network is due to congestion only and the sender responds by reducing its packet transfer rate. The baseline TCP (TCP Reno) specifies slow start, congestion avoidance, fast retransmit and fast recovery for congestion control. The TCP us

25、es window flow control mechanism in which the transmission window allows the receiving TCP to control the amount of data being sent to it at any given time. The receiver advertises a window size to the sender. The window measures, in byte/s, the amount of unacknowledged data that the sender can have

26、 in transit to the receiver. 3.1 Bandwidth-delay product The bandwidth-delay product (BDP) defines the amount of data a TCP connection should have “in flight” (data that has been transmitted, but not yet acknowledged) at any time to fully utilize the available channel capacity. The delay is the roun

27、d trip time (RTT) and the bandwidth is the capacity of the bottleneck link in the path. For links with a large BDP, such as in geostationary satellite networks, TCP senders and receivers with limited congestion/receive windows will not be able to take advantage of the available bandwidth. The standa

28、rd maximum TCP window of 65 535 byte/s is not adequate to allow a single TCP connection to utilize the entire bandwidth available on some satellite channels. In a loss-free network the TCP throughput is limited by equation (1): RTTsizeWindowthroughputMaximum = (1) Therefore, when using the maximum T

29、CP window size of 64 kbyte/s and satellite links with variable RTT, the maximum throughput is as follows: TABLE 1 Maximum throughput according to RTT values Satellite network type RTT (ms) Maximum throughput (kbyte/s) LEO 20 3 200 MEO 200 320 HEO 600 110 GSO 520 120 NOTE 1 The above-mentioned RTT do

30、 not take into account any buffer delay but are computed on the basis of the propagation delay. IETF1Request for Comments 31502recommends performance of network paths that traverse “very low bit-rate” links. It is applicable for any network where hosts can saturate available bandwidth, but the desig

31、n space explicitly includes connections that traverse 56 kbit/s modem links or 4.8 kbit/s 1Internet Engineering Task Force. 2End-to-end Performance implications of slow links. 6 Rep. ITU-R S.2148 wireless access links. Some of the discussion is common with Request for Comments 26893, using header co

32、mpression. It focuses more on traditional data applications for which “best-effort delivery” is appropriate. 3.2 Slow start and congestion avoidance The TCP sender maintains a congestion window to measure the network capacity. The number of unacknowledged packets in the network is limited to this va

33、lue (or to the receiver advertised window whichever is lower). At the start of a TCP connection, the congestion window is set to one TCP segment. It increases by one segment on the receipt of each new acknowledgment until it reaches its maximum value of 64 kbyte/s. The sender maintains a retransmiss

34、ion time out for the last unacknowledged packet. Congestion is detected by the expiration of the retransmission time out. When the timer expires, the sender saves the value of half the congestion window (called slow start threshold) and sets it to one segment. The sender then retransmits segments st

35、arting from the lost segment. The congestion window is increased by one segment on the receipt of each new acknowledgement until it reaches the slow start threshold. This is the slow start phase. After that, the congestion window increases by one segment every RTT. This results in a linear increase

36、of the congestion window every RTT and is called the congestion avoidance phase. Figure 4 shows the slow start and congestion avoidance phases for a typical TCP connection (in Fig. 4, cwnd stands for congestion window). The time required by the slow start mechanism to reach a bit rate B is given by

37、equation (2): +=lB RTTlog1RTTdurationstartSlow2(2) where l is the average packet length expressed in bits. Table 2 shows the duration of slow start phase for various satellite orbits and different values of bit rates B, when l = 1 kbit. FIGURE 4 TCP slow start and congestion avoidance Report 2148-04

38、cwnd/2cwndSlowstartWait fortime outSlowstartCongestionavoidanceTime out3RFC 2689 “Providing integrated services over low-bit rate links”. Rep. ITU-R S.2148 7 TABLE 2 Duration of slow start for various satellite orbits Slow start duration (s) Satellite type (RTT) (ms) B = 1 Mbit/s B = 10 Mbit/s B = 1

39、55 Mbit/s LEO 20 0.05 0.11 0.19 MEO 200 1.14 1.80 2.59 HEO 600 4.36 6.35 8.73 GSO 520 3.67 5.40 7.45 If the delayed acknowledgment mechanism is implemented then the time required by slow start to reach the bit rate B is given by the following formula: +=lB RTTlog1RTTdurationstartSlow5.1(3) It implie

40、s that the slow start duration becomes even longer compared to the previous case. Thus, delayed acknowledgements also waste capacity during the slow start phase. In the congestion avoidance phase, the increase of data rate is a function of the bandwidth-delay product. In fact, during each RTT, the d

41、ata rate is increased by l/(B RTT). So if a TCP connection is in the congestion avoidance phase and some additional bandwidth becomes available, this connection will not use it for a long time. This time will be longer in the presence of transmission losses. Therefore the congestion avoidance mechan

42、ism in satellite networks with high RTT performs lower than in a terrestrial network. 3.3 Fast retransmit and fast recovery Currently TCP implementations use a coarse granularity (typically 500 ms) timer for the retransmission time out. As a result, during congestion, the TCP connection loses time w

43、aiting for the time out. In Fig. 4, the horizontal line (at the cwnd value) shows the time lost when waiting for a time out to occur. During this time, TCP neither sends new packets nor retransmits lost packets. Moreover, once the time out occurs, the congestion window is set to one segment, and the

44、 connection takes several round trips to efficiently utilize the network. TCP Reno implements the fast retransmit and recovery algorithms that enable the connection to quickly recover from isolated segment losses. If the network drops a segment, the subsequent segments arriving at the receiver are o

45、ut-of-order. For each of them, the TCP receiver immediately sends an acknowledgement to the sender indicating the sequence number of the missing segment. This acknowledgement is called a duplicate acknowledgement. When the sender receives three duplicate acknowledgements, it concludes that the segme

46、nt indicated by the acknowledgements has been lost and immediately retransmits the lost segment. The sender then reduces the congestion window by half plus three segments and also saves half the original congestion window value in the slow start threshold. For each subsequent duplicate acknowledgeme

47、nt, the sender increases the congestion window by one and tries to send a new segment. Effectively, the sender waits for half a round trip before sending one segment for each subsequent duplicate acknowledgement it receives. As a result, the sender maintains the network link at half capacity at the

48、time of fast retransmit. Approximately one round trip after the missing segment has been retransmitted, its acknowledgement is received (assuming the retransmitted segment was not lost). At this time, 8 Rep. ITU-R S.2148 instead of setting the congestion window to one segment and performing slow sta

49、rt, the TCP directly sets the congestion window to the slow start threshold. This is the fast recovery algorithm. Fast retransmit and recovery mechanisms are also affected by long RTT as those encountered over satellite links. The multiple retransmission of duplicate acknowledgements results in a waste of bandwidth, which is a limited resource in satellite networks. 3.4 Effect of bit errors on TCP throughput Because TCP has no mechanism to distinguish between congestion loss and transmission errors, TCP performs poorly