Network Working Group H. Inamura, Ed.
Request for Comments: 3481 NTT DoCoMo, Inc.
BCP: 71 G. Montenegro, Ed.
Category: Best Current Practice Sun Microsystems Laboratories
Europe
R. Ludwig
Ericsson Research
A. Gurtov
Sonera
F. Khafizov
Nortel Networks
February 2003
Network Working Group H. Inamura, Ed.
Request for Comments: 3481 NTT DoCoMo, Inc.
BCP: 71 G. Montenegro, Ed.
Category: Best Current Practice Sun Microsystems Laboratories
Europe
R. Ludwig
Ericsson Research
A. Gurtov
Sonera
F. Khafizov
Nortel Networks
February 2003
TCP over Second (2.5G) and Third (3G) Generation Wireless Networks
第二代（2.5G）和第三代（3G）无线网络上的TCP
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes a profile for optimizing TCP to adapt so that it handles paths including second (2.5G) and third (3G) generation wireless networks. It describes the relevant characteristics of 2.5G and 3G networks, and specific features of example deployments of such networks. It then recommends TCP algorithm choices for nodes known to be starting or ending on such paths, and it also discusses open issues. The configuration options recommended in this document are commonly found in modern TCP stacks, and are widely available standards-track mechanisms that the community considers safe for use on the general Internet.
本文档描述了优化TCP以适应的配置文件，以便它处理包括第二代（2.5G）和第三代（3G）无线网络在内的路径。它描述了2.5G和3G网络的相关特征，以及此类网络部署示例的具体特征。然后，它为已知在此类路径上开始或结束的节点推荐TCP算法选择，并讨论了开放性问题。本文档中推荐的配置选项通常存在于现代TCP协议栈中，并且是广泛可用的标准跟踪机制，社区认为在通用Internet上使用这些机制是安全的。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. 2.5G and 3G Link Characteristics. . . . . . . . . . . . . . . 4
2.1 Latency. . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Data Rates . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Asymmetry . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Delay Spikes . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Packet Loss Due to Corruption. . . . . . . . . . . . . . 7
2.6 Intersystem Handovers. . . . . . . . . . . . . . . . . . 7
2.7 Bandwidth Oscillation. . . . . . . . . . . . . . . . . . 7
3. Example 2.5G and 3G Deployments . . . . . . . . . . . . . . . 8
3.1 2.5G Technologies: GPRS, HSCSD and CDMA2000 1XRTT. . . . 8
3.2 A 3G Technology: W-CDMA. . . . . . . . . . . . . . . . . 8
3.3 A 3G Technology: CDMA2000 1X-EV. . . . . . . . . . . . . 10
4. TCP over 2.5G and 3G. . . . . . . . . . . . . . . . . . . . . 10
4.1 Appropriate Window Size (Sender & Receiver). . . . . . . 11
4.2 Increased Initial Window (Sender). . . . . . . . . . . . 11
4.3 Limited Transmit (Sender). . . . . . . . . . . . . . . . 12
4.4 IP MTU Larger than Default . . . . . . . . . . . . . . . 12
4.5 Path MTU Discovery (Sender & Intermediate Routers) . . . 13
4.6 Selective Acknowledgments (Sender & Receiver). . . . . . 13
4.7 Explicit Congestion Notification (Sender, Receiver &
Intermediate Routers). . . . . . . . . . . . . . . . . . 13
4.8 TCP Timestamps Option (Sender & Receiver). . . . . . . . 13
4.9 Disabling RFC 1144 TCP/IP Header Compression (Wireless
Host) . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. Normative References . . . . . . . . . . . . . . . . . . . . . 19
10. Informative References . . . . . . . . . . . . . . . . . . . . 21
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. 2.5G and 3G Link Characteristics. . . . . . . . . . . . . . . 4
2.1 Latency. . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Data Rates . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Asymmetry . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Delay Spikes . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Packet Loss Due to Corruption. . . . . . . . . . . . . . 7
2.6 Intersystem Handovers. . . . . . . . . . . . . . . . . . 7
2.7 Bandwidth Oscillation. . . . . . . . . . . . . . . . . . 7
3. Example 2.5G and 3G Deployments . . . . . . . . . . . . . . . 8
3.1 2.5G Technologies: GPRS, HSCSD and CDMA2000 1XRTT. . . . 8
3.2 A 3G Technology: W-CDMA. . . . . . . . . . . . . . . . . 8
3.3 A 3G Technology: CDMA2000 1X-EV. . . . . . . . . . . . . 10
4. TCP over 2.5G and 3G. . . . . . . . . . . . . . . . . . . . . 10
4.1 Appropriate Window Size (Sender & Receiver). . . . . . . 11
4.2 Increased Initial Window (Sender). . . . . . . . . . . . 11
4.3 Limited Transmit (Sender). . . . . . . . . . . . . . . . 12
4.4 IP MTU Larger than Default . . . . . . . . . . . . . . . 12
4.5 Path MTU Discovery (Sender & Intermediate Routers) . . . 13
4.6 Selective Acknowledgments (Sender & Receiver). . . . . . 13
4.7 Explicit Congestion Notification (Sender, Receiver &
Intermediate Routers). . . . . . . . . . . . . . . . . . 13
4.8 TCP Timestamps Option (Sender & Receiver). . . . . . . . 13
4.9 Disabling RFC 1144 TCP/IP Header Compression (Wireless
Host) . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. Normative References . . . . . . . . . . . . . . . . . . . . . 19
10. Informative References . . . . . . . . . . . . . . . . . . . . 21
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
The second generation cellular systems are commonly referred to as 2G. The 2G phase began in the 1990s when digital voice encoding had replaced analog systems (1G). 2G systems are based on various radio technologies including frequency-, code- and time- division multiple access. Examples of 2G systems include GSM (Europe), PDC (Japan), and IS-95 (USA). Data links provided by 2G systems are mostly circuit-switched and have transmission speeds of 10-20 kbps uplink and downlink. Demand for higher data rates, instant availability and data volume-based charging, as well as lack of radio spectrum allocated for 2G led to the introduction of 2.5G (for example, GPRS and PDC-P) and 3G (for example, Wideband CDMA and cdma2000) systems.
第二代蜂窝系统通常被称为2G。2G阶段始于20世纪90年代，当时数字语音编码已经取代了模拟系统（1G）。2G系统基于各种无线电技术，包括频分、码分多址和时分多址。2G系统的示例包括GSM（欧洲）、PDC（日本）和IS-95（美国）。2G系统提供的数据链路大多为电路交换，上行和下行传输速度为10-20 kbps。对更高数据速率、即时可用性和基于数据量的收费的需求，以及缺乏为2G分配的无线电频谱，导致了2.5G（例如GPRS和PDC-P）和3G（例如宽带CDMA和cdma2000）系统的引入。
Radio technology for both Wideband CDMA (W-CDMA) (adopted, for example, in Europe, Japan, etc) and cdma2000 (adopted, for example, in US, South Korea, etc) is based on code division multiple access allowing for higher data rates and more efficient spectrum utilization than 2G systems. 3G systems provide both packet-switched and circuit-switched connectivity in order to address the quality of service requirements of conversational, interactive, streaming, and bulk transfer applications. The transition to 3G is expected to be a gradual process. Initially, 3G will be deployed to introduce high capacity and high speed access in densely populated areas. Mobile users with multimode terminals will be able to utilize existing coverage of 2.5G systems on the rest of territory.
宽带CDMA（W-CDMA）（例如在欧洲、日本等采用）和cdma2000（例如在美国、韩国等采用）的无线电技术均基于码分多址，允许比2G系统更高的数据速率和更高效的频谱利用率。3G系统提供分组交换和电路交换连接，以满足会话、交互、流式传输和批量传输应用的服务质量要求。向3G的过渡预计将是一个渐进的过程。最初，将部署3G，在人口密集地区引入高容量和高速接入。使用多模终端的移动用户将能够利用领土其他地区现有的2.5G系统覆盖范围。
Much development and deployment activity has centered around 2.5G and 3G technologies. Along with objectives like increased capacity for voice channels, a primary motivation for these is data communication, and, in particular, Internet access. Accordingly, key issues are TCP performance and the several techniques which can be applied to optimize it over different wireless environments [19].
许多开发和部署活动都围绕着2.5G和3G技术展开。除了增加语音通道容量等目标外，数据通信，尤其是互联网接入是实现这些目标的主要动机。因此，关键问题是TCP性能以及可用于在不同无线环境中优化TCP性能的几种技术[19]。
This document proposes a profile of such techniques, (particularly effective for use with 2.5G and 3G wireless networks). The configuration options in this document are commonly found in modern TCP stacks, and are widely available IETF standards-track mechanisms that the community has judged to be safe on the general Internet (that is, even in predominantly non-wireless scenarios). Furthermore, this document makes one set of recommendations that covers both 2.5G and 3G networks. Since both generations of wireless technologies exhibit similar challenges to TCP performance (see Section 2), one common set is warranted.
本文件介绍了此类技术（尤其适用于2.5G和3G无线网络）。本文档中的配置选项通常存在于现代TCP协议栈中，并且是广泛可用的IETF标准跟踪机制，社区认为这些机制在一般互联网上是安全的（即，即使在主要的非无线场景中）。此外，本文件还提出了一套涵盖2.5G和3G网络的建议。由于两代无线技术对TCP性能的挑战相似（见第2节），因此需要一套通用的技术。
Two example applications of the recommendations in this document are:
本文件中建议的两个示例应用为：
o The WAP Forum [25] (part of the Open Mobile Alliance [26] as of June 2002) is an industry association that has developed standards for wireless information and telephony services on digital mobile phones. In order to address WAP functionality for higher speed networks such as 2.5G and 3G networks, and to aim at convergence with Internet standards, the WAP Forum thoroughly revised its specifications. The resultant version 2.0 [31] adopts TCP as its transport protocol, and recommends TCP optimization mechanisms closely aligned with those described in this document.
o WAP论坛[25]（截至2002年6月为开放移动联盟[26]的一部分）是一个行业协会，它为数字移动电话上的无线信息和电话服务制定了标准。为了解决高速网络（如2.5G和3G网络）的WAP功能，并与互联网标准接轨，WAP论坛彻底修订了其规范。最终版本2.0[31]采用TCP作为其传输协议，并推荐与本文档中描述的密切一致的TCP优化机制。
o I-mode [33] is a wireless Internet service deployed on handsets in Japan. The newer version of i-mode runs on FOMA [34], an implementation of W-CDMA. I-mode over FOMA deploys the profile of TCP described in this document.
o I-mode[33]是一种部署在日本手机上的无线互联网服务。较新版本的i-mode在FOMA[34]上运行，FOMA是W-CDMA的一种实现。FOMA上的I-mode部署了本文档中描述的TCP配置文件。
This document is structured as follows: Section 2 reviews the link layer characteristics of 2.5G/3G networks; Section 3 gives a brief overview of some representative 2.5G/3G technologies like W-CDMA, cdma2000 and GPRS; Section 4 recommends mechanisms and configuration options for TCP implementations used in 2.5G/3G networks, including a summary in chart form at the end of the section; finally, Section 5 discusses some open issues.
本文件的结构如下：第2节回顾了2.5G/3G网络的链路层特性；第三节简要介绍了一些具有代表性的2.5G/3G技术，如W-CDMA、cdma2000和GPRS；第4节为2.5G/3G网络中使用的TCP实现推荐了机制和配置选项，包括本节末尾的图表总结；最后，第5节讨论了一些悬而未决的问题。
Link layer characteristics of 2.5G/3G networks have significant effects on TCP performance. In this section we present various aspects of link characteristics unique to the 2.5G/3G networks.
2.5G/3G网络的链路层特性对TCP性能有显著影响。在本节中，我们将介绍2.5G/3G网络特有的链路特性的各个方面。
The latency of 2.5G/3G links is high mostly due to the extensive processing required at the physical layer of those networks, e.g., for FEC and interleaving, and due to transmission delays in the radio access network [58] (including link-level retransmissions). A typical RTT varies between a few hundred milliseconds and one second. The associated radio channels suffer from difficult propagation environments. Hence, powerful but complex physical layer techniques need to be applied to provide high capacity in a wide coverage area in a resource efficient way. Hopefully, rapid improvements in all areas of wireless networks ranging from radio layer techniques over signal processing to system architecture will ultimately also lead to reduced delays in 3G wireless systems.
2.5G/3G链路的延迟很高，这主要是由于这些网络的物理层需要大量的处理，例如FEC和交织，以及由于无线接入网络中的传输延迟[58]（包括链路级重传）。典型的RTT在几百毫秒到一秒钟之间变化。相关的无线信道受到困难的传播环境的影响。因此，需要应用功能强大但复杂的物理层技术，以资源高效的方式在广泛的覆盖区域提供高容量。从信号处理的无线层技术到系统架构，无线网络各个领域的快速改进有望最终减少3G无线系统的延迟。
The main incentives for transition from 2G to 2.5G to 3G are the increase in voice capacity and in data rates for the users. 2.5G systems have data rates of 10-20 kbps in uplink and 10-40 kbps in downlink. Initial 3G systems are expected to have bit rates around 64 kbps in uplink and 384 kbps in downlink. Considering the resulting bandwidth-delay product (BDP) of around 1-5 KB for 2.5G and 8-50 KB for 3G, 2.5G links can be considered LTNs (Long Thin Networks [19]), and 3G links approach LFNs (Long Fat Networks [2], as exemplified by some satellite networks [48]). Accordingly, interested readers might find related and potentially relevant issues discussed in RFC 2488 [49]. For good TCP performance both LFNs and LTNs require maintaining a large enough window of outstanding data. For LFNs, utilizing the available network bandwidth is of particular concern. LTNs need a sufficiently large window for efficient loss recovery. In particular, the fast retransmit algorithm cannot be triggered if the window is less than four segments. This leads to a lengthy recovery through retransmission timeouts. The Limited Transmit algorithm RFC 3042 [10] helps avoid the deleterious effects of timeouts on connections with small windows. Nevertheless, making full use of the SACK RFC 2018 [3] information for loss recovery in both LFNs and LTNs may require twice the window otherwise sufficient to utilize the available bandwidth.
从2G向2.5G过渡到3G的主要激励因素是用户语音容量和数据速率的增加。2.5G系统的上行数据速率为10-20 kbps，下行数据速率为10-40 kbps。最初的3G系统预计上行链路的比特率约为64 kbps，下行链路的比特率约为384 kbps。考虑到由此产生的带宽延迟积（BDP）约为2.5G的1-5 KB和3G的8-50 KB，2.5G链路可被视为LTN（长瘦网络[19]），3G链路接近LFN（长胖网络[2]，如一些卫星网络[48]所示）。因此，感兴趣的读者可能会发现RFC 2488[49]中讨论的相关和潜在相关问题。为了获得良好的TCP性能，LFN和LTN都需要保持足够大的未完成数据窗口。对于LFN，利用可用的网络带宽尤其值得关注。LTN需要一个足够大的窗口来实现有效的损失恢复。特别是，如果窗口小于四段，则无法触发快速重传算法。这会导致通过重新传输超时进行长时间的恢复。有限传输算法RFC 3042[10]有助于避免超时对小窗口连接的有害影响。然而，在LFN和LTN中充分利用SACK RFC 2018[3]信息进行损失恢复可能需要两倍的窗口，否则就足以利用可用带宽。
This document recommends only standard mechanisms suitable both for LTNs and LFNs, and to any network in general. However, experimental mechanisms suggested in Section 5 can be targeted either for LTNs [19] or LFNs [48].
本文件仅推荐适用于LTN和LFN以及任何一般网络的标准机制。然而，第5节中建议的实验机制可以针对LTN[19]或LFN[48]。
Data rates are dynamic due to effects from other users and from mobility. Arriving and departing users can reduce or increase the available bandwidth in a cell. Increasing the distance from the base station decreases the link bandwidth due to reduced link quality. Finally, by simply moving into another cell the user can experience a sudden change in available bandwidth. For example, if upon changing cells a connection experiences a sudden increase in available bandwidth, it can underutilize it, because during congestion avoidance TCP increases the sending rate slowly. Changing from a fast to a slow cell normally is handled well by TCP due to the self-clocking property. However, a sudden increase in RTT in this case can cause a spurious TCP timeout as described in Section 2.7. In addition, a large TCP window used in the fast cell can create congestion resulting in overbuffering in the slow cell.
由于其他用户和移动性的影响，数据速率是动态的。到达和离开的用户可以减少或增加小区中的可用带宽。由于链路质量降低，增加与基站的距离会降低链路带宽。最后，只要移动到另一个小区，用户就可以体验到可用带宽的突然变化。例如，如果在更换小区时，一个连接的可用带宽突然增加，它可能会利用不足，因为在避免拥塞期间，TCP会缓慢地增加发送速率。由于自时钟特性，TCP通常可以很好地处理从快速单元到慢速单元的变化。然而，如第2.7节所述，在这种情况下，RTT的突然增加可能会导致虚假TCP超时。此外，快速小区中使用的大型TCP窗口可能会造成拥塞，从而导致慢速小区中的过度缓冲。
2.5G/3G systems may run asymmetric uplink and downlink data rates. The uplink data rate is limited by battery power consumption and complexity limitations of mobile terminals. However, the asymmetry does not exceed 3-6 times, and can be tolerated by TCP without the need for techniques like ACK congestion control or ACK filtering [50]. Accordingly, this document does not include recommendations meant for such highly asymmetric networks.
2.5G/3G系统可以运行不对称的上行链路和下行链路数据速率。上行数据速率受到电池功耗和移动终端复杂性限制的限制。然而，不对称性不超过3-6倍，TCP可以容忍，而不需要ACK拥塞控制或ACK过滤等技术[50]。因此，本文件不包括针对此类高度不对称网络的建议。
A delay spike is a sudden increase in the latency of the communication path. 2.5G/3G links are likely to experience delay spikes exceeding the typical RTT by several times due to the following reasons.
延迟尖峰是通信路径延迟的突然增加。由于以下原因，2.5G/3G链路可能会经历多次超过典型RTT的延迟峰值。
1. A long delay spike can occur during link layer recovery from a link outage due to temporal loss of radio coverage, for example, while driving into a tunnel or within an elevator.
1. 在链路层从链路中断恢复期间，由于无线电覆盖的暂时性丢失，例如在驶入隧道或电梯内时，可能会出现长延迟尖峰。
2. During a handover the mobile terminal and the new base station must exchange messages and perform some other time-consuming actions before data can be transmitted in a new cell.
2. 在切换期间，移动终端和新基站必须交换消息并执行一些其他耗时动作，然后才能在新小区中传输数据。
3. Many wide area wireless networks provide seamless mobility by internally re-routing packets from the old to the new base station which may cause extra delay.
3. 许多广域无线网络通过内部将数据包从旧基站重新路由到新基站提供无缝移动，这可能会导致额外的延迟。
4. Blocking by high-priority traffic may occur when an arriving circuit-switched call or higher priority data temporarily preempts the radio channel. This happens because most current terminals are not able to handle a voice call and a data connection simultaneously and suspend the data connection in this case.
4. 当到达的电路交换呼叫或更高优先级的数据临时抢占无线信道时，可能会发生高优先级业务阻塞。这是因为大多数当前终端无法同时处理语音呼叫和数据连接，并且在这种情况下会暂停数据连接。
5. Additionally, a scheduler in the radio network can suspend a low-priority data transfer to give the radio channel to higher priority users.
5. 此外，无线网络中的调度器可以暂停低优先级数据传输，以便将无线信道提供给高优先级用户。
Delay spikes can cause spurious TCP timeouts, unnecessary retransmissions and a multiplicative decrease in the congestion window size.
延迟峰值会导致虚假TCP超时、不必要的重新传输以及拥塞窗口大小的成倍减小。
Even in the face of a high probability of physical layer frame errors, 2.5G/3G systems have a low rate of packet losses thanks to link-level retransmissions. Justification for link layer ARQ is discussed in [23], [22], [44]. In general, link layer ARQ and FEC can provide a packet service with a negligibly small probability of undetected errors (failures of the link CRC), and a low level of loss (non-delivery) for the upper layer traffic, e.g., IP. The loss rate of IP packets is low due to the ARQ, but the recovery at the link layer appears as delay jitter to the higher layers lengthening the computed RTO value.
即使面对高概率的物理层帧错误，由于链路级重传，2.5G/3G系统的数据包丢失率也很低。链路层ARQ的合理性在[23]、[22]、[44]中讨论。一般来说，链路层ARQ和FEC可以提供分组服务，其未检测到的错误（链路CRC的故障）的概率小得可以忽略，并且上层业务（例如IP）的丢失水平低（不传送）。由于ARQ，IP数据包的丢失率较低，但链路层的恢复表现为对更高层的延迟抖动，延长了计算的RTO值。
In the initial phase of deployment, 3G systems will be used as a 'hot spot' technology in high population areas, while 2.5G systems will provide lower speed data service elsewhere. This creates an environment where a mobile user can roam between 2.5G and 3G networks while keeping ongoing TCP connections. The inter-system handover is likely to trigger a high delay spike (Section 2.4), and can result in data loss. Additional problems arise because of context transfer, which is out of scope of this document, but is being addressed elsewhere in the IETF in activities addressing seamless mobility [51].
在部署的初始阶段，3G系统将被用作高人口地区的“热点”技术，而2.5G系统将在其他地区提供低速数据服务。这创造了一个环境，移动用户可以在2.5G和3G网络之间漫游，同时保持TCP连接。系统间切换可能触发高延迟峰值（第2.4节），并可能导致数据丢失。由于上下文转移而产生的其他问题超出了本文件的范围，但在IETF中的其他活动中正在解决无缝移动性[51]。
Intersystem handovers can adversely affect ongoing TCP connections since features may only be negotiated at connection establishment and cannot be changed later. After an intersystem handover, the network characteristics may be radically different, and, in fact, may be negatively affected by the initial configuration. This point argues against premature optimization by the TCP implementation.
系统间切换可能会对正在进行的TCP连接产生不利影响，因为功能只能在连接建立时协商，以后不能更改。在系统间切换之后，网络特性可能完全不同，并且实际上可能受到初始配置的负面影响。这一点反对TCP实现的过早优化。
Given the limited RF spectrum, satisfying the high data rate needs of 2.5G/3G wireless systems requires dynamic resource sharing among concurrent data users. Various scheduling mechanisms can be deployed in order to maximize resource utilization. If multiple users wish to transfer large amounts of data at the same time, the scheduler may have to repeatedly allocate and de-allocate resources for each user. We refer to periodic allocation and release of high-speed channels as Bandwidth Oscillation. Bandwidth Oscillation effects such as spurious retransmissions were identified elsewhere (e.g., [30]) as factors that degrade throughput. There are research studies [52], [54], which show that in some cases Bandwidth Oscillation can be the single most important factor in reducing throughput. For fixed TCP parameters the achievable throughput depends on the pattern of
鉴于有限的射频频谱，满足2.5G/3G无线系统的高数据速率需求需要并发数据用户之间的动态资源共享。可以部署各种调度机制，以最大限度地提高资源利用率。如果多个用户希望同时传输大量数据，调度程序可能必须为每个用户重复分配和取消分配资源。我们将高速信道的周期性分配和释放称为带宽振荡。其他地方（例如，[30]）发现了带宽振荡效应（如伪重传）是降低吞吐量的因素。有研究[52]，[54]表明，在某些情况下，带宽振荡可能是降低吞吐量的最重要因素。对于固定的TCP参数，可实现的吞吐量取决于
resource allocation. When the frequency of resource allocation and de-allocation is sufficiently high, there is no throughput degradation. However, increasing the frequency of resource allocation/de-allocation may come at the expense of increased signaling, and, therefore, may not be desirable. Standards for 3G wireless technologies provide mechanisms that can be used to combat the adverse effects of Bandwidth Oscillation. It is the consensus of the PILC Working Group that the best approach for avoiding adverse effects of Bandwidth Oscillation is proper wireless sub-network design [23].
资源分配。当资源分配和取消分配的频率足够高时，没有吞吐量降低。然而，增加资源分配/取消分配的频率可能以增加信令为代价，因此可能不可取。3G无线技术标准提供了一些机制，可用于对抗带宽振荡的不利影响。PILC工作组一致认为，避免带宽振荡不利影响的最佳方法是适当的无线子网设计[23]。
This section provides further details on a few example 2.5G/3G technologies. The objective is not completeness, but merely to discuss some representative technologies and the issues that may arise with TCP performance. Other documents discuss the underlying technologies in more detail. For example, ARQ and FEC are discussed in [23], while further justification for link layer ARQ is discussed in [22], [44].
本节提供了一些示例2.5G/3G技术的详细信息。目标不是完整性，而只是讨论一些有代表性的技术以及TCP性能可能出现的问题。其他文档更详细地讨论了底层技术。例如，ARQ和FEC在[23]中讨论，而链路层ARQ的进一步合理性在[22]、[44]中讨论。
High Speed Circuit-Switched Data (HSCSD) and General Packet Radio Service (GPRS) are extensions of GSM providing high data rates for a user. Both extensions were developed first by ETSI and later by 3GPP. In GSM, a user is assigned one timeslot downlink and one uplink. HSCSD allocates multiple timeslots to a user creating a fast circuit-switched link. GPRS is based on packet-switched technology that allows efficient sharing of radio resources among users and always-on capability. Several terminals can share timeslots. A GPRS network uses an updated base station subsystem of GSM as the access network; the GPRS core network includes Serving GPRS Support Nodes (SGSN) and Gateway GPRS Support Nodes (GGSN). The RLC protocol operating between a base station controller and a terminal provides ARQ capability over the radio link. The Logical Link Control (LLC) protocol between the SGSN and the terminal also has an ARQ capability utilized during handovers.
高速电路交换数据（HSCSD）和通用分组无线业务（GPRS）是GSM的扩展，为用户提供高数据速率。这两个扩展首先由ETSI开发，然后由3GPP开发。在GSM中，用户被分配一个时隙下行链路和一个上行链路。HSCSD为创建快速电路交换链路的用户分配多个时隙。GPRS基于分组交换技术，可在用户之间高效共享无线资源，并始终保持开启状态。多个终端可以共享时隙。GPRS网络使用GSM的更新基站子系统作为接入网络；GPRS核心网络包括服务GPRS支持节点（SGSN）和网关GPRS支持节点（GGSN）。在基站控制器和终端之间运行的RLC协议通过无线链路提供ARQ能力。SGSN和终端之间的逻辑链路控制（LLC）协议还具有在切换期间使用的ARQ能力。
The International Telecommunication Union (ITU) has selected Wideband Code Division Multiple Access (W-CDMA) as one of the global telecom systems for the IMT-2000 3G mobile communications standard. W-CDMA specifications are created in the 3rd Generation Partnership Project (3GPP).
国际电信联盟（ITU）选择宽带码分多址（W-CDMA）作为IMT-2000 3G移动通信标准的全球电信系统之一。W-CDMA规范是在第三代合作伙伴计划（3GPP）中创建的。
The link layer characteristics of the 3G network which have the largest effect on TCP performance over the link are error controlling schemes such as layer two ARQ (L2 ARQ) and FEC (forward error correction).
3G网络的链路层特性对链路上的TCP性能影响最大，它们是差错控制方案，如第二层ARQ（l2arq）和FEC（前向纠错）。
W-CDMA uses RLC (Radio Link Control) [20], a Selective Repeat and sliding window ARQ. RLC uses protocol data units (PDUs) with a 16 bit RLC header. The size of the PDUs may vary. Typically, 336 bit PDUs are implemented [34]. This is the unit for link layer retransmission. The IP packet is fragmented into PDUs for transmission by RLC. (For more fragmentation discussion, see Section 4.4.)
W-CDMA使用RLC（无线链路控制）[20]，一种选择性重复和滑动窗口ARQ。RLC使用带有16位RLC头的协议数据单元（PDU）。PDU的大小可能会有所不同。通常，实现336位PDU[34]。这是链路层重传的单元。IP数据包被分割成PDU，以便通过RLC进行传输。（有关更多碎片的讨论，请参见第4.4节。）
In W-CDMA, one to twelve PDUs (RLC frames) constitute one FEC frame, the actual size of which depends on link conditions and bandwidth allocation. The FEC frame is the unit of interleaving. This accumulation of PDUs for FEC adds part of the latency mentioned in Section 2.1.
在W-CDMA中，一到十二个PDU（RLC帧）构成一个FEC帧，其实际大小取决于链路条件和带宽分配。FEC帧是交织单元。FEC的PDU累积增加了第2.1节中提到的部分延迟。
For reliable transfer, RLC has an acknowledged mode for PDU retransmission. RLC uses checkpoint ARQ [20] with "status report" type acknowledgments; the poll bit in the header explicitly solicits the peer for a status report containing the sequence number that the peer acknowledges. The use of the poll bit is controlled by timers and by the size of available buffer space in RLC. Also, when the peer detects a gap between sequence numbers in received frames, it can issue a status report to invoke retransmission. RLC preserves the order of packet delivery.
为了可靠传输，RLC具有PDU重传的确认模式。RLC使用带有“状态报告”类型确认的检查点ARQ[20]；标头中的轮询位显式请求对等方提供包含对等方确认的序列号的状态报告。轮询位的使用由计时器和RLC中可用缓冲区空间的大小控制。此外，当对等方检测到所接收帧中的序列号之间的间隔时，它可以发出状态报告以调用重传。RLC保留数据包传递的顺序。
The maximum number of retransmissions is a configurable RLC parameter that is specified by RRC [39] (Radio Resource Controller) through RLC connection initialization. The RRC can set the maximum number of retransmissions (up to a maximum of 40). Therefore, RLC can be described as an ARQ that can be configured for either HIGH-PERSISTENCE or LOW-PERSISTENCE, not PERFECT-PERSISTENCE, according to the terminology in [22].
最大重传次数是可配置的RLC参数，由RRC[39]（无线资源控制器）通过RLC连接初始化指定。RRC可以设置最大重传次数（最多40次）。因此，根据[22]中的术语，RLC可以被描述为ARQ，可以配置为高持久性或低持久性，而不是完美持久性。
Since the RRC manages RLC connection state, Bandwidth Oscillation (Section 2.7) can be eliminated by the RRC's keeping RF resource on an RLC connection with data in its queue. This avoids resource de-allocation in the middle of transferring data.
由于RRC管理RLC连接状态，因此可以通过RRC将RF资源保持在RLC连接上并使数据在其队列中来消除带宽振荡（第2.7节）。这避免了在传输数据中间的资源去分配。
In summary, the link layer ARQ and FEC can provide a packet service with a negligibly small probability of undetected error (failure of the link CRC), and a low level of loss (non-delivery) for the upper layer traffic, i.e., IP. Retransmission of PDUs by ARQ introduces latency and delay jitter to the IP flow. This is why the transport layer sees the underlying W-CDMA network as a network with a
总之，链路层ARQ和FEC可以提供分组服务，其未检测到的错误（链路CRC的故障）的概率小得可以忽略，并且上层业务（即IP）的丢失水平低（不传送）。通过ARQ重新传输PDU会给IP流带来延迟和延迟抖动。这就是为什么传输层将底层W-CDMA网络视为具有
relatively large BDP (Bandwidth-Delay Product) of up to 50 KB for the 384 kbps radio bearer.
对于384kbps的无线承载，相对较大的BDP（带宽延迟乘积）高达50kb。
One of the Terrestrial Radio Interface standards for 3G wireless systems, proposed under the International Mobile Telecommunications-2000 umbrella, is cdma2000 [55]. It employs Multi-Carrier Code Division Multiple Access (CDMA) technology with a single-carrier RF bandwidth of 1.25 MHz. cdma2000 evolved from IS-95 [56], a 2G standard based on CDMA technology. The first phase of cdma2000 utilizes a single carrier and is designed to double the voice capacity of existing CDMA (IS-95) networks and to support always-on data transmission speeds of up to 316.8 kbps. As mentioned above, these enhanced capabilities are delivered by cdma2000 1XRTT. 3G speeds of 2 Mbps are offered by cdma2000 1X-EV. At the physical layer, the standard allows transmission in 5,10,20,40 or 80 ms time frames. Various orthogonal (Walsh) codes are used for channel identification and to achieve higher data rates.
在国际移动通信-2000框架下提出的3G无线系统的地面无线电接口标准之一是cdma2000[55]。它采用多载波码分多址（CDMA）技术，单载波射频带宽为1.25 MHz。cdma2000是从基于CDMA技术的2G标准IS-95[56]演变而来的。cdma2000的第一阶段采用单载波，旨在将现有CDMA（is-95）网络的语音容量提高一倍，并支持高达316.8 kbps的始终在线数据传输速度。如上所述，这些增强功能由cdma2000 1XRTT提供。cdma2000 1X-EV提供2 Mbps的3G速度。在物理层，标准允许在5、10、20、40或80毫秒的时间帧内传输。各种正交（沃尔什）码用于信道识别和实现更高的数据速率。
Radio Link Protocol Type 3 (RLP) [57] is used with a cdma2000 Traffic Channel to support CDMA data services. RLP provides an octet stream transport service and is unaware of higher layer framing. There are several RLP frame formats. RLP frame formats with higher payload were designed for higher data rates. Depending on the channel speed, one or more RLP frames can be transmitted in a single physical layer frame.
无线链路协议类型3（RLP）[57]与cdma2000业务信道一起使用，以支持CDMA数据服务。RLP提供八位组流传输服务，不知道更高层的帧。有几种RLP帧格式。具有更高负载的RLP帧格式设计用于更高的数据速率。根据信道速度，可以在单个物理层帧中传输一个或多个RLP帧。
RLP can substantially decrease the error rate exhibited by CDMA traffic channels [53]. When transferring data, RLP is a pure NAK-based finite selective repeat protocol. The receiver does not acknowledge successfully received data frames. If one or more RLP data frames are missing, the receiving RLP makes several attempts (called NAK rounds) to recover them by sending one or more NAK control frames to the transmitter. Each NAK frame must be sent in a separate physical layer frame. When RLP supplies the last NAK control frame of a particular NAK round, a retransmission timer is set. If the missing frame is not received when the timer expires, RLP may try another NAK round. RLP may not recover all missing frames. If after all RLP rounds, a frame is still missing, RLP supplies data with a missing frame to the higher layer protocols.
RLP可以显著降低CDMA业务信道显示的错误率[53]。在传输数据时，RLP是一种纯粹的基于NAK的有限选择性重复协议。接收器未确认成功接收的数据帧。如果一个或多个RLP数据帧丢失，则接收RLP通过向发射机发送一个或多个NAK控制帧来进行多次尝试（称为NAK轮）以恢复它们。每个NAK帧必须在单独的物理层帧中发送。当RLP提供特定NAK轮的最后一个NAK控制帧时，设置重传定时器。如果在计时器过期时未接收到丢失的帧，则RLP可以尝试另一个NAK轮。RLP可能无法恢复所有丢失的帧。如果在所有RLP轮次之后，仍然缺少一个帧，则RLP将缺少帧的数据提供给更高层协议。
What follows is a set of recommendations for configuration parameters for protocol stacks which will be used to support TCP connections over 2.5G and 3G wireless networks. Some of these recommendations imply special configuration:
下面是一组协议栈配置参数的建议，这些协议栈将用于支持2.5G和3G无线网络上的TCP连接。其中一些建议暗示了特殊配置：
o at the data receiver (frequently a stack at or near the wireless device),
o 在数据接收器处（通常是无线设备处或附近的堆栈），
o at the data sender (frequently a host in the Internet or possibly a gateway or proxy at the edge of a wireless network), or
o 在数据发送方（通常是Internet上的主机或无线网络边缘的网关或代理），或
o at both.
o 两者都有。
These configuration options are commonly available IETF standards-track mechanisms considered safe on the general Internet. System administrators are cautioned, however, that increasing the MTU size (Section 4.4) and disabling RFC 1144 header compression (Section 4.9) could affect host efficiency, and that changing such parameters should be done with care.
这些配置选项通常是通用Internet上认为安全的IETF标准跟踪机制。但是，系统管理员应注意，增加MTU大小（第4.4节）和禁用RFC 1144标头压缩（第4.9节）可能会影响主机效率，更改此类参数时应小心。
TCP over 2.5G/3G should support appropriate window sizes based on the Bandwidth Delay Product (BDP) of the end-to-end path (see Section 2.2). The TCP specification [14] limits the receiver window size to 64 KB. If the end-to-end BDP is expected to be larger than 64 KB, the window scale option [2] can be used to overcome that limitation. Many operating systems by default use small TCP receive and send buffers around 16KB. Therefore, even for a BDP below 64 KB, the default buffer size setting should be increased at the sender and at the receiver to allow a large enough window.
TCP over 2.5G/3G应支持基于端到端路径的带宽延迟积（BDP）的适当窗口大小（参见第2.2节）。TCP规范[14]将接收器窗口大小限制为64 KB。如果端到端BDP预计大于64 KB，则可以使用窗口缩放选项[2]来克服该限制。默认情况下，许多操作系统使用大约16KB的小型TCP接收和发送缓冲区。因此，即使对于低于64 KB的BDP，发送方和接收方的默认缓冲区大小设置也应增加，以允许足够大的窗口。
TCP controls its transmit rate using the congestion window mechanism. The traditional initial window value of one segment, coupled with the delayed ACK mechanism [17] implies unnecessary idle times in the initial phase of the connection, including the delayed ACK timeout (typically 200 ms, but potentially as much as 500 ms) [4]. Senders can avoid this by using a larger initial window of up to four segments (not to exceed roughly 4 KB) [4]. Experiments with increased initial windows and related measurements have shown (1) that it is safe to deploy this mechanism (i.e., it does not lead to congestion collapse), and (2) that it is especially effective for the transmission of a few TCP segments' worth of data (which is the behavior commonly seen in such applications as Internet-enabled mobile wireless devices). For large data transfers, on the other hand, the effect of this mechanism is negligible.
TCP使用拥塞窗口机制控制其传输速率。一个段的传统初始窗口值加上延迟ACK机制[17]意味着连接初始阶段不必要的空闲时间，包括延迟ACK超时（通常为200 ms，但可能高达500 ms）[4]。发送方可以通过使用最多四个段（不超过大约4KB）的较大初始窗口来避免这种情况[4]。增加初始窗口和相关测量的实验表明：（1）部署这种机制是安全的（即，它不会导致拥塞崩溃），并且（2）对于传输少量TCP段的数据特别有效（这是在支持互联网的移动无线设备等应用中常见的行为）。另一方面，对于大数据传输，这种机制的影响可以忽略不计。
TCP over 2.5G/3G SHOULD set the initial CWND (congestion window) according to Equation 1 in [4]:
TCP over 2.5G/3G应根据[4]中的等式1设置初始CWND（拥塞窗口）：
min (4*MSS, max (2*MSS, 4380 bytes))
最小值（4*MSS，最大值（2*MSS，4380字节））
This increases the permitted initial window from one to between two and four segments (not to exceed approximately 4 KB).
这将允许的初始窗口从一个增加到两到四个段之间（不超过约4KB）。
RFC 3042 [10], Limited Transmit, extends Fast Retransmit/Fast Recovery for TCP connections with small congestion windows that are not likely to generate the three duplicate acknowledgements required to trigger Fast Retransmit [1]. If a sender has previously unsent data queued for transmission, the limited transmit mechanism calls for sending a new data segment in response to each of the first two duplicate acknowledgments that arrive at the sender. This mechanism is effective when the congestion window size is small or if a large number of segments in a window are lost. This may avoid some retransmissions due to TCP timeouts. In particular, some studies [10] have shown that over half of a busy server's retransmissions were due to RTO expiration (as opposed to Fast Retransmit), and that roughly 25% of those could have been avoided using Limited Transmit. Similar to the discussion in Section 4.2, this mechanism is useful for small amounts of data to be transmitted. TCP over 2.5G/3G implementations SHOULD implement Limited Transmit.
RFC 3042[10]，有限传输，扩展了TCP连接的快速重传/快速恢复，具有较小的拥塞窗口，不可能生成触发快速重传所需的三个重复确认[1]。如果发送方之前已将未发送的数据排队等待传输，则受限传输机制将调用发送新数据段，以响应到达发送方的前两个重复确认中的每一个。当拥塞窗口的大小很小或窗口中的大量段丢失时，这种机制是有效的。这可以避免由于TCP超时而导致的一些重传。特别是，一些研究[10]表明，繁忙服务器的重传有一半以上是由于RTO过期（与快速重传相反），其中大约25%可以使用有限的传输避免。与第4.2节中的讨论类似，该机制对于传输少量数据非常有用。TCP over 2.5G/3G实现应实现有限传输。
The maximum size of an IP datagram supported by a link layer is the MTU (Maximum Transfer Unit). The link layer may, in turn, fragment IP datagrams into PDUs. For example, on links with high error rates, a smaller link PDU size increases the chance of successful transmission. With layer two ARQ and transparent link layer fragmentation, the network layer can enjoy a larger MTU even in a relatively high BER (Bit Error Rate) condition. Without these features in the link, a smaller MTU is suggested.
链路层支持的IP数据报的最大大小是MTU（最大传输单元）。链路层又可以将IP数据报分段成pdu。例如，在错误率较高的链路上，较小的链路PDU大小会增加成功传输的机会。使用第二层ARQ和透明链路层分段，即使在相对较高的BER（误码率）条件下，网络层也可以享受更大的MTU。如果链接中没有这些功能，建议使用较小的MTU。
TCP over 2.5G/3G should allow freedom for designers to choose MTU values ranging from small values (such as 576 bytes) to a large value that is supported by the type of link in use (such as 1500 bytes for IP packets on Ethernet). Given that the window is counted in units of segments, a larger MTU allows TCP to increase the congestion window faster [5]. Hence, designers are generally encouraged to choose larger values. These may exceed the default IP MTU values of 576 bytes for IPv4 RFC 1191 [6] and 1280 bytes for IPv6 [18]. While this recommendation is applicable to 3G networks, operation over 2.5G networks should exercise caution as per the recommendations in RFC 3150 [5].
TCP over 2.5G/3G应允许设计者自由选择MTU值，范围从较小的值（如576字节）到使用的链路类型支持的较大值（如以太网上IP数据包的1500字节）。鉴于窗口是以段为单位计算的，较大的MTU允许TCP更快地增加拥塞窗口[5]。因此，通常鼓励设计师选择较大的值。这些值可能超过IPv4 RFC 1191[6]的默认IP MTU值576字节和IPv6[18]的默认IP MTU值1280字节。虽然本建议适用于3G网络，但在2.5G网络上的操作应根据RFC 3150[5]中的建议谨慎。
Path MTU discovery allows a sender to determine the maximum end-to-end transmission unit (without IP fragmentation) for a given routing path. RFC 1191 [6] and RFC 1981 [8] describe the MTU discovery procedure for IPv4 and IPv6, respectively. This allows TCP senders to employ larger segment sizes (without causing IP layer fragmentation) instead of assuming the small default MTU. TCP over 2.5G/3G implementations should implement Path MTU Discovery. Path MTU Discovery requires intermediate routers to support the generation of the necessary ICMP messages. RFC 1435 [7] provides recommendations that may be relevant for some router implementations.
路径MTU发现允许发送方确定给定路由路径的最大端到端传输单元（无IP碎片）。RFC 1191[6]和RFC 1981[8]分别描述了IPv4和IPv6的MTU发现过程。这允许TCP发送方采用更大的段大小（不会导致IP层碎片），而不是采用较小的默认MTU。TCP over 2.5G/3G实施应实现路径MTU发现。路径MTU发现需要中间路由器来支持生成必要的ICMP消息。RFC 1435[7]提供了可能与某些路由器实现相关的建议。
The selective acknowledgment option (SACK), RFC 2018 [3], is effective when multiple TCP segments are lost in a single TCP window [24]. In particular, if the end-to-end path has a large BDP and a high packet loss rate, the probability of multiple segment losses in a single window of data increases. In such cases, SACK provides robustness beyond TCP-Tahoe and TCP-Reno [21]. TCP over 2.5G/3G SHOULD support SACK.
选择性确认选项（SACK）RFC 2018[3]在单个TCP窗口中丢失多个TCP段时有效[24]。特别地，如果端到端路径具有大BDP和高分组丢失率，则在单个数据窗口中多个段丢失的概率增加。在这种情况下，SACK提供了TCP Tahoe和TCP Reno之外的健壮性[21]。TCP over 2.5G/3G应支持SACK。
In the absence of SACK feature, the TCP should use NewReno RFC 2582 [15].
在没有SACK功能的情况下，TCP应使用NewReno RFC 2582[15]。
4.7 Explicit Congestion Notification (Sender, Receiver & Intermediate Routers)
4.7 显式拥塞通知（发送方、接收方和中间路由器）
Explicit Congestion Notification, RFC 3168 [9], allows a TCP receiver to inform the sender of congestion in the network by setting the ECN-Echo flag upon receiving an IP packet marked with the CE bit(s). The TCP sender will then reduce its congestion window. Thus, the use of ECN is believed to provide performance benefits [32], [43]. RFC 3168 [9] also places requirements on intermediate routers (e.g., active queue management and setting of the CE bit(s) in the IP header to indicate congestion). Therefore, the potential improvement in performance can only be achieved when ECN capable routers are deployed along the path. TCP over 2.5G/3G SHOULD support ECN.
显式拥塞通知RFC 3168[9]，允许TCP接收方在接收到标有CE位的IP数据包时，通过设置ECN Echo标志来通知发送方网络中的拥塞。然后，TCP发送方将减少其拥塞窗口。因此，ECN的使用被认为提供了性能优势[32]，[43]。RFC 3168[9]还对中间路由器提出了要求（例如，主动队列管理和在IP报头中设置CE位以指示拥塞）。因此，只有在沿路径部署支持ECN的路由器时，才能实现性能的潜在改进。TCP over 2.5G/3G应支持ECN。
Traditionally, TCPs collect one RTT sample per window of data [14], [17]. This can lead to an underestimation of the RTT, and spurious timeouts on paths in which the packet transmission delay dominates the RTT. This holds despite a conservative retransmit timer such as the one specified in RFC 2988 [11]. TCP connections with large windows may benefit from more frequent RTT samples provided with
传统上，TCP每个数据窗口收集一个RTT样本[14]，[17]。这可能导致对RTT的低估，以及在包传输延迟主导RTT的路径上出现虚假超时。尽管采用了保守的重传计时器（如RFC 2988[11]中规定的计时器），但这种情况仍然存在。具有大窗口的TCP连接可能受益于随附的更频繁的RTT示例
timestamps by adapting quicker to changing network conditions [2]. However, there is some empirical evidence that for TCPs with an RFC 2988 timer [11], timestamps provide little or no benefits on backbone Internet paths [59]. Using the TCP Timestamps option has the advantage that retransmitted segments can be used for RTT measurement, which is otherwise forbidden by Karn's algorithm [17], [11]. Furthermore, the TCP Timestamps option is the basis for detecting spurious retransmits using the Eifel algorithm [30].
通过更快地适应不断变化的网络条件来设置时间戳[2]。然而，有一些经验证据表明，对于带有RFC 2988定时器的TCP[11]，时间戳在主干互联网路径上几乎没有或根本没有好处[59]。使用TCP时间戳选项的优点是重传的段可以用于RTT测量，这是Karn算法禁止的[17]，[11]。此外，TCP时间戳选项是使用Eifel算法检测虚假重传的基础[30]。
A 2.5/3G link (layer) is dedicated to a single host. It therefore only experiences a low degree of statistical multiplexing between different flows. Also, the packet transmission and queuing delays of a 2.5/3G link often dominate the path's RTT. This already results in large RTT variations as packets fill the queue while a TCP sender probes for more bandwidth, or as packets drain from the queue while a TCP sender reduces its load in response to a packet loss. In addition, the delay spikes across a 2.5/3G link (see Section 2.4) may often exceed the end-to-end RTT. The thus resulting large variations in the path's RTT may often cause spurious timeouts.
2.5/3G链路（层）专用于单个主机。因此，它在不同流之间只经历了较低程度的统计复用。此外，2.5/3G链路的数据包传输和排队延迟通常控制路径的RTT。当TCP发送方探测更多带宽时，数据包填满队列，或者当TCP发送方响应数据包丢失而减少其负载时，数据包从队列中流出，这已经导致RTT的巨大变化。此外，2.5/3G链路（见第2.4节）上的延迟峰值通常可能超过端到端RTT。由此导致的路径RTT的较大变化通常会导致虚假超时。
When running TCP in such an environment, it is therefore advantageous to sample the path's RTT more often than only once per RTT. This allows the TCP sender to track changes in the RTT more closely. In particular, a TCP sender can react more quickly to sudden increases of the RTT by sooner updating the RTO to a more conservative value. The TCP Timestamps option [2] provides this capability, allowing the TCP sender to sample the RTT from every segment that is acknowledged. Using timestamps in the mentioned scenario leads to a more conservative TCP retransmission timer and reduces the risk of triggering spurious timeouts [45], [52], [54], [60].
因此，在这样的环境中运行TCP时，对路径的RTT进行采样的频率比每个RTT仅采样一次更为有利。这允许TCP发送方更密切地跟踪RTT中的更改。特别是，TCP发送方可以更快地将RTO更新为更保守的值，从而对RTT的突然增加做出更快的反应。TCP时间戳选项[2]提供了此功能，允许TCP发送方从每个已确认的段中采样RTT。在上述场景中使用时间戳会导致更保守的TCP重传计时器，并降低触发虚假超时的风险[45]、[52]、[54]、[60]。
There are two problematic issues with using timestamps:
使用时间戳有两个问题：
o 12 bytes of overhead are introduced by carrying the TCP Timestamps option and padding in the TCP header. For a small MTU size, it can present a considerable overhead. For example, for an MTU of 296 bytes the added overhead is 4%. For an MTU of 1500 bytes, the added overhead is only 0.8%.
o 通过在TCP报头中携带TCP时间戳选项和填充，引入了12字节的开销。对于较小的MTU大小，它可能会带来相当大的开销。例如，对于296字节的MTU，增加的开销为4%。对于1500字节的MTU，增加的开销仅为0.8%。
o Current TCP header compression schemes are limited in their handling of the TCP options field. For RFC 2507 [13], any change in the options field (caused by timestamps or SACK, for example) renders the entire field uncompressible (leaving the TCP/IP header itself compressible, however). Even worse, for RFC 1144 [40] such a change in the options field effectively disables TCP/IP header compression altogether. This is the case when a connection uses the TCP Timestamps option. That option field is used both in the data and the ACK path, and its value typically changes from one
o 当前的TCP头压缩方案在处理TCP选项字段方面受到限制。对于RFC 2507[13]，选项字段中的任何更改（例如，由时间戳或SACK引起）都会使整个字段不可压缩（但是，TCP/IP报头本身是可压缩的）。更糟糕的是，对于RFC 1144[40]，选项字段中的这种更改实际上完全禁用了TCP/IP报头压缩。当连接使用TCP时间戳选项时就是这种情况。该选项字段在数据和ACK路径中都使用，其值通常从1更改为1
packet to the next. The IETF is currently specifying a robust TCP/IP header compression scheme with better support for TCP options [29].
将数据包发送到下一个。IETF目前正在指定一种健壮的TCP/IP报头压缩方案，更好地支持TCP选项[29]。
The original definition of the timestamps option [2] specifies that duplicate segments below cumulative ACK do not update the cached timestamp value at the receiver. This may lead to overestimating of RTT for retransmitted segments. A possible solution [47] allows the receiver to use a more recent timestamp from a duplicate segment. However, this suggestion allows for spoofing attacks against the TCP receiver. Therefore, careful consideration is needed in implementing this solution.
时间戳选项[2]的原始定义规定，累积ACK下的重复段不会在接收器处更新缓存的时间戳值。这可能导致对重传段的RTT估计过高。一种可能的解决方案[47]允许接收机使用来自重复段的较新时间戳。但是，此建议允许对TCP接收器进行欺骗攻击。因此，在实施此解决方案时需要仔细考虑。
Recommendation: TCP SHOULD use the TCP Timestamps option. It allows for better RTT estimation and reduces the risk of spurious timeouts.
建议：TCP应使用TCP时间戳选项。它允许更好的RTT估计，并降低虚假超时的风险。
It is well known (and has been shown with experimental data) that RFC 1144 [40] TCP header compression does not perform well in the presence of packet losses [43], [52]. If a wireless link error is not recovered, it will cause TCP segment loss between the compressor and decompressor, and then RFC 1144 header compression does not allow TCP to take advantage of Fast Retransmit Fast Recovery mechanism. The RFC 1144 header compression algorithm does not transmit the entire TCP/IP headers, but only the changes in the headers of consecutive segments. Therefore, loss of a single TCP segment on the link causes the transmitting and receiving TCP sequence numbers to fall out of synchronization. Hence, when a TCP segment is lost after the compressor, the decompressor will generate false TCP headers. Consequently, the TCP receiver will discard all remaining packets in the current window because of a checksum error. This continues until the compressor receives the first retransmission which is forwarded uncompressed to synchronize the decompressor [40].
众所周知（并已通过实验数据证明），RFC 1144[40]TCP报头压缩在存在数据包丢失的情况下不能很好地执行[43]，[52]。如果未恢复无线链路错误，将导致压缩器和解压缩器之间的TCP段丢失，然后RFC 1144报头压缩不允许TCP利用快速重传快速恢复机制。RFC 1144报头压缩算法不传输整个TCP/IP报头，只传输连续段报头中的更改。因此，链路上单个TCP段的丢失会导致发送和接收TCP序列号不同步。因此，当TCP段在压缩器之后丢失时，解压缩器将生成错误的TCP头。因此，由于校验和错误，TCP接收器将丢弃当前窗口中所有剩余的数据包。这一直持续到压缩器接收到第一次重传，该重传未经压缩转发以同步解压缩器[40]。
As previously recommended in RFC 3150 [5], RFC 1144 header compression SHOULD NOT be enabled unless the packet loss probability between the compressor and decompressor is very low. Actually, enabling the Timestamps Option effectively accomplishes the same thing (see Section 4.8). Other header compression schemes like RFC 2507 [13] and Robust Header Compression [12] are meant to address deficiencies in RFC 1144 header compression. At the time of this writing, the IETF was working on multiple extensions to Robust Header Compression (negotiating Robust Header Compression over PPP, compressing TCP options, etc) [16].
正如之前在RFC 3150[5]中建议的那样，除非压缩器和解压缩器之间的丢包概率非常低，否则不应启用RFC 1144报头压缩。实际上，启用Timestamps选项可以有效地完成同样的事情（参见第4.8节）。其他报头压缩方案，如RFC 2507[13]和鲁棒报头压缩[12]旨在解决RFC 1144报头压缩中的缺陷。在撰写本文时，IETF正在研究鲁棒头压缩的多个扩展（通过PPP协商鲁棒头压缩、压缩TCP选项等）[16]。
Items Comments
----------------------------------------------------------------
Appropriate Window Size (sender & receiver)
based on end-to-end BDP
Items Comments
----------------------------------------------------------------
Appropriate Window Size (sender & receiver)
based on end-to-end BDP
Window Scale Option (sender & receiver) [RFC1323] Window size > 64KB
窗口缩放选项（发送方和接收方）[RFC1323]窗口大小>64KB
Increased Initial Window (sender) [RFC3390] CWND = min (4*MSS, max (2*MSS, 4380 bytes))
增加的初始窗口（发送方）[RFC3390]CWND=min（4*MSS，最大值（2*MSS，4380字节））
Limited Transmit (sender) [RFC3042]
有限传输（发送方）[RFC3042]
IP MTU larger than more applicable to 3G Default
IP MTU大于更适用于3G默认值
Path MTU Discovery (sender & intermediate routers) [RFC1191,RFC1981]
路径MTU发现（发送方和中间路由器）[RFC1191，RFC1981]
Selective Acknowledgment option (SACK) [RFC2018] (sender & receiver)
选择性确认选项（SACK）[RFC2018]（发送方和接收方）
Explicit Congestion Notification(ECN) [RFC3168] (sender, receiver & intermediate routers)
显式拥塞通知（ECN）[RFC3168]（发送方、接收方和中间路由器）
Timestamps Option (sender & receiver) [RFC1323, R.T.Braden's ID]
时间戳选项（发送方和接收方）[RFC1323，R.T.Braden的ID]
Disabling RFC1144 TCP/IP Header Compression [RFC1144] (wireless host)
禁用RFC1144 TCP/IP标头压缩[RFC1144]（无线主机）
This section outlines additional mechanisms and parameter settings that may increase end-to-end performance when running TCP across 2.5G/3G networks. Note, that apart from the discussion of the RTO's initial value, those mechanisms and parameter settings are not part of any standards track RFC at the time of this writing. Therefore, they cannot be recommended for the Internet in general.
本节概述了在2.5G/3G网络上运行TCP时可能提高端到端性能的其他机制和参数设置。注意，除了讨论RTO的初始值外，在撰写本文时，这些机制和参数设置不属于任何标准跟踪RFC的一部分。因此，一般来说，不能将其推荐给Internet。
Other mechanisms for increasing TCP performance include enhanced TCP/ IP header compression schemes [29], active queue management RFC 2309 [28], link layer retransmission schemes [23], and caching packets during transient link outages to retransmit them locally when the link is restored to operation [23].
提高TCP性能的其他机制包括增强的TCP/IP报头压缩方案[29]、主动队列管理RFC 2309[28]、链路层重传方案[23]，以及在瞬时链路中断期间缓存数据包，以便在链路恢复运行时在本地重传数据包[23]。
Shortcomings of existing TCP/IP header compression schemes (RFC 1144 [40], RFC 2507 [13]) are that they do not compress headers of handshaking packets (SYNs and FINs), and that they lack proper handling of TCP option fields (e.g., SACK or timestamps) (see Section 4.8). Although RFC 3095 [12] does not yet address this issue, the IETF is developing improved TCP/IP header compression schemes, including better handling of TCP options such as timestamps and selective acknowledgements. Especially, if many short-lived TCP connections run across the link, the compression of the handshaking packets may greatly improve the overall header compression ratio.
现有TCP/IP报头压缩方案（RFC 1144[40]，RFC 2507[13]）的缺点是，它们不压缩握手数据包（SYN和FINs）的报头，并且缺乏对TCP选项字段（例如SACK或时间戳）的正确处理（见第4.8节）。尽管RFC 3095[12]尚未解决此问题，但IETF正在开发改进的TCP/IP报头压缩方案，包括更好地处理TCP选项，如时间戳和选择性确认。特别是，如果许多短命TCP连接在链路上运行，则握手数据包的压缩可大大提高整体报头压缩率。
Implementing active queue management is attractive for a number of reasons as outlined in RFC 2309 [28]. One important benefit for 2.5G/ 3G networks, is that it minimizes the amount of potentially stale data that may be queued in the network ("clicking from page to page" before the download of the previous page is complete). Avoiding the transmission of stale data across the 2.5G/3G radio link saves transmission (battery) power, and increases the ratio of useful data over total data transmitted. Another important benefit of active queue management for 2.5G/3G networks, is that it reduces the risk of a spurious timeout for the first data segment as outlined below.
如RFC 2309[28]所述，出于许多原因，实施主动队列管理具有吸引力。2.5G/3G网络的一个重要好处是，它最大限度地减少了网络中可能排队的潜在陈旧数据量（“在完成前一页的下载之前，从一页点击到另一页”）。避免在2.5G/3G无线链路上传输过时数据可节省传输（电池）功率，并提高有用数据与传输总数据的比率。2.5G/3G网络的主动队列管理的另一个重要好处是，它降低了第一个数据段出现虚假超时的风险，如下所述。
Since 2.5G/3G networks are commonly characterized by high delays, avoiding unecessary round-trip times is particularly attractive. This is specially beneficial for short-lived, transactional (request/ response-style) TCP sessions that typically result from browsing the Web from a smart phone. However, existing solutions such as T/TCP RFC 1644 [27], have not been adopted due to known security concerns [38].
由于2.5G/3G网络通常具有高延迟的特点，因此避免不必要的往返时间尤其具有吸引力。这对于通常通过智能手机浏览Web而产生的短命、事务性（请求/响应样式）TCP会话特别有用。然而，由于已知的安全问题，诸如T/TCP RFC 1644[27]等现有解决方案尚未被采用[38]。
Spurious timeouts, packet re-ordering, and packet duplication may reduce TCP's performance. Thus, making TCP more robust against those events is desirable. Solutions to this problem have been proposed [30], [35], [41], and standardization work within the IETF is ongoing at the time of writing. Those solutions include reverting congestion control state after such an event has been detected, and adapting the retransmission timer and duplicate acknowledgement threshold. The deployment of such solutions may be particularly beneficial when running TCP across wireless networks because wireless access links may often be subject to handovers and resource preemption, or the mobile transmitter may traverse through a radio coverage hole. Such
虚假超时、数据包重新排序和数据包复制可能会降低TCP的性能。因此，使TCP对这些事件更加健壮是可取的。已经提出了该问题的解决方案[30]、[35]、[41]，在撰写本文时，IETF内的标准化工作正在进行中。这些解决方案包括在检测到此类事件后恢复拥塞控制状态，以及调整重传计时器和重复确认阈值。当在无线网络上运行TCP时，这种解决方案的部署可能特别有益，因为无线接入链路可能经常受到切换和资源抢占的影响，或者移动发射机可能穿过无线电覆盖孔。这样的
disrupting events may easily trigger a spurious timeout despite a conservative retransmission timer. Also, the mobility mechanisms of some wireless networks may cause packet duplication.
中断事件可能很容易触发虚假超时，尽管有保守的重新传输计时器。此外，某些无线网络的移动机制可能导致数据包重复。
The algorithm for computing TCP's retransmission timer is specified in RFC 2988 [11]. The standard specifies that the initial setting of the retransmission timeout value (RTO) should not be less than 3 seconds. This value might be too low when running TCP across 2.5G/3G networks. In addition to its high latencies, those networks may be run at bit rates of as low as about 10 kb/s which results in large packet transmission delays. In this case, the RTT for the first data segment may easily exceed the initial TCP retransmission timer setting of 3 seconds. This would then cause a spurious timeout for that segment. Hence, in such situations it may be advisable to set TCP's initial RTO to a value larger than 3 seconds. Furthermore, due to the potentially large packet transmission delays, a TCP sender might choose to refrain from initializing its RTO from the RTT measured for the SYN, but instead take the RTT measured for the first data segment.
RFC 2988[11]中规定了计算TCP重传计时器的算法。该标准规定重传超时值（RTO）的初始设置不应小于3秒。在2.5G/3G网络上运行TCP时，此值可能太低。除了高延迟之外，这些网络可能以低至约10 kb/s的比特率运行，这导致大的分组传输延迟。在这种情况下，第一数据段的RTT可能很容易超过3秒的初始TCP重传定时器设置。这将导致该段出现虚假超时。因此，在这种情况下，建议将TCP的初始RTO设置为大于3秒的值。此外，由于潜在的大数据包传输延迟，TCP发送方可能会选择不从为SYN测量的RTT初始化其RTO，而是采用为第一个数据段测量的RTT。
Some of the recommendations in RFC 2988 [11] are optional, and are not followed by all TCP implementations. Specifically, some TCP stacks allow a minimum RTO less than the recommended value of 1 second (section 2.4 of [11]), and some implementations do not implement the recommended restart of the RTO timer when an ACK is received (section 5.3 of [11]). Some experiments [52], [54], have shown that in the face of bandwidth oscillation, using the recommended minimum RTO value of 1 sec (along with the also recommended initial RTO of 3 sec) reduces the number of spurious retransmissions as compared to using small minimum RTO values of 200 or 400 ms. Furthermore, TCP stacks that restart the retransmission timer when an ACK is received experience far less spurious retransmissions than implementations that do not restart the RTO timer when an ACK is received. Therefore, at the time of this writing, it seems preferable for TCP implementations used in 3G wireless data transmission to comply with all recommendations of RFC 2988.
RFC 2988[11]中的一些建议是可选的，并非所有TCP实现都遵循这些建议。具体而言，一些TCP堆栈允许最小RTO小于建议值1秒（见[11]第2.4节），而一些实现在收到ACK时不执行建议的RTO计时器重启（见[11]第5.3节）。一些实验[52]，[54]表明，与使用200或400 ms的最小RTO值相比，在面对带宽振荡时，使用建议的最小RTO值1秒（以及也建议的初始RTO值3秒）可以减少伪重传的次数。此外，与接收到ACK时不重新启动RTO计时器的实现相比，在接收到ACK时重新启动重传计时器的TCP堆栈经历的伪重传要少得多。因此，在撰写本文时，3G无线数据传输中使用的TCP实现似乎更符合RFC 2988的所有建议。
In 2.5G/3G wireless networks, data is transmitted as ciphertext over the air and as cleartext between the Radio Access Network (RAN) and the core network. IP security RFC 2401 [37] or TLS RFC 2246 [36] can be deployed by user devices for end-to-end security.
在2.5G/3G无线网络中，数据在空中以密文和明文的形式在无线接入网络（RAN）和核心网络之间传输。IP安全RFC 2401[37]或TLS RFC 2246[36]可由用户设备部署以实现端到端安全。
This specification requires no IANA actions.
本规范不需要IANA操作。
The authors would like to acknowledge contributions to the text from the following individuals:
作者要感谢以下个人对本文本的贡献：
Max Hata, NTT DoCoMo, Inc. (hata@mml.yrp.nttdocomo.co.jp)
马克斯·哈塔，NTT多科莫公司(hata@mml.yrp.nttdocomo.co.jp)
Masahiro Hara, Fujitsu, Inc. (mhara@FLAB.FUJITSU.CO.JP)
富士通公司原正弘(mhara@FLAB.FUJITSU.CO.JP)
Joby James, Motorola, Inc. (joby@MIEL.MOT.COM)
乔比·詹姆斯，摩托罗拉公司(joby@MIEL.MOT.COM)
William Gilliam, Hewlett-Packard Company (wag@cup.hp.com)
William Gilliam，惠普公司(wag@cup.hp.com)
Alan Hameed, Fujitsu FNC, Inc. (Alan.Hameed@fnc.fujitsu.com)
阿兰·哈米德，富士通FNC公司（阿兰。Hameed@fnc.fujitsu.com)
Rodrigo Garces, Mobility Network Systems (rodrigo.garces@mobilitynetworks.com)
Rodrigo Garces，移动网络系统（Rodrigo。garces@mobilitynetworks.com)
Peter Ford, Microsoft (peterf@Exchange.Microsoft.com)
彼得·福特，微软(peterf@Exchange.Microsoft.com)
Fergus Wills, Openwave (fergus.wills@openwave.com)
弗格斯·威尔斯，Openwave（弗格斯。wills@openwave.com)
Michael Meyer (Michael.Meyer@eed.ericsson.se)
迈克尔·迈耶（迈克尔。Meyer@eed.ericsson.se)
The authors gratefully acknowledge the valuable advice from the following individuals:
作者衷心感谢以下人士提出的宝贵建议：
Gorry Fairhurst (gorry@erg.abdn.ac.uk)
戈里·费尔赫斯特(gorry@erg.abdn.ac.uk)
Mark Allman (mallman@grc.nasa.gov)
马克·奥尔曼(mallman@grc.nasa.gov)
Aaron Falk (falk@ISI.EDU)
亚伦·福克(falk@ISI.EDU)
[1] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[1] Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[2] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[2] Jacobson，V.，Braden，R.和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[3] Mathis, M., Mahdavi, J., Floyd, S. and R. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[3] Mathis，M.，Mahdavi，J.，Floyd，S.和R.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[4] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[4] 奥尔曼，M.，弗洛伊德，S.和C.帕特里奇，“增加TCP的初始窗口”，RFC3390，2002年10月。
[5] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
[5] Dawkins，S.，黑山，G.，Kojo，M.和V.Magret，“慢链路的端到端性能影响”，BCP 48，RFC 3150，2001年7月。
[6] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[6] Mogul，J.和S.Deering，“MTU发现路径”，RFC191990年11月。
[7] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[7] Knowles，S.，“从Path MTU发现的经验中得出的IESG建议”，RFC 1435，1993年3月。
[8] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[8] McCann，J.，Deering，S.和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[9] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[9] Ramakrishnan，K.，Floyd，S.和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[10] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[10] Allman，M.，Balakrishnan，H.和S.Floyd，“使用有限传输增强TCP的丢失恢复”，RFC 3042，2001年1月。
[11] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[11] Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[12] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[12] Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP和未压缩”，RFC 3095，2001年7月。
[13] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[13] Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[14] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, September 1981.
[14] Postel，J.，“传输控制协议-DARPA互联网程序协议规范”，STD 7，RFC 793，1981年9月。
[15] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[15] Floyd，S.和T.Henderson，“TCP快速恢复算法的NewReno修改”，RFC 2582，1999年4月。
[16] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[16] Bormann，C.，“PPP上的鲁棒头压缩（ROHC）”，RFC 32412002年4月。
[17] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[17] Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[18] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[18] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[19] Montenegro, G., Dawkins, S., Kojo, M., Magret, V. and N. Vaidya, "Long Thin Networks", RFC 2757, January 2000.
[19] 黑山，G.，道金斯，S.，科乔，M.，马格雷特，V.和N.瓦迪亚，“细长网络”，RFC 2757，2000年1月。
[20] Third Generation Partnership Project, "RLC Protocol Specification (3G TS 25.322:)", 1999.
[20] 第三代合作项目，“RLC协议规范（3G TS 25.322:）”，1999年。
[21] Fall, K. and S. Floyd, "Simulation-based Comparisons of Tahoe, Reno, and SACK TCP", Computer Communication Review, 26(3) , July 1996.
[21] Fall，K.和S.Floyd，“塔霍、雷诺和萨克TCP基于模拟的比较”，《计算机通信评论》，26（3），1996年7月。
[22] Fairhurst, G. and L. Wood, "Advice to link designers on link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.
[22] Fairhurst，G.和L.Wood，“关于链路自动重复请求（ARQ）的链路设计者建议”，BCP 62，RFC 3366，2002年8月。
[23] Karn, P., "Advice for Internet Subnetwork Designers", Work in Progress.
[23] 卡恩，P.，“互联网子网设计师的建议”，正在进行中。
[24] Dawkins, S., Montenegro, G., Magret, V., Vaidya, N. and M. Kojo, "End-to-end Performance Implications of Links with Errors", BCP 50, RFC 3135, August 2001.
[24] Dawkins，S.，黑山，G.，Magret，V.，Vaidya，N.和M.Kojo，“带错误链接的端到端性能影响”，BCP 50，RFC 31352001年8月。
[25] Wireless Application Protocol, "WAP Specifications", 2002, <http://www.wapforum.org>.
[25] 无线应用协议，“WAP规范”，2002年<http://www.wapforum.org>.
[26] Open Mobile Alliance, "Open Mobile Alliance", 2002, <http://www.openmobilealliance.org/>.
[26] 开放移动联盟，“开放移动联盟”，2002年<http://www.openmobilealliance.org/>.
[27] Braden, R., "T/TCP -- TCP Extensions for Transactions", RFC 1644, July 1994.
[27] Braden，R.，“T/TCP——事务的TCP扩展”，RFC16441994年7月。
[28] Braden, R., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[28] Braden，R.，Clark，D.，Crowcroft，J.，Davie，B.，Deering，S.，Estrin，D.，Floyd，S.，Jacobson，V.，Minshall，G.，Partridge，C.，Peterson，L.，Ramakrishnan，K.，Shenker，S.，Wroclawski，J.和L.Zhang，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[29] IETF, "Robust Header Compression", 2001, <http://www.ietf.org/html.charters/rohc-charter.html>.
[29] IETF，“鲁棒头压缩”，2001年<http://www.ietf.org/html.charters/rohc-charter.html>.
[30] Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions", ACM Computer Communication Review 30(1), January 2000.
[30] Ludwig，R.和R.H.Katz，“Eifel算法：使TCP对伪重传具有鲁棒性”，ACM计算机通信评论30（1），2000年1月。
[31] Wireless Application Protocol, "WAP Wireless Profiled TCP", WAP-225-TCP-20010331-a, April 2001, <http://www.wapforum.com/what/technical.htm>.
[31] 无线应用协议，“WAP无线分析TCP”，WAP-225-TCP-20010331-a，2001年4月<http://www.wapforum.com/what/technical.htm>.
[32] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks", RFC 2884, July 2000.
[32] Hadi Salim，J.和U.Ahmed，“IP网络中显式拥塞通知（ECN）的性能评估”，RFC 2884，2000年7月。
[33] NTT DoCoMo Technical Journal, "Special Issue on i-mode Service", October 1999.
[33] NTT DoCoMo技术期刊，“i模式服务专刊”，1999年10月。
[34] NTT DoCoMo Technical Journal, "Special Article on IMT-2000 Services", September 2001.
[34] NTT DoCoMo技术期刊，“关于IMT-2000服务的特别文章”，2001年9月。
[35] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[35] Floyd，S.，Mahdavi，J.，Mathis，M.和M.Podolsky，“TCP选择性确认（SACK）选项的扩展”，RFC 28832000年7月。
[36] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[36] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[37] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[37] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[38] de Vivo, M., O. de Vivo, G., Koeneke, R. and G. Isern, "Internet Vulnerabilities Related to TCP/IP and T/TCP", ACM Computer Communication Review 29(1), January 1999.
[38] de Vivo，M.，O.de Vivo，G.，Koeneke，R.和G.Isern，“与TCP/IP和T/TCP相关的互联网漏洞”，ACM计算机通信评论29（1），1999年1月。
[39] Third Generation Partnership Project, "RRC Protocol Specification (3GPP TS 25.331:)", September 2001.
[39] 第三代合作项目，“RRC协议规范（3GPP TS 25.331:）”，2001年9月。
[40] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[40] Jacobson，V.，“压缩低速串行链路的TCP/IP报头”，RFC 1144，1990年2月。
[41] Blanton, E. and M. Allman, "On Making TCP More Robust to Packet Reordering", ACM Computer Communication Review 32(1), January 2002, <http://roland.grc.nasa.gov/~mallman/papers/tcp-reorder-ccr.ps>.
[41] Blanton，E.和M.Allman，“关于使TCP对数据包重新排序更具鲁棒性”，ACM计算机通信评论32（1），2002年1月<http://roland.grc.nasa.gov/~mallman/papers/tcp-reorder-ccr.ps>。
[42] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", ACM SIGCOMM 87, 1987.
[42] Karn，P.和C.Partridge，“改进可靠传输协议中的往返时间估计”，ACM SIGCOMM 87，1987年。
[43] Ludwig, R., Rathonyi, B., Konrad, A. and A. Joseph, "Multi-layer tracing of TCP over a reliable wireless link", ACM SIGMETRICS 99, May 1999.
[43] Ludwig，R.，Rathonyi，B.，Konrad，A.和A.Joseph，“可靠无线链路上TCP的多层跟踪”，ACM SIGMETRICS 99，1999年5月。
[44] Ludwig, R., Konrad, A., Joseph, A. and R. Katz, "Optimizing the End-to-End Performance of Reliable Flows over Wireless Links", Kluwer/ACM Wireless Networks Journal Vol. 8, Nos. 2/3, pp. 289- 299, March-May 2002.
[44] Ludwig，R.，Konrad，A.，Joseph，A.和R.Katz，“优化无线链路上可靠流的端到端性能”，《Kluwer/ACM无线网络杂志》第8卷，第2/3期，第289-299页，2002年3月至5月。
[45] Gurtov, A., "Making TCP Robust Against Delay Spikes", University of Helsinki, Department of Computer Science, Series of Publications C, C-2001-53, Nov 2001, <http://www.cs.helsinki.fi/u/gurtov/papers/report01.html>.
[45] Gurtov，A.，“使TCP对延迟尖峰健壮”，赫尔辛基大学，计算机系，系列出版物C，C-1-1-53，NOV 2001，<http://www.cs.helsinki.fi/u/gurtov/papers/report01.html>.
[46] Stevens, W., "TCP/IP Illustrated, Volume 1; The Protocols", Addison Wesley, 1995.
[46] Stevens，W.，“TCP/IP图解，第1卷；协议”，Addison-Wesley，1995年。
[47] Braden, R., "TCP Extensions for High Performance: An Update", Work in Progress.
[47] Braden，R.，“高性能TCP扩展：更新”，正在进行中。
[48] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D., Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann, S., Scott, K. and J. Semke, "Ongoing TCP Research Related to Satellites", RFC 2760, February 2000.
[48] 奥尔曼，M.，道金斯，S.，格洛弗，D.，格林纳，J.，特兰，D.，亨德森，T.，海德曼，J.，Touch，J.，克鲁斯，H.，奥斯特曼，S.，斯科特，K.和J.塞姆克，“正在进行的与卫星相关的TCP研究”，RFC 2760，2000年2月。
[49] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
[49] Allman，M.，Glover，D.和L.Sanchez，“使用标准机制增强卫星信道上的TCP”，BCP 28，RFC 2488，1999年1月。
[50] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M. Sooriyabandara, "TCP Performance Implications of Network Asymmetry", RFC 3449, December 2002.
[50] Balakrishnan，H.，Padmanabhan，V.，Fairhurst，G.和M.Sooriyabandara，“网络不对称对TCP性能的影响”，RFC 3449，2002年12月。
[51] Kempf, J., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002.
[51] Kempf，J.，“问题描述：在IP接入网络中的节点之间执行上下文传输的原因”，RFC 3374，2002年9月。
[52] Khafizov, F. and M. Yavuz, "Running TCP over IS-2000", Proc. of IEEE ICC, 2002.
[52] Khafizov，F.和M.Yavuz，“在IS-2000上运行TCP”，Proc。IEEE国际商会，2002年。
[53] Khafizov, F. and M. Yavuz, "Analytical Model of RLP in IS-2000 CDMA Networks", Proc. of IEEE Vehicular Technology Conference, September 2002.
[53] Khafizov，F.和M.Yavuz，“IS-2000 CDMA网络中RLP的分析模型”，Proc。IEEE车辆技术会议，2002年9月。
[54] Yavuz, M. and F. Khafizov, "TCP over Wireless Links with Variable Bandwidth", Proc. of IEEE Vehicular Technology Conference, September 2002.
[54] Yavuz，M.和F.Khafizov，“可变带宽无线链路上的TCP”，Proc。IEEE车辆技术会议，2002年9月。
[55] TIA/EIA/cdma2000, "Mobile Station - Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular Systems", Washington: Telecommunication Industry Association, 1999.
[55] TIA/EIA/cdma2000，“双模宽带扩频蜂窝系统的移动站-基站兼容性标准”，华盛顿：电信行业协会，1999年。
[56] TIA/EIA/IS-95 Rev A, "Mobile Station - Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular Systems", Washington: Telecommunication Industry Association, 1995.
[56] TIA/EIA/IS-95 A版，“移动台-双模宽带扩频蜂窝系统基站兼容性标准”，华盛顿：电信业协会，1995年。
[57] TIA/EIA/IS-707-A-2.10, "Data Service Options for Spread Spectrum Systems: Radio Link Protocol Type 3", January 2000.
[57] TIA/EIA/IS-707-A-2.10，“扩频系统的数据服务选项：无线电链路协议类型3”，2000年1月。
[58] Dahlman, E., Beming, P., Knutsson, J., Ovesjo, F., Persson, M. and C. Roobol, "WCDMA - The Radio Interface for Future Mobile Multimedia Communications", IEEE Trans. on Vehicular Technology, vol. 47, no. 4, pp. 1105-1118, November 1998.
[58] Dahlman，E.，Beming，P.，Knutsson，J.，Ovesjo，F.，Persson，M.和C.Roobol，“WCDMA-未来移动多媒体通信的无线电接口”，IEEE Trans。《车辆技术》，第47卷，第4期，第1105-1118页，1998年11月。
[59] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", ACM SIGCOMM 99, September 1999.
[59] Allman，M.和V.Paxson，“关于估算端到端网络路径属性”，ACM SIGCOMM 991999年9月。
[60] Gurtov, A. and R. Ludwig, "Responding to Spurious Timeouts in TCP", IEEE INFOCOM'03, March 2003.
[60] Gurtov，A.和R.Ludwig，“对TCP中虚假超时的响应”，IEEE INFOCOM'03，2003年3月。
Hiroshi Inamura NTT DoCoMo, Inc. 3-5 Hikarinooka Yokosuka Shi, Kanagawa Ken 239-8536 Japan
Hiroshi Inamura NTT DoCoMo，Inc.日本神奈川县Hikarinooka横须贺市3-5号，邮编239-8536
EMail: inamura@mml.yrp.nttdocomo.co.jp
URI: http://www.nttdocomo.co.jp/
EMail: inamura@mml.yrp.nttdocomo.co.jp
URI: http://www.nttdocomo.co.jp/
Gabriel Montenegro Sun Microsystems Laboratories, Europe Avenue de l'Europe ZIRST de Montbonnot 38334 Saint Ismier CEDEX France
加布里埃尔黑山太阳微系统实验室，法国圣伊斯梅尔塞德克斯蒙博诺欧洲大道（邮编：38334）
EMail: gab@sun.com
EMail: gab@sun.com
Reiner Ludwig Ericsson Research Ericsson Allee 1 52134 Herzogenrath Germany
Reiner Ludwig Ericsson Research爱立信Allee 1 52134 Herzogenrath德国
EMail: Reiner.Ludwig@Ericsson.com
EMail: Reiner.Ludwig@Ericsson.com
Andrei Gurtov Sonera P.O. Box 970, FIN-00051 Helsinki, Finland
芬兰赫尔辛基FIN-00051安德烈·古托夫·索内拉邮政信箱970
EMail: andrei.gurtov@sonera.com
URI: http://www.cs.helsinki.fi/u/gurtov/
EMail: andrei.gurtov@sonera.com
URI: http://www.cs.helsinki.fi/u/gurtov/
Farid Khafizov Nortel Networks 2201 Lakeside Blvd Richardson, TX 75082, USA
美国德克萨斯州理查森湖畔大道2201号Farid Khafizov Nortel Networks 75082
EMail: faridk@nortelnetworks.com
EMail: faridk@nortelnetworks.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。