Network Working Group G. Montenegro
Request for Comments: 2757 Sun Microsystems, Inc.
Category: Informational S. Dawkins
Nortel Networks
M. Kojo
University of Helsinki
V. Magret
Alcatel
N. Vaidya
Texas A&M University
January 2000
Network Working Group G. Montenegro
Request for Comments: 2757 Sun Microsystems, Inc.
Category: Informational S. Dawkins
Nortel Networks
M. Kojo
University of Helsinki
V. Magret
Alcatel
N. Vaidya
Texas A&M University
January 2000
Long Thin Networks
长瘦网络
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
In view of the unpredictable and problematic nature of long thin networks (for example, wireless WANs), arriving at an optimized transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks.
鉴于超长网络（例如无线广域网）的不可预测性和问题性，实现优化传输是一项艰巨的任务。我们已检讨现有的建议及未来的研究项目。基于此概述，我们还推荐在长瘦网络中实现的机制。
Our goal is to identify a TCP that works for all users, including users of long thin networks. We started from the working recommendations of the IETF TCP Over Satellite Links (tcpsat) working group with this end in mind.
我们的目标是确定一种适用于所有用户的TCP，包括长瘦网络的用户。我们从IETF TCP Over Satellite Link（tcpsat）工作组的工作建议开始考虑这一目标。
We recognize that not every tcpsat recommendation will be required for long thin networks as well, and work toward a set of TCP recommendations that are 'benign' in environments that do not require them.
我们认识到，对于长瘦网络来说，并非每一项tcpsat建议都是必需的，我们将致力于在不需要它们的环境中实现一组“良性”的TCP建议。
Table of Contents
目录
1 Introduction ................................................. 3
1.1 Network Architecture .................................... 5
1.2 Assumptions about the Radio Link ........................ 6
2 Should it be IP or Not? ..................................... 7
2.1 Underlying Network Error Characteristics ................ 7
2.2 Non-IP Alternatives ..................................... 8
2.2.1 WAP ................................................ 8
2.2.2 Deploying Non-IP Alternatives ...................... 9
2.3 IP-based Considerations ................................. 9
2.3.1 Choosing the MTU [Stevens94, RFC1144] .............. 9
2.3.2 Path MTU Discovery [RFC1191] ....................... 10
2.3.3 Non-TCP Proposals .................................. 10
3 The Case for TCP ............................................. 11
4 Candidate Optimizations ...................................... 12
4.1 TCP: Current Mechanisms ................................. 12
4.1.1 Slow Start and Congestion Avoidance ................ 12
4.1.2 Fast Retransmit and Fast Recovery .................. 12
4.2 Connection Setup with T/TCP [RFC1397, RFC1644] .......... 14
4.3 Slow Start Proposals .................................... 14
4.3.1 Larger Initial Window .............................. 14
4.3.2 Growing the Window during Slow Start ............... 15
4.3.2.1 ACK Counting .................................. 15
4.3.2.2 ACK-every-segment ............................. 16
4.3.3 Terminating Slow Start ............................. 17
4.3.4 Generating ACKs during Slow Start .................. 17
4.4 ACK Spacing ............................................. 17
4.5 Delayed Duplicate Acknowlegements ....................... 18
4.6 Selective Acknowledgements [RFC2018] .................... 18
4.7 Detecting Corruption Loss ............................... 19
4.7.1 Without Explicit Notification ...................... 19
4.7.2 With Explicit Notifications ........................ 20
4.8 Active Queue Management ................................. 21
4.9 Scheduling Algorithms ................................... 21
4.10 Split TCP and Performance-Enhancing Proxies (PEPs) ..... 22
4.10.1 Split TCP Approaches .............................. 23
4.10.2 Application Level Proxies ......................... 26
4.10.3 Snoop and its Derivatives ......................... 27
4.10.4 PEPs to handle Periods of Disconnection ........... 29
4.11 Header Compression Alternatives ........................ 30
4.12 Payload Compression .................................... 31
4.13 TCP Control Block Interdependence [Touch97] ............ 32
5 Summary of Recommended Optimizations ......................... 33
6 Conclusion ................................................... 35
7 Acknowledgements ............................................. 35
8 Security Considerations ...................................... 35
1 Introduction ................................................. 3
1.1 Network Architecture .................................... 5
1.2 Assumptions about the Radio Link ........................ 6
2 Should it be IP or Not? ..................................... 7
2.1 Underlying Network Error Characteristics ................ 7
2.2 Non-IP Alternatives ..................................... 8
2.2.1 WAP ................................................ 8
2.2.2 Deploying Non-IP Alternatives ...................... 9
2.3 IP-based Considerations ................................. 9
2.3.1 Choosing the MTU [Stevens94, RFC1144] .............. 9
2.3.2 Path MTU Discovery [RFC1191] ....................... 10
2.3.3 Non-TCP Proposals .................................. 10
3 The Case for TCP ............................................. 11
4 Candidate Optimizations ...................................... 12
4.1 TCP: Current Mechanisms ................................. 12
4.1.1 Slow Start and Congestion Avoidance ................ 12
4.1.2 Fast Retransmit and Fast Recovery .................. 12
4.2 Connection Setup with T/TCP [RFC1397, RFC1644] .......... 14
4.3 Slow Start Proposals .................................... 14
4.3.1 Larger Initial Window .............................. 14
4.3.2 Growing the Window during Slow Start ............... 15
4.3.2.1 ACK Counting .................................. 15
4.3.2.2 ACK-every-segment ............................. 16
4.3.3 Terminating Slow Start ............................. 17
4.3.4 Generating ACKs during Slow Start .................. 17
4.4 ACK Spacing ............................................. 17
4.5 Delayed Duplicate Acknowlegements ....................... 18
4.6 Selective Acknowledgements [RFC2018] .................... 18
4.7 Detecting Corruption Loss ............................... 19
4.7.1 Without Explicit Notification ...................... 19
4.7.2 With Explicit Notifications ........................ 20
4.8 Active Queue Management ................................. 21
4.9 Scheduling Algorithms ................................... 21
4.10 Split TCP and Performance-Enhancing Proxies (PEPs) ..... 22
4.10.1 Split TCP Approaches .............................. 23
4.10.2 Application Level Proxies ......................... 26
4.10.3 Snoop and its Derivatives ......................... 27
4.10.4 PEPs to handle Periods of Disconnection ........... 29
4.11 Header Compression Alternatives ........................ 30
4.12 Payload Compression .................................... 31
4.13 TCP Control Block Interdependence [Touch97] ............ 32
5 Summary of Recommended Optimizations ......................... 33
6 Conclusion ................................................... 35
7 Acknowledgements ............................................. 35
8 Security Considerations ...................................... 35
9 References ................................................... 36
Authors' Addresses ............................................. 44
Full Copyright Statement ....................................... 46
9 References ................................................... 36
Authors' Addresses ............................................. 44
Full Copyright Statement ....................................... 46
1 Introduction
1导言
Optimized wireless networking is one of the major hurdles that Mobile Computing must solve if it is to enable ubiquitous access to networking resources. However, current data networking protocols have been optimized primarily for wired networks. Wireless environments have very different characteristics in terms of latency, jitter, and error rate as compared to wired networks. Accordingly, traditional protocols are ill-suited to this medium.
优化无线网络是移动计算必须解决的主要障碍之一，如果它要实现对网络资源的无处不在的访问。然而，目前的数据网络协议主要针对有线网络进行了优化。与有线网络相比，无线环境在延迟、抖动和错误率方面具有非常不同的特征。因此，传统协议不适合这种媒体。
Mobile Wireless networks can be grouped in W-LANs (for example, 802.11 compliant networks) and W-WANs (for example, CDPD [CDPD], Ricochet, CDMA [CDMA], PHS, DoCoMo, GSM [GSM] to name a few). W-WANs present the most serious challenge, given that the length of the wireless link (expressed as the delay*bandwidth product) is typically 4 to 5 times as long as that of its W-LAN counterparts. For example, for an 802.11 network, assuming the delay (round-trip time) is about 3 ms. and the bandwidth is 1.5 Mbps, the delay*bandwidth product is 4500 bits. For a W-WAN such as Ricochet, a typical round-trip time may be around 500 ms. (the best is about 230 ms.), and the sustained bandwidth is about 24 Kbps. This yields a delay*bandwidth product roughly equal to 1.5 KB. In the near future, 3rd Generation wireless services will offer 384Kbps and more. Assuming a 200 ms round-trip, the delay*bandwidth product in this case is 76.8 Kbits (9.6 KB). This value is larger than the default 8KB buffer space used by many TCP implementations. This means that, whereas for W-LANs the default buffer space is enough, future W-WANs will operate inefficiently (that is, they will not be able to fill the pipe) unless they override the default value. A 3rd Generation wireless service offering 2 Mbps with 200-millisecond latency requires a 50 KB buffer.
移动无线网络可分为W-LAN（例如，802.11兼容网络）和W-WAN（例如，CDPD[CDPD]、回跳、CDMA[CDMA]、PHS、DoCoMo、GSM[GSM]等等）。鉴于无线链路的长度（表示为延迟*带宽乘积）通常是其W-LAN对应物的4到5倍，W-WAN是最严重的挑战。例如，对于802.11网络，假设延迟（往返时间）约为3 ms，并且带宽为1.5 Mbps，则延迟*带宽乘积为4500比特。对于W-WAN（如跳弹），典型的往返时间可能约为500毫秒（最好的时间约为230毫秒），持续带宽约为24 Kbps。这将产生大约等于1.5 KB的延迟*带宽乘积。在不久的将来，第三代无线服务将提供384Kbps甚至更多。假设一个200毫秒的往返行程，本例中的延迟*带宽乘积为76.8 Kbits（9.6 KB）。此值大于许多TCP实现使用的默认8KB缓冲区空间。这意味着，尽管W-LAN的默认缓冲区空间足够，但未来的W-WAN将无法有效运行（即，它们将无法填充管道），除非它们覆盖默认值。提供2 Mbps、200毫秒延迟的第三代无线服务需要50 KB的缓冲区。
Most importantly, latency across a link adversely affects throughput. For example, [MSMO97] derives an upper bound on TCP throughput. Indeed, the resultant expression is inversely related to the round-trip time.
最重要的是，链路上的延迟会对吞吐量产生不利影响。例如，[MSMO97]得出TCP吞吐量的上限。事实上，结果表达式与往返时间成反比。
The long latencies also push the limits (and commonly transgress them) for what is acceptable to users of interactive applications.
长延迟也会对交互应用程序用户可以接受的内容施加限制（通常会超过这些限制）。
As a quick glance to our list of references will reveal, there is a wealth of proposals that attempt to solve the wireless networking problem. In this document, we survey the different solutions available or under investigation, and issue the corresponding recommendations.
快速浏览一下我们的参考文献列表就会发现，有很多建议试图解决无线网络问题。在本文件中，我们调查了现有或正在调查的不同解决方案，并提出了相应的建议。
There is a large body of work on the subject of improving TCP performance over satellite links. The documents under development by the tcpsat working group of the IETF [AGS98, ADGGHOSSTT98] are very relevant. In both cases, it is essential to start by improving the characteristics of the medium by using forward error correction (FEC) at the link layer to reduce the BER (bit error rate) from values as high as 10-3 to 10-6 or better. This makes the BER manageable. Once in this realm, retransmission schemes like ARQ (automatic repeat request) may be used to bring it down even further. Notice that sometimes it may be desirable to forego ARQ because of the additional delay it implies. In particular, time sensitive traffic (video, audio) must be delivered within a certain time limit beyond which the data is obsolete. Exhaustive retransmissions in this case merely succeed in wasting time in order to deliver data that will be discarded once it arrives at its destination. This indicates the desirability of augmenting the protocol stack implementation on devices such that the upper protocol layers can inform the link and MAC layer when to avoid such costly retransmission schemes.
在改善卫星链路上的TCP性能这一主题上，有大量的工作要做。IETF的tcpsat工作组正在编制的文件[AGS98，ADGGHOSSTT98]非常相关。在这两种情况下，必须首先通过在链路层使用前向纠错（FEC）来改善介质的特性，以将BER（误码率）从高达10-3的值降低到10-6或更好。这使得BER易于管理。一旦进入这个领域，像ARQ（自动重复请求）这样的重传方案就可以用来进一步降低它。请注意，有时可能需要放弃ARQ，因为它意味着额外的延迟。特别是，对时间敏感的流量（视频、音频）必须在数据过时的特定时间限制内交付。在这种情况下，彻底的重新传输只会成功地浪费时间，以便交付一旦到达目的地就会丢弃的数据。这表示希望在设备上增加协议栈实现，使得上层协议层可以通知链路层和MAC层何时避免这种昂贵的重传方案。
Networks that include satellite links are examples of "long fat networks" (LFNs or "elephants"). They are "long" networks because their round-trip time is quite high (for example, 0.5 sec and higher for geosynchronous satellites). Not all satellite links fall within the LFN regime. In particular, round-trip times in a low-earth orbiting (LEO) satellite network may be as little as a few milliseconds (and never extend beyond 160 to 200 ms). W-WANs share the "L" with LFNs. However, satellite networks are also "fat" in the sense that they may have high bandwidth. Satellite networks may often have a delay*bandwidth product above 64 KBytes, in which case they pose additional problems to TCP [TCPHP]. W-WANs do not generally exhibit this behavior. Accordingly, this document only deals with links that are "long thin pipes", and the networks that contain them: "long thin networks". We call these "LTNs".
包括卫星链路的网络是“长胖网络”（LFN或“大象”）的例子。它们是“长”网络，因为它们的往返时间相当长（例如，地球同步卫星的往返时间为0.5秒或更高）。并非所有卫星链路都属于LFN体制。特别是，低地球轨道（LEO）卫星网络的往返时间可能只有几毫秒（并且永远不会超过160到200毫秒）。W-WAN与LFN共享“L”。然而，卫星网络也很“胖”，因为它们可能具有高带宽。卫星网络的延迟*带宽乘积通常超过64 KB，在这种情况下，它们会给TCP[TCPHP]带来额外的问题。W-WAN通常不会表现出这种行为。因此，本文档仅涉及“细长管道”链接以及包含它们的网络：“细长网络”。我们称之为“LTN”。
This document does not give an overview of the API used to access the underlying transport. We believe this is an orthogonal issue, even though some of the proposals below have been put forth assuming a given interface. It is possible, for example, to support the traditional socket semantics without fully relying on TCP/IP transport [MOWGLI].
本文档没有概述用于访问底层传输的API。我们认为这是一个正交问题，尽管下面的一些建议是假设给定接口提出的。例如，可以在不完全依赖TCP/IP传输[MOWGLI]的情况下支持传统套接字语义。
Our focus is on the on-the-wire protocols. We try to include the most relevant ones and briefly (given that we provide the references needed for further study) mention their most salient points.
我们的重点是在线协议。我们试图包括最相关的，并简要地（鉴于我们提供了进一步研究所需的参考资料）提到它们最突出的点。
One significant difference between LFNs and LTNs is that we assume the W-WAN link is the last hop to the end user. This allows us to assume that a single intermediate node sees all packets transferred between the wireless mobile device and the rest of the Internet. This is only one of the topologies considered by the TCP Satellite community.
LFN和LTN之间的一个显著区别是，我们假设W-WAN链路是到最终用户的最后一跳。这允许我们假设单个中间节点可以看到无线移动设备和互联网其余部分之间传输的所有数据包。这只是TCP卫星社区考虑的拓扑之一。
Given our focus on mobile wireless applications, we only consider a very specific architecture that includes:
鉴于我们专注于移动无线应用，我们只考虑一个非常具体的体系结构，包括：
- a wireless mobile device, connected via
- 无线移动设备，通过
- a wireless link (which may, in fact comprise several hops at the link layer), to
- 无线链路（实际上可能包括链路层上的几个跃点）到
- an intermediate node (sometimes referred to as a base station) connected via
- 通过网络连接的中间节点（有时称为基站）
- a wireline link, which in turn interfaces with
- 一种有线链路，它反过来与
- the landline Internet and millions of legacy servers and web sites.
- 有线互联网和数百万传统服务器和网站。
Specifically, we are not as concerned with paths that include two wireless segments separated by a wired one. This may occur, for example, if one mobile device connects across its immediate wireless segment via an intermediate node to the Internet, and then via a second wireless segment to another mobile device. Quite often, mobile devices connect to a legacy server on the wired Internet.
具体来说，我们并不关心包含两个无线段（由有线段分隔）的路径。例如，如果一个移动设备通过其直接无线段经由中间节点连接到互联网，然后经由第二无线段连接到另一个移动设备，则可能发生这种情况。通常，移动设备连接到有线互联网上的传统服务器。
Typically, the endpoints of the wireless segment are the intermediate node and the mobile device. However, the latter may be a wireless router to a mobile network. This is also important and has applications in, for example, disaster recovery.
通常，无线段的端点是中间节点和移动设备。然而，后者可以是移动网络的无线路由器。这一点也很重要，并在灾难恢复等方面有应用。
Our target architecture has implications which concern the deployability of candidate solutions. In particular, an important requirement is that we cannot alter the networking stack on the legacy servers. It would be preferable to only change the networking stack at the intermediate node, although changing it at the mobile devices is certainly an option and perhaps a necessity.
我们的目标体系结构涉及候选解决方案的可部署性。特别是，一个重要的要求是我们不能改变遗留服务器上的网络堆栈。最好只在中间节点上更改网络堆栈，尽管在移动设备上更改网络堆栈肯定是一种选择，也可能是必要的。
We envision mobile devices that can use the wireless medium very efficiently, but overcome some of its traditional constraints. That is, full mobility implies that the devices have the flexibility and agility to use whichever happens to be the best network connection
我们设想移动设备可以非常有效地使用无线媒体，但要克服一些传统的限制。也就是说，完全移动性意味着设备具有灵活性和敏捷性，可以使用最佳网络连接
available at any given point in time or space. Accordingly, devices could switch from a wired office LAN and hand over their ongoing connections to continue on, say, a wireless WAN. This type of agility also requires Mobile IP [RFC2002].
在任何给定的时间或空间点可用。因此，设备可以从有线办公室局域网切换，并将其正在进行的连接移交给（比如）无线广域网。这种敏捷性还需要移动IP[RFC2002]。
The system architecture described above assumes at most one wireless link (perhaps comprising more than one wireless hop). However, this is not enough to characterize a wireless link. Additional considerations are:
上述系统架构假定最多一个无线链路（可能包括多个无线跳）。然而，这还不足以描述无线链路的特性。其他考虑因素包括：
- What are the error characteristics of the wireless medium? The link may present a higher BER than a wireline network due to burst errors and disconnections. The techniques below usually do not address all the types of errors. Accordingly, a complete solution should combine the best of all the proposals. Nevertheless, in this document we are more concerned with (and give preference to solving) the most typical case: (1) higher BER due to random errors (which implies longer and more variable delays due to link-layer error corrections and retransmissions) rather than (2) an interruption in service due to a handoff or a disconnection. The latter are also important and we do include relevant proposals in this survey.
- 无线媒体的错误特征是什么？由于突发错误和断开连接，链路可能呈现比有线网络更高的误码率。下面的技术通常不能解决所有类型的错误。因此，一个完整的解决方案应该结合所有建议中的最佳方案。然而，在本文档中，我们更关注（并优先解决）最典型的情况：（1）由于随机错误导致的较高误码率（这意味着由于链路层错误纠正和重新传输导致的更长和更多可变延迟），而不是（2）由于切换或断开连接导致的服务中断。后者也很重要，我们在本次调查中确实纳入了相关建议。
- Is the wireless service datagram oriented, or is it a virtual circuit? Currently, switched virtual circuits are more common, but packet networks are starting to appear, for example, Metricom's Starmode [CB96], CDPD [CDPD] and General Packet Radio Service (GPRS) [GPRS],[BW97] in GSM.
- 是面向无线服务数据报，还是虚拟电路？目前，交换虚拟电路更为常见，但分组网络开始出现，例如，Metricom的Starmode[CB96]、CDPD[CDPD]和GSM中的通用分组无线业务（GPRS）[GPRS]、[BW97]。
- What kind of reliability does the link provide? Wireless services typically retransmit a packet (frame) until it has been acknowledged by the target. They may allow the user to turn off this behavior. For example, GSM allows RLP [RLP] (Radio Link Protocol) to be turned off. Metricom has a similar "lightweight" mode. In GSM RLP, a frame is retransmitted until the maximum number of retransmissions (protocol parameter) is reached. What happens when this limit is reached is determined by the telecom operator: the physical link connection is either disconnected or a link reset is enforced where the sequence numbers are resynchronized and the transmit and receive buffers are flushed resulting in lost data. Some wireless services, like CDMA IS95-RLP [CDMA, Karn93], limit the latency on the wireless link by retransmitting a frame only a couple of times. This decreases the residual frame error rate significantly, but does not provide fully reliable link service.
- 链接提供了什么样的可靠性？无线服务通常会重新传输数据包（帧），直到它被目标确认为止。它们可能允许用户关闭此行为。例如，GSM允许关闭RLP[RLP]（无线链路协议）。Metricom也有类似的“轻量级”模式。在GSM RLP中，帧被重传，直到达到最大重传次数（协议参数）。达到此限制时发生的情况由电信运营商决定：物理链路连接断开，或者在序列号重新同步且发送和接收缓冲区刷新导致数据丢失的情况下强制链路重置。一些无线服务，如CDMA IS95-RLP[CDMA，Karn93]，通过只重传几次帧来限制无线链路上的延迟。这显著降低了残余帧错误率，但不能提供完全可靠的链路服务。
- Does the mobile device transmit and receive at the same time? Doing so increases the cost of the electronics on the mobile device. Typically, this is not the case. We assume in this document that mobile devices do not transmit and receive simultaneously.
- 移动设备是否同时发送和接收？这样做会增加移动设备上电子设备的成本。通常情况下，情况并非如此。在本文档中，我们假设移动设备不会同时发送和接收。
- Does the mobile device directly address more than one peer on the wireless link? Packets to each different peer may traverse spatially distinct wireless paths. Accordingly, the path to each peer may exhibit very different characteristics. Quite commonly, the mobile device addresses only one peer (the intermediate node) at any given point in time. When this is not the case, techniques such as Channel-State Dependent Packet Scheduling come into play (see the section "Packet Scheduling" below).
- 移动设备是否直接寻址无线链路上的多个对等方？到每个不同对等方的分组可以穿越空间上不同的无线路径。因此，到每个对等点的路径可能表现出非常不同的特征。非常常见的是，移动设备在任何给定时间点仅寻址一个对等方（中间节点）。当情况并非如此时，诸如信道状态相关的分组调度之类的技术开始发挥作用（参见下面的“分组调度”一节）。
2 Should it be IP or Not?
2是否应该是IP？
The first decision is whether to use IP as the underlying network protocol or not. In particular, some data protocols evolved from wireless telephony are not always -- though at times they may be -- layered on top of IP [MOWGLI, WAP]. These proposals are based on the concept of proxies that provide adaptation services between the wireless and wireline segments.
第一个决定是是否使用IP作为底层网络协议。特别是，从无线电话发展而来的一些数据协议并不总是——尽管有时可能是——在IP[MOWGLI，WAP]之上分层的。这些建议基于代理的概念，代理提供无线和有线段之间的适配服务。
This is a reasonable model for mobile devices that always communicate through the proxy. However, we expect many wireless mobile devices to utilize wireline networks whenever they are available. This model closely follows current laptop usage patterns: devices typically utilize LANs, and only resort to dial-up access when "out of the office."
对于始终通过代理进行通信的移动设备来说，这是一个合理的模型。然而，我们期望许多无线移动设备在任何时候都能利用有线网络。这种模式紧跟当前笔记本电脑的使用模式：设备通常使用局域网，只有在“外出”时才使用拨号接入
For these devices, an architecture that assumes IP is the best approach, because it will be required for communications that do not traverse the intermediate node (for example, upon reconnection to a W-LAN or a 10BaseT network at the office).
对于这些设备，假定IP的体系结构是最佳方法，因为不通过中间节点的通信（例如，在办公室重新连接到W-LAN或10BaseT网络时）需要IP。
Using IP as the underlying network protocol requires a certain (low) level of link robustness that is expected of wireless links.
使用IP作为底层网络协议要求无线链路具有一定（低）级别的链路健壮性。
IP, and the protocols that are carried in IP packets, are protected end-to-end by checksums that are relatively weak [Stevens94, Paxson97] (and, in some cases, optional). For much of the Internet, these checksums are sufficient; in wireless environments, the error characteristics of the raw wireless link are much less robust than the rest of the end-to-end path. Hence for paths that include
IP以及IP数据包中承载的协议通过相对较弱的校验和（Stevens94，Paxson97）（在某些情况下是可选的）进行端到端保护。对于大多数互联网，这些校验和就足够了；在无线环境中，原始无线链路的错误特性比端到端路径的其余部分要差得多。因此，对于包含
wireless links, exclusively relying on end-to-end mechanisms to detect and correct transmission errors is undesirable. These should be complemented by local link-level mechanisms. Otherwise, damaged IP packets are propagated through the network only to be discarded at the destination host. For example, intermediate routers are required to check the IP header checksum, but not the UDP or TCP checksums. Accordingly, when the payload of an IP packet is corrupted, this is not detected until the packet arrives at its ultimate destination.
无线链路完全依赖端到端机制来检测和纠正传输错误是不可取的。这些机制应得到地方链路级机制的补充。否则，损坏的IP数据包将通过网络传播，但只会在目标主机上丢弃。例如，中间路由器需要检查IP报头校验和，而不是UDP或TCP校验和。因此，当IP分组的有效载荷被破坏时，直到分组到达其最终目的地才检测到这一点。
A better approach is to use link-layer mechanisms such as FEC, retransmissions, and so on in order to improve the characteristics of the wireless link and present a much more reliable service to IP. This approach has been taken by CDPD, Ricochet and CDMA.
更好的方法是使用链路层机制，如FEC、重传等，以改善无线链路的特性，并向IP提供更可靠的服务。CDPD、Ricochet和CDMA采用了这种方法。
This approach is roughly analogous to the successful deployment of Point-to-Point Protocol (PPP), with robust framing and 16-bit checksumming, on wireline networks as a replacement for the Serial Line Interface Protocol (SLIP), with only a single framing byte and no checksumming.
这种方法大致类似于在有线网络上成功部署点对点协议（PPP），该协议具有健壮的帧和16位校验和，以替代串行线接口协议（SLIP），仅具有一个帧字节，无校验和。
[AGS98] recommends the use of FEC in satellite environments.
[AGS98]建议在卫星环境中使用FEC。
Notice that the link-layer could adapt its frame size to the prevalent BER. It would perform its own fragmentation and reassembly so that IP could still enjoy a large enough MTU size [LS98].
请注意，链接层可以根据当前的误码率调整其帧大小。它将执行自己的碎片化和重组，这样IP仍然可以拥有足够大的MTU大小[LS98]。
A common concern for using IP as a transport is the header overhead it implies. Typically, the underlying link-layer appears as PPP [RFC1661] to the IP layer above. This allows for header compression schemes [IPHC, IPHC-RTP, IPHC-PPP] which greatly alleviate the problem.
将IP用作传输的一个常见问题是它所带来的报头开销。通常，对于上面的IP层，底层链路层显示为PPP[RFC1661]。这允许采用头压缩方案[IPHC、IPHC-RTP、IPHC-PPP]，这大大缓解了问题。
A number of non-IP alternatives aimed at wireless environments have been proposed. One representative proposal is discussed here.
已经提出了许多针对无线环境的非IP替代方案。这里讨论了一个具有代表性的建议。
The Wireless Application Protocol (WAP) specifies an application framework and network protocols for wireless devices such as mobile telephones, pagers, and PDAs [WAP]. The architecture requires a proxy between the mobile device and the server. The WAP protocol stack is layered over a datagram transport service. Such a service is provided by most wireless networks; for example, IS-136, GSM SMS/USSD, and UDP in IP networks like CDPD and GSM GPRS. The core of
无线应用协议（WAP）为移动电话、寻呼机和PDA等无线设备指定了应用框架和网络协议[WAP]。该体系结构需要移动设备和服务器之间的代理。WAP协议栈在数据报传输服务上分层。这种服务由大多数无线网络提供；例如，IP网络（如CDPD和GSM GPRS）中的IS-136、GSM SMS/USSD和UDP。核心
the WAP protocols is a binary HTTP/1.1 protocol with additional features such as header caching between requests and a shared state between client and server.
WAP协议是一种二进制HTTP/1.1协议，具有附加功能，例如请求之间的头缓存以及客户端和服务器之间的共享状态。
IP is such a fundamental element of the Internet that non-IP alternatives face substantial obstacles to deployment, because they do not exploit the IP infrastructure. Any non-IP alternative that is used to provide gatewayed access to the Internet must map between IP addresses and non-IP addresses, must terminate IP-level security at a gateway, and cannot use IP-oriented discovery protocols (Dynamic Host Configuration Protocol, Domain Name Services, Lightweight Directory Access Protocol, Service Location Protocol, etc.) without translation at a gateway.
IP是互联网的一个基本要素，非IP替代方案在部署上面临巨大障碍，因为它们不利用IP基础设施。用于提供对Internet的网关访问的任何非IP替代方案必须在IP地址和非IP地址之间映射，必须在网关上终止IP级别的安全性，并且不能使用面向IP的发现协议（动态主机配置协议、域名服务、轻型目录访问协议、服务位置协议等），无需在网关上进行转换。
A further complexity occurs when a device supports both wireless and wireline operation. If the device uses IP for wireless operation, uninterrupted operation when the device is connected to a wireline network is possible (using Mobile IP). If a non-IP alternative is used, this switchover is more difficult to accomplish.
当设备同时支持无线和有线操作时，会出现进一步的复杂性。如果设备使用IP进行无线操作，则当设备连接到有线网络时，可以不间断地操作（使用移动IP）。如果使用非IP替代方案，则更难实现此切换。
Non-IP alternatives face the burden of proof that IP is so ill-suited to a wireless environment that it is not a viable technology.
非IP替代方案面临的举证责任是，IP非常不适合无线环境，因此它不是一种可行的技术。
Given its worldwide deployment, IP is an obvious choice for the underlying network technology. Optimizations implemented at this level benefit traditional Internet application protocols as well as new ones layered on top of IP or UDP.
鉴于其在全球的部署，IP显然是底层网络技术的选择。在这个级别上实现的优化有利于传统的Internet应用程序协议以及在IP或UDP之上分层的新协议。
In slow networks, the time required to transmit the largest possible packet may be considerable. Interactive response time should not exceed the well-known human factors limit of 100 to 200 ms. This should be considered the maximum time budget to (1) send a packet and (2) obtain a response. In most networking stack implementations, (1) is highly dependent on the maximum transmission unit (MTU). In the worst case, a small packet from an interactive application may have to wait for a large packet from a bulk transfer application before being sent. Hence, a good rule of thumb is to choose an MTU such that its transmission time is less than (or not much larger than) 200 ms.
在慢速网络中，传输最大可能数据包所需的时间可能相当长。交互响应时间不应超过众所周知的人为因素限制100至200 ms。这应被视为（1）发送数据包和（2）获得响应的最长时间预算。在大多数网络堆栈实现中，（1）高度依赖于最大传输单元（MTU）。在最坏的情况下，来自交互应用程序的小数据包可能必须等待来自批量传输应用程序的大数据包才能发送。因此，一个好的经验法则是选择MTU，使其传输时间小于（或不大于）200 ms。
Of course, compression and type-of-service queuing (whereby interactive data packets are given a higher priority) may alleviate this problem. In particular, the latter may reduce the average wait time to about half the MTU's transmission time.
当然，压缩和服务队列的类型（交互数据包被赋予更高的优先级）可以缓解这个问题。特别地，后者可以将平均等待时间减少到MTU的传输时间的大约一半。
Path MTU discovery benefits any protocol built on top of IP. It allows a sender to determine what the maximum end-to-end transmission unit is to a given destination. Without Path MTU discovery, the default IPv4 MTU size is 576. The benefits of using a larger MTU are:
路径MTU发现有利于任何建立在IP之上的协议。它允许发送方确定到给定目的地的最大端到端传输单元。如果没有路径MTU发现，默认IPv4 MTU大小为576。使用更大MTU的好处是：
- Smaller ratio of header overhead to data
- 标头开销与数据的比率较小
- Allows TCP to grow its congestion window faster, since it increases in units of segments.
- 允许TCP更快地增长其拥塞窗口，因为它以段为单位增加。
Of course, for a given BER, a larger MTU has a correspondingly larger probability of error within any given segment. The BER may be reduced using lower level techniques like FEC and link-layer retransmissions. The issue is that now delays may become a problem due to the additional retransmissions, and the fact that packet transmission time increases with a larger MTU.
当然，对于给定的误码率，较大的MTU在任何给定段内具有相应较大的错误概率。可以使用诸如FEC和链路层重传之类的较低级别技术来降低BER。问题是，由于额外的重传，以及数据包传输时间随MTU增大而增加的事实，现在延迟可能成为一个问题。
Recommendation: Path MTU discovery is recommended. [AGS98] already recommends its use in satellite environments.
建议：建议使用路径MTU发现。[AGS98]已经建议在卫星环境中使用。
Other proposals assume an underlying IP datagram service, and implement an optimized transport either directly on top of IP [NETBLT] or on top of UDP [MNCP]. Not relying on TCP is a bold move, given the wealth of experience and research related to it. It could be argued that the Internet has not collapsed because its main protocol, TCP, is very careful in how it uses the network, and generally treats it as a black box assuming all packet losses are due to congestion and prudently backing off. This avoids further congestion.
其他方案假设基础IP数据报服务，并直接在IP[NETBLT]或UDP[MNCP]之上实现优化传输。鉴于与TCP相关的丰富经验和研究，不依赖TCP是一个大胆的举措。可以说，互联网并没有崩溃，因为它的主要协议TCP在使用网络时非常谨慎，通常将其视为一个黑匣子，假设所有数据包丢失都是由于拥塞和谨慎退避造成的。这避免了进一步的拥挤。
However, in the wireless medium, packet losses may also be due to corruption due to high BER, fading, and so on. Here, the right approach is to try harder, instead of backing off. Alternative transport protocols are:
然而，在无线介质中，分组丢失也可能是由于高误码率、衰落等造成的损坏。在这里，正确的方法是更加努力，而不是退缩。替代传输协议包括：
- NETBLT [NETBLT, RFC1986, RFC1030]
- NETBLT[NETBLT，RFC1986，RFC1030]
- MNCP [MNCP]
- MNCP[MNCP]
- ESRO [RFC2188]
- ESRO[RFC2188]
- RDP [RFC908, RFC1151]
- RDP[RFC908，RFC1151]
- VMTP [VMTP]
- VMTP[VMTP]
3 The Case for TCP
3 TCP的情况
This is one of the most hotly debated issues in the wireless arena. Here are some arguments against it:
这是无线领域争论最激烈的问题之一。以下是一些反对的论据：
- It is generally recognized that TCP does not perform well in the presence of significant levels of non-congestion loss. TCP detractors argue that the wireless medium is one such case, and that it is hard enough to fix TCP. They argue that it is easier to start from scratch.
- 人们普遍认为，TCP在非拥塞损失严重的情况下表现不佳。TCP批评者认为无线媒体就是这样一种情况，修复TCP已经足够困难了。他们认为从头开始比较容易。
- TCP has too much header overhead.
- TCP有太多的头开销。
- By the time the mechanisms are in place to fix it, TCP is very heavy, and ill-suited for use by lightweight, portable devices.
- 当修复机制就位时，TCP非常沉重，不适合轻量级便携式设备使用。
and here are some in support of TCP:
下面是一些支持TCP的示例：
- It is preferable to continue using the same protocol that the rest of the Internet uses for compatibility reasons. Any extensions specific to the wireless link may be negotiated.
- 出于兼容性原因，最好继续使用互联网其他部分使用的相同协议。可以协商特定于无线链路的任何扩展。
- Legacy mechanisms may be reused (for example three-way handshake).
- 可以重用遗留机制（例如三方握手）。
- Link-layer FEC and ARQ can reduce the BER such that any losses TCP does see are, in fact, caused by congestion (or a sustained interruption of link connectivity). Modern W-WAN technologies do this (CDPD, US-TDMA, CDMA, GSM), thus improving TCP throughput.
- 链路层FEC和ARQ可以降低误码率，使得TCP确实看到的任何损失实际上都是由拥塞（或链路连接的持续中断）引起的。现代W-WAN技术可以做到这一点（CDPD、US-TDMA、CDMA、GSM），从而提高TCP吞吐量。
- Handoffs among different technologies are made possible by Mobile IP [RFC2002], but only if the same protocols, namely TCP/IP, are used throughout.
- 不同技术之间的切换可以通过移动IP实现[RFC2002]，但前提是在整个过程中使用相同的协议，即TCP/IP。
- Given TCP's wealth of research and experience, alternative protocols are relatively immature, and the full implications of their widespread deployment not clearly understood.
- 鉴于TCP丰富的研究和经验，替代协议相对不成熟，其广泛部署的全部含义尚不清楚。
Overall, we feel that the performance of TCP over long-thin networks can be improved significantly. Mechanisms to do so are discussed in the next sections.
总的来说，我们认为TCP在长瘦网络上的性能可以显著提高。下一节将讨论实现这一点的机制。
4 Candidate Optimizations
4个候选优化
There is a large volume of work on the subject of optimizing TCP for operation over wireless media. Even though satellite networks generally fall in the LFN regime, our current LTN focus has much to benefit from it. For example, the work of the TCP-over-Satellite working group of the IETF has been extremely helpful in preparing this section [AGS98, ADGGHOSSTT98].
在优化TCP以在无线媒体上运行这一主题上，有大量的工作要做。尽管卫星网络通常属于LFN体制，但我们当前的LTN重点从中受益匪浅。例如，IETF的TCP over Satellite工作组的工作对本节的编写非常有帮助[AGS98，ADGGHOSSTT98]。
A TCP sender adapts its use of bandwidth based on feedback from the receiver. The high latency characteristic of LTNs implies that TCP's adaptation is correspondingly slower than on networks with shorter delays. Similarly, delayed ACKs exacerbate the perceived latency on the link. Given that TCP grows its congestion window in units of segments, small MTUs may slow adaptation even further.
TCP发送方根据接收方的反馈调整其带宽使用。LTN的高延迟特性意味着TCP的适应相应地比在延迟较短的网络上慢。类似地，延迟的ack加剧了链路上的感知延迟。考虑到TCP以段为单位增加拥塞窗口，较小的MTU可能会进一步降低自适应速度。
Slow Start and Congestion Avoidance [RFC2581] are essential the Internet's stability. However there are two reasons why the wireless medium adversely affects them:
慢启动和拥塞避免[RFC2581]是互联网稳定性的关键。但是，无线媒体对其产生不利影响的原因有两个：
- Whenever TCP's retransmission timer expires, the sender assumes that the network is congested and invokes slow start. This is why it is important to minimize the losses caused by corruption, leaving only those caused by congestion (as expected by TCP).
- 每当TCP的重传计时器过期时，发送方就会认为网络拥塞并调用慢速启动。这就是为什么必须将腐败造成的损失降至最低，只留下那些由拥塞造成的损失（正如TCP所预期的那样）。
- The sender increases its window based on the number of ACKs received. Their rate of arrival, of course, is dependent on the RTT (round-trip-time) between sender and receiver, which implies long ramp-up times in high latency links like LTNs. The dependency lasts until the pipe is filled.
- 发送方根据收到的ACK数量增加其窗口。当然，它们的到达率取决于发送方和接收方之间的RTT（往返时间），这意味着在像LTN这样的高延迟链路中有很长的爬升时间。依赖关系将持续到管道被填充为止。
- During slow start, the sender increases its window in units of segments. This is why it is important to use an appropriately large MTU which, in turn, requires requires link layers with low loss.
- 在慢速启动期间，发送方以段为单位增加其窗口。这就是为什么使用适当大的MTU非常重要，而MTU反过来又需要低损耗的链路层。
When a TCP sender receives several duplicate ACKs, fast retransmit [RFC2581] allows it to infer that a segment was lost. The sender retransmits what it considers to be this lost segment without waiting for the full timeout, thus saving time.
当TCP发送方收到多个重复的ACK时，快速重传[RFC2581]允许其推断某个段丢失。发送方在不等待完全超时的情况下重新传输它认为丢失的数据段，从而节省时间。
After a fast retransmit, a sender invokes the fast recovery [RFC2581] algorithm. Fast recovery allows the sender to transmit at half its previous rate (regulating the growth of its window based on congestion avoidance), rather than having to begin a slow start. This also saves time.
在快速重传之后，发送方调用快速恢复[RFC2581]算法。快速恢复允许发送方以其先前速率的一半进行传输（根据拥塞避免调整其窗口的增长），而不必缓慢启动。这也节省了时间。
In general, TCP can increase its window beyond the delay-bandwidth product. However, in LTN links the congestion window may remain rather small, less than four segments, for long periods of time due to any of the following reasons:
通常，TCP可以将其窗口增加到延迟带宽乘积之外。然而，在LTN链路中，由于以下任何原因，拥塞窗口可能在很长一段时间内保持相当小，少于四个区段：
1. Typical "file size" to be transferred over a connection is relatively small (Web requests, Web document objects, email messages, files, etc.) In particular, users of LTNs are not very willing to carry out large transfers as the response time is so long.
1. 通过连接传输的典型“文件大小”相对较小（Web请求、Web文档对象、电子邮件、文件等）。特别是，LTN用户不太愿意执行大型传输，因为响应时间太长。
2. If the link has high BER, the congestion window tends to stay small
2. 如果链路具有较高的误码率，拥塞窗口往往保持较小
3. When an LTN is combined with a highly congested wireline Internet path, congestion losses on the Internet have the same effect as 2.
3. 当LTN与高度拥挤的有线互联网路径相结合时，互联网上的拥塞损失与2的影响相同。
4. Commonly, ISPs/operators configure only a small number of buffers (even as few as for 3 packets) per user in their dial-up routers
4. 通常，ISP/运营商在其拨号路由器中仅为每个用户配置少量缓冲区（甚至少至3个数据包）
5. Often small socket buffers are recommended with LTNs in order to prevent the RTO from inflating and to diminish the amount of packets with competing traffic.
5. 通常，LTN建议使用小型套接字缓冲区，以防止RTO膨胀，并减少具有竞争流量的数据包数量。
A small window effectively prevents the sender from taking advantage of Fast Retransmits. Moreover, efficient recovery from multiple losses within a single window requires adoption of new proposals (NewReno [RFC2582]). In addition, on slow paths with no packet reordering waiting for three duplicate ACKs to arrive postpones retransmission unnecessarily.
小窗口有效地防止发送方利用快速重传。此外，在一个窗口内从多个损失中有效恢复需要采用新方案（NewReno[RFC2582]）。此外，在没有分组重新排序的慢路径上，等待三个重复的ack到达会不必要地延迟重传。
Recommendation: Implement Fast Retransmit and Fast Recovery at this time. This is a widely-implemented optimization and is currently at Proposed Standard level. [AGS98] recommends implementation of Fast Retransmit/Fast Recovery in satellite environments. NewReno [RFC2582] apparently does help a sender better handle partial ACKs and multiple losses in a single window, but at this point is not recommended due to its experimental nature. Instead, SACK [RFC2018] is the preferred mechanism.
建议：此时实现快速重传和快速恢复。这是一个广泛实施的优化，目前处于建议的标准水平。[AGS98]建议在卫星环境中实施快速重传/快速恢复。NewReno[RFC2582]显然确实可以帮助发送方在单个窗口中更好地处理部分ACK和多个丢失，但由于其实验性质，目前不推荐使用。相反，SACK[RFC2018]是首选机制。
TCP engages in a "three-way handshake" whenever a new connection is set up. Data transfer is only possible after this phase has completed successfully. T/TCP allows data to be exchanged in parallel with the connection set up, saving valuable time for short transactions on long-latency networks.
每当建立新连接时，TCP都会进行“三方握手”。只有在此阶段成功完成后，才能进行数据传输。T/TCP允许在建立连接的同时并行交换数据，为长延迟网络上的短事务节省了宝贵的时间。
Recommendation: T/TCP is not recommended, for these reasons:
建议：不建议使用T/TCP，原因如下：
- It is an Experimental RFC.
- 这是一个实验性RFC。
- It is not widely deployed, and it has to be deployed at both ends of a connection.
- 它没有广泛部署，必须部署在连接的两端。
- Security concerns have been raised that T/TCP is more vulnerable to address-spoofing attacks than TCP itself.
- 有人提出了安全问题，即T/TCP比TCP本身更容易受到欺骗攻击。
- At least some of the benefits of T/TCP (eliminating three-way handshake on subsequent query-response transactions, for instance) are also available with persistent connections on HTTP/1.1, which is more widely deployed.
- 至少T/TCP的一些好处（例如，消除了后续查询响应事务中的三方握手）也可以通过HTTP/1.1上的持久连接获得，后者的部署更为广泛。
[ADGGHOSSTT98] does not have a recommendation on T/TCP in satellite environments.
[ADGGHOSSTT98]没有关于卫星环境中T/TCP的建议。
Because slow start dominates the network response seen by interactive users at the beginning of a TCP connection, a number of proposals have been made to modify or eliminate slow start in long latency environments.
由于慢启动控制着交互用户在TCP连接开始时看到的网络响应，因此提出了许多建议来修改或消除长延迟环境中的慢启动。
Stability of the Internet is paramount, so these proposals must demonstrate that they will not adversely affect Internet congestion levels in significant ways.
互联网的稳定性至关重要，因此这些提案必须证明它们不会对互联网拥塞水平产生重大不利影响。
Traditional slow start, with an initial window of one segment, is a time-consuming bandwidth adaptation procedure over LTNs. Studies on an initial window larger than one segment [RFC2414, AHO98] resulted in the TCP standard supporting a maximum value of 2 [RFC2581]. Higher values are still experimental in nature.
传统的慢启动（初始窗口为一段）是LTN上耗时的带宽自适应过程。对大于一个段的初始窗口[RFC2414，AHO98]的研究导致TCP标准支持最大值2[RFC2581]。更高的数值在本质上仍然是实验性的。
In simulations with an increased initial window of three packets [RFC2415], this proposal does not contribute significantly to packet drop rates, and it has the added benefit of improving initial response times when the peer device delays acknowledgements during slow start (see next proposal).
在具有增加的三个分组的初始窗口[RFC2415]的模拟中，该方案对分组丢弃率没有显著贡献，并且当对等设备在慢启动期间延迟确认时，其具有改进初始响应时间的额外益处（参见下一个方案）。
[RFC2416] addresses situations where the initial window exceeds the number of buffers available to TCP and indicates that this situation is no different from the case where the congestion window grows beyond the number of buffers available.
[RFC2416]解决初始窗口超过TCP可用缓冲区数量的情况，并指出这种情况与拥塞窗口超过可用缓冲区数量的情况没有区别。
[RFC2581] now allows an initial congestion window of two segments. A larger initial window, perhaps as many as four segments, might be allowed in the future in environments where this significantly improves performance (LFNs and LTNs).
[RFC2581]现在允许两段的初始拥塞窗口。在将来的环境中，可能会允许一个更大的初始窗口（可能多达四个段），这将显著提高性能（LFN和LTN）。
Recommendation: Implement this on devices now. The research on this optimization indicates that 3 segments is a safe initial setting, and is centering on choosing between 2, 3, and 4. For now, use 2 (following RFC2581), which at least allows clients running query-response applications to get an initial ACK from unmodified servers without waiting for a typical delayed ACK timeout of 200 milliseconds, and saves two round-trips. An initial window of 3 [RFC2415] looks promising and may be adopted in the future pending further research and experience.
Recommendation: Implement this on devices now. The research on this optimization indicates that 3 segments is a safe initial setting, and is centering on choosing between 2, 3, and 4. For now, use 2 (following RFC2581), which at least allows clients running query-response applications to get an initial ACK from unmodified servers without waiting for a typical delayed ACK timeout of 200 milliseconds, and saves two round-trips. An initial window of 3 [RFC2415] looks promising and may be adopted in the future pending further research and experience.translate error, please retry
The sender increases its window based on the flow of ACKs coming back from the receiver. Particularly during slow start, this flow is very important. A couple of the proposals that have been studied are (1) ACK counting and (2) ACK-every-segment.
发送方根据从接收方返回的ack流增加其窗口。特别是在缓慢启动期间，此流量非常重要。已研究的两个方案是（1）确认计数和（2）确认每个段。
The main idea behind ACK counting is:
ACK计数背后的主要思想是：
- Make each ACK count to its fullest by growing the window based on the data being acknowledged (byte counting) instead of the number of ACKs (ACK counting). This has been shown to cause bursts which lead to congestion. [Allman98] shows that Limited Byte Counting (LBC), in which the window growth is limited to 2 segments, does not lead to as much burstiness, and offers some performance gains.
- 通过根据正在确认的数据（字节计数）而不是ACK数（ACK计数）增长窗口，使每个ACK计数达到最大值。这已被证明会导致突发事件，从而导致拥塞。[Allman98]表明，有限字节计数（LBC），即窗口增长限制为2个段，不会导致太多的突发性，并提供一些性能增益。
Recommendation: Unlimited byte counting is not recommended. Van Jacobson cautions against byte counting [TCPSATMIN] because it leads to burstiness, and recommends ACK spacing [ACKSPACING] instead.
建议：不建议无限字节计数。Van Jacobson警告不要使用字节计数[TCPSATMIN]，因为它会导致突发性，因此建议使用ACK间隔[ACKSPACTING]。
ACK spacing requires ACKs to consistently pass through a single ACK-spacing router. This requirement works well for W-WAN environments if the ACK-spacing router is also the intermediate node.
ACK间隔要求ACK一致地通过单个ACK间隔路由器。如果ACK间隔路由器也是中间节点，则此要求适用于W-WAN环境。
Limited byte counting warrants further investigation before we can recommend this proposal, but it shows promise.
有限的字节计数保证在我们推荐此方案之前进行进一步的调查，但它显示了希望。
The main idea behind ACK-every-segment is:
每个细分市场背后的主要理念是：
- Keep a constant stream of ACKs coming back by turning off delayed ACKs [RFC1122] during slow start. ACK-every-segment must be limited to slow start, in order to avoid penalizing asymmetric-bandwidth configurations. For instance, a low bandwidth link carrying acknowledgements back to the sender, hinders the growth of the congestion window, even if the link toward the client has a greater bandwidth [BPK99].
- 通过在慢速启动期间关闭延迟ACK[RFC1122]，保持返回的ACK流恒定。ACK每个段必须限制为慢速启动，以避免惩罚不对称带宽配置。例如，将确认信息带回发送方的低带宽链路会阻碍拥塞窗口的增长，即使通向客户端的链路具有更大的带宽[BPK99]。
Even though simulations confirm its promise (it allows receivers to receive the second segment from unmodified senders without waiting for a typical delayed ACK timeout of 200 milliseconds), for this technique to be practical the receiver must acknowledge every segment only when the sender is in slow start. Continuing to do so when the sender is in congestion avoidance may have adverse effects on the mobile device's battery consumption and on traffic in the network.
即使模拟证实了其承诺（它允许接收器从未经修改的发送器接收第二段，而无需等待典型的延迟确认超时200毫秒），为了使该技术实用，接收器必须仅在发送器处于慢速启动时才确认每个段。当发送方处于拥塞避免状态时继续这样做可能对移动设备的电池消耗和网络中的流量产生不利影响。
This violates a SHOULD in [RFC2581]: delayed acknowledgements SHOULD be used by a TCP receiver.
这违反了[RFC2581]中的应：TCP接收器应使用延迟确认。
"Disabling Delayed ACKs During Slow Start" is technically unimplementable, as the receiver has no way of knowing when the sender crosses ssthresh (the "slow start threshold") and begins using the congestion avoidance algorithm. If receivers follow recommendations for increased initial windows, disabling delayed ACKs during an increased initial window would open the TCP window more rapidly without doubling ACK traffic in general. However, this scheme might double ACK traffic if most connections remain in slow-start.
“在慢启动期间禁用延迟ACK”在技术上是不可实现的，因为接收方无法知道发送方何时越过ssthresh（“慢启动阈值”）并开始使用拥塞避免算法。如果接收器遵循增加初始窗口的建议，则在增加初始窗口期间禁用延迟ACK将更快地打开TCP窗口，而通常不会使ACK流量加倍。但是，如果大多数连接保持慢速启动，此方案可能会使ACK流量加倍。
Recommendation: ACK only the first segment on a new connection with no delay.
建议：只确认新连接上的第一段，无延迟。
New mechanisms [ADGGHOSSTT98] are being proposed to improve TCP's adaptive properties such that the available bandwidth is better utilized while reducing the possibility of congesting the network. This results in the closing of the congestion window to 1 segment (which precludes fast retransmit), and the subsequent slow start phase.
正在提出新的机制[ADGGHOSSTT98]来改进TCP的自适应特性，以便更好地利用可用带宽，同时降低网络拥塞的可能性。这将导致阻塞窗口关闭到1段（这将阻止快速重传），并导致随后的慢速启动阶段。
Theoretically, an optimum value for slow-start threshold (ssthresh) allows connection bandwidth utilization to ramp up as aggressively as possible without "overshoot" (using so much bandwidth that packets are lost and congestion avoidance procedures are invoked).
从理论上讲，慢启动阈值（ssthresh）的最佳值允许连接带宽利用率在没有“超调”（使用如此多的带宽导致数据包丢失并调用拥塞避免程序）的情况下尽可能积极地增加。
Recommendation: Estimating the slow start threshold is not recommended. Although this would be helpful if we knew how to do it, rough consensus on the tcp-impl and tcp-sat mailing lists is that in non-trivial operational networks there is no reliable method to probe during TCP startup and estimate the bandwidth available.
建议：不建议估计慢启动阈值。虽然如果我们知道如何做，这将是有帮助的，但关于tcp impl和tcp sat邮件列表的大致共识是，在非平凡的操作网络中，没有可靠的方法在tcp启动期间进行探测并估计可用带宽。
Mitigations that inject additional ACKs (whether "ACK-first-segment" or "ACK-every-segment-during-slow-start") beyond what today's conformant TCPs inject are only applicable during the slow-start phases of a connection. After an initial exchange, the connection usually completes slow-start, so TCPs only inject additional ACKs when (1) the connection is closed, and a new connection is opened, or (2) the TCPs handle idle connection restart correctly by performing slow start.
注入额外ACK（无论是“ACK第一段”还是“慢启动期间的ACK每个段”）的缓解措施超出了当前一致性TCP注入的范围，仅适用于连接的慢启动阶段。初始交换后，连接通常完成慢启动，因此TCP仅在以下情况下注入额外的ACK：（1）连接关闭，新连接打开，或（2）TCP通过执行慢启动正确处理空闲连接重启。
Item (1) is typical when using HTTP/1.0, in which each request-response transaction requires a new connection. Persistent connections in HTTP/1.1 help in maintaining a connection in congestion avoidance instead of constantly reverting to slow-start. Because of this, these optimizations which are only enabled during slow-start do not get as much of a chance to act. Item (2), of course, is independent of HTTP version.
第（1）项是使用HTTP/1.0时的典型情况，其中每个请求-响应事务都需要一个新连接。HTTP/1.1中的持久连接有助于在避免拥塞的情况下维护连接，而不是经常恢复到慢速启动。因此，这些仅在慢速启动期间启用的优化不会有太多机会采取行动。当然，第（2）项独立于HTTP版本。
During slow start, the sender responds to the incoming ACK stream by transmitting N+1 segments for each ACK, where N is the number of new segments acknowledged by the incoming ACK. This results in data being sent at twice the speed at which it can be processed by the network. Accordingly, queues will form, and due to insufficient buffering at the bottleneck router, packets may get dropped before the link's capacity is full.
在慢启动期间，发送方通过为每个ACK发送N+1个段来响应传入ACK流，其中N是由传入ACK确认的新段的数目。这导致数据的发送速度是网络处理速度的两倍。因此，将形成队列，并且由于瓶颈路由器的缓冲不足，数据包可能在链路容量满之前被丢弃。
Spacing out the ACKs effectively controls the rate at which the sender will transmit into the network, and may result in little or no queueing at the bottleneck router [ACKSPACING]. Furthermore, ack spacing reduces the size of the bursts.
间隔ACK有效地控制了发送方将传输到网络的速率，并且可能导致瓶颈路由器很少或没有排队[ACKSPACTING]。此外，ack间隔减小了突发的大小。
Recommendation: No recommendation at this time. Continue monitoring research in this area.
建议：目前没有建议。继续监测这方面的研究。
As was mentioned above, link-layer retransmissions may decrease the BER enough that congestion accounts for most of packet losses; still, nothing can be done about interruptions due to handoffs, moving beyond wireless coverage, etc. In this scenario, it is imperative to prevent interaction between link-layer retransmission and TCP retransmission as these layers duplicate each other's efforts. In such an environment it may make sense to delay TCP's efforts so as to give the link-layer a chance to recover. With this in mind, the Delayed Dupacks [MV97, Vaidya99] scheme selectively delays duplicate acknowledgements at the receiver. It is preferable to allow a local mechanism to resolve a local problem, instead of invoking TCP's end-to-end mechanism and incurring the associated costs, both in terms of wasted bandwidth and in terms of its effect on TCP's window behavior.
如上所述，链路层重传可以充分降低误码率，使得拥塞占大部分分组丢失；但是，对于由于切换、移动到无线覆盖范围以外等造成的中断，我们无能为力。在这种情况下，必须防止链路层重传和TCP重传之间的交互，因为这些层相互重复。在这样的环境中，延迟TCP的工作以便给链路层一个恢复的机会是有意义的。考虑到这一点，延迟的重复确认[MV97，Vaidya99]方案选择性地延迟接收器处的重复确认。最好允许本地机制解决本地问题，而不是调用TCP的端到端机制并产生相关成本，包括浪费的带宽及其对TCP窗口行为的影响。
The Delayed Dupacks scheme can be used despite IP encryption since the intermediate node does not need to examine the TCP headers.
由于中间节点不需要检查TCP报头，因此即使进行IP加密，也可以使用延迟Dupacks方案。
Currently, it is not well understood how long the receiver should delay the duplicate acknowledgments. In particular, the impact of wireless medium access control (MAC) protocol on the choice of delay parameter needs to be studied. The MAC protocol may affect the ability to choose the appropriate delay (either statically or dynamically). In general, significant variabilities in link-level retransmission times can have an adverse impact on the performance of the Delayed Dupacks scheme. Furthermore, as discussed later in section 4.10.3, Delayed Dupacks and some other schemes (such as Snoop [SNOOP]) are only beneficial in certain types of network links.
目前，还不清楚接收器应将重复确认延迟多长时间。特别是，需要研究无线媒体访问控制（MAC）协议对延迟参数选择的影响。MAC协议可能影响选择适当延迟的能力（静态或动态）。通常，链路级重传时间的显著变化会对延迟的Dupacks方案的性能产生不利影响。此外，如下文第4.10.3节所述，延迟dupack和一些其他方案（如Snoop[Snoop]）仅在某些类型的网络链路中有益。
Recommendation: Delaying duplicate acknowledgements may be useful in specific network topologies, but a general recommendation requires further research and experience.
建议：延迟重复确认可能在特定网络拓扑中有用，但一般建议需要进一步研究和经验。
SACK may not be useful in many LTNs, according to Section 1.1 of [TCPHP]. In particular, SACK is more useful in the LFN regime, especially if large windows are being used, because there is a
根据[TCPHP]的第1.1节，SACK在许多LTN中可能没有用处。特别是，SACK在LFN模式中更有用，尤其是在使用大窗口时，因为存在
considerable probability of multiple segment losses per window. In the LTN regime, TCP windows are much smaller, and burst errors must be much longer in duration in order to damage multiple segments.
每个窗口出现多段损失的可能性相当大。在LTN体制中，TCP窗口小得多，突发错误的持续时间必须长得多，才能损坏多个段。
Accordingly, the complexity of SACK may not be justifiable, unless there is a high probability of burst errors and congestion on the wireless link. A desire for compatibility with TCP recommendations for non-LTN environments may dictate LTN support for SACK anyway.
因此，SACK的复杂性可能是不合理的，除非在无线链路上存在突发错误和拥塞的高概率。为了与非LTN环境的TCP建议兼容，可能需要对SACK提供LTN支持。
[AGS98] recommends use of SACK with Large TCP Windows in satellite environments, and notes that this implies support for PAWS (Protection Against Wrapped Sequence space) and RTTM (Round Trip Time Measurement) as well.
[AGS98]建议在卫星环境中使用带有大TCP窗口的SACK，并注意到这意味着支持PAWS（针对包裹序列空间的保护）和RTTM（往返时间测量）。
Berkeley's SNOOP protocol research [SNOOP] indicates that SACK does improve throughput for SNOOP when multiple segments are lost per window [BPSK96]. SACK allows SNOOP to recover from multi-segment losses in one round-trip. In this case, the mobile device needs to implement some form of selective acknowledgements. If SACK is not used, TCP may enter congestion avoidance as the time needed to retransmit the lost segments may be greater than the retransmission timer.
Berkeley的SNOOP协议研究[SNOOP]表明，当每个窗口有多个段丢失时，SACK确实提高了SNOOP的吞吐量[BPSK96]。SACK允许SNOOP在一次往返中从多段损失中恢复。在这种情况下，移动设备需要实现某种形式的选择性确认。如果不使用SACK，TCP可能会进入拥塞避免，因为重新传输丢失的段所需的时间可能大于重新传输计时器。
Recommendation: Implement SACK now for compatibility with other TCPs and improved performance with SNOOP.
建议：立即实施SACK，以便与其他TCP兼容，并通过SNOOP提高性能。
In the absence of explicit notification from the network, some researchers have suggested statistical methods for congestion avoidance [Jain89, WC91, VEGAS]. A natural extension of these heuristics would enable a sender to distinguish between losses caused by congestion and other causes. The research results on the reliability of sender-based heuristics is unfavorable [BV97, BV98]. [BV98a] reports better results in constrained environments using packet inter-arrival times measured at the receiver, but highly-variable delay - of the type encountered in wireless environments during intercell handoff - confounds these heuristics.
在网络没有明确通知的情况下，一些研究人员提出了避免拥塞的统计方法[Jain89，WC91，VEGAS]。这些启发式算法的自然扩展将使发送者能够区分拥塞和其他原因造成的损失。关于基于发送方的启发式算法可靠性的研究结果是不利的[BV97，BV98]。[BV98a]报告在受限环境中使用在接收器处测量的数据包到达时间获得更好的结果，但高度可变的延迟（在小区间切换期间无线环境中遇到的类型）混淆了这些启发式方法。
Recommendation: No recommendation at this time - continue to monitor research results.
建议：目前没有建议-继续监测研究结果。
With explicit notification from the network it is possible to determine when a loss is due to congestion. Several proposals along these lines include:
有了来自网络的明确通知，就可以确定何时由于拥塞而导致丢失。这方面的几项建议包括：
- Explicit Loss Notification (ELN) [BPSK96]
- 明确损失通知（ELN）[BPSK96]
- Explicit Bad State Notification (EBSN) [BBKVP96]
- 显式错误状态通知（EBSN）[BBKVP96]
- Explicit Loss Notification to the Receiver (ELNR), and Explicit Delayed Dupack Activation Notification (EDDAN) (notifications to mobile receiver) [MV97]
- 向接收方发出的显式丢失通知（ELNR）和显式延迟重复包激活通知（EDDAN）（向移动接收方发出的通知）[MV97]
- Explicit Congestion Notification (ECN) [ECN]
- 显式拥塞通知（ECN）[ECN]
Of these proposals, Explicit Congestion Notification (ECN) seems closest to deployment on the Internet, and will provide some benefit for TCP connections on long thin networks (as well as for all other TCP connections).
在这些建议中，显式拥塞通知（ECN）似乎最接近于在Internet上部署，并将为长瘦网络上的TCP连接（以及所有其他TCP连接）提供一些好处。
Recommendation: No recommendation at this time. Schemes like ELNR and EDDAN [MV97], in which the only systems that need to be modified are the intermediate node and the mobile device, are slated for adoption pending further research. However, this solution has some limitations. Since the intermediate node must have access to the TCP headers, the IP payload must not be encrypted.
建议：目前没有建议。像ELNR和EDDAN[MV97]这样的方案，其中唯一需要修改的系统是中间节点和移动设备，计划在进一步研究之前采用。然而，这种解决方案有一些局限性。由于中间节点必须能够访问TCP报头，因此IP有效负载不得加密。
ECN uses the TOS byte in the IP header to carry congestion information (ECN-capable and Congestion-encountered). This byte is not encrypted in IPSEC, so ECN can be used on TCP connections that are encrypted using IPSEC.
ECN使用IP报头中的TOS字节携带拥塞信息（支持ECN和遇到拥塞）。此字节在IPSEC中未加密，因此可以在使用IPSEC加密的TCP连接上使用ECN。
Recommendation: Implement ECN. In spite of this, mechanisms for explicit corruption notification are still relevant and should be tracked.
建议：实施ECN。尽管如此，明确的腐败通报机制仍然是相关的，应当予以跟踪。
Note: ECN provides useful information to avoid deteriorating further a bad situation, but has some limitations for wireless applications. Absence of packets marked with ECN should not be interpreted by ECN-capable TCP connections as a green light for aggressive retransmissions. On the contrary, during periods of extreme network congestion routers may drop packets marked with explicit notification because their buffers are exhausted - exactly the wrong time for a host to begin retransmitting aggressively.
注意：ECN提供了有用的信息，以避免进一步恶化糟糕的情况，但对无线应用有一些限制。支持ECN的TCP连接不应将没有标记为ECN的数据包解释为主动重传的绿灯。相反，在极端网络拥塞期间，路由器可能会丢弃标记有显式通知的数据包，因为它们的缓冲区已耗尽——这正是主机开始主动重新传输的错误时间。
As has been pointed out above, TCP responds to congestion by closing down the window and invoking slow start. Long-delay networks take a particularly long time to recover from this condition. Accordingly, it is imperative to avoid congestion in LTNs. To remedy this, active queue management techniques have been proposed as enhancements to routers throughout the Internet [RED]. The primary motivation for deployment of these mechanisms is to prevent "congestion collapse" (a severe degradation in service) by controlling the average queue size at the routers. As the average queue length grows, Random Early Detection [RED] increases the possibility of dropping packets.
如上所述，TCP通过关闭窗口并调用慢启动来响应拥塞。长延迟网络需要特别长的时间才能从这种情况中恢复。因此，必须避免LTN中的拥塞。为了解决这个问题，主动队列管理技术被提议作为对整个互联网路由器的增强[RED]。部署这些机制的主要动机是通过控制路由器上的平均队列大小来防止“拥塞崩溃”（严重的服务降级）。随着平均队列长度的增长，随机早期检测[RED]增加了丢弃数据包的可能性。
The benefits are:
好处是：
- Reduce packet drops in routers. By dropping a few packets before severe congestion sets in, RED avoids dropping bursts of packets. In other words, the objective is to drop m packets early to prevent n drops later on, where m is less than n.
- 减少路由器中的数据包丢失。通过在严重拥塞出现之前丢弃几个数据包，RED可以避免丢弃突发数据包。换句话说，目标是尽早丢弃m个数据包，以防止随后n次丢弃，其中m小于n。
- Provide lower delays. This follows from the smaller queue sizes, and is particularly important for interactive applications, for which the inherent delays of wireless links already push the user experience to the limits of the non-acceptable.
- 提供更低的延迟。这源于较小的队列大小，对于交互式应用尤其重要，因为无线链路的固有延迟已经将用户体验推到了不可接受的极限。
- Avoid lock-outs. Lack of resources in a router (and the resultant packet drops) may, in effect, obliterate throughput on certain connections. Because of active queue management, it is more probable for an incoming packet to find available buffer space at the router.
- 避免上锁。路由器中资源的缺乏（以及由此产生的丢包）实际上可能会消除某些连接上的吞吐量。由于主动队列管理，传入数据包更有可能在路由器上找到可用的缓冲区空间。
Active Queue Management has two components: (1) routers detect congestion before exhausting their resources, and (2) they provide some form of congestion indication. Dropping packets via RED is only one example of the latter. Another way to indicate congestion is to use ECN [ECN] as discussed above under "Detecting Corruption Loss: With Explicit Notifications."
主动队列管理有两个组成部分：（1）路由器在耗尽资源之前检测拥塞，（2）它们提供某种形式的拥塞指示。通过RED丢弃数据包只是后者的一个例子。指示拥塞的另一种方法是使用ECN[ECN]，如上文“检测损坏丢失：使用显式通知”中所述
Recommendation: RED is currently being deployed in the Internet, and LTNs should follow suit. ECN deployment should complement RED's.
建议：RED目前正在互联网上部署，LTN也应效仿。ECN部署应补充RED。
Active queue management helps control the length of the queues. Additionally, a general solution requires replacing FIFO with other scheduling algorithms that improve:
活动队列管理有助于控制队列的长度。此外，一般解决方案要求用其他调度算法取代FIFO，以改进：
1. Fairness (by policing how different packet streams utilize the available bandwidth), and
1. 公平性（通过监控不同的数据包流如何利用可用带宽），以及
2. Throughput (by improving the transmitter's radio channel utilization).
2. 吞吐量（通过提高发射机的无线信道利用率）。
For example, fairness is necessary for interactive applications (like telnet or web browsing) to coexist with bulk transfer sessions. Proposals here include:
例如，要使交互式应用程序（如telnet或web浏览）与批量传输会话共存，公平性是必要的。这里的建议包括：
- Fair Queueing (FQ) [Demers90]
- 公平排队（FQ）[Demers90]
- Class-based Queueing (CBQ) [Floyd95]
- 基于类的排队（CBQ）[Floyd95]
Even if they are only implemented over the wireless link portion of the communication path, these proposals are attractive in wireless LTN environments, because new connections for interactive applications can have difficulty starting when a bulk TCP transfer has already stabilized using all available bandwidth.
即使它们仅在通信路径的无线链路部分上实现，这些方案在无线LTN环境中也是有吸引力的，因为当使用所有可用带宽的批量TCP传输已经稳定时，交互式应用程序的新连接可能难以启动。
In our base architecture described above, the mobile device typically communicates directly with only one wireless peer at a given time: the intermediate node. In some W-WANs, it is possible to directly address other mobiles within the same cell. Direct communication with each such wireless peer may traverse a spatially distinct path, each of which may exhibit statistically independent radio link characteristics. Channel State Dependent Packet Scheduling (CSDP) [BBKT96] tracks the state of the various radio links (as defined by the target devices), and gives preferential treatment to packets destined for radio links in a "good" state. This avoids attempting to transmit to (and expect acknowledgements from) a peer on a "bad" radio link, thus improving throughput.
在上述基本架构中，移动设备通常在给定时间仅与一个无线对等方直接通信：中间节点。在某些W-WAN中，可以直接寻址同一小区内的其他手机。与每个这样的无线对等方的直接通信可以穿越空间上不同的路径，其中每个路径可以表现出统计上独立的无线链路特性。信道状态相关分组调度（CSDP）[BBKT96]跟踪各种无线链路（由目标设备定义）的状态，并在“良好”状态下优先处理发送给无线链路的分组。这避免了试图向“坏”无线链路上的对等方发送（并期望收到确认），从而提高吞吐量。
A further refinement of this idea suggests that both fairness and throughput can be improved by combining a wireless-enhanced CBQ with CSDP [FSS98].
这一思想的进一步完善表明，通过将无线增强CBQ与CSDP相结合，可以提高公平性和吞吐量[FSS98]。
Recommendation: No recommendation at this time, pending further study.
建议：目前没有建议，有待进一步研究。
Given the dramatic differences between the wired and the wireless links, a very common approach is to provide some impedance matching where the two different technologies meet: at the intermediate node.
考虑到有线和无线链路之间的巨大差异，一种非常常见的方法是在两种不同技术相遇的地方提供一些阻抗匹配：在中间节点。
The idea is to replace an end-to-end TCP connection with two clearly distinct connections: one across the wireless link, the other across its wireline counterpart. Each of the two resulting TCP sessions operates under very different networking characteristics, and may adopt the policies best suited to its particular medium. For example, in a specific LTN topology it may be desirable to modify TCP Fast Retransmit to resend after the first duplicate ack and Fast Recovery to not shrink the congestion window if the LTN link has an extremely long RTT, is known to not reorder packets, and is not subject to congestion. Moreover, on a long-delay link or on a link with a relatively high bandwidth-delay product it may be desirable to "slow-start" with a relatively large initial window, even larger than four segments. While these kinds of TCP modifications can be negotiated to be employed over the LTN link, they would not be deployed end-to-end over the global Internet. In LTN topologies where the underlying link characteristics are known, a various similar types of performance enhancements can be employed without endangering operations over the global Internet.
这个想法是用两个明显不同的连接取代端到端的TCP连接：一个通过无线链路，另一个通过其有线对应物。由此产生的两个TCP会话中的每一个都在非常不同的网络特性下运行，并且可能采用最适合其特定介质的策略。例如，在特定LTN拓扑中，如果LTN链路具有非常长的RTT、已知不重新排序分组并且不受拥塞影响，则可能希望修改TCP快速重传以在第一次重复ack和快速恢复之后重新发送，以不收缩拥塞窗口。此外，在长延迟链路上或在具有相对高带宽延迟乘积的链路上，可能希望使用相对大的初始窗口（甚至大于四个段）来“慢启动”。虽然这些类型的TCP修改可以通过协商在LTN链路上使用，但它们不会在全球互联网上端到端部署。在已知基本链路特性的LTN拓扑中，可以采用各种类似类型的性能增强，而不会危及全球互联网上的操作。
In some proposals, in addition to a PEP mechanism at the intermediate node, custom protocols are used on the wireless link (for example, [WAP], [YB94] or [MOWGLI]).
在一些方案中，除了中间节点的PEP机制外，在无线链路上使用自定义协议（例如，[WAP]、[YB94]或[MOWGLI]）。
Even if the gains from using non-TCP protocols are moderate or better, the wealth of research on optimizing TCP for wireless, and compatibility with the Internet are compelling reasons to adopt TCP on the wireless link (enhanced as suggested in section 5 below).
即使使用非TCP协议的收益是中等或更好的，但关于优化无线TCP的大量研究以及与Internet的兼容性都是在无线链路上采用TCP的有力理由（如下文第5节所述增强）。
Split-TCP proposals include schemes like I-TCP [ITCP] and MTCP [YB94] which achieve performance improvements by abandoning end-to-end semantics.
拆分TCP方案包括I-TCP[ITCP]和MTCP[YB94]等方案，它们通过放弃端到端语义来实现性能改进。
The Mowgli architecture [MOWGLI] proposes a split approach with support for various enhancements at all the protocol layers, not only at the transport layer. Mowgli provides an option to replace the TCP/IP core protocols on the LTN link with a custom protocol that is tuned for LTN links [KRLKA97]. In addition, the protocol provides various features that are useful with LTNs. For example, it provides priority-based multiplexing of concurrent connections together with shared flow control, thus offering link capacity to interactive applications in a timely manner even if there are bandwidth-intensive background transfers. Also with this option, Mowgli preserves the socket semantics on the mobile device so that legacy applications can be run unmodified.
Mowgli体系结构[Mowgli]提出了一种拆分方法，支持所有协议层（而不仅仅是传输层）的各种增强。Mowgli提供了一个选项，用为LTN链路调优的自定义协议替换LTN链路上的TCP/IP核心协议[KRLKA97]。此外，该协议还提供了对LTN有用的各种功能。例如，它提供了基于优先级的并发连接多路复用和共享流控制，因此即使存在带宽密集型后台传输，也能及时为交互式应用程序提供链路容量。同样使用此选项，Mowgli保留移动设备上的套接字语义，以便可以不经修改地运行遗留应用程序。
Employing split TCP approaches have several benefits as well as drawbacks. Benefits related to split TCP approaches include the following:
采用分离TCP方法有几个优点和缺点。与拆分TCP方法相关的好处包括：
- Splitting the end-to-end TCP connection into two parts is a straightforward way to shield the problems of the wireless link from the wireline Internet path, and vice versa. Thus, a split TCP approach enables applying local solutions to the local problems on the wireless link. For example, it automatically solves the problem of distinguishing congestion related packet losses on the wireline Internet and packet losses due to transmission error on the wireless link as these occur on separate TCP connections. Even if both segments experience congestion, it may be of a different nature and may be treated as such. Moreover, temporary disconnections of the wireless link can be effectively shielded from the wireline Internet.
- 将端到端TCP连接分为两部分是一种简单的方法，可以将无线链路的问题与有线互联网路径隔离开来，反之亦然。因此，拆分TCP方法能够将本地解决方案应用于无线链路上的本地问题。例如，它自动解决了区分有线互联网上与拥塞相关的数据包丢失和由于无线链路上的传输错误而导致的数据包丢失的问题，因为这些数据包丢失发生在单独的TCP连接上。即使两个路段都出现拥堵，其性质也可能不同，因此可能会被视为拥堵。此外，无线链路的临时断开可以有效地屏蔽有线互联网。
- When one of the TCP connections crosses only a single hop wireless link or a very limited number of hops, some or all link characteristics for the wireless TCP path are known. For example, with a particular link we may know that the link provides reliable delivery of packets, packets are not delivered out of order, or the link is not subject to congestion. Having this information for the TCP path one could expect that defining the TCP mitigations to be employed becomes a significantly easier task. In addition, several mitigations that cannot be employed safely over the global Internet, can be successfully employed over the wireless link.
- 当其中一个TCP连接仅跨越一个单跳无线链路或非常有限的跳数时，无线TCP路径的部分或全部链路特征是已知的。例如，对于一个特定的链路，我们可能知道该链路提供了可靠的数据包交付，数据包不会无序交付，或者该链路不会出现拥塞。将此信息用于TCP路径可以预期，定义要采用的TCP缓解措施将变得非常容易。此外，一些无法在全球互联网上安全使用的缓解措施可以在无线链路上成功使用。
- Splitting one TCP connection into two separate ones allows much earlier deployment of various recent proposals to improve TCP performance over wireless links; only the TCP implementations of the mobile device and intermediate node need to be modified, thus allowing the vast number of Internet hosts to continue running the legacy TCP implementations unmodified. Any mitigations that would require modification of TCP in these wireline hosts may take far too long to become widely deployed.
- 将一个TCP连接拆分为两个独立的连接，可以更早地部署各种最新建议，以提高无线链路上的TCP性能；只需修改移动设备和中间节点的TCP实现，从而允许大量Internet主机继续运行未经修改的传统TCP实现。任何需要在这些有线主机中修改TCP的缓解措施都可能需要很长时间才能得到广泛部署。
- Allows exploitation of various application level enhancements which may give significant performance gains (see section 4.10.2).
- 允许利用各种应用程序级增强功能，这可能会显著提高性能（请参阅第4.10.2节）。
Drawbacks related to split TCP approaches include the following:
与拆分TCP方法相关的缺点包括：
- One of the main criticisms against the split TCP approaches is that it breaks TCP end-to-end semantics. This has various drawbacks some of which are more severe than others. The most detrimental drawback is probably that splitting the TCP connection disables end-to-end usage of IP layer security mechanisms, precluding the application of IPSec to achieve end-to-end
- 对拆分TCP方法的主要批评之一是它破坏了TCP端到端语义。这有各种各样的缺点，其中一些比其他的更严重。最有害的缺点可能是，拆分TCP连接会禁用IP层安全机制的端到端使用，从而阻止应用IPSec来实现端到端安全
security. Still, IPSec could be employed separately in each of the two parts, thus requiring the intermediate node to become a party to the security association between the mobile device and the remote host. This, however, is an undesirable or unacceptable alternative in most cases. Other security mechanisms above the transport layer, like TLS [RFC2246] or SOCKS [RFC1928], should be employed for end-to-end security.
安全然而，IPSec可以在这两部分中的每一部分中单独使用，因此要求中间节点成为移动设备和远程主机之间的安全关联的一方。然而，在大多数情况下，这是一种不可取或不可接受的选择。传输层之上的其他安全机制，如TLS[RFC2246]或SOCKS[RFC1928]，应用于端到端安全。
- Another drawback of breaking end-to-end semantics is that crashes of the intermediate node become unrecoverable resulting in termination of the TCP connections. Whether this should be considered a severe problem depends on the expected frequency of such crashes.
- 破坏端到端语义的另一个缺点是中间节点的崩溃变得不可恢复，从而导致TCP连接的终止。这是否应被视为严重问题取决于此类碰撞的预期频率。
- In many occasions claims have been stated that if TCP end-to-end semantics is broken, applications relying on TCP to provide reliable data delivery become more vulnerable. This, however, is an overstatement as a well-designed application should never fully rely on TCP in achieving end-to-end reliability at the application level. First, current APIs to TCP, such as the Berkeley socket interface, do not allow applications to know when an TCP acknowledgement for previously sent user data arrives at TCP sender. Second, even if the application is informed of the TCP acknowledgements, the sending application cannot know whether the receiving application has received the data: it only knows that the data reached the TCP receive buffer at the receiving end. Finally, in order to achieve end-to-end reliability at the application level an application level acknowledgement is required to confirm that the receiver has taken the appropriate actions on the data it received.
- 在许多情况下，有人声称，如果TCP端到端语义被破坏，依赖TCP提供可靠数据传输的应用程序将变得更加脆弱。然而，这是夸大其词，因为设计良好的应用程序永远不应该完全依赖TCP来实现应用程序级别的端到端可靠性。首先，当前的TCP API（如Berkeley套接字接口）不允许应用程序知道TCP发送方何时收到以前发送的用户数据的TCP确认。其次，即使应用程序被告知TCP确认，发送应用程序也无法知道接收应用程序是否已收到数据：它只知道数据已到达接收端的TCP接收缓冲区。最后，为了在应用级实现端到端可靠性，需要应用级确认，以确认接收器已对其接收的数据采取了适当的措施。
- When a mobile device moves, it is subject to handovers by the serving base station. If the base station acts as the intermediate node for the split TCP connection, the state of both TCP endpoints on the previous intermediate node must be transferred to the new intermediate node to ensure continued operation over the split TCP connection. This requires extra work and causes overhead. However, in most of the W-WAN wireless networks, unlike in W-LANs, the W-WAN base station does not provide the mobile device with the connection point to the wireline Internet (such base stations may not even have an IP stack). Instead, the W-WAN network takes care of the mobility and retains the connection point to the wireline Internet unchanged while the mobile device moves. Thus, TCP state handover is not required in most W-WANs.
- 当移动设备移动时，服务基站进行切换。如果基站充当拆分TCP连接的中间节点，则必须将前一个中间节点上的两个TCP端点的状态传输到新的中间节点，以确保在拆分TCP连接上继续运行。这需要额外的工作并导致开销。然而，在大多数W-WAN无线网络中，与W-lan不同，W-WAN基站不向移动设备提供到有线因特网的连接点（此类基站甚至可能没有IP堆栈）。相反，W-WAN网络负责移动性，并在移动设备移动时保持到有线因特网的连接点不变。因此，在大多数W-WAN中不需要TCP状态切换。
- The packets traversing through all the protocol layers up to transport layer and again down to the link layer result in extra overhead at the intermediate node. In case of LTNs with low
- 数据包穿过所有协议层，上至传输层，再下至链路层，会在中间节点产生额外的开销。如果LTN具有较低的
bandwidth, this extra overhead does not cause serious additional performance problems unlike with W-LANs that typically have much higher bandwidth.
带宽，这种额外的开销不会导致严重的额外性能问题，这与通常具有更高带宽的W-LAN不同。
- Split TCP proposals are not applicable to networks with asymmetric routing. Deploying a split TCP approach requires that traffic to and from the mobile device be routed through the intermediate node. With some networks, this cannot be accomplished, or it requires that the intermediate node is located several hops away from the wireless network edge which in turn is unpractical in many cases and may result in non-optimal routing.
- 拆分TCP方案不适用于具有非对称路由的网络。部署拆分TCP方法需要通过中间节点路由进出移动设备的流量。对于某些网络，这是无法实现的，或者它要求中间节点距离无线网络边缘几跳，这在许多情况下是不实际的，并且可能导致非最优路由。
- Split TCP, as the name implies, does not address problems related to UDP.
- 顾名思义，拆分TCP不能解决与UDP相关的问题。
It should noted that using split TCP does not necessarily exclude simultaneous usage of IP for end-to-end connectivity. Correct usage of split TCP should be managed per application or per connection and should be under the end-user control so that the user can decide whether a particular TCP connection or application makes use of split TCP or whether it operates end-to-end directly over IP.
应该注意的是，使用拆分TCP并不一定排除同时使用IP进行端到端连接。拆分TCP的正确使用应按照每个应用程序或每个连接进行管理，并且应在最终用户的控制下，以便用户可以决定特定TCP连接或应用程序是否使用拆分TCP，或者它是否直接通过IP端到端运行。
Recommendation: Split TCP proposals that alter TCP semantics are not recommended. Deploying custom protocols on the wireless link, such as MOWGLI proposes is not recommended, because this note gives preference to (1) improving TCP instead of designing a custom protocol and (2) allowing end-to-end sessions at all times.
建议：不建议使用改变TCP语义的拆分TCP方案。不建议在无线链路上部署自定义协议，如MOWGLI建议的，因为本说明优先考虑（1）改进TCP而不是设计自定义协议，（2）始终允许端到端会话。
Nowadays, application level proxies are widely used in the Internet. Such proxies include Web proxy caches, relay MTAs (Mail Transfer Agents), and secure transport proxies (e.g., SOCKS). In effect, employing an application level proxy results in a "split TCP connection" with the proxy as the intermediary. Hence, some of the problems present with wireless links, such as combining of a congested wide-area Internet path with a wireless LTN link, are automatically alleviated to some extent.
目前，应用级代理在互联网上得到了广泛的应用。此类代理包括Web代理缓存、中继MTA（邮件传输代理）和安全传输代理（例如SOCKS）。实际上，使用应用程序级代理会导致以代理作为中介的“拆分TCP连接”。因此，无线链路存在的一些问题，例如拥塞的广域因特网路径与无线LTN链路的组合，在某种程度上被自动缓解。
The application protocols often employ plenty of (unnecessary) round trips, lots of headers and inefficient encoding. Even unnecessary data may get delivered over the wireless link in regular application protocol operation. In many cases a significant amount of this overhead can be reduced by simply running an application level proxy on the intermediate node. With LTN links, significant additional improvement can be achieved by introducing application level proxies with application-specific enhancements. Such a proxy may employ an enhanced version of the application protocol over the wireless link.
应用程序协议通常使用大量（不必要的）往返、大量的报头和低效的编码。在常规应用程序协议操作中，甚至不必要的数据也可能通过无线链路传输。在许多情况下，只需在中间节点上运行应用程序级代理，就可以大大减少这种开销。使用LTN链接，通过引入具有特定于应用程序的增强功能的应用程序级代理，可以实现显著的额外改进。这样的代理可以在无线链路上采用应用协议的增强版本。
In an LTN environment enhancements at the application layer may provide much more notable performance improvements than any transport level enhancements.
在LTN环境中，应用层的增强可能比任何传输级别的增强提供更显著的性能改进。
The Mowgli system provides full support for adding application level agent-proxy pairs between the client and the server, the agent on the mobile device and the proxy on the intermediate node. Such a pair may be either explicit or fully transparent to the applications, but it is, at all times, under the end-user control. Good examples of enhancements achieved with application-specific proxies include Mowgli WWW [LAKLR95], [LHKR96] and WebExpress [HL96], [CTCSM97].
Mowgli系统完全支持在客户端和服务器、移动设备上的代理和中间节点上的代理之间添加应用程序级代理对。这样的一对可以是显式的，也可以是对应用程序完全透明的，但它始终处于最终用户的控制之下。使用特定于应用程序的代理实现增强的好例子包括Mowgli WWW[LAKLR95]、[LHKR96]和WebExpress[HL96]、[CTCSM97]。
Recommendation: Usage of application level proxies is conditionally recommended: an application must be proxy enabled and the decision of employing a proxy for an application must be under the user control at all times.
建议：有条件地建议使用应用程序级代理：应用程序必须启用代理，并且为应用程序使用代理的决定必须始终由用户控制。
Berkeley's SNOOP protocol [SNOOP] is a hybrid scheme mixing link-layer reliability mechanisms with the split connection approach. It is an improvement over split TCP approaches in that end-to-end semantics are retained. SNOOP does two things:
Berkeley的SNOOP协议[SNOOP]是一种混合方案，混合了链路层可靠性机制和分离连接方法。这是对拆分TCP方法的改进，因为保留了端到端语义。史努普做了两件事：
1. Locally (on the wireless link) retransmit lost packets, instead of allowing TCP to do so end-to-end.
1. 本地（在无线链路上）重新传输丢失的数据包，而不是允许TCP端到端地这样做。
2. Suppress the duplicate acks on their way from the receiver back to the sender, thus avoiding fast retransmit and congestion avoidance at the latter.
2. 在从接收方返回到发送方的过程中抑制重复的ack，从而避免后者的快速重传和拥塞避免。
Thus, the Snoop protocol is designed to avoid unnecessary fast retransmits by the TCP sender, when the wireless link layer retransmits a packet locally. Consider a system that does not use the Snoop agent. Consider a TCP sender S that sends packets to receiver R via an intermediate node IN. Assume that the sender sends packet A, B, C, D, E (in that order) which are forwarded by IN to the wireless receiver R. Assume that the intermediate node then retransmits B subsequently, because the first transmission of packet B is lost due to errors on the wireless link. In this case, receiver R receives packets A, C, D, E and B (in that order). Receipt of packets C, D and E triggers duplicate acknowledgements. When the TCP sender receives three duplicate acknowledgements, it triggers fast retransmit (which results in a retransmission, as well as reduction of congestion window). The fast retransmit occurs despite the link level retransmit on the wireless link, degrading throughput.
因此，当无线链路层在本地重传分组时，Snoop协议被设计为避免TCP发送方不必要的快速重传。考虑一个不使用监听代理的系统。考虑一个TCP发送器S，它通过中间节点将数据包发送给接收者R。假设发送方发送分组A、B、C、D、E（按该顺序），这些分组由in转发到无线接收器R。假设中间节点随后重新发送B，因为分组B的第一次传输由于无线链路上的错误而丢失。在这种情况下，接收器R接收分组A、C、D、E和B（按该顺序）。收到数据包C、D和E会触发重复确认。当TCP发送方收到三个重复的确认时，它会触发快速重传（这会导致重传，并减少拥塞窗口）。尽管在无线链路上进行链路级重传，但仍会发生快速重传，从而降低吞吐量。
SNOOP [SNOOP] deals with this problem by dropping TCP dupacks appropriately (at the intermediate node). The Delayed Dupacks (see section 4.5) attempts to approximate Snoop without requiring modifications at the intermediate node. Such schemes are needed only if the possibility of a fast retransmit due to wireless errors is non-negligible. In particular, if the wireless link uses a stop-and-go protocol (or otherwise delivers packets in-order), then these schemes are not very beneficial. Also, if the bandwidth-delay product of the wireless link is smaller than four segments, the probability that the intermediate node will have an opportunity to send three new packets before a lost packet is retransmitted is small. Since at least three dupacks are needed to trigger a fast retransmit, with a wireless bandwidth-delay product less than four packets, schemes such as Snoop and Delayed Dupacks would not be necessary (unless the link layer is not designed properly). Conversely, when the wireless bandwidth-delay product is large enough, Snoop can provide significant performance improvement (compared with standard TCP). For further discussion on these topics, please refer to [Vaidya99].
SNOOP[SNOOP]通过适当地（在中间节点）丢弃TCP Dupack来处理此问题。延迟的dupack（参见第4.5节）尝试近似Snoop，而不需要在中间节点进行修改。仅当由于无线错误而导致的快速重传的可能性不可忽略时，才需要这样的方案。特别地，如果无线链路使用停止和移动协议（或以其他方式按顺序传送分组），则这些方案不是非常有益的。此外，如果无线链路的带宽延迟乘积小于四个段，则中间节点将有机会在丢失的分组被重新传输之前发送三个新分组的概率很小。由于触发快速重传至少需要三个DUPACK，且无线带宽延迟乘积小于四个数据包，因此不需要Snoop和延迟DUPACK等方案（除非链路层设计不当）。相反，当无线带宽延迟乘积足够大时，Snoop可以提供显著的性能改进（与标准TCP相比）。有关这些主题的进一步讨论，请参阅[Vaidya99]。
The Delayed Dupacks scheme tends to provide performance benefit in environments where Snoop performs well. In general, performance improvement achieved by the Delayed Dupacks scheme is a function of packet loss rates due to congestion and transmission errors. When congestion-related losses occur, the Delayed Dupacks scheme unnecessarily delays retransmission. Thus, in the presence of congestion losses, the Delayed Dupacks scheme cannot achieve the same performance improvement as Snoop. However, simulation results [Vaidya99] indicate that the Delayed Dupacks can achieve a significant improvement in performance despite moderate congestion losses.
延迟Dupacks方案倾向于在Snoop性能良好的环境中提供性能优势。通常，延迟Dupacks方案实现的性能改进是由于拥塞和传输错误导致的分组丢失率的函数。当发生拥塞相关的丢失时，延迟的Dupacks方案不必要地延迟重传。因此，在存在拥塞损失的情况下，延迟Dupacks方案无法实现与Snoop相同的性能改进。然而，仿真结果[Vaidya99]表明，尽管存在适度的拥塞损失，但延迟的DUPACK可以显著提高性能。
WTCP [WTCP] is similar to SNOOP in that it preserves end-to-end semantics. In WTCP, the intermediate node uses a complex scheme to hide the time it spends recovering from local errors across the wireless link (this typically includes retransmissions due to error recovery, but may also include time spent dealing with congestion). The idea is for the sender to derive a smooth estimate of round-trip time. In order to work effectively, it assumes that the TCP endpoints implement the Timestamps option in RFC 1323 [TCPHP]. Unfortunately, support for RFC 1323 in TCP implementations is not yet widespread. Beyond this, WTCP requires changes only at the intermediate node.
WTCP[WTCP]类似于SNOOP，因为它保留了端到端语义。在WTCP中，中间节点使用复杂方案来隐藏其在无线链路上从本地错误恢复所花费的时间（这通常包括由于错误恢复而导致的重传，但也可能包括处理拥塞所花费的时间）。这个想法是为了让发送者对往返时间进行平滑估计。为了有效地工作，它假设TCP端点实现RFC1323[TCPHP]中的时间戳选项。不幸的是，TCP实现中对RFC1323的支持还没有普及。除此之外，WTCP只需要在中间节点进行更改。
SNOOP and WTCP require the intermediate node to examine and operate on the traffic between the portable wireless device and the TCP server on the wired Internet. SNOOP and WTCP do not work if the IP traffic is encrypted, unless, of course, the intermediate node shares
SNOOP和WTCP要求中间节点检查并操作便携式无线设备和有线互联网上TCP服务器之间的流量。如果IP通信被加密，SNOOP和WTCP将不工作，当然，除非中间节点共享
the security association between the mobile device and its end-to-end peer. They also require that both the data and the corresponding ACKs traverse the same intermediate node. Furthermore, if the intermediate node retransmits packets at the transport layer across the wireless link, this may duplicate efforts by the link-layer. SNOOP has been described by its designers as a TCP-aware link-layer. This is the right approach: the link and network layers can be much more aware of each other than traditional OSI layering suggests.
移动设备与其端到端对等设备之间的安全关联。它们还要求数据和相应的ack都穿过相同的中间节点。此外，如果中间节点跨无线链路在传输层重新传输分组，这可能会重复链路层的工作。SNOOP的设计者将其描述为TCP感知链路层。这是正确的方法：链路层和网络层可以比传统的OSI分层更了解彼此。
Encryption of IP packets via IPSEC's ESP header (in either transport or tunnel mode) renders the TCP header and payload unintelligible to the intermediate node. This precludes SNOOP (and WTCP) from working, because it needs to examine the TCP headers in both directions. Possible solutions involve:
通过IPSEC的ESP报头（在传输或隧道模式下）对IP数据包进行加密会使中间节点无法理解TCP报头和有效负载。这使得SNOOP（和WTCP）无法工作，因为它需要从两个方向检查TCP头。可能的解决办法包括：
- making the SNOOP (or WTCP) intermediate node a party to the security association between the client and the server
- 使SNOOP（或WTCP）中间节点成为客户端和服务器之间安全关联的一方
- IPSEC tunneling mode, terminated at the SNOOPing intermediate node
- IPSEC隧道模式，在侦听中间节点终止
However, these techniques require that users trust intermediate nodes. Users valuing both privacy and performance should use SSL or SOCKS for end-to-end security. These, however, are implemented above the transport layer, and are not as resistant to some security attacks (for example, those based on guessing TCP sequence numbers) as IPSEC.
然而，这些技术要求用户信任中间节点。重视隐私和性能的用户应使用SSL或SOCKS实现端到端安全。但是，这些都是在传输层之上实现的，对于某些安全攻击（例如，那些基于猜测TCP序列号的攻击）的抵抗力不如IPSEC。
Recommendation: Implement SNOOP on intermediate nodes now. Research results are encouraging, and it is an "invisible" optimization in that neither the client nor the server needs to change, only the intermediate node (for basic SNOOP without SACK). However, as discussed above there is little or no benefit from implementing SNOOP if:
建议：现在在中间节点上实现SNOOP。研究结果令人鼓舞，这是一种“隐形”优化，客户机和服务器都不需要更改，只需更改中间节点（用于基本的无SACK的SNOOP）。但是，如上所述，在以下情况下，实施SNOOP几乎没有好处：
1. The wireless link provides reliable, in-order packet delivery, or,
1. 无线链路提供可靠、有序的分组传送，或，
2. The bandwidth-delay product of the wireless link is smaller than four segments.
2. 无线链路的带宽延迟乘积小于四段。
Periods of disconnection are very common in wireless networks, either during handoff, due to lack of resources (dropped connections) or natural obstacles. During these periods, a TCP sender does not receive the expected acknowledgements. Upon expiration of the retransmit timer, this causes TCP to close its congestion window with all the related drawbacks. Re-transmitting packets is useless
在无线网络中，由于缺乏资源（断开连接）或自然障碍，在切换期间断开连接的时间非常常见。在这些期间，TCP发送方不会收到预期的确认。当重传计时器过期时，这会导致TCP关闭其拥塞窗口，并具有所有相关的缺点。重新传输数据包是无用的
since the connection is broken. [M-TCP] aims at enabling TCP to better handle handoffs and periods of disconnection, while preserving end-to-end semantics. M-TCP adds an element: supervisor host (SH-TCP) at the edge of the wireless network.
因为连接断了。[M-TCP]旨在使TCP能够更好地处理切换和断开连接期间，同时保留端到端语义。M-TCP在无线网络的边缘添加了一个元素：监控主机（SH-TCP）。
This intermediate node monitors the traffic coming from the sender to the mobile device. It does not break end-to-end semantics because the ACKs sent from the intermediate node to the sender are effectively the ones sent by the mobile node. The principle is to generally leave the last byte unacknowledged. Hence, SH-TCP could shut down the sender's window by sending the ACK for the last byte with a window set to zero. Thus the sender will go to persist mode.
此中间节点监视从发送方到移动设备的通信量。它不会破坏端到端语义，因为从中间节点发送到发送方的ack实际上是移动节点发送的ack。原则是通常不确认最后一个字节。因此，SH-TCP可以通过发送窗口设置为零的最后一个字节的ACK来关闭发送方的窗口。因此，发送方将进入持久模式。
The second optimization is done on both the intermediate node and the mobile host. On the latter, TCP is aware of the current state of the connection. In the event of a disconnection, it is capable of freezing all timers. Upon reconnection, the mobile sends a specially marked ACK with the number of the highest byte received. The intermediate node assumes that the mobile is disconnected because it monitors the flow on the wireless link, so in the absence of acknowledgments from the mobile, it will inform SH-TCP, which will send the ACK closing the sender window as described in the previous paragraph. The intermediate node learns that the mobile is again connected when it receives a duplicate acknowledgment marked as reconnected. At this point it sends a duplicate ACK to the sender and grows the window. The sender exits persist mode and resumes transmitting at the same rate as before. It begins by retransmitting any data previously unacknowledged by the mobile node. Non overlapping or non soft handoffs are lightweight because the previous intermediate system can shrink the window, and the new one modifies it as soon as it has received an indication from the mobile.
第二个优化在中间节点和移动主机上进行。对于后者，TCP知道连接的当前状态。在断开连接的情况下，它能够冻结所有计时器。在重新连接时，移动设备发送带有接收到的最高字节数的特别标记的ACK。中间节点假定移动设备已断开连接，因为它监视无线链路上的流量，因此在没有来自移动设备的确认的情况下，它将通知SH-TCP，后者将发送ACK，如前一段所述关闭发送方窗口。中间节点在接收到标记为重新连接的重复确认时获悉移动设备再次连接。此时，它向发送方发送一个重复的ACK，并增大窗口。发送方退出持久模式并以与以前相同的速率恢复传输。它首先重新传输移动节点先前未确认的任何数据。非重叠或非软切换是轻量级的，因为先前的中间系统可以缩小窗口，而新的中间系统在收到移动设备的指示后立即修改窗口。
Recommendation: M-TCP is not slated for adoption at this moment, because of the highly experimental nature of the proposal, and the uncertainty that TCP/IP implementations handle zero window updates correctly. Continue tracking developments in this space.
建议：由于该提案的高度实验性，以及TCP/IP实现是否正确处理零窗口更新的不确定性，M-TCP目前不打算采用。继续跟踪这一领域的发展。
Because Long Thin Networks are bandwidth-constrained, compressing every byte out of over-the-air segments is worth while.
由于细长网络的带宽受限，因此压缩无线传输段中的每个字节是值得的。
Mechanisms for TCP and IP header compression defined in [RFC1144, IPHC, IPHC-RTP, IPHC-PPP] provide the following benefits:
[RFC1144、IPHC、IPHC-RTP、IPHC-PPP]中定义的TCP和IP报头压缩机制具有以下优点：
- Improve interactive response time
- 提高交互式响应时间
- Allow using small packets for bulk data with good line efficiency
- 允许以良好的线路效率使用小数据包进行批量数据
- Allow using small packets for delay sensitive low data-rate traffic
- 允许对延迟敏感的低数据速率流量使用小数据包
- Decrease header overhead (for a common TCP segment size of 512 the header overhead of IPv4/TCP within a Mobile IP tunnel can decrease from 11.7 to less than 1 per cent.
- 减少报头开销（对于512的常见TCP段大小，移动IP隧道内IPv4/TCP的报头开销可以从11.7%减少到1%以下。
- Reduce packet loss rate over lossy links (because of the smaller cross-section of compressed packets).
- 减少有损链路上的数据包丢失率（因为压缩数据包的横截面较小）。
Van Jacobson (VJ) header compression [RFC1144] describes a Proposed Standard for TCP Header compression that is widely deployed. It uses TCP timeouts to detect a loss of synchronization between the compressor and decompressor. [IPHC] includes an explicit request for transmission of uncompressed headers to allow resynchronization without waiting for a TCP timeout (and executing congestion avoidance procedures).
Van Jacobson（VJ）头压缩[RFC1144]描述了广泛部署的TCP头压缩拟议标准。它使用TCP超时来检测压缩机和解压缩器之间的同步丢失。[IPHC]包括传输未压缩头的显式请求，以允许在不等待TCP超时的情况下重新同步（并执行拥塞避免过程）。
Recommendation: Implement [IPHC], in particular as it relates to IP-in-IP [RFC2003] and Minimal Encapsulation [RFC2004] for Mobile IP, as well as TCP header compression for lossy links and links that reorder packets. PPP capable devices should implement [IPHC-PPP]. VJ header compression may optionally be implemented as it is a widely deployed Proposed Standard. However, it should only be enabled when operating over reliable LTNs, because even a single bit error most probably would result in a full TCP window being dropped, followed by a costly recovery via slow-start.
建议：实施[IPHC]，特别是因为它涉及IP中的IP[RFC2003]和移动IP的最小封装[RFC2004]，以及有损链路和重新排序数据包的链路的TCP报头压缩。支持PPP的设备应实现[IPHC-PPP]。VJ报头压缩可以选择性地实现，因为它是广泛部署的建议标准。但是，仅当在可靠的LTN上运行时才应启用它，因为即使是一个位错误也极有可能导致整个TCP窗口被丢弃，然后通过缓慢启动进行代价高昂的恢复。
Compression of IP payloads is also desirable. "IP Payload Compression Protocol (IPComp)" [IPPCP] defines a framework where common compression algorithms can be applied to arbitrary IP segment payloads. IP payload compression is something of a niche optimization. It is necessary because IP-level security converts IP payloads to random bitstreams, defeating commonly-deployed link-layer compression mechanisms which are faced with payloads that have no redundant "information" that can be more compactly represented.
IP有效负载的压缩也是可取的。“IP有效负载压缩协议（IPComp）”[IPPCP]定义了一个框架，在该框架中，通用压缩算法可应用于任意IP段有效负载。IP有效负载压缩是一种小生境优化。这是必要的，因为IP级别的安全性将IP有效负载转换为随机比特流，从而击败了通常部署的链路层压缩机制，这些机制面临的有效负载没有可以更紧凑地表示的冗余“信息”。
However, many IP payloads are already compressed (images, audio, video, "zipped" files being FTPed), or are already encrypted above the IP layer (SSL/TLS, etc.). These payloads will not "compress" further, limiting the benefit of this optimization.
但是，许多IP有效负载已经被压缩（图像、音频、视频、“压缩”文件被FTPed），或者已经在IP层上加密（SSL/TLS等）。这些有效载荷不会进一步“压缩”，从而限制了这种优化的好处。
HTTP/1.1 already supports compression of the message body. For example, to use zlib compression the relevant directives are: "Content-Encoding: deflate" and "Accept-Encoding: deflate" [HTTP-PERF].
HTTP/1.1已经支持消息体的压缩。例如，要使用zlib压缩，相关的指令是：“内容编码：deflate”和“接受编码：deflate”[HTTP-PERF]。
HTTP-NG is considering supporting compression of resources at the HTTP level, which would provide equivalent benefits for common compressible MIME types like text/html. This will reduce the need for IPComp. If IPComp is deployed more rapidly than HTTP-NG, IPComp compression of HTML and MIME headers would be beneficial.
HTTP-NG正在考虑在HTTP级别支持资源压缩，这将为常见的可压缩MIME类型（如text/html）提供同等的好处。这将减少对IPComp的需求。如果IPComp的部署速度比HTTP-NG更快，则HTML和MIME头的IPComp压缩将是有益的。
In general, application-level compression can often outperform IPComp, because of the opportunity to use compression dictionaries based on knowledge of the specific data being compressed.
一般来说，应用程序级压缩通常优于IPComp，因为有机会使用基于压缩的特定数据知识的压缩字典。
Recommendation: IPComp may optionally be implemented. Track HTTP-NG standardization and deployment for now. Implementing HTTP/1.1 compression using zlib SHOULD is recommended.
建议：可选择实施IPComp。现在跟踪HTTP-NG标准化和部署。建议使用zlib实现HTTP/1.1压缩。
TCP maintains per-connection information such as connection state, current round-trip time, congestion control or maximum segment size. Sharing information between two consecutive connections or when creating a new connection while the first is still active to the same host may improve performance of the latter connection. The principle could easily be extended to sharing information amongst systems in a LAN not just within a given system. [Touch97] describes cache update for both cases.
TCP维护每个连接的信息，如连接状态、当前往返时间、拥塞控制或最大段大小。在两个连续连接之间共享信息，或者在第一个连接仍处于活动状态时创建新连接时，共享信息可以提高后一个连接的性能。这一原则可以很容易地扩展到局域网中的系统间共享信息，而不仅仅是在给定的系统内。[Touch97]描述了这两种情况下的缓存更新。
Users of W-WAN devices frequently request connections to the same servers or set of servers. For example, in order to read their email or to initiate connections to other servers, the devices may be configured to always use the same email server or WWW proxy. The main advantage of this proposal is that it relieves the application of the burden of optimizing the transport layer. In order to improve the performance of TCP connections, this mechanism only requires changes at the wireless device.
W-WAN设备的用户经常请求连接到相同的服务器或服务器集。例如，为了读取其电子邮件或发起到其他服务器的连接，可以将设备配置为始终使用相同的电子邮件服务器或WWW代理。该方案的主要优点是，它减轻了应用程序优化传输层的负担。为了提高TCP连接的性能，此机制只需要在无线设备上进行更改。
In general, this scheme should improve the dynamism of connection setup without increasing the cost of the implementation.
一般来说，此方案应在不增加实现成本的情况下提高连接设置的动态性。
Recommendation: This mechanism is recommended, although HTTP/1.1 with its persistent connections may partially achieve the same effect without it. Other applications (even HTTP/1.0) may find it useful. Continue monitoring research on this. In particular, work on a "Congestion Manager" [CM] may generalize this concept of sharing information among protocols and applications with a view to making them more adaptable to network conditions.
建议：建议使用此机制，尽管HTTP/1.1及其持久连接在没有它的情况下可能部分实现相同的效果。其他应用程序（甚至HTTP/1.0）可能会发现它很有用。继续监测这方面的研究。特别是，“拥塞管理器”[CM]的工作可以概括协议和应用程序之间共享信息的概念，以使它们更适合网络条件。
5 Summary of Recommended Optimizations
5推荐优化的总结
The table below summarizes our recommendations with regards to the main proposals mentioned above.
下表总结了我们对上述主要提案的建议。
The first column, "Stability of the Proposal," refers to the maturity of the mechanism in question. Some proposals are being pursued within the IETF in a somewhat open fashion. An IETF proposal is either an Internet Drafts (I-D) or a Request for Comments (RFC). The former is a preliminary version. There are several types of RFCs. A Draft Standards (DS) is standards track, and carries more weight than a Proposed Standard (PS), which may still undergo revisions. Informational or Experimental RFCs do not specify a standard. Other proposals are isolated efforts with little or no public review, and unknown chances of garnering industry backing.
第一栏“提案的稳定性”指的是有关机制的成熟度。IETF内部正在以某种开放的方式寻求一些建议。IETF提案可以是互联网草案（I-D）或征求意见（RFC）。前者是初步版本。有几种类型的RFC。标准草案（DS）是标准轨道，比提议的标准（PS）更具份量，后者可能仍在修订中。信息性或实验性RFC未指定标准。其他提案是孤立的，很少或根本没有公开审查，获得行业支持的机会未知。
"Implemented at" indicates which participant in a TCP session must be modified to implement the proposal. Legacy servers typically cannot be modified, so this column indicates whether implementation happens at either or both of the two nodes under some control: mobile device and intermediate node. The symbols used are: WS (wireless sender, that is, the mobile device's TCP send operation must be modified), WR (wireless receiver, that is, the mobile device's TCP receive operation must be modified), WD (wireless device, that is, modifications at the mobile device are not specific to either TCP send or receive), IN (intermediate node) and NI (network infrastructure). These entities are to be understood within the context of Section 1.1 ("Network Architecture"). NA simply means "not applicable."
“实施时间”表示必须修改TCP会话中的哪个参与者才能实施提案。传统服务器通常无法修改，因此此列指示实现是在某些控制下的两个节点（移动设备和中间节点）中的一个节点上进行，还是同时在两个节点上进行。使用的符号是：WS（无线发送器，即必须修改移动设备的TCP发送操作）、WR（无线接收器，即必须修改移动设备的TCP接收操作）、WD（无线设备，即移动设备上的修改不特定于TCP发送或接收）、IN（中间节点）和NI（网络基础设施）。这些实体应在第1.1节（“网络架构”）的上下文中理解。NA仅表示“不适用”
The "Recommendation" column captures our suggestions. Some mechanisms are endorsed for immediate adoption, others need more evidence and research, and others are not recommended.
“推荐”栏包含了我们的建议。一些机制得到认可，可立即采用，其他机制需要更多证据和研究，其他机制则不建议采用。
Name Stability of Implemented Recommendation
the Proposal at
==================== ============= =========== =================
Name Stability of Implemented Recommendation
the Proposal at
==================== ============= =========== =================
Increased Initial RFC 2581 (PS) WS Yes Window (initial_window=2)
增加初始RFC 2581（PS）WS是窗口（初始窗口=2）
Disable delayed ACKs NA WR When stable during slow start
在缓慢启动期间稳定时禁用延迟确认NA WR
Byte counting NA WS No instead of ACK counting
字节计数不支持WS-No而不是ACK计数
TCP Header RFC 1144 (PS) WD Yes compression for PPP IN (see 4.11)
中PPP的TCP标头RFC 1144（PS）WD Yes压缩（见4.11）
IP Payload RFC 2393 (PS) WD Yes Compression (simultaneously (IPComp) needed on Server)
IP有效负载RFC 2393（PS）WD Yes压缩（服务器上需要同时（IPComp）
Header RFC 2507 (PS), WD Yes Compression RFC 2509 (PS) IN (For IPv4, TCP and Mobile IP, PPP)
标头RFC 2507（PS），WD Yes压缩RFC 2509（PS）（用于IPv4、TCP和移动IP、PPP）
SNOOP plus SACK In limited use IN Yes WD (for SACK)
SNOOP plus袋在Yes WD中有限使用（用于袋）
Fast retransmit/fast RFC 2581 (PS) WD Yes (should be recovery there already)
快速重传/Fast RFC 2581（PS）WD是（应该已经恢复）
Transaction/TCP RFC 1644 WD No (Experimental) (simultaneously needed on Server)
事务/TCP RFC 1644 WD No（实验性）（服务器上同时需要）
Estimating Slow NA WS No Start Threshold (ssthresh)
估计慢速NA WS无启动阈值（ssthresh）
Delayed Duplicate Not stable WR When stable Acknowledgements IN (for notifications)
在中出现稳定确认时，延迟复制不稳定WR（用于通知）
Class-based Queuing NA WD When stable on End Systems
端系统稳定时基于类的排队NA WD
Explicit Congestion RFC 2481 (EXP) WD Yes
显式拥塞RFC 2481（EXP）WD是
Notification NI
通知NI
TCP Control Block RFC 2140 WD Yes Interdependence (Informational) (Track research)
TCP控制块RFC 2140 WD（信息）（跟踪研究）
Of all the optimizations in the table above, only SNOOP plus SACK and Delayed duplicate acknowledgements are currently being proposed only for wireless networks. The others are being considered even for non-wireless applications. Their more general applicability attracts more attention and analysis from the research community.
在上表中的所有优化中，目前仅针对无线网络提出了SNOOP plus SACK和延迟重复确认。即使在非无线应用中，也会考虑使用其他方法。它们更普遍的适用性吸引了研究界更多的关注和分析。
Of the above mechanisms, only Header Compression (for IP and TCP) and "SNOOP plus SACK" cease to work in the presence of IPSec.
在上述机制中，只有报头压缩（针对IP和TCP）和“SNOOP plus SACK”在存在IPSec的情况下停止工作。
6 Conclusion
6结论
In view of the unpredictable and problematic nature of long thin networks, arriving at an optimized transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks (LTNs).
鉴于超长网络的不可预测性和问题性，实现优化传输是一项艰巨的任务。我们已检讨现有的建议及未来的研究项目。基于此概述，我们还推荐在长瘦网络（LTN）中实现的机制。
7 Acknowledgements
7致谢
The authors are deeply indebted to the IETF tcpsat and tcpimpl working groups. The following individuals have also provided valuable feedback: Mark Allman (NASA), Vern Paxson (ACIRI), Raphi Rom (Technion/Sun), Charlie Perkins (Nokia), Peter Stark (Phone.com).
作者非常感谢IETF tcpsat和tcpimpl工作组。以下个人也提供了宝贵的反馈：马克·奥尔曼（NASA）、弗恩·帕克森（ACIRI）、拉菲·罗姆（Technion/Sun）、查理·珀金斯（诺基亚）、彼得·斯塔克（Phone.com）。
8 Security Considerations
8安全考虑
The mechanisms discussed and recommended in this document have been proposed in previous publications. The security considerations outlined in the original discussions apply here as well. Several security issues are also discussed throughout this document. Additionally, we present below a non-exhaustive list of the most salient issues concerning our recommended mechanisms:
本文件中讨论和建议的机制已在以前的出版物中提出。最初讨论中概述的安全注意事项也适用于此处。本文档还讨论了几个安全问题。此外，我们在下面列出了与我们建议的机制有关的最突出问题的非详尽清单：
- Larger Initial TCP Window Size
- 较大的初始TCP窗口大小
No known security issues [RFC2414, RFC2581].
没有已知的安全问题[RFC2414，RFC2581]。
- Header Compression
- 头部压缩
May be open to some denial of service attacks. But any attacker in a position to launch these attacks would have much stronger attacks at his disposal [IPHC, IPHC-RTP].
可能会受到某些拒绝服务攻击。但任何能够发动这些攻击的攻击者都会有更强大的攻击供其使用[IPHC，IPHC-RTP]。
- Congestion Control, Fast Retransmit/Fast Recovery
- 拥塞控制、快速重传/快速恢复
An attacker may force TCP connections to grind to a halt, or, more dangerously, behave more aggressively. The latter possibility may lead to congestion collapse, at least in some regions of the network [RFC2581].
攻击者可能会强制TCP连接停止，或者更危险的是，其行为更具攻击性。后一种可能性可能导致拥塞崩溃，至少在网络的某些区域[RFC2581]。
- Explicit Congestion Notification
- 显式拥塞通知
It does not appear to increase the vulnerabilities in the network. On the contrary, it may reduce them by aiding in the identification of flows unresponsive to or non-compliant with TCP congestion control [ECN].
它似乎不会增加网络中的漏洞。相反，它可以通过帮助识别对TCP拥塞控制不响应或不符合TCP拥塞控制[ECN]的流来减少它们。
- Sharing of Network Performance Information (TCP Control Block Sharing and Congestion Manager module)
- 网络性能信息共享（TCP控制块共享和拥塞管理器模块）
Some information should not be shared. For example, TCP sequence numbers are used to protect against spoofing attacks. Even limiting the sharing to performance values leaves open the possibility of denial-of-service attacks [Touch97].
有些信息不应该被分享。例如，TCP序列号用于防止欺骗攻击。即使将共享限制为性能值，也存在拒绝服务攻击的可能性[Touch97]。
- Performance Enhancing Proxies
- 性能增强代理
These systems are men-in-the-middle from the point of view of their security vulnerabilities. Accordingly, they must be used with extreme care so as to prevent their being hijacked and misused.
从安全漏洞的角度来看，这些系统处于中间位置。因此，必须极其小心地使用它们，以防止它们被劫持和滥用。
This last point is not to be underestimated: there is a general security concern whenever an intermediate node performs operations different from those carried out in an end-to-end basis. This is not specific to performance-enhancing proxies. In particular, there may be a tendency to forego IPSEC-based privacy in order to allow, for example, a SNOOP module, header compression (TCP, UDP, RTP, etc), or HTTP proxies to work.
最后一点不可低估：每当中间节点执行与端到端操作不同的操作时，都存在一个普遍的安全问题。这并不特定于性能增强代理。特别地，可能存在放弃基于IPSEC的隐私的趋势，以便允许例如SNOOP模块、报头压缩（TCP、UDP、RTP等）或HTTP代理工作。
Adding end-to-end security at higher layers (for example via RTP encryption, or via TLS encryption of the TCP payload) alleviates the problem. However, this still leaves protocol headers in the clear, and these may be exploited for traffic analysis and denial-of-service attacks.
在更高层添加端到端安全性（例如通过RTP加密或通过TCP有效负载的TLS加密）可以缓解该问题。但是，这仍然会使协议头处于空白状态，这些头可能会被用于流量分析和拒绝服务攻击。
9 References
9参考文献
[ACKSPACING] Partridge, C., "ACK Spacing for High Delay-Bandwidth Paths with Insufficient Buffering", Work in Progress.
[ACKSPACING]帕特里奇，C.，“缓冲不足的高延迟带宽路径的ACK间隔”，正在进行中。
[ADGGHOSSTT98] Allman, M., Dawkins, S., Glover, D., Griner, J., Henderson, T., Heidemann, J., Kruse, H., Osterman, S., Scott, K., Semke, J., Touch, J. and D. Tran, "Ongoing TCP Research Related to Satellites", Work in Progress.
[ADGGHOSSTT98]奥尔曼，M.，道金斯，S.，格洛弗，D.，格林纳，J.，亨德森，T.，海德曼，J.，克鲁斯，H.，奥斯特曼，S.，斯科特，K.，塞姆克，J.，Touch，J.和D.Tran，“正在进行的与卫星相关的TCP研究”，正在进行中。
[AGS98] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
[AGS98]Allman，M.，Glover，D.和L.Sanchez，“使用标准机制增强卫星信道上的TCP”，BCP 28，RFC 2488，1999年1月。
[Allman98] Mark Allman. On the Generation and Use of TCP Acknowledgments. ACM Computer Communication Review, 28(5), October 1998.
[奥尔曼]马克·奥尔曼。关于TCP确认的生成和使用。ACM计算机通信评论，28（5），1998年10月。
[AHO98] Allman, M., Hayes, C., Ostermann, S., "An Evaluation of TCP with Larger Initial Windows," Computer Communication Review, 28(3), July 1998.
[AHO98]Allman，M.，Hayes，C.，Ostermann，S.，“具有较大初始窗口的TCP评估”，计算机通信评论，28（3），1998年7月。
[BBKT96] Bhagwat, P., Bhattacharya, P., Krishna, A., Tripathi, S., "Enhancing Throughput over Wireless LANs Using Channel State Dependent Packet Scheduling," in Proc. IEEE INFOCOM'96, pp. 1133-40, March 1996.
[BBKT96]Bhagwat，P.，Bhattacharya，P.，Krishna，A.，Tripathi，S.，“使用依赖于信道状态的数据包调度提高无线局域网的吞吐量”，在Proc。IEEE INFOCOM'96，第1133-40页，1996年3月。
[BBKVP96] Bakshi, B., P., Krishna, N., Vaidya, N., Pradhan, D.K., "Improving Performance of TCP over Wireless Networks," Technical Report 96-014, Texas A&M University, 1996.
[BBKVP96]Bakshi，B.，P.，Krishna，N.，Vaidya，N.，Pradhan，D.K.，“改善无线网络上TCP的性能”，技术报告96-014，德克萨斯农工大学，1996年。
[BPSK96] Balakrishnan, H., Padmanabhan, V., Seshan, S., Katz, R., "A Comparison of Mechanisms for Improving TCP Performance over Wireless Links," in ACM SIGCOMM, Stanford, California, August 1996.
[BPSK96]Balakrishnan，H.，Padmanabhan，V.，Seshan，S.，Katz，R.，“无线链路上改进TCP性能的机制比较”，ACM SIGCOMM，斯坦福，加利福尼亚，1996年8月。
[BPK99] Balakrishnan, H., Padmanabhan, V., Katz, R., "The effects of asymmetry on TCP performance," ACM Mobile Networks and Applications (MONET), Vol. 4, No. 3, 1999, pp. 219-241.
[BPK99]Balakrishnan，H.，Padmanabhan，V.，Katz，R.，“不对称对TCP性能的影响”，ACM移动网络和应用（MONET），第4卷，第3期，1999年，第219-241页。
[BV97] S. Biaz and N. H. Vaidya, "Distinguishing Congestion Losses from Wireless Transmission Losses: A Negative Result," Seventh International Conference on Computer Communications and Networks (IC3N), New Orleans, October 1998.
[BV97]S.Biaz和N.H.Vaidya，“区分拥塞损失和无线传输损失：负面结果”，第七届计算机通信与网络国际会议（IC3N），新奥尔良，1998年10月。
[BV98] Biaz, S., Vaidya, N., "Sender-Based heuristics for Distinguishing Congestion Losses from Wireless Transmission Losses," Texas A&M University, Technical Report 98-013, June 1998.
[BV98]Biaz，S.，Vaidya，N.，“区分拥塞损失和无线传输损失的基于发送方的启发式方法”，德克萨斯A&M大学，技术报告98-013，1998年6月。
[BV98a] Biaz, S., Vaidya, N., "Discriminating Congestion Losses from Wireless Losses using Inter-Arrival Times at the Receiver," Texas A&M University, Technical Report 98-014, June 1998.
[BV98a]Biaz，S.，Vaidya，N.，“使用接收器的到达时间区分拥塞损失和无线损失”，德克萨斯A&M大学，技术报告98-014，1998年6月。
[BW97] Brasche, G., Walke, B., "Concepts, Services, and Protocols of the New GSM Phase 2+ general Packet Radio Service," IEEE Communications Magazine, Vol. 35, No. 8, August 1997.
[BW97]Brasche，G.，Walke，B.，“新GSM阶段2+通用分组无线电服务的概念、服务和协议”，IEEE通信杂志，第35卷，第8期，1997年8月。
[CB96] Cheshire, S., Baker, M., "Experiences with a Wireless Network in MosquitoNet," IEEE Micro, February 1996. Available online as: http://rescomp.stanford.edu/~cheshire/papers /wireless.ps.
[CB96]Cheshire，S.，Baker，M.，“蚊子网中无线网络的体验”，IEEE Micro，1996年2月。可通过以下网址在线获取：http://rescomp.stanford.edu/~cheshire/papers/wireless.ps。
[CDMA] Electronic Industry Alliance(EIA)/Telecommunications Industry Association (TIA), IS-95: Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System, 1993.
[CDMA]电子工业联盟（EIA）/电信工业协会（TIA），IS-95：双模宽带扩频蜂窝系统的移动站基站兼容性标准，1993年。
[CDPD] Wireless Data Forum, CDPD System Specification, Release 1.1, 1995.
[CDPD]无线数据论坛，CDPD系统规范，1.11995版。
[CM] Hari Balakrishnan and Srinivasan Seshan, "The Congestion Manager," Work in Progress.
[CM]Hari Balakrishnan和Srinivasan Seshan，“拥堵管理者”正在进行工作。
[CTCSM97] Chang, H., Tait, C., Cohen, N., Shapiro, M., Mastrianni, S., Floyd, R., Housel, B., Lindquist, D., "Web Browsing in a Wireless Environment: Disconnected and Asynchronous Operation in ARTour Web Express," in Proc. MobiCom'97, Budapest, Hungary, September 1997.
[CTCSM97]Chang，H.，Tait，C.，Cohen，N.，Shapiro，M.，Mastrianni，S.，Floyd，R.，Housel，B.，Lindquist，D.，“无线环境中的网页浏览：ARTour Web Express中的断开连接和异步操作”，在Proc。MobiCom'97，匈牙利布达佩斯，1997年9月。
[Demers90] Demers, A., Keshav, S., and Shenker, S., Analysis and Simulation of a Fair Queueing Algorithm, Internetworking: Research and Experience, Vol. 1, 1990, pp. 3-26.
[Demers90]Demers，A.，Keshav，S.，和Shenker，S.，公平排队算法的分析和模拟，互联网：研究与经验，第1卷，1990年，第3-26页。
[ECN] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[ECN]Ramakrishnan，K.和S.Floyd，“向IP添加明确拥塞通知（ECN）的提案”，RFC 2481，1999年1月。
[Floyd95] Floyd, S., and Jacobson, V., Link-sharing and Resource Management Models for Packet Networks. IEEE/ACM Transactions on Networking, Vol. 3 No. 4, pp. 365-386, August 1995.
[Floyd95]Floyd，S.，和Jacobson，V.，分组网络的链路共享和资源管理模型。IEEE/ACM网络交易，第3卷第4期，第365-386页，1995年8月。
[FSS98] Fragouli, C., Sivaraman, V., Srivastava, M., "Controlled Multimedia Wireless Link Sharing via Enhanced Class-Based Queueing with Channel-State-Dependent Packet Scheduling," Proc. IEEE INFOCOM'98, April 1998.
[FSS98]Fragouli，C.，Sivaraman，V.，Srivastava，M.，“通过增强的基于类的排队和信道状态相关的分组调度来控制多媒体无线链路共享”，Proc。IEEE INFOCOM'98，1998年4月。
[GPRS] ETSI, "General Packet Radio Service (GPRS): Service Description, Stage 2," GSM03.60, v.6.1.1 August 1998.
[GPRS]ETSI，“通用分组无线业务（GPRS）：服务说明，第2阶段”，GSM03.60，1998年8月6.1.1节。
[GSM] Rahnema, M., "Overview of the GSM system and protocol architecture," IEEE Communications Magazine, vol. 31, pp 92-100, April 1993.
[GSM]Rahnema，M.，“GSM系统和协议架构概述”，《IEEE通信杂志》，第31卷，第92-100页，1993年4月。
[HL96] Hausel, B., Lindquist, D., "WebExpress: A System for Optimizing Web Browsing in a Wireless Environment," in Proc. MobiCom'96, Rye, New York, USA, November 1996.
[HL96]Hausel，B.，Lindquist，D.，“WebExpress：在无线环境中优化Web浏览的系统”，在Proc。1996年11月，美国纽约，黑麦，MobiCom'96。
[HTTP-PERF] Henrik Frystyk Nielsen (W3C, MIT), Jim Gettys (W3C, Digital), Anselm Baird-Smith (W3C, INRIA), Eric Prud'hommeaux (W3C, MIT), Hon Lie (W3C, INRIA), Chris Lilley (W3C, INRIA), "Network Performance Effects of HTTP/1.1, CSS1, and PNG," ACM SIGCOMM '97, Cannes, France, September 1997. Available at: http://www.w3.org/Protocols/HTTP/Performance /Pipeline.html
[HTTP-PERF]Henrik Frystyk Nielsen（W3C，麻省理工），Jim Gettys（W3C，数字），Anselm Baird Smith（W3C，INRIA），Eric Prud'Hommeux（W3C，麻省理工），Hon Lie（W3C，INRIA），Chris Lilley（W3C，INRIA），“HTTP/1.1，CSS1和PNG的网络性能影响”，ACM SIGCOMM'97，法国戛纳，1997年9月。网址：http://www.w3.org/Protocols/HTTP/Performance /Pipeline.html
[IPPCP] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, December 1998.
[IPPCP]Shacham，A.，Monsour，R.，Pereira，R.和M.Thomas，“IP有效载荷压缩协议（IPComp）”，RFC 23931998年12月。
[IPHC] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[IPHC]Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[IPHC-RTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[IPHC-RTP]Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[IPHC-PPP] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.
[IPHC-PPP]Engan，M.，Casner，S.和C.Bormann，“PPP上的IP报头压缩”，RFC 2509，1999年2月。
[ITCP] Bakre, A., Badrinath, B.R., "Handoff and Systems Support for Indirect TCP/IP. In Proceedings of the Second USENIX Symposium on Mobile and Location-Independent Computing, Ann Arbor, Michigan, April 10- 11, 1995.
[ITCP]Bakre，A.，Badrinath，B.R.，“间接TCP/IP的切换和系统支持。第二届USENIX移动和位置独立计算研讨会论文集，密歇根州安娜堡，1995年4月10-11日。
[Jain89] Jain, R., "A Delay-Based Approach for Congestion Avoidance in Interconnected Heterogeneous Computer Networks," Digital Equipment Corporation, Technical Report DEC-TR-566, April 1989.
[Jain89]Jain，R.，“互连异构计算机网络中基于延迟的拥塞避免方法”，数字设备公司，技术报告DEC-TR-566，1989年4月。
[Karn93] Karn, P., "The Qualcomm CDMA Digital Cellular System" Proc. USENIX Mobile and Location-Independent Computing Symposium, USENIX Association, August 1993.
[Karn93]Karn，P.，“高通CDMA数字蜂窝系统”程序。USENIX移动和位置独立计算研讨会，USENIX协会，1993年8月。
[KRLKA97] Kojo, M., Raatikainen, K., Liljeberg, M., Kiiskinen, J., Alanko, T., "An Efficient Transport Service for Slow Wireless Telephone Links," in IEEE Journal on Selected Areas of Communication, volume 15, number 7, September 1997.
[KRLKA97]Kojo，M.，Raatikainen，K.，Liljeberg，M.，Kiiskinen，J.，Alanko，T.，“慢速无线电话链路的高效传输服务”，载于《IEEE通信选定领域期刊》，第15卷，第7期，1997年9月。
[LAKLR95] Liljeberg, M., Alanko, T., Kojo, M., Laamanen, H., Raatikainen, K., "Optimizing World-Wide Web for Weakly-Connected Mobile Workstations: An Indirect Approach," in Proc. 2nd Int. Workshop on Services in Distributed and Networked Environments, Whistler, Canada, pp. 132-139, June 1995.
[LAKLR95]Liljeberg，M.，Alanko，T.，Kojo，M.，Laamanen，H.，Raatikainen，K.，“为弱连接移动工作站优化万维网：一种间接方法”，在Proc。第二期分布式和网络环境服务国际研讨会，加拿大惠斯勒，第132-139页，1995年6月。
[LHKR96] Liljeberg, M., Helin, H., Kojo, M., Raatikainen, K., "Mowgli WWW Software: Improved Usability of WWW in Mobile WAN Environments," in Proc. IEEE Global Internet 1996 Conference, London, UK, November 1996.
[LHKR96]Liljeberg，M.，Helin，H.，Kojo，M.，Raatikainen，K.，“Mowgli WWW软件：在移动WAN环境中改进WWW的可用性”，摘自Proc。IEEE全球互联网1996年会议，伦敦，英国，1996年11月。
[LS98] Lettieri, P., Srivastava, M., "Adaptive Frame Length Control for Improving Wireless Link Throughput, Range, and Energy Efficiency," Proc. IEEE INFOCOM'98, April 1998.
[LS98]Lettieri，P.，Srivastava，M.，“用于提高无线链路吞吐量、范围和能量效率的自适应帧长度控制”，Proc。IEEE INFOCOM'98，1998年4月。
[MNCP] Piscitello, D., Phifer, L., Wang, Y., Hovey, R., "Mobile Network Computing Protocol (MNCP)", Work in Progress.
[MNCP]Piscitello，D.，Phifer，L.，Wang，Y.，Hovey，R.，“移动网络计算协议（MNCP）”，正在进行的工作。
[MOWGLI] Kojo, M., Raatikainen, K., Alanko, T., "Connecting Mobile Workstations to the Internet over a Digital Cellular Telephone Network," in Proc. Workshop on Mobile and Wireless Information Systems (MOBIDATA), Rutgers University, NJ, November 1994. Available at: http://www.cs.Helsinki.FI/research/mowgli/. Revised version published in Mobile Computing, pp. 253-270, Kluwer, 1996.
[MOWGLI]Kojo，M.，Raatikainen，K.，Alanko，T.，“通过数字蜂窝电话网络将移动工作站连接到互联网”，在Proc。移动和无线信息系统讲习班，罗格斯大学，新泽西州，1994年11月。网址：http://www.cs.Helsinki.FI/research/mowgli/. 修订版发布于移动计算，第253-270页，Kluwer，1996年。
[MSMO97] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm," in Computer Communications Review, a publication of ACM SIGCOMM, volume 27, number 3, July 1997.
[MSMO97]Mathis，M.，Semke，J.，Mahdavi，J.，Ott，T.，“TCP拥塞避免算法的宏观行为”，《计算机通信评论》，ACM SIGCOMM出版物，第27卷，第3期，1997年7月。
[MTCP] Brown, K. Singh, S., "A Network Architecture for
Mobile Computing," Proc. IEEE INFOCOM'96, pp. 1388-
1396, March 1996. Available at
ftp://ftp.ece.orst.edu/pub/singh/papers
/transport.ps.gz
[MTCP] Brown, K. Singh, S., "A Network Architecture for
Mobile Computing," Proc. IEEE INFOCOM'96, pp. 1388-
1396, March 1996. Available at
ftp://ftp.ece.orst.edu/pub/singh/papers
/transport.ps.gz
[M-TCP] Brown, K. Singh, S., "M-TCP: TCP for Mobile Cellular
Networks," ACM Computer Communications Review Vol.
27(5), 1997. Available at
ftp://ftp.ece.orst.edu/pub/singh/papers/mtcp.ps.gz
[M-TCP] Brown, K. Singh, S., "M-TCP: TCP for Mobile Cellular
Networks," ACM Computer Communications Review Vol.
27(5), 1997. Available at
ftp://ftp.ece.orst.edu/pub/singh/papers/mtcp.ps.gz
[MV97] Mehta, M., Vaidya, N., "Delayed Duplicate-
Acknowledgements: A Proposal to Improve Performance
of TCP on Wireless Links," Texas A&M University,
December 24, 1997. Available at
http://www.cs.tamu.edu/faculty/vaidya/mobile.html
[MV97] Mehta, M., Vaidya, N., "Delayed Duplicate-
Acknowledgements: A Proposal to Improve Performance
of TCP on Wireless Links," Texas A&M University,
December 24, 1997. Available at
http://www.cs.tamu.edu/faculty/vaidya/mobile.html
[NETBLT] White, J., "NETBLT (Network Block Transfer Protocol)", Work in Progress.
[NETBLT]White，J.，“NETBLT（网络块传输协议）”，正在进行中。
[Paxson97] V. Paxson, "End-to-End Internet Packet Dynamics,"
Proc. SIGCOMM '97. Available at
ftp://ftp.ee.lbl.gov/papers/vp-pkt-dyn-sigcomm97.ps.Z
[Paxson97] V. Paxson, "End-to-End Internet Packet Dynamics,"
Proc. SIGCOMM '97. Available at
ftp://ftp.ee.lbl.gov/papers/vp-pkt-dyn-sigcomm97.ps.Z
[RED] Braden, B., 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.
[红色]Braden，B.，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月。
[RLP] ETSI, "Radio Link Protocol for Data and Telematic Services on the Mobile Station - Base Station System (MS-BSS) interface and the Base Station System - Mobile Switching Center (BSS-MSC) interface," GSM Specification 04.22, Version 3.7.0, February 1992.
[RLP]ETSI，“移动台-基站系统（MS-BSS）接口和基站系统-移动交换中心（BSS-MSC）接口上数据和远程信息处理服务的无线链路协议”，GSM规范04.22，版本3.7.0，1992年2月。
[RFC908] Velten, D., Hinden, R. and J. Sax, "Reliable Data Protocol", RFC 908, July 1984.
[RFC908]Velten，D.，Hinden，R.和J.Sax，“可靠数据协议”，RFC 908，1984年7月。
[RFC1030] Lambert, M., "On Testing the NETBLT Protocol over Divers Networks", RFC 1030, November 1987.
[RFC1030]Lambert，M.，“在潜水员网络上测试NETBLT协议”，RFC 1030，1987年11月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求——通信层”，标准3，RFC 1122，1989年10月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]Jacobson，V.，“压缩低速串行链路的TCP/IP头”，RFC1144，1990年2月。
[RFC1151] Partridge, C., Hinden, R., "Version 2 of the Reliable Data Protocol (RDP)", RFC 1151, April 1990.
[RFC1151]Partridge，C.，Hinden，R.，“可靠数据协议（RDP）的第2版”，RFC151990年4月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1397] Braden, R., "Extending TCP for Transactions -- Concepts", RFC 1397, November 1992.
[RFC1397]Braden，R.，“为事务扩展TCP——概念”，RFC13971992年11月。
[RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[RFC1644]Braden，R.，“T/TCP——事务功能规范的TCP扩展”，RFC16441994年7月。
[RFC1661] Simpson, W., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[RFC1928]Leech，M.，Ganis，M.，Lee，Y.，Kuris，R.，Koblas，D.和L.Jones，“SOCKS协议版本5”，RFC 19281996年3月。
[RFC1986] Polites, W., Wollman, W., Woo, D. and R. Langan, "Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP)", RFC 1986, August 1996.
[RFC1986]Polites，W.，Wollman，W.，Woo，D.和R.Langan，“使用增强普通文件传输协议（ETFTP）对无线电链路的简单文件传输协议进行实验”，RFC 1986，1996年8月。
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[RFC2002]Perkins，C.，“IP移动支持”，RFC 2002，1996年10月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004]Perkins，C.，“IP内的最小封装”，RFC 2004，1996年10月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018]Mathis，M.，Mahdavi，J.，Floyd，S.和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[RFC2188] Banan, M., Taylor, M. and J. Cheng, "AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2", RFC 2188, September 1997.
[RFC2188]Banan，M.，Taylor，M.和J.Cheng，“AT&T/Neda的高效短距离远程操作（ESRO）协议规范版本1.2”，RFC 2188，1997年9月。
[RFC2246] Dierk, T. and E. Allen, "TLS Protocol Version 1", RFC 2246, January 1999.
[RFC2246]Dierk，T.和E.Allen，“TLS协议版本1”，RFC 2246，1999年1月。
[RFC2414] Allman, M., Floyd, S. and C. Partridge. "Increasing TCP's Initial Window", RFC 2414, September 1998.
[RFC2414]奥尔曼，M.，弗洛伊德，S.和C.帕特里奇。“增加TCP的初始窗口”，RFC 2414，1998年9月。
[RFC2415] Poduri, K.and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
[RFC2415]Poduri，K.和K.Nichols，“增加初始TCP窗口大小的模拟研究”，RFC 2415，1998年9月。
[RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC 2416, September 1998.
[RFC2416]Shepard，T.和C.Partridge，“当TCP启动时，只有四个数据包进入三个缓冲区”，RFC 2416，1998年9月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[RFC2582]Floyd，S.和T.Henderson，“TCP快速恢复算法的NewReno修改”，RFC 25821999年4月。
[SNOOP] Balakrishnan, H., Seshan, S., Amir, E., Katz, R., "Improving TCP/IP Performance over Wireless Networks," Proc. 1st ACM Conf. on Mobile Computing and Networking (Mobicom), Berkeley, CA, November 1995.
[SNOOP]Balakrishnan，H.，Seshan，S.，Amir，E.，Katz，R.，“改善无线网络上的TCP/IP性能”，Proc。第一届ACM移动计算和网络会议（Mobicom），加利福尼亚州伯克利，1995年11月。
[Stevens94] R. Stevens, "TCP/IP Illustrated, Volume 1," Addison-Wesley, 1994 (section 2.10 for MTU size considerations and section 11.3 for weak checksums).
[Stevens94]R.Stevens，“TCP/IP图解，第1卷”，Addison-Wesley，1994年（第2.10节考虑MTU大小，第11.3节考虑弱校验和）。
[TCPHP] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[TCPHP]Jacobson，V.，Braden，R.和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[TCPSATMIN] TCPSAT Minutes, August, 1997. Available at: http://tcpsat.lerc.nasa.gov/tcpsat/meetings/munich-minutes.txt.
[TCPSATMIN]TCPSAT会议记录，1997年8月。网址：http://tcpsat.lerc.nasa.gov/tcpsat/meetings/munich-minutes.txt.
[Touch97] Touch, T., "TCP Control Block Interdependence", RFC 2140, April 1997.
[Touch97]Touch，T.，“TCP控制块相互依赖”，RFC 2140，1997年4月。
[Vaidya99] N. H. Vaidya, M. Mehta, C. Perkins, G. Montenegro, "Delayed Duplicate Acknowledgements: A TCP-Unaware Approach to Improve Performance of TCP over Wireless," Technical Report 99-003, Computer Science Dept., Texas A&M University, February 1999.
[Vaidya99]N.H.Vaidya，M.Mehta，C.Perkins，G.黑山，“延迟重复确认：改进无线TCP性能的TCP非意识方法”，技术报告99-003，德克萨斯A&M大学计算机科学系，1999年2月。
[VEGAS] Brakmo, L., O'Malley, S., "TCP Vegas, New Techniques for Congestion Detection and Avoidance," SIGCOMM'94, London, pp 24-35, October 1994.
[VEGAS]Brakmo，L.，O'Malley，S.，“TCP VEGAS，拥塞检测和避免的新技术”，SIGCOMM'94，伦敦，第24-35页，1994年10月。
[VMTP] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC 1045, February 1988.
[VMTP]Cheriton，D.，“VMTP：通用消息事务协议”，RFC 10451988年2月。
[WAP] Wireless Application Protocol Forum.
http://www.wapforum.org/
[WAP] Wireless Application Protocol Forum.
http://www.wapforum.org/
[WC91] Wang, Z., Crowcroft, J., "A New Congestion Control Scheme: Slow Start and Search," ACM Computer Communication Review, vol 21, pp 32-43, January 1991.
[WC91]Wang，Z.，Crowcroft，J.，“一种新的拥塞控制方案：慢启动和搜索”，ACM计算机通信评论，第21卷，第32-43页，1991年1月。
[WTCP] Ratnam, K., Matta, I., "WTCP: An Efficient
Transmission Control Protocol for Networks with
Wireless Links," Technical Report NU-CCS-97-11,
Northeastern University, July 1997. Available at:
http://www.ece.neu.edu/personal/karu/papers/WTCP-
NU.ps.gz
[WTCP] Ratnam, K., Matta, I., "WTCP: An Efficient
Transmission Control Protocol for Networks with
Wireless Links," Technical Report NU-CCS-97-11,
Northeastern University, July 1997. Available at:
http://www.ece.neu.edu/personal/karu/papers/WTCP-
NU.ps.gz
[YB94] Yavatkar, R., Bhagawat, N., "Improving End-to-End Performance of TCP over Mobile Internetworks," Proc. Workshop on Mobile Computing Systems and Applications, IEEE Computer Society Press, Los Alamitos, California, 1994.
[YB94]Yavatkar，R.，Bhagawat，N.，“改善移动互联网上TCP的端到端性能”，Proc。移动计算系统和应用研讨会，IEEE计算机学会出版社，加利福尼亚州洛斯阿拉米托斯，1994年。
Authors' Addresses
作者地址
Questions about this document may be directed at:
有关本文件的问题，请联系：
Gabriel E. Montenegro Sun Labs Networking and Security Group Sun Microsystems, Inc. 901 San Antonio Road Mailstop UMPK 15-214 Mountain View, California 94303
加布里埃尔E.黑山太阳实验室网络和安全集团太阳微系统公司，加利福尼亚州山景城圣安东尼奥路901号邮递站UMPK 15-214 94303
Phone: +1-650-786-6288
Fax: +1-650-786-6445
EMail: gab@sun.com
Phone: +1-650-786-6288
Fax: +1-650-786-6445
EMail: gab@sun.com
Spencer Dawkins Nortel Networks P.O. Box 833805 Richardson, Texas 75083-3805
德克萨斯州理查森市斯宾塞·道金斯北电网络公司邮政信箱833805，邮编75083-3805
Phone: +1-972-684-4827
Fax: +1-972-685-3292
EMail: sdawkins@nortel.com
Phone: +1-972-684-4827
Fax: +1-972-685-3292
EMail: sdawkins@nortel.com
Markku Kojo Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland
马尔库科乔赫尔辛基大学计算机科学系P.O盒26（TeulLuuukkutu 23）FIF-000 014赫尔辛基芬兰
Phone: +358-9-1914-4179
Fax: +358-9-1914-4441
EMail: kojo@cs.helsinki.fi
Phone: +358-9-1914-4179
Fax: +358-9-1914-4441
EMail: kojo@cs.helsinki.fi
Vincent Magret Corporate Research Center Alcatel Network Systems, Inc 1201 Campbell Mail stop 446-310 Richardson Texas 75081 USA M/S 446-310
文森特·马格里特公司研究中心阿尔卡特网络系统公司1201坎贝尔邮站446-310美国德克萨斯州理查森75081 M/S 446-310
Phone: +1-972-996-2625
Fax: +1-972-996-5902
EMail: vincent.magret@aud.alcatel.com
Phone: +1-972-996-2625
Fax: +1-972-996-5902
EMail: vincent.magret@aud.alcatel.com
Nitin Vaidya Dept. of Computer Science Texas A&M University College Station, TX 77843-3112
德克萨斯州A&M大学学院站Nitin Vaidya计算机科学系，邮编77843-3112
Phone: 979-845-0512 Fax: 979-847-8578 EMail: vaidya@cs.tamu.edu
电话：979-845-0512传真：979-847-8578电子邮件：vaidya@cs.tamu.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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编辑功能的资金目前由互联网协会提供。