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）
本文档跟踪记录Internet团体为完善协议而进行的讨论、建议。详情请参见官方文件（STD1）。本文可任意分发。
版权声明（Copyright Notice）
Copyright (C) The Internet Society (1999). All Rights Reserved.
摘要（Abstract）
由于远程窄带网络（long thin networks）的发展状况尚不明朗（例如，无线宽带网[wireless WANs]），要达到优化传输的目标还有很多工作要做。我们将回顾已有的建议及其未来发展趋势，并建议在远程窄带网络的实现中采用基于本文描述的机制。
我们的目标是确保TCP协议可以适用于所有使用者，包括远程窄带网络的用户。我们从IETF 基于卫星链接（Satellite Links）的TCP（即，卫星TCP－tcpsat）协议入手，开始本建议。
我们认识到，对于远程窄带网络来说，并非每条tcpsat建议都是必需的，但是这些建议仍具有积极的参考价值。
目录（Table of Contents）
1 介绍（Introduction） ........................... ............... ............... ............... ...................... 3
1.1 网络体系结构（Network Architecture ）.......................... ............... ............. 5
1.2 无线连接的设想（Assumptions about the Radio Link ）..................... ......... 6
2 它应不应该算IP协议（Should it be IP or Not）? ................................ ................ 7
2.1潜在的网络错误特征（ Underlying Network Error Characteristics ）......….. 7
Montenegro, et al. Informational [Page 1]
2.2 非IP选择（Non-IP Alternatives） .................................... ............... .......... 8
2.2.1 WAP .............................................………………………………………. 8
2.2.2 配置非IP选择（Deploying Non-IP Alternatives） ................ .........….. 9
2.3 基于IP的考虑（IP-based Considerations）.........................……………….. 9
2.3.1 选择最大传输单元（MTU Choosing the MTU）[Stevens94, RFC1144] . 9
2.3.2 MTU通道发明（Path MTU Discovery ）[RFC1191] .....................…. 10
2.3.3 非基于TCP协议的建议（Non-TCP Proposals）................................. 10
3 TCP协议的状况（The Case for TCP ）..........................................………………… 11
4 候选优化（Candidate Optimizations ）...................................……………………... 12
4.1 TCP：当前机制（TCP: Current Mechanisms ）..............................…………. 12
4.1.1 慢启动与拥塞避免（Slow Start and Congestion Avoidance ）............ 12
4.1.2 快中继和快恢复（Fast Retransmit and Fast Recovery ）................….. 12
4.2 基于T/TCP[RFC1397, RFC1644]的
连结设置（Connection Setup with T/TCP ）…………………………………….. 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 分割TCP及性能增强代理
（Split TCP and Performance-Enhancing Proxies [PEPs]） ………………..…. 22
4.10.1 分割TCP的方式（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控制块的内部依赖性（TCP Control Block Interdependence [Touch97]）. 32
5 推荐优化摘要（Summary of Recommended Optimizations ）.........………….......... 33
6 结论（Conclusion ）........................................…………………………………......... 35
7 感谢（Acknowledgements） ................................……………………………............ 35
8 安全考虑（Security Considerations ）........................………………………............. 35
Montenegro, et al. Informational [Page 2]
9 参考书目（References ）......................................……………………………............ 36
作者地址（Authors' Addresses ）.........................................………………………….... 44
完整版权声明（Full Copyright Statement ）..................................…………………..... 46
1介绍（Introduction）
移动计算要支持网络资源的自由访问，必须要解决的主要障碍就是实现无线网络的最优化。然而，目前被优化的数据网络协议主要还集中在有线网络部分。与有线网络相比，无线环境下的延迟时间、信号抖动及错误率都有很大不同，因而，传统的协议也不太适用于这种媒介。
移动无线网可归于宽带局域网（即W-LANs，例如，802.11兼容网络）和宽带广域网（即W-WANs，例如，CDPD [CDPD], Ricochet, CDMA [CDMA], PHS, DoCoMo, GSM [GSM]等）。宽带广域网（W-LANs）最严重的问题是，其无线连结时间（即延迟时间*带宽）是同样情况下宽带局域网（W-LAN）的4至5倍。例如，对于802.11网络来说，假定延迟（即往返行程时间）是3毫秒，其带宽是1.5Mbps，则延迟*带宽就是4500bits。对于象Ricochet这样的宽带广域网来说，典型的往返行程（round-trip）时间可能是500毫秒（最好情况大约是230毫秒），持续的带宽大约维持在24Kbps，这样，延迟*带宽大约等于1.5KB。在不久的将来，第三代无线服务将要提供384Kbps或者更高的带宽。假定往返行程时间是200ms，这种情况下算延迟*带宽应为76.8Kbits（即，9.6KB），而在许多TCP协议的实现中，缺省的缓冲空间只有8KB，这就意味着，除非替代这个缺省值，否则即使W-LANs的缺省缓冲空间足够大，将来的W-WANs也不会以最大的效率工作（也就是说，管道始终不会被充满）。第三代无线服务如果提供2Mbps的带宽，反应时间在200毫秒以内，需要大约50KB的缓冲区。
最为重要的是，连结的反应时间会反过来影响吞吐能力。例如，[MSMO97]中就导出了TCP协议吞吐能力的上限，它与行程时间成反比。
另外，反应时间长也限制了用户对交互性应用的可接纳程度。
我们可以快速地扫一眼参考书目，从中可以发现，在解决无线网络问题上，有许多颇具价值的建议。本文中，我们将审视这些不同的解决方案，不管它们已经应用或者还处于研究阶段，并发布相应的建议。
Montenegro, et al. Informational [Page 3]
对于提高卫星连结上TCP协议性能，尚有大量的工作要做，与此关系最密切的是IETF [AGS98, ADGGHOSSTT98]的tcpsat工作组开发的文档。不管从哪方面看，为提高媒介的特性，在链路层（link layer）采用‘向前错误纠正’（FEC，forward error correction）有助于降低‘错位率’（BER，bit error rate），从10-3 降至10-6，甚至更好，这使BER更便于管理。在这个领域，通过中继方案（如ARQ，automatic repeat request，自动请求重复）可以将信息传送到更远的地方。注意，由于ARQ会产生额外的延迟，所以在实际中将其时间提前一些会获得更理想的效果。特殊情况下，对于时间敏感性传输（如视频、音频），数据必须在某一时间范围内传到，超出此时间范围的数据将被丢弃。在这种情况下，采用耗时的中继只能是浪费时间，数据即使被运到目的地，也只能被丢弃。这表明需要增加设备协议堆栈的实现，以使上层协议能够及时通知连结及MAC层，以避免这种代价高昂的中继方案。
包括卫星连结在内的网络都是‘远程肥胖网’（LFNs,Long Fat Networks或大象）。它们是“远程”网，因为其往返行程时间非常大（例如，地球同步卫星是0.5秒或更大）。并非所有的卫星连结都是LFN，尤其是一些近地轨道卫星（low-earth orbiting ,LEO）网络可能就在几个毫秒（再长也超不过160至200ms）。宽带广域网（W-WANs）有LFN中的“L”特性，即远程。同时，卫星网络也很“肥”（fat），因为它们有很高的带宽。通常情况下，卫星网络的延迟与带宽之积在64K字节以上，这也给TCP[TCPHP]带来了额外的麻烦。W-WANs通常并不展示这种行为。相应地，本文只处理与‘远程窄带管道’（long thin pipes）相关的连结，以及包含它们的“远程窄带网络”（long thin networks），我们将其简称为LTNs。
虽然下面的一些建议是在假定接口已经给定的前提下提出的，但本文并不打算涉及低层传输的API函数。要支持这些传统的SOCKET语法，而又不完全依赖TCP/IP传输[MOWGLI]，还是有可能的。
我们先将注意力放到有线网络的协议上。我们将尽量涵盖大多数相关的协议并简要论述其显著的特点（我们还提供了其出处，以方便更进一步的研究）。
Montenegro, et al. Informational [Page 4]
1.1 网络体系（Network Architecture）
LFNs和LTNs之间的一个显著区别就在于我们假定W-WAN是连结最终用户的最后方式。这就允许我们做出这样的设想：单个的中间结点可以看到在无线移动设备与Internet之间传递的所有‘包（packets）’，当然这种拓扑方式只是TCP卫星委员会（Satellite community）规范中的一种。
我们将重点放在移动无线应用上，只考虑特别指定的几种体系，包括如下内容：
- 提供相连的无线移动设备；
- 无线连结（可能实际上在链路层由多级组成）；
- 连结所通过的中间结点（有时特指基站）；
- 轮流方式提供接口的有线连结；
- 地球上的Internet及数以百万计的服务器与web站点。
特别地，我们不关心两个无线网段被一个有线网段分隔情况下的通道问题。这种情况是有可能发生的，例如，一个移动设备经由它的中介无线网段连到Internet上的中介结点上，并通过第二个无线网段连到其它的移动设备上。实际上，移动设备会经常连上有线Internet网络上的传统服务器。
典型地，无线网络的终点要么是中介结点，要么是移动设备。其中，后者可能是与移动网络相连的无线路由器。同样，也存在类似灾难恢复之类的重要应用。
我们的目标体系将暗示其所涉及的备选解决方案在调度能力方面是有差异的。其中一个重要的需求就是，我们不能改变传统服务器上的网络堆栈。尽管在移动设备上修改也是个选择（而且可能是必要的），如果能在中介结点处修改网络堆栈的话，那将是最完美的解决方案。
我们可以预想，移动装置能够非常有效率地利用这些无线中介，但其自身的一些传统缺欠仍须被克服。完美的移动性意味着移动装置有高度的灵活性和适应性，即不管发生任何情况，总能在任何指定的时间或地区与最好的网络建立连接。
Montenegro, et al. Informational [Page 5]
