Network Working Group P. Karn, Ed.
Request for Comments: 3819 Qualcomm
BCP: 89 C. Bormann
Category: Best Current Practice Universitaet Bremen TZI
G. Fairhurst
University of Aberdeen
D. Grossman
Motorola, Inc.
R. Ludwig
Ericsson Research
J. Mahdavi
Novell
G. Montenegro
Sun Microsystems Laboratories, Europe
J. Touch
USC/ISI
L. Wood
Cisco Systems
July 2004
Network Working Group P. Karn, Ed.
Request for Comments: 3819 Qualcomm
BCP: 89 C. Bormann
Category: Best Current Practice Universitaet Bremen TZI
G. Fairhurst
University of Aberdeen
D. Grossman
Motorola, Inc.
R. Ludwig
Ericsson Research
J. Mahdavi
Novell
G. Montenegro
Sun Microsystems Laboratories, Europe
J. Touch
USC/ISI
L. Wood
Cisco Systems
July 2004
Advice for Internet Subnetwork Designers
互联网子网设计者的建议
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document provides advice to the designers of digital communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with the Internet architecture and the implications of their design choices on the performance and efficiency of the Internet.
本文件为数字通信设备、链路层协议和分组交换本地网络（统称为子网）的设计者提供建议，希望支持互联网协议，但可能不熟悉互联网架构及其设计选择对互联网性能和效率的影响。
Table of Contents
目录
1. Introduction and Overview. . . . . . . . . . . . . . . . . . . 2
2. Maximum Transmission Units (MTUs) and IP Fragmentation . . . . 4
2.1. Choosing the MTU in Slow Networks. . . . . . . . . . . . 6
3. Framing on Connection-Oriented Subnetworks . . . . . . . . . . 7
4. Connection-Oriented Subnetworks. . . . . . . . . . . . . . . . 9
5. Broadcasting and Discovery . . . . . . . . . . . . . . . . . . 10
6. Multicasting . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Bandwidth on Demand (BoD) Subnets. . . . . . . . . . . . . . . 13
8. Reliability and Error Control. . . . . . . . . . . . . . . . . 14
8.1. TCP vs Link-Layer Retransmission . . . . . . . . . . . . 14
8.2. Recovery from Subnetwork Outages . . . . . . . . . . . . 17
8.3. CRCs, Checksums and Error Detection. . . . . . . . . . . 18
8.4. How TCP Works. . . . . . . . . . . . . . . . . . . . . . 20
8.5. TCP Performance Characteristics. . . . . . . . . . . . . 22
8.5.1. The Formulae . . . . . . . . . . . . . . . . . . 22
8.5.2. Assumptions. . . . . . . . . . . . . . . . . . . 23
8.5.3. Analysis of Link-Layer Effects on TCP
Performance. . . . . . . . . . . . . . . . . . . 24
9. Quality-of-Service (QoS) Considerations. . . . . . . . . . . . 26
10. Fairness vs Performance. . . . . . . . . . . . . . . . . . . . 29
11. Delay Characteristics. . . . . . . . . . . . . . . . . . . . . 30
12. Bandwidth Asymmetries. . . . . . . . . . . . . . . . . . . . . 31
13. Buffering, Flow and Congestion Control . . . . . . . . . . . . 31
14. Compression. . . . . . . . . . . . . . . . . . . . . . . . . . 34
15. Packet Reordering. . . . . . . . . . . . . . . . . . . . . . . 36
16. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
17. Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
18. Security Considerations. . . . . . . . . . . . . . . . . . . . 41
19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44
20. Informative References . . . . . . . . . . . . . . . . . . . . 45
21. Contributors' Addresses. . . . . . . . . . . . . . . . . . . . 57
22. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 58
23. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 60
1. Introduction and Overview. . . . . . . . . . . . . . . . . . . 2
2. Maximum Transmission Units (MTUs) and IP Fragmentation . . . . 4
2.1. Choosing the MTU in Slow Networks. . . . . . . . . . . . 6
3. Framing on Connection-Oriented Subnetworks . . . . . . . . . . 7
4. Connection-Oriented Subnetworks. . . . . . . . . . . . . . . . 9
5. Broadcasting and Discovery . . . . . . . . . . . . . . . . . . 10
6. Multicasting . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Bandwidth on Demand (BoD) Subnets. . . . . . . . . . . . . . . 13
8. Reliability and Error Control. . . . . . . . . . . . . . . . . 14
8.1. TCP vs Link-Layer Retransmission . . . . . . . . . . . . 14
8.2. Recovery from Subnetwork Outages . . . . . . . . . . . . 17
8.3. CRCs, Checksums and Error Detection. . . . . . . . . . . 18
8.4. How TCP Works. . . . . . . . . . . . . . . . . . . . . . 20
8.5. TCP Performance Characteristics. . . . . . . . . . . . . 22
8.5.1. The Formulae . . . . . . . . . . . . . . . . . . 22
8.5.2. Assumptions. . . . . . . . . . . . . . . . . . . 23
8.5.3. Analysis of Link-Layer Effects on TCP
Performance. . . . . . . . . . . . . . . . . . . 24
9. Quality-of-Service (QoS) Considerations. . . . . . . . . . . . 26
10. Fairness vs Performance. . . . . . . . . . . . . . . . . . . . 29
11. Delay Characteristics. . . . . . . . . . . . . . . . . . . . . 30
12. Bandwidth Asymmetries. . . . . . . . . . . . . . . . . . . . . 31
13. Buffering, Flow and Congestion Control . . . . . . . . . . . . 31
14. Compression. . . . . . . . . . . . . . . . . . . . . . . . . . 34
15. Packet Reordering. . . . . . . . . . . . . . . . . . . . . . . 36
16. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
17. Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
18. Security Considerations. . . . . . . . . . . . . . . . . . . . 41
19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44
20. Informative References . . . . . . . . . . . . . . . . . . . . 45
21. Contributors' Addresses. . . . . . . . . . . . . . . . . . . . 57
22. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 58
23. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 60
IP, the Internet Protocol [RFC791] [RFC2460], is the core protocol of the Internet. IP defines a simple "connectionless" packet-switched network. The success of the Internet is largely attributed to IP's simplicity, the "end-to-end principle" [SRC81] on which the Internet is based, and the resulting ease of carrying IP on a wide variety of subnetworks, not necessarily designed with IP in mind. A subnetwork refers to any network operating immediately below the IP layer to connect two or more systems using IP (i.e., end hosts or routers). In its simplest form, this may be a direct connection between the IP systems (e.g., using a length of cable or a wireless medium).
IP，即互联网协议[RFC791][RFC2460]，是互联网的核心协议。IP定义了一个简单的“无连接”分组交换网络。互联网的成功在很大程度上归功于IP的简单性、互联网所基于的“端到端原则”[SRC81]，以及由此带来的在各种各样的子网络上轻松承载IP的便利性，这些子网络的设计不一定要考虑IP。子网是指在IP层正下方运行的任何网络，用于使用IP连接两个或多个系统（即终端主机或路由器）。在其最简单的形式中，这可以是IP系统之间的直接连接（例如，使用一段电缆或无线介质）。
This document defines a subnetwork as a layer 2 network, which is a network that does not rely upon the services of IP routers to forward packets between parts of the subnetwork. However, IP routers may bridge frames at Layer 2 between parts of a subnetwork. Sometimes, it is convenient to aggregate a group of such subnetworks into a single logical subnetwork. IP routing protocols (e.g., OSPF, IS-IS, and PIM) can be configured to support this aggregation, but typically present a layer-3 subnetwork rather than a layer-2 subnetwork. This may also result in a specific packet passing several times over the same layer-2 subnetwork via an intermediate layer-3 gateway (router). Because that aggregation requires layer-3 components, issues thereof are beyond the scope of this document.
本文件将子网定义为第2层网络，该网络不依赖IP路由器的服务在子网各部分之间转发数据包。然而，IP路由器可以在子网的部分之间的第2层桥接帧。有时，将一组这样的子网聚合为一个逻辑子网是很方便的。IP路由协议（例如，OSPF、IS-IS和PIM）可配置为支持此聚合，但通常呈现第3层子网而不是第2层子网。这也可能导致特定数据包通过中间层3网关（路由器）在同一层2子网上多次通过。由于该聚合需要第3层组件，因此其问题超出了本文档的范围。
However, while many subnetworks carry IP, they do not necessarily do so with maximum efficiency, minimum complexity, or cost, nor do they implement certain features to efficiently support newer Internet features of increasing importance, such as multicasting or quality of service.
然而，尽管许多子网承载IP，但它们不一定以最高的效率、最低的复杂性或成本来承载IP，也不一定实现某些功能来有效支持日益重要的新Internet功能，如多播或服务质量。
With the explosive growth of the Internet, IP packets comprise an increasingly large fraction of the traffic carried by the world's telecommunications networks. It therefore makes sense to optimize both existing and new subnetwork technologies for IP as much as possible.
随着互联网的爆炸性增长，IP数据包在世界电信网络承载的流量中所占比例越来越大。因此，尽可能优化现有和新的IP子网技术是有意义的。
Optimizing a subnetwork for IP involves three complementary considerations:
优化IP子网涉及三个互补的考虑因素：
1. Providing functionality sufficient to carry IP.
1. 提供足以承载IP的功能。
2. Eliminating unnecessary functions that increase cost or complexity.
2. 消除增加成本或复杂性的不必要功能。
3. Choosing subnetwork parameters that maximize the performance of the Internet protocols.
3. 选择子网参数，以最大限度地提高互联网协议的性能。
Because IP is so simple, consideration 2 is more of an issue than consideration 1. That is to say, subnetwork designers make many more errors of commission than errors of omission. However, certain enhancements to Internet features, such as multicasting and quality-of-service, benefit significantly from support given by the underlying subnetworks beyond that necessary to carry "traditional" unicast, best-effort IP.
因为IP非常简单，所以考虑因素2比考虑因素1更重要。也就是说，子网络设计者犯的委托错误要比遗漏错误多得多。然而，对互联网功能的某些增强，如多播和服务质量，从底层子网提供的支持中获益匪浅，而不仅仅是承载“传统”单播、尽力而为的IP所必需的支持。
A major consideration in the efficient design of any layered communication network is the appropriate layer(s) in which to implement a given function. This issue was first addressed in the seminal paper, "End-to-End Arguments in System Design" [SRC81]. That paper argued that many functions can be implemented properly *only* on an end-to-end basis, i.e., at the highest protocol layers, outside the subnetwork. These functions include ensuring the reliable delivery of data and the use of cryptography to provide confidentiality and message integrity.
在任何分层通信网络的有效设计中，主要考虑的是实现给定功能的适当层。这一问题首先在开创性论文“系统设计中的端到端参数”[SRC81]中得到解决。该论文认为，许多功能只能在端到端的基础上，即在子网之外的最高协议层上，正确地实现。这些功能包括确保数据的可靠传输，以及使用加密技术提供机密性和消息完整性。
Such functions cannot be provided solely by the concatenation of hop-by-hop services; duplicating these functions at the lower protocol layers (i.e., within the subnetwork) can be needlessly redundant or even harmful to cost and performance.
这种功能不能仅仅通过逐跳服务的串联来提供；在较低的协议层（即在子网内）复制这些功能可能是不必要的冗余，甚至对成本和性能有害。
However, partial duplication of functionality in a lower layer can *sometimes* be justified by performance, security, or availability considerations. Examples include link-layer retransmission to improve the performance of an unusually lossy channel, e.g., mobile radio, link-level encryption intended to thwart traffic analysis, and redundant transmission links to improve availability, increase throughput, or to guarantee performance for certain classes of traffic. Duplication of protocol functions should be done only with an understanding of system-level implications, including possible interactions with higher-layer mechanisms.
但是，出于性能、安全性或可用性方面的考虑，较低层的部分功能复制*有时*是合理的。示例包括链路层重传以提高异常有损信道（例如，移动无线电）的性能，链路级加密旨在阻止流量分析，以及冗余传输链路以提高可用性、增加吞吐量或保证特定类别流量的性能。协议功能的复制只能在理解系统级含义的情况下进行，包括可能与更高层机制的交互。
The original architecture of the Internet was influenced by the end-to-end principle [SRC81], and has been, in our view, part of the reason for the Internet's success.
互联网的原始架构受到端到端原则[SRC81]的影响，在我们看来，这是互联网成功的部分原因。
The remainder of this document discusses the various subnetwork design issues that the authors consider relevant to efficient IP support.
本文档的其余部分讨论了作者认为与有效IP支持相关的各种子网设计问题。
IPv4 packets (datagrams) vary in size, from 20 bytes (the size of the IPv4 header alone) to a maximum of 65535 bytes. Subnetworks need not support maximum-sized (64KB) IP packets, as IP provides a scheme that breaks packets that are too large for a given subnetwork into fragments that travel as independent IP packets and are reassembled at the destination. The maximum packet size supported by a subnetwork is known as its Maximum Transmission Unit (MTU).
IPv4数据包（数据报）的大小各不相同，从20字节（仅IPv4报头的大小）到最大65535字节不等。子网不需要支持最大大小（64KB）的IP数据包，因为IP提供了一种方案，可以将对于给定子网来说太大的数据包分解为作为独立IP数据包传输的片段，并在目的地重新组装。子网支持的最大数据包大小称为其最大传输单元（MTU）。
Subnetworks may, but are not required to, indicate the length of each packet they carry. One example is Ethernet with the widely used DIX [DIX82] (not IEEE 802.3 [IEEE8023]) header, which lacks a length
子网络可以（但不要求）指示其承载的每个数据包的长度。一个例子是具有广泛使用的DIX[DIX82]（而不是IEEE 802.3[IEEE8023]）头的以太网，它缺少长度
field to indicate the true data length when the packet is padded to a minimum of 60 bytes. This is not a problem for uncompressed IP because each IP packet carries its own length field.
字段，指示数据包填充到最小60字节时的真实数据长度。这对于未压缩的IP来说不是问题，因为每个IP包都有自己的长度字段。
If optional header compression [RFC1144] [RFC2507] [RFC2508] [RFC3095] is used, however, it is required that the link framing indicate frame length because that is needed for the reconstruction of the original header.
但是，如果使用可选的报头压缩[RFC1144][RFC2507][RFC2508][RFC3095]，则要求链路帧指示帧长度，因为重建原始报头需要帧长度。
In IP version 4 (the version now in widespread use), fragmentation can occur at either the sending host or in an intermediate router, and fragments can be further fragmented at subsequent routers if necessary.
在IP版本4（目前广泛使用的版本）中，碎片可能发生在发送主机或中间路由器上，如果需要，碎片可以在后续路由器上进一步碎片化。
In IP version 6 [RFC2460], fragmentation can occur only at the sending host; it cannot occur in a router (called "router fragmentation" in this document).
在IP版本6[RFC2460]中，碎片只能在发送主机上发生；它不能发生在路由器中（在本文档中称为“路由器碎片”）。
Both IPv4 and IPv6 provide a "path MTU discovery" procedure [RFC1191] [RFC1435] [RFC1981] that allows the sending host to avoid fragmentation by discovering the minimum MTU along a given path and reduce its packet sizes accordingly. This procedure is optional in IPv4 and IPv6.
IPv4和IPv6都提供了“路径MTU发现”过程[RFC1191][RFC1435][RFC1981]，该过程允许发送主机通过沿给定路径发现最小MTU并相应减小其数据包大小来避免碎片。此过程在IPv4和IPv6中是可选的。
Path MTU discovery is widely deployed, but it sometimes encounters problems. Some routers fail to generate the ICMP messages that convey path MTU information to the sender, and sometimes the ICMP messages are blocked by overly restrictive firewalls. The result can be a "Path MTU Black Hole" [RFC2923] [RFC1435].
Path MTU发现已广泛部署，但有时会遇到问题。一些路由器无法生成将路径MTU信息传递给发送方的ICMP消息，有时ICMP消息被限制过度的防火墙阻止。结果可能是一个“路径MTU黑洞”[RFC2923][RFC1435]。
The Path MTU Discovery procedure, the persistence of path MTU black holes, and the deletion of router fragmentation in IPv6 reflect a consensus of the Internet technical community that router fragmentation is best avoided. This requires that subnetworks support MTUs that are "reasonably" large. All IPv4 end hosts are required to accept and reassemble IP packets of size 576 bytes [RFC791], but such a small value would clearly be inefficient. Because IPv6 omits fragmentation by routers, [RFC2460] specifies a larger minimum MTU of 1280 bytes. Any subnetwork with an internal packet payload smaller than 1280 bytes must implement a mechanism that performs fragmentation/reassembly of IP packets to/from subnetwork frames if it is to support IPv6.
路径MTU发现过程、路径MTU黑洞的持久性以及IPv6中路由器碎片的删除反映了互联网技术界的共识，即最好避免路由器碎片。这要求子网支持“合理”大的MTU。所有IPv4终端主机都需要接受并重新组装大小为576字节的IP数据包[RFC791]，但如此小的值显然是低效的。因为IPv6省略了路由器的分段，[RFC2460]指定了更大的最小MTU（1280字节）。如果要支持IPv6，任何内部数据包有效负载小于1280字节的子网都必须实现一种机制，该机制可以执行IP数据包与子网帧之间的分段/重组。
If a subnetwork cannot directly support a "reasonable" MTU with native framing mechanisms, it should internally fragment. That is, it should transparently break IP packets into internal data elements and reassemble them at the other end of the subnetwork.
如果子网络不能直接支持具有本机帧机制的“合理”MTU，则应在内部分段。也就是说，它应该透明地将IP数据包分解为内部数据元素，并在子网的另一端重新组装它们。
This leaves the question of what is a "reasonable" MTU. Ethernet (10 and 100 Mb/s) has an MTU of 1500 bytes, and because of the ubiquity of Ethernet few Internet paths currently have MTUs larger than this value. This severely limits the utility of larger MTUs provided by other subnetworks. Meanwhile, larger MTUs are increasingly desirable on high-speed subnetworks to reduce the per-packet processing overhead in host computers, and implementers are encouraged to provide them even though they may not be usable when Ethernet is also in the path.
这就留下了什么是“合理”MTU的问题。以太网（10和100 Mb/s）的MTU为1500字节，由于以太网的普遍存在，目前很少有互联网路径的MTU大于此值。这严重限制了其他子网提供的较大MTU的效用。同时，在高速子网上越来越需要更大的MTU以减少主机中的每包处理开销，并且鼓励实施者提供它们，即使当以太网也在路径中时它们可能不可用。
Various "tunneling" schemes, such as GRE [RFC2784] or IP Security in tunnel mode [RFC2406], treat IP as a subnetwork for IP. Since tunneling adds header overhead, it can trigger fragmentation, even when the same physical subnetworks (e.g., Ethernet) are used on both sides of the host performing IPsec encapsulation. Tunneling has made it more difficult to avoid router fragmentation and has increased the incidence of path MTU black holes [RFC2401] [RFC2923]. Larger subnetwork MTUs may help to alleviate this problem.
各种“隧道”方案，如GRE[RFC2784]或隧道模式下的IP安全[RFC2406]，将IP视为IP的子网。由于隧道传输增加了报头开销，因此即使在执行IPsec封装的主机两侧使用相同的物理子网（例如以太网）时，它也会触发碎片。隧道使得避免路由器碎片变得更加困难，并且增加了路径MTU黑洞[RFC2401][RFC2923]的发生率。较大的子网MTU可能有助于缓解此问题。
In slow networks, the largest possible packet may take a considerable amount of time to send. This is known as channelisation or serialisation delay. Total end-to-end interactive response time should not exceed the well-known human factors limit of 100 to 200 ms. This includes all sources of delay: electromagnetic propagation delay, queuing delay, serialisation delay, and the store-and-forward time, i.e., the time to transmit a packet at link speed.
在慢速网络中，最大可能的数据包可能需要相当长的时间才能发送。这称为信道化或串行化延迟。端到端交互响应总时间不应超过众所周知的人为因素限制100至200 ms。这包括所有延迟源：电磁传播延迟、排队延迟、串行化延迟以及存储和转发时间，即以链路速度传输数据包的时间。
At low link speeds, store-and-forward delays can dominate total end-to-end delay; these are in turn directly influenced by the maximum transmission unit (MTU) size. Even when an interactive packet is given a higher queuing priority, it may have to wait for a large bulk transfer packet to finish transmission. This worst-case wait can be set by an appropriate choice of MTU.
在低链路速度下，存储和转发延迟可以控制总的端到端延迟；这些反过来又直接受到最大传输单元（MTU）大小的影响。即使交互式数据包被赋予更高的排队优先级，它也可能必须等待大容量传输数据包完成传输。这种最坏情况下的等待可以通过适当选择MTU来设置。
For example, if the MTU is set to 1500 bytes, then an MTU-sized packet will take about 8 milliseconds to send on a T1 (1.536 Mb/s) link. But if the link speed is 19.2kb/s, then the transmission time becomes 625 ms -- well above our 100-200ms limit. A 256-byte MTU would lower this delay to a little over 100 ms. However, care should be taken not to lower the MTU excessively, as this will increase header overhead and trigger frequent router fragmentation (if Path MTU discovery is not in use). This is likely to be the case with multicast, where Path MTU discovery is ineffective.
例如，如果MTU设置为1500字节，则MTU大小的数据包在T1（1.536 Mb/s）链路上发送大约需要8毫秒。但如果链路速度为19.2kb/s，则传输时间将变为625ms——远高于我们的100-200ms限制。256字节的MTU会将此延迟降低到略高于100毫秒。但是，应注意不要过度降低MTU，因为这会增加报头开销并触发频繁的路由器碎片（如果未使用路径MTU发现）。多播很可能就是这种情况，路径MTU发现无效。
One way to limit delay for interactive traffic without imposing a small MTU is to give priority to this traffic and to preempt (abort)
在不使用小型MTU的情况下限制交互流量延迟的一种方法是优先处理该流量并抢占（中止）
the transmission of a lower-priority packet when a higher priority packet arrives in the queue. However, the link resources used to send the aborted packet are lost, and overall throughput will decrease.
当高优先级数据包到达队列时，低优先级数据包的传输。但是，用于发送中止数据包的链路资源丢失，总体吞吐量将降低。
Another way to limit delay is to implement a link-level multiplexing scheme that allows several packets to be in progress simultaneously, with transmission priority given to segments of higher-priority IP packets. For links using the Point-To-Point Protocol (PPP) [RFC1661], multi-class multilink [RFC2686] [RFC2687] [RFC2689] provides such a facility.
限制延迟的另一种方法是实施链路级多路复用方案，该方案允许多个分组同时进行，传输优先级被赋予高优先级IP分组的段。对于使用点对点协议（PPP）[RFC1661]的链路，多类多链路[RFC2686][RFC2687][RFC2689]提供了这种功能。
ATM (asynchronous transfer mode), where SNDUs are fragmented and interleaved across smaller 53-byte ATM cells, is another example of this technique. However, ATM is generally used on high-speed links where the store-and-forward delays are already minimal, and it introduces significant (~9%) increases in overhead due to the addition of 5-byte cell overhead to each 48-byte ATM cell.
ATM（异步传输模式）是该技术的另一个示例，其中SNDU被分段并在较小的53字节ATM信元之间交错。然而，ATM通常用于存储和转发延迟已经很小的高速链路上，并且由于每个48字节ATM信元增加了5字节信元开销，因此会导致开销显著增加（~9%）。
A third example is the Data-Over-Cable Service Interface Specification (DOCSIS) with typical upstream bandwidths of 2.56 Mb/s or 5.12 Mb/s. To reduce the impact of a 1500-byte MTU in DOCSIS 1.0 [DOCSIS1], a data link layer fragmentation mechanism is specified in DOCSIS 1.1 [DOCSIS2]. To accommodate the installed base, DOCSIS 1.1 must be backward compatible with DOCSIS 1.0 cable modems, which generally do not support fragmentation. Under the co-existence of DOCSIS 1.0 and DOCSIS 1.1, the unfragmented large data packets from DOCSIS 1.0 cable modems may affect the quality of service for voice packets from DOCSIS 1.1 cable modems. In this case, it has been shown in [DOCSIS3] that the use of bandwidth allocation algorithms can mitigate this effect.
第三个例子是有线数据服务接口规范（DOCSIS），其典型上行带宽为2.56 Mb/s或5.12 Mb/s。为了减少DOCSIS 1.0[DOCSIS 1]中1500字节MTU的影响，DOCSIS 1.1[DOCSIS 2]中规定了数据链路层分段机制。为了适应安装基数，DOCSIS 1.1必须向后兼容DOCSIS 1.0电缆调制解调器，后者通常不支持分段。在DOCSIS 1.0和DOCSIS 1.1共存的情况下，来自DOCSIS 1.0电缆调制解调器的未分割大数据包可能会影响来自DOCSIS 1.1电缆调制解调器的语音包的服务质量。在这种情况下，[DOCSIS3]中表明，使用带宽分配算法可以缓解这种影响。
To summarize, there is a fundamental tradeoff between efficiency and latency in the design of a subnetwork, and the designer should keep this tradeoff in mind.
总之，在子网的设计中，效率和延迟之间有一个基本的折衷，设计者应该记住这个折衷。
IP requires that subnetworks mark the beginning and end of each variable-length, asynchronous IP packet. Some examples of links and subnetworks that do not provide this as an intrinsic feature include:
IP要求子网标记每个可变长度异步IP数据包的开始和结束。一些链路和子网的示例不提供这一固有特性，包括：
1. leased lines carrying a synchronous bit stream;
1. 承载同步比特流的租用线路；
2. ISDN B-channels carrying a synchronous octet stream;
2. 承载同步八位组流的ISDN B信道；
3. dialup telephone modems carrying an asynchronous octet stream;
3. 携带异步八位字节流的拨号电话调制解调器；
and
和
4. Asynchronous Transfer Mode (ATM) networks carrying an asynchronous stream of fixed-sized "cells".
4. 异步传输模式（ATM）网络承载固定大小的“信元”异步流。
The Internet community has defined packet framing methods for all these subnetworks. The Point-To-Point Protocol (PPP) [RFC1661], which uses a variant of HDLC, is applicable to bit synchronous, octet-synchronous, and octet asynchronous links (i.e., examples 1-3 above). PPP is one preferred framing method for IP, since a large number of systems interoperate with PPP. ATM has its own framing methods, described in [RFC2684] [RFC2364].
互联网社区已经为所有这些子网定义了数据包帧方法。使用HDLC变体的点到点协议（PPP）[RFC1661]适用于位同步、八位同步和八位异步链路（即，上面的示例1-3）。PPP是IP的一种首选成帧方法，因为大量系统与PPP互操作。ATM有自己的成帧方法，如[RFC2684][RFC2364]所述。
At high speeds, a subnetwork should provide a framed interface capable of carrying asynchronous, variable-length IP datagrams. The maximum packet size supported by this interface is discussed above in the MTU/Fragmentation section. The subnetwork may implement this facility in any convenient manner.
在高速下，子网应提供一个框架接口，能够承载异步、可变长度的IP数据报。该接口支持的最大数据包大小在上面的MTU/分段部分中讨论。子网可以以任何方便的方式实现该设施。
IP packet boundaries need not coincide with any framing or synchronization mechanisms internal to the subnetwork. When the subnetwork implements variable sized data units, the most straightforward approach is to place exactly one IP packet into each subnetwork data unit (SNDU), and to rely on the subnetwork's existing ability to delimit SNDUs to also delimit IP packets. A good example is Ethernet. However, some subnetworks have SNDUs of one or more fixed sizes, as dictated by switching, forward error correction and/or interleaving considerations. Examples of such subnetworks include ATM, with a single cell payload size of 48 octets plus a 5- octet header, and IS-95 digital cellular, with two "rate sets" of four fixed frame sizes each that may be selected on 20 millisecond boundaries.
IP包边界不需要与子网内部的任何帧或同步机制一致。当子网实现可变大小的数据单元时，最直接的方法是在每个子网数据单元（SNDU）中恰好放置一个IP数据包，并依靠子网现有的SNDU定界能力来同时定界IP数据包。以太网就是一个很好的例子。然而，一些子网具有一个或多个固定大小的sndu，这取决于交换、前向纠错和/或交织考虑。此类子网的示例包括ATM，其单信元有效负载大小为48个八位字节加上5个八位字节报头，以及IS-95数字蜂窝，其两个“速率集”为四个固定帧大小，每个可在20毫秒边界上选择。
Because IP packets are of variable length, they may not necessarily fit into an integer multiple of fixed-sized SNDUs. An "adaptation layer" is needed to convert IP packets into SNDUs while marking the boundary between each IP packet in some manner.
由于IP数据包的长度可变，它们不一定适合固定大小SNDU的整数倍。需要“适配层”将IP分组转换为SNDU，同时以某种方式标记每个IP分组之间的边界。
There are several approaches to this problem. The first is to encode each IP packet into one or more SNDUs with no SNDU containing pieces of more than one IP packet, and to pad out the last SNDU of the packet as needed. Bits in a control header added to each SNDU indicate where the data segment belongs in the IP packet. If the subnetwork provides in-order, at-most-once delivery, the header can be as simple as a pair of bits indicating whether the SNDU is the first and/or the last in the IP packet. Alternatively, for subnetworks that do not reorder the fragments of an SNDU, only the last SNDU of the packet could be marked, as this would implicitly
有几种方法可以解决这个问题。第一种方法是将每个IP分组编码成一个或多个SNDU，其中没有SNDU包含多个IP分组的片段，并根据需要填充分组的最后一个SNDU。添加到每个SNDU的控制报头中的位指示数据段在IP分组中所属的位置。如果子网按顺序提供，最多一次交付，则报头可以像指示SNDU是IP分组中的第一个和/或最后一个的一对比特一样简单。或者，对于不重新排序SNDU片段的子网络，只能标记数据包的最后一个SNDU，因为这将隐含地进行标记
indicate the next SNDU as the first in a new IP packet. The AAL5 (ATM Adaptation Layer 5) scheme used with ATM is an example of this approach, though it adds other features, including a payload length field and a payload CRC.
将下一个SNDU指示为新IP数据包中的第一个。与ATM一起使用的AAL5（ATM适配层5）方案就是这种方法的一个示例，尽管它添加了其他功能，包括有效负载长度字段和有效负载CRC。
In AAL5, the ATM User-User Indication, which is encoded in the Payload Type field of an ATM cell, indicates the last cell of a packet. The packet trailer is located at the end of the SNDU and contains the packet length and a CRC.
在AAL5中，在ATM信元的有效负载类型字段中编码的ATM用户指示表示数据包的最后一个信元。数据包尾部位于SNDU的末端，包含数据包长度和CRC。
Another framing technique is to insert per-segment overhead to indicate the presence of a segment option. When present, the option carries a pointer to the end of the packet. This differs from AAL5 in that it permits another packet to follow within the same segment. MPEG-2 Transport Streams [EN301192] [ISO13818] support this style of fragmentation, and may either use padding (limiting each MPEG transport stream packet to carry only part of one IP packet), or allow a second IP packet to start in the same Transport Stream packet (no padding).
另一种成帧技术是插入每段开销，以指示是否存在段选项。当存在时，该选项携带一个指向数据包末尾的指针。这与AAL5的不同之处在于，它允许在同一段中跟随另一个数据包。MPEG-2传输流[EN301192][ISO13818]支持这种类型的分段，并且可以使用填充（限制每个MPEG传输流数据包仅携带一个IP数据包的一部分），或者允许第二个IP数据包在同一传输流数据包中启动（无填充）。
A third approach is to insert a special flag sequence into the data stream between each IP packet, and to pack the resulting data stream into SNDUs without regard to SNDU boundaries. This may have implications when frames are lost. The flag sequence can also pad unused space at the end of an SNDU. If the special flag appears in the user data, it is escaped to an alternate sequence (usually larger than a flag) to avoid being misinterpreted as a flag. The HDLC-based framing schemes used in PPP are all examples of this approach.
第三种方法是在每个IP分组之间的数据流中插入一个特殊的标志序列，并将得到的数据流打包到SNDU中，而不考虑SNDU边界。当帧丢失时，这可能会产生影响。标志序列还可以在SNDU的末尾填充未使用的空间。如果特殊标志出现在用户数据中，则将其转义为备用序列（通常大于标志），以避免被误解为标志。PPP中使用的基于HDLC的成帧方案都是这种方法的示例。
All three adaptation schemes introduce overhead; how much depends on the distribution of IP packet sizes, the size(s) of the SNDUs, and in the HDLC-like approaches, the content of the IP packet (since flag-like sequences occurring in the packet must be escaped, which expands them). The designer must also weigh implementation complexity and performance in the choice and design of an adaptation layer.
所有三种自适应方案都会引入开销；多少取决于IP数据包大小的分布、SNDU的大小，以及在类似HDLC的方法中，IP数据包的内容（因为数据包中出现的类似标志的序列必须转义，这会扩展它们）。在选择和设计适配层时，设计者还必须权衡实现的复杂性和性能。
IP has no notion of a "connection"; it is a purely connectionless protocol. When a connection is required by an application, it is usually provided by TCP [RFC793], the Transmission Control Protocol, running atop IP on an end-to-end basis.
IP没有“连接”的概念；它是一个纯粹的无连接协议。当应用程序需要连接时，通常由TCP[RFC793]提供，TCP[RFC793]是一种传输控制协议，在端到端的基础上运行于IP之上。
Connection-oriented subnetworks can be (and are widely) used to carry IP, but often with considerable complexity. Subnetworks consisting of few nodes can simply open a permanent connection between each pair of nodes. This is frequently done with ATM. However, the number of connections increases as the square of the number of nodes, so this
面向连接的子网可以（并且被广泛）用于承载IP，但通常具有相当的复杂性。由几个节点组成的子网络可以简单地在每对节点之间打开一个永久连接。这通常是通过ATM完成的。但是，连接数随着节点数的平方而增加，因此
is clearly impractical for large subnetworks. A "shim" layer between IP and the subnetwork is therefore required to manage connections. This is one of the most common functions of a Subnetwork Dependent Convergence Function (SNDCF) sublayer between IP and a subnetwork.
对于大型子网来说，这显然是不切实际的。因此，IP和子网之间需要一个“垫片”层来管理连接。这是IP和子网之间的子网相关收敛函数（SNDCF）子层最常见的函数之一。
SNDCFs typically open subnetwork connections as needed when an IP packet is queued for transmission and close them after an idle timeout. There is no relation between subnetwork connections and any connections that may exist at higher layers (e.g., TCP).
SNDCF通常在IP数据包排队等待传输时根据需要打开子网连接，并在空闲超时后关闭它们。子网络连接和可能存在于更高层（例如TCP）的任何连接之间没有关系。
Because Internet traffic is typically bursty and transaction-oriented, it is often difficult to pick an optimal idle timeout. If the timeout is too short, subnetwork connections are opened and closed rapidly, possibly over-stressing the subnetwork connection management system (especially if it was designed for voice traffic call holding times). If the timeout is too long, subnetwork connections are idle much of the time, wasting any resources dedicated to them by the subnetwork.
由于Internet流量通常是突发性的和面向事务的，因此通常很难选择最佳空闲超时。如果超时时间太短，子网连接会快速打开和关闭，这可能会对子网连接管理系统造成过大压力（特别是如果它是为语音通信呼叫保持时间而设计的）。如果超时时间过长，则子网络连接大部分时间处于空闲状态，从而浪费子网络专用于它们的任何资源。
Purely connectionless subnets (such as Ethernet), which have no state and dynamically share resources, are optimal for supporting best-effort IP, which is stateless and dynamically shares resources. Connection-oriented packet networks (such as ATM and Frame Relay), which have state and dynamically share resources, are less optimal, since best-effort IP does not benefit from the overhead of creating and maintaining state. Connection-oriented circuit-switched networks (including the PSTN and ISDN) have state and statically allocate resources for a call, and thus require state creation and maintenance overhead, but do not benefit from the efficiencies of statistical multiplexing sharing of capacity inherent in IP.
纯无连接的子网（如以太网）没有状态且动态共享资源，最适合支持无状态且动态共享资源的尽力而为IP。面向连接的分组网络（如ATM和帧中继）具有状态并动态共享资源，其优化程度较低，因为尽力而为IP不会从创建和维护状态的开销中获益。面向连接的电路交换网络（包括PSTN和ISDN）具有状态并静态地为呼叫分配资源，因此需要状态创建和维护开销，但不能从IP固有的容量统计复用共享效率中获益。
In any event, if an SNDCF that opens and closes subnet connections is used to support IP, care should be taken to make sure that connection processing in the subnet can keep up with relatively short holding times.
在任何情况下，如果使用打开和关闭子网连接的SNDCF来支持IP，则应注意确保子网中的连接处理能够跟上相对较短的保持时间。
Subnetworks fall into two categories: point-to-point and shared. A point-to-point subnet has exactly two endpoint components (hosts or routers); a shared link has more than two endpoint components, using either an inherently broadcast medium (e.g., Ethernet, radio) or a switching layer hidden from the network layer (e.g., switched Ethernet, Myrinet [MYR95], ATM). Switched subnetworks handle broadcast by copying broadcast packets, providing each interface that supports one, or more, systems (hosts or routers) with a copy of each packet.
子网络分为两类：点对点和共享。点到点子网正好有两个端点组件（主机或路由器）；共享链路具有两个以上的端点组件，使用固有的广播媒体（例如，以太网、无线电）或隐藏在网络层之外的交换层（例如，交换以太网、Myrinet[MYR95]、ATM）。交换子网通过复制广播包来处理广播，为支持一个或多个系统（主机或路由器）的每个接口提供每个包的副本。
Several Internet protocols for IPv4 make use of broadcast capabilities, including link-layer address lookup (ARP), auto-configuration (RARP, BOOTP, DHCP), and routing (RIP).
IPv4的几种Internet协议利用广播功能，包括链路层地址查找（ARP）、自动配置（RARP、BOOTP、DHCP）和路由（RIP）。
A lack of broadcast capability can impede the performance of these protocols, or render them inoperable (e.g., DHCP). ARP-like link address lookup can be provided by a centralized database, but at the expense of potentially higher response latency and the need for nodes to have explicit knowledge of the ARP server address. Shared links should support native, link-layer subnet broadcast.
缺乏广播功能可能会妨碍这些协议的性能，或使其无法运行（例如DHCP）。集中式数据库可以提供类似ARP的链接地址查找，但代价可能是更高的响应延迟，并且节点需要明确了解ARP服务器地址。共享链接应支持本地链接层子网广播。
A corresponding set of IPv6 protocols uses multicasting (see next section) instead of broadcasting to provide similar functions with improved scaling in large networks.
一组相应的IPv6协议使用多播（见下一节）而不是广播来提供类似的功能，并在大型网络中改进了扩展性。
The Internet model includes "multicasting", where IP packets are sent to all the members of a multicast group [RFC1112] [RFC3376] [RFC2710]. Multicast is an option in IPv4, but a standard feature of IPv6. IPv4 multicast is currently used by multimedia, teleconferencing, gaming, and file distribution (web, peer-to-peer sharing) applications, as well as by some key network and host protocols (e.g., RIPv2, OSPF, NTP). IPv6 additionally relies on multicast for network configuration (DHCP-like autoconfiguration) and link-layer address discovery [RFC2461] (replacing ARP). In the case of IPv6, this can allow autoconfiguration and address discovery to span across routers, whereas the IPv4 broadcast-based services cannot without ad-hoc router support [RFC1812].
Internet模型包括“多播”，其中IP数据包被发送到多播组[RFC1112][RFC3376][RFC2710]的所有成员。多播是IPv4中的一个选项，但却是IPv6的标准功能。IPv4多播目前用于多媒体、电话会议、游戏和文件分发（web、对等共享）应用程序，以及一些关键网络和主机协议（如RIPv2、OSPF、NTP）。IPv6还依赖多播进行网络配置（类似DHCP的自动配置）和链路层地址发现[RFC2461]（取代ARP）。在IPv6的情况下，这可以允许自动配置和地址发现跨越路由器，而基于IPv4广播的服务离不开特设路由器的支持[RFC1812]。
Multicast-enabled IP routers organize each multicast group into a spanning tree, and route multicast packets by making copies of each multicast packet and forwarding the copies to each output interface that includes at least one downstream member of the multicast group.
启用多播的IP路由器将每个多播组组织到生成树中，并通过制作每个多播分组的副本并将副本转发到包括多播组的至少一个下游成员的每个输出接口来路由多播分组。
Multicasting is considerably more efficient when a subnetwork explicitly supports it. For example, a router relaying a multicast packet onto an Ethernet segment need send only one copy of the packet, no matter how many members of the multicast group are connected to the segment. Without native multicast support, routers and switches on shared links would need to use broadcast with software filters, such that every multicast packet sent incurs software overhead for every node on the subnetwork, even if a node is not a member of the multicast group. Alternately, the router would transmit a separate copy to every member of the multicast group on the segment, as is done on multicast-incapable switched subnets.
当子网明确支持多播时，多播的效率要高得多。例如，将多播分组中继到以太网段的路由器只需要发送该分组的一个副本，而不管多播组有多少成员连接到该段。如果没有本机多播支持，共享链路上的路由器和交换机将需要使用带有软件过滤器的广播，这样发送的每个多播数据包都会导致子网上每个节点的软件开销，即使节点不是多播组的成员。或者，路由器将向段上的多播组的每个成员发送一个单独的副本，就像在不能多播的交换子网上所做的那样。
Subnetworks using shared channels (e.g., radio LANs, Ethernets) are especially suitable for native multicasting, and their designers should make every effort to support it. This involves designating a section of the subnetwork's own address space for multicasting. On these networks, multicast is basically broadcast on the medium, with Layer-2 receiver filters.
使用共享信道的子网（如无线局域网、以太网）特别适合本机多播，其设计者应尽一切努力支持本机多播。这涉及到为多播指定子网自身地址空间的一部分。在这些网络上，多播基本上是通过第二层接收器过滤器在媒体上广播的。
Subnet interfaces also need to be designed to accept packets addressed to some number of multicast addresses, in addition to the unicast packets specifically addressed to them. The number of multicast addresses that needs to be supported by a host depends on the requirements of the associated host; at least several dozen will meet most current needs.
子网接口还需要设计为除了专门针对特定多播地址的单播数据包之外，还可以接受多播地址的数据包。主机需要支持的多播地址的数量取决于相关主机的要求；至少几十个将满足大多数当前的需求。
On low-speed networks, the multicast address recognition function may be readily implemented in host software, but on high-speed networks, it should be implemented in subnetwork hardware. This hardware need not be complete; for example, many Ethernet interfaces implement a "hashing" function where the IP layer receives all of the multicast (and unicast) traffic to which the associated host subscribes, plus some small fraction of multicast traffic to which the host does not subscribe. Host/router software then has to discard the unwanted packets that pass the Layer-2 multicast address filter [RFC1112].
在低速网络上，多播地址识别功能可能很容易在主机软件中实现，但在高速网络上，它应该在子网络硬件中实现。这个硬件不需要是完整的；例如，许多以太网接口实现“哈希”功能，其中IP层接收关联主机订阅的所有多播（和单播）流量，以及主机未订阅的一小部分多播流量。然后，主机/路由器软件必须丢弃通过第二层多播地址过滤器[RFC1112]的不需要的数据包。
There does not need to be a one-to-one mapping between a Layer-2 multicast address and an IP multicast address. An address overlap may significantly degrade the filtering capability of a receiver's hardware multicast address filter. A subnetwork supporting only broadcast should use this service for multicast and must rely on software filtering.
第二层多播地址和IP多播地址之间不需要一对一的映射。地址重叠可显著降低接收器的硬件多播地址过滤器的过滤能力。仅支持广播的子网应将此服务用于多播，并且必须依赖软件过滤。
Switched subnetworks must also provide a mechanism for copying multicast packets to ensure the packets reach at least all members of a multicast group. One option is to "flood" multicast packets in the same manner as broadcast. This can lead to unnecessary transmissions on some subnetwork links (notably non-multicast-aware Ethernet switches). Some subnetworks therefore allow multicast filter tables to control which links receive packets belonging to a specific group. To configure this automatically requires access to Layer-3 group membership information (e.g., IGMP [RFC3376], or MLD [RFC2710]). Various implementation options currently exist to provide a subnet node with a list of mappings of multicast addresses to ports/interfaces. These employ a range of approaches, including signaling from end hosts (e.g., IEEE 802 GARP/GMRP [802.1p]), signaling from switches (e.g., CGMP [CGMP] and RGMP [RFC3488]), interception and proxy of IP group membership packets (e.g., IGMP/MLD Proxy [MAGMA-PROXY]), and enabling Layer-2 devices to snoop/inspect/peek into forwarded Layer-3 protocol headers (e.g.,
交换子网还必须提供复制多播数据包的机制，以确保数据包至少到达多播组的所有成员。一种选择是以与广播相同的方式“泛滥”多播数据包。这可能会导致在某些子网络链路（尤其是非多播感知以太网交换机）上进行不必要的传输。因此，一些子网允许多播筛选器表控制哪些链路接收属于特定组的数据包。要自动配置，需要访问第3层组成员信息（例如，IGMP[RFC3376]或MLD[RFC2710]）。目前存在各种实现选项，为子网节点提供多播地址到端口/接口的映射列表。它们采用一系列方法，包括来自终端主机的信令（例如，IEEE 802 GARP/GMRP[802.1p]）、来自交换机的信令（例如，CGMP[CGMP]和RGMP[RFC3488]）、IP组成员数据包的拦截和代理（例如，IGMP/MLD代理[MAGMA-proxy]），以及使第2层设备能够窥探/检查/窥视转发的第3层协议头（例如。，
IGMP, MLD, PIM) so that they may infer Layer-3 multicast group membership [MAGMA-SNOOP]. These approaches differ in their complexity, flexibility, and ability to support new protocols.
IGMP、MLD、PIM），以便他们可以推断第三层多播组成员身份[MAGMA-SNOOP]。这些方法的复杂性、灵活性和支持新协议的能力各不相同。
Some subnets allow a number of subnet nodes to share a channel efficiently by assigning transmission opportunities dynamically. Transmission opportunities are requested by a subnet node when it has packets to send. The subnet schedules and grants transmission opportunities sufficient to allow the transmitting subnet node to send one or more packets (or packet fragments). We call these subnets Bandwidth on Demand (BoD) subnets. Examples of BoD subnets include Demand Assignment Multiple Access (DAMA) satellite and terrestrial wireless networks, IEEE 802.11 point coordination function (PCF) mode, and DOCSIS. A connection-oriented network (such as the PSTN, ATM or Frame Relay) reserves resources on a much longer timescale, and is therefore not a BoD subnet in our taxonomy.
一些子网通过动态分配传输机会，允许多个子网节点高效地共享信道。当子网节点有数据包要发送时，它会请求传输机会。子网调度并授予足够的传输机会，以允许传输子网节点发送一个或多个数据包（或数据包片段）。我们称这些子网为按需带宽（BoD）子网。BoD子网的示例包括按需分配多址（DAMA）卫星和地面无线网络、IEEE 802.11点协调功能（PCF）模式和DOCSIS。面向连接的网络（如PSTN、ATM或帧中继）在更长的时间尺度上保留资源，因此在我们的分类中不是BoD子网。
The design parameters for BoD are similar to those in connection-oriented subnetworks, although the implementations may vary significantly. In BoD, the user typically requests access to the shared channel for some duration. Access may be allocated for a period of time at a specific rate, for a certain number of packets, or until the user releases the channel. Access may be coordinated through a central management entity or with a distributed algorithm amongst the users. Examples of the resource that may be shared include a terrestrial wireless hop, an upstream channel in a cable television system, a satellite uplink, and an end-to-end satellite channel.
BoD的设计参数与面向连接的子网中的设计参数类似，尽管实现可能会有很大差异。在BoD中，用户通常在一段时间内请求访问共享通道。可以以特定速率为特定数量的分组分配一段时间的访问，或者直到用户释放信道为止。可通过中央管理实体或通过用户之间的分布式算法来协调访问。可以共享的资源的示例包括地面无线跳、有线电视系统中的上行信道、卫星上行链路和端到端卫星信道。
Long-delay BoD subnets pose problems similar to connection-oriented subnets in anticipating traffic. While connection-oriented subnets hold idle channels open expecting new data to arrive, BoD subnets request channel access based on buffer occupancy (or expected buffer occupancy) on the sending port. Poor performance will likely result if the sender does not anticipate additional traffic arriving at that port during the time it takes to grant a transmission request. It is recommended that the algorithm have the capability to extend a hold on the channel for data that has arrived after the original request was generated (this may be done by piggybacking new requests on user data).
长延迟BoD子网在预测流量方面与面向连接的子网存在类似的问题。当面向连接的子网保持空闲通道打开并期望新数据到达时，BoD子网基于发送端口上的缓冲区占用（或预期缓冲区占用）请求通道访问。如果发送方在允许传输请求的时间内没有预料到到达该端口的额外流量，则可能会导致性能低下。建议算法能够为原始请求生成后到达的数据扩展通道保持（这可以通过在用户数据上搭载新请求来实现）。
There is a wide variety of BoD protocols available. However, there has been relatively little comprehensive research on the interactions between BoD mechanisms and Internet protocol performance. Research on some specific mechanisms is available (e.g., [AR02]). One item that has been studied is TCP's retransmission timer [KY02]. BoD
有各种各样的BoD协议可用。然而，关于BoD机制与Internet协议性能之间的相互作用的综合研究相对较少。可以对某些特定机制进行研究（例如[AR02]）。研究的一个项目是TCP的重传计时器[KY02]。生化需氧量
systems can cause spurious timeouts when adjusting from a relatively high data rate, to a relatively low data rate. In this case, TCP's transmitted data takes longer to get through the network than predicted by the TCP sender's computed retransmission timeout. Therefore, the TCP sender is prone to resending a segment prematurely.
当从相对较高的数据速率调整到相对较低的数据速率时，系统可能导致虚假超时。在这种情况下，TCP传输的数据通过网络的时间比TCP发送方计算的重传超时所预测的时间长。因此，TCP发送方容易过早地重新发送段。
In the Internet architecture, the ultimate responsibility for error recovery is at the end points [SRC81]. The Internet may occasionally drop, corrupt, duplicate, or reorder packets, and the transport protocol (e.g., TCP) or application (e.g., if UDP is used as the transport protocol) must recover from these errors on an end-to-end basis [RFC3155]. Error recovery in the subnetwork is therefore justifiable only to the extent that it can enhance overall performance. It is important to recognize that a subnetwork can go too far in attempting to provide error recovery services in the Internet environment. Subnet reliability should be "lightweight", i.e., it only has to be "good enough", *not* perfect.
在互联网体系结构中，错误恢复的最终责任在端点[SRC81]。互联网偶尔会丢弃、损坏、复制或重新排序数据包，传输协议（如TCP）或应用程序（如UDP用作传输协议）必须在端到端的基础上从这些错误中恢复[RFC3155]。因此，子网中的错误恢复只有在能够提高整体性能的情况下才是合理的。必须认识到，子网络在试图在Internet环境中提供错误恢复服务时可能会走得太远。子网可靠性应该是“轻量级的”，即它只需要“足够好”，而不是“完美”。
In this section, we discuss how to analyze characteristics of a subnetwork to determine what is "good enough". The discussion below focuses on TCP, which is the most widely-used transport protocol in the Internet. It is widely believed (and is a stated goal within the IETF) that non-TCP transport protocols should attempt to be "TCP-friendly" and have many of the same performance characteristics. Thus, the discussion below should be applicable, even to portions of the Internet where TCP may not be the predominant protocol.
在本节中，我们将讨论如何分析子网络的特性，以确定什么是“足够好”。下面讨论的重点是TCP，它是Internet上使用最广泛的传输协议。人们普遍认为（这是IETF中的一个既定目标），非TCP传输协议应尽量做到“TCP友好”，并具有许多相同的性能特征。因此，下面的讨论应该适用，甚至适用于TCP可能不是主要协议的互联网部分。
Error recovery involves the generation and transmission of redundant information computed from user data. Depending on how much redundant information is sent and how it is generated, the receiver can use it to reliably detect transmission errors, correct up to some maximum number of transmission errors, or both. The general approach is known as Error Control Coding, or ECC.
错误恢复涉及从用户数据计算出的冗余信息的生成和传输。根据发送了多少冗余信息以及如何生成冗余信息，接收器可以使用冗余信息可靠地检测传输错误、纠正最大数量的传输错误，或者两者兼而有之。一般的方法称为差错控制编码（ECC）。
The use of ECC to detect transmission errors so that retransmissions (hopefully without errors) can be requested is widely known as "ARQ" (Automatic Repeat Request).
使用ECC来检测传输错误，以便可以请求重新传输（希望没有错误），这被广泛称为“ARQ”（自动重复请求）。
When enough ECC information is available to permit the receiver to correct some transmission errors without a retransmission, the approach is known as Forward Error Correction (FEC). Due to the greater complexity of the required ECC and the need to tailor its design to the characteristics of a specific modem and channel, FEC
当有足够的ECC信息可供使用以允许接收机在不重新传输的情况下纠正某些传输错误时，该方法称为前向纠错（FEC）。由于所需ECC的复杂性更高，并且需要根据特定调制解调器和信道的特性定制其设计，FEC
has traditionally been implemented in special-purpose hardware integral to a modem. This effectively makes it part of the physical layer.
传统上是在调制解调器的专用硬件中实现的。这实际上使其成为物理层的一部分。
Unlike ARQ, FEC was rarely used for telecommunications outside of space links prior to the 1990s. It is now nearly universal in telephone, cable and DSL modems, digital satellite links, and digital mobile telephones. FEC is also heavily used in optical and magnetic storage where "retransmissions" are not possible.
与ARQ不同，FEC在20世纪90年代之前很少用于空间链路以外的电信。它现在几乎在电话、电缆和DSL调制解调器、数字卫星链路和数字移动电话中普及。FEC还大量用于不可能“重新传输”的光存储和磁存储。
Some systems use hybrid combinations of ARQ layered atop FEC; V.90 dialup modems (in the upstream direction) with V.42 error control are one example. Most errors are corrected by the trellis (FEC) code within the V.90 modem, and most remaining errors are detected and corrected by the ARQ mechanisms in V.42.
一些系统使用分层在FEC上的ARQ的混合组合；带有V.42错误控制的V.90拨号调制解调器（在上行方向）就是一个例子。大多数错误由V.90调制解调器内的网格（FEC）代码纠正，其余大多数错误由V.42中的ARQ机制检测和纠正。
Work is now underway to apply FEC above the physical layer, primarily in connection with reliable multicasting [RFC3048] [RFC3450-RFC3453] where conventional ARQ mechanisms are inefficient or difficult to implement. However, in this discussion, we will assume that if FEC is present, it is implemented within the physical layer.
目前，在物理层之上应用FEC的工作正在进行中，主要与可靠的多播[RFC3048][RFC3450-RFC3453]有关，其中传统的ARQ机制效率低下或难以实现。然而，在本讨论中，我们将假设如果存在FEC，它将在物理层中实现。
Depending on the layer in which it is implemented, error control can operate on an end-to-end basis or over a shorter span, such as a single link. TCP is the most important example of an end-to-end protocol that uses an ARQ strategy.
根据实现错误控制的层，错误控制可以在端到端的基础上运行，也可以在较短的范围内运行，例如单个链路。TCP是使用ARQ策略的端到端协议的最重要示例。
Many link-layer protocols use ARQ, usually some flavor of HDLC [ISO3309]. Examples include the X.25 link layer, the AX.25 protocol used in amateur packet radio, 802.11 wireless LANs, and the reliable link layer specified in IEEE 802.2.
许多链路层协议使用ARQ，通常是HDLC[ISO3309]的一些风格。示例包括X.25链路层、业余分组无线电中使用的AX.25协议、802.11无线局域网以及IEEE 802.2中规定的可靠链路层。
Only end-to-end error recovery can ensure reliable service to the application (see Section 8). However, some subnetworks (e.g., many wireless links) also have link-layer error recovery as a performance enhancement [RFC3366]. For example, many cellular links have small physical frame sizes (< 100 bytes) and relatively high frame loss rates. Relying solely on end-to-end error recovery can clearly yield a performance degradation, as retransmissions across the end-to-end path take much longer to be received than when link layer retransmissions are used. Thus, link-layer error recovery can often increase end-to-end performance. As a result, link-layer and end-to-end recovery often co-exist; this can lead to the possibility of inefficient interactions between the two layers of ARQ protocols.
只有端到端错误恢复才能确保为应用程序提供可靠的服务（请参阅第8节）。然而，一些子网（例如，许多无线链路）也将链路层错误恢复作为性能增强[RFC3366]。例如，许多蜂窝链路具有较小的物理帧大小（<100字节）和相对较高的帧丢失率。完全依赖端到端错误恢复显然会导致性能下降，因为跨端到端路径的重传接收时间比使用链路层重传时长得多。因此，链路层错误恢复通常可以提高端到端性能。因此，链路层和端到端恢复常常共存；这可能导致两层ARQ协议之间的低效交互。
This inter-layer "competition" might lead to the following wasteful situation. When the link layer retransmits (parts of) a packet, the link latency momentarily increases. Since TCP bases its
这种层间“竞争”可能导致以下浪费情况。当链路层重新传输（部分）数据包时，链路延迟瞬间增加。由于TCP是其
retransmission timeout on prior measurements of total end-to-end latency, including that of the link in question, this sudden increase in latency may trigger an unnecessary retransmission by TCP of a packet that the link layer is still retransmitting. Such spurious end-to-end retransmissions generate unnecessary load and reduce end-to-end throughput. As a result, the link layer may even have multiple copies of the same packet in the same link queue at the same time. In general, one could say the competing error recovery is caused by an inner control loop (link-layer error recovery) reacting to the same signal as an outer control loop (end-to-end error recovery) without any coordination between the loops. Note that this is solely an efficiency issue; TCP continues to provide reliable end-to-end delivery over such links.
重新传输超时在总端到端延迟（包括所讨论链路的延迟）的先前测量上，延迟的这种突然增加可能触发TCP对链路层仍在重新传输的数据包的不必要的重新传输。这种虚假的端到端重传会产生不必要的负载并降低端到端吞吐量。结果，链路层甚至可以同时在同一链路队列中具有同一分组的多个副本。一般来说，可以说竞争性错误恢复是由内部控制环路（链路层错误恢复）对与外部控制环路（端到端错误恢复）相同的信号作出反应而导致的，而环路之间没有任何协调。请注意，这仅仅是一个效率问题；TCP继续通过这些链路提供可靠的端到端传输。
This raises the question of how persistent a link-layer sender should be in performing retransmission [RFC3366]. We define the link-layer (LL) ARQ persistency as the maximum time that a particular link will spend trying to transfer a packet before it can be discarded. This deliberately simplified definition says nothing about the maximum number of retransmissions, retransmission strategies, queue sizes, queuing disciplines, transmission delays, or the like. The reason we use the term LL ARQ persistency, instead of a term such as "maximum link-layer packet holding time," is that the definition closely relates to link-layer error recovery. For example, on links that implement straightforward error recovery strategies, LL ARQ persistency will often correspond to a maximum number of retransmissions permitted per link-layer frame.
这就提出了一个问题，即链路层发送方在执行重传时应该具有多大的持久性[RFC3366]。我们将链路层（LL）ARQ持久性定义为特定链路在丢弃数据包之前尝试传输数据包的最长时间。这一刻意简化的定义没有说明最大重传次数、重传策略、队列大小、排队规则、传输延迟等。我们使用术语LL ARQ持久性而不是“最大链路层分组保持时间”之类的术语的原因是，该定义与链路层错误恢复密切相关。例如，在实现直接错误恢复策略的链路上，LL-ARQ持久性通常对应于每个链路层帧允许的最大重传次数。
For link layers that do not or cannot differentiate between flows (e.g., due to network layer encryption), the LL ARQ persistency should be small. This avoids any harmful effects or performance degradation resulting from indiscriminate high persistence. A detailed discussion of these issues is provided in [RFC3366].
对于不区分或无法区分流的链路层（例如，由于网络层加密），LL ARQ持久性应较小。这避免了由于不加选择的高持久性而导致的任何有害影响或性能下降。[RFC3366]中详细讨论了这些问题。
However, when a link layer can identify individual flows and apply ARQ selectively [LKJK02], then the link ARQ persistency should be high for a flow using reliable unicast transport protocols (e.g., TCP) and must be low for all other flows. Setting the link ARQ persistency larger than the largest link outage allows TCP to rapidly restore transmission without needing to wait for a retransmission time out. This generally improves TCP performance in the face of transient outages. However, excessively high persistence may be disadvantageous; a practical upper limit of 30-60 seconds may be desirable. Implementation of such schemes remains a research issue. (See also the following section "Recovery from Subnetwork Outages").
然而，当链路层可以识别单个流并有选择地应用ARQ[LKJK02]时，对于使用可靠单播传输协议（例如TCP）的流，链路ARQ持久性应该较高，而对于所有其他流，链路ARQ持久性必须较低。将链路ARQ持久性设置为大于最大链路中断允许TCP快速恢复传输，而无需等待重传超时。这通常会提高TCP在遇到暂时中断时的性能。然而，过高的持久性可能是不利的；可能需要30-60秒的实际上限。这些计划的实施仍然是一个研究问题。（另请参见以下章节“从子网中断中恢复”）。
Many subnetwork designers have opportunities to reduce the probability of packet loss, e.g., with FEC, ARQ, and interleaving, at the cost of increased delay. TCP performance improves with decreasing loss but worsens with increasing end-to-end delay, so it is important to find the proper balance through analysis and simulation.
许多子网设计者有机会降低数据包丢失的概率，例如使用FEC、ARQ和交织，但代价是增加延迟。TCP性能随着丢包的减少而提高，但随着端到端延迟的增加而恶化，因此通过分析和仿真找到合适的平衡点非常重要。
Some types of subnetworks, particularly mobile radio, are subject to frequent temporary outages. For example, an active cellular data user may drive or walk into an area (such as a tunnel) that is out of range of any base station. No packets will be delivered successfully until the user returns to an area with coverage.
某些类型的子网络，特别是移动无线电，经常会发生临时中断。例如，活动蜂窝数据用户可以驾驶或步行进入任何基站范围之外的区域（例如隧道）。在用户返回到覆盖区域之前，不会成功传递数据包。
The Internet protocols currently provide no standard way for a subnetwork to explicitly notify an upper layer protocol (e.g., TCP) that it is experiencing an outage rather than severe congestion.
Internet协议目前没有为子网提供明确通知上层协议（例如TCP）其正在经历中断而不是严重拥塞的标准方式。
Under these circumstances TCP will, after each unsuccessful retransmission, wait even longer before trying again; this is its "exponential back-off" algorithm. Furthermore, TCP will not discover that the subnetwork outage has ended until its next retransmission attempt. If TCP has backed off, this may take some time. This can lead to extremely poor TCP performance over such subnetworks.
在这种情况下，TCP将在每次不成功的重新传输之后，在重试之前等待更长的时间；这是它的“指数退避”算法。此外，在下一次重新传输尝试之前，TCP不会发现子网中断已经结束。如果TCP已退出，这可能需要一些时间。这可能导致此类子网上的TCP性能极低。
It is therefore highly desirable that a subnetwork subject to outages does not silently discard packets during an outage. Ideally, the subnetwork should define an interface to the next higher layer (i.e., IP) that allows it to refuse packets during an outage, and to automatically ask IP for new packets when it is again able to deliver them. If it cannot do this, then the subnetwork should hold onto at least some of the packets it accepts during an outage and attempt to deliver them when the outage ends. When packets are discarded, IP should be notified so that the appropriate ICMP messages can be sent.
因此，极为理想的是，受中断影响的子网在中断期间不会自动丢弃数据包。理想情况下，子网应定义一个到下一更高层（即IP）的接口，该接口允许其在中断期间拒绝数据包，并在再次能够传送数据包时自动向IP请求新数据包。如果它不能做到这一点，那么子网络应该在中断期间保留至少一些它接受的数据包，并在中断结束时尝试传递它们。丢弃数据包时，应通知IP，以便发送适当的ICMP消息。
Note that it is *not* necessary to completely avoid dropping packets during an outage. The purpose of holding onto a packet during an outage, either in the subnetwork or at the IP layer, is so that its eventual delivery will implicitly notify TCP that the subnetwork is again operational. This is to enhance performance, not to ensure reliability -- reliability, as discussed earlier, can only be ensured on an end-to-end basis.
请注意，完全避免在中断期间丢弃数据包*不是*必要的。在中断期间，在子网或IP层保留数据包的目的是，数据包的最终交付将隐含地通知TCP子网再次运行。这是为了提高性能，而不是确保可靠性——正如前面所讨论的，可靠性只能在端到端的基础上得到保证。
Only a few packets per TCP connection, including ACKs, need be held in this way to cause the TCP sender to recover from the additional losses once the flow resumes [RFC3366].
每个TCP连接只需要以这种方式保留少数数据包，包括ACK，以使TCP发送方在流恢复后从额外损失中恢复[RFC3366]。
Because it would be a layering violation (and possibly a performance hit) for IP or a subnetwork layer to look at TCP headers (which would in any event be impossible if IPsec encryption [RFC2401] is in use), it would be reasonable for the IP or subnetwork layers to choose, as a design parameter, some small number of packets that will be retained during an outage.
由于IP或子网络层查看TCP头（如果使用IPsec加密[RFC2401]，在任何情况下都是不可能的），因此IP或子网络层选择作为设计参数是合理的，中断期间将保留的少量数据包。
The TCP [RFC793], UDP [RFC768], ICMP, and IPv4 [RFC791] protocols all use the same simple 16-bit 1's complement checksum algorithm [RFC1071] to detect corrupted packets. The IPv4 header checksum protects only the IPv4 header, while the TCP, ICMP, and UDP checksums provide end-to-end error detection for both the transport pseudo header (including network and transport layer information) and the transport payload data. Protection of the data is optional for applications using UDP [RFC768] for IPv4, but is required for IPv6.
TCP[RFC793]、UDP[RFC768]、ICMP和IPv4[RFC791]协议都使用相同的简单16位1补码校验和算法[RFC1071]来检测损坏的数据包。IPv4报头校验和仅保护IPv4报头，而TCP、ICMP和UDP校验和为传输伪报头（包括网络和传输层信息）和传输有效负载数据提供端到端错误检测。对于使用UDP[RFC768]进行IPv4的应用程序，数据保护是可选的，但对于IPv6则是必需的。
The Internet checksum is not very strong from a coding theory standpoint, but it is easy to compute in software, and various proposals to replace the Internet checksums with stronger checksums have failed. However, it is known that undetected errors can and do occur in packets received by end hosts [SP2000].
从编码理论的角度来看，互联网校验和不是很强，但很容易在软件中计算，用更强的校验和替换互联网校验和的各种建议都失败了。然而，众所周知，终端主机接收的数据包中可能也确实存在未检测到的错误[SP2000]。
To reduce processing costs, IPv6 has no IP header checksum. The destination host detects "important" errors in the IP header, such as the delivery of the packet to the wrong destination. This is done by including the IP source and destination addresses (pseudo header) in the computation of the checksum in the TCP or UDP header, a practice already performed in IPv4. Errors in other IPv6 header fields may go undetected within the network; this was considered a reasonable price to pay for a considerable reduction in the processing required by each router, and it was assumed that subnetworks would use a strong link CRC.
为了降低处理成本，IPv6没有IP报头校验和。目标主机检测IP报头中的“重要”错误，例如将数据包传递到错误的目标。这是通过在TCP或UDP报头中的校验和计算中包含IP源地址和目标地址（伪报头）来实现的，IPv4中已经执行了这种做法。其他IPv6标头字段中的错误可能在网络中未被检测到；这被认为是为大大减少每个路由器所需的处理而付出的合理代价，并且假设子网将使用强链路CRC。
One way to provide additional protection for an IPv4 or IPv6 header is by the authentication and packet integrity services of the IP Security (IPsec) protocol [RFC2401]. However, this may not be a choice available to the subnetwork designer.
为IPv4或IPv6报头提供额外保护的一种方法是通过IP安全（IPsec）协议[RFC2401]的身份验证和数据包完整性服务。但是，这可能不是子网络设计者可用的选择。
Most subnetworks implement error detection just above the physical layer. Packets corrupted in transmission are detected and discarded before delivery to the IP layer. A 16-bit cyclic redundancy check (CRC) is usually the minimum for error detection. This is significantly more robust against most patterns of errors than the 16-bit Internet checksum. Note that the error detection properties of a specific CRC code diminish with increasing frame size. The Point-to-Point Protocol [RFC1662] requires support of a 16-bit CRC
大多数子网在物理层上实现错误检测。传输中损坏的数据包在传送到IP层之前被检测并丢弃。16位循环冗余校验（CRC）通常是错误检测的最小值。与16位互联网校验和相比，它对大多数错误模式的鲁棒性明显更强。请注意，特定CRC码的错误检测特性随着帧大小的增加而减小。点对点协议[RFC1662]需要支持16位CRC
for each link frame, with a 32-bit CRC as an option. (PPP is often used in conjunction with a dialup modem, which provides its own error control). Other subnetworks, including 802.3/Ethernet, AAL5/ATM, FDDI, Token Ring, and PPP over SONET/SDH all use a 32-bit CRC. Many subnetworks can also use other mechanisms to enhance the error detection capability of the link CRC (e.g., FEC in dialup modems, mobile radio and satellite channels).
对于每个链路帧，使用32位CRC作为选项。（PPP通常与拨号调制解调器结合使用，拨号调制解调器提供自己的错误控制）。其他子网，包括802.3/Ethernet、AAL5/ATM、FDDI、令牌环和SONET/SDH上的PPP都使用32位CRC。许多子网还可以使用其他机制来增强链路CRC的错误检测能力（例如，拨号调制解调器、移动无线电和卫星信道中的FEC）。
Any new subnetwork designed to carry IP should therefore provide error detection for each IP packet that is at least as strong as the 32-bit CRC specified in [ISO3309]. While this will achieve a very low undetected packet error rate due to transmission errors, it will not (and need not) achieve a very low packet loss rate as the Internet protocols are better suited to dealing with lost packets than to dealing with corrupted packets [SRC81].
因此，任何设计用于承载IP的新子网都应为每个IP数据包提供错误检测，该数据包的强度至少与[ISO3309]中规定的32位CRC相同。虽然由于传输错误，这将实现非常低的未检测到的数据包错误率，但它不会（也不需要）实现非常低的数据包丢失率，因为互联网协议更适合处理丢失的数据包，而不是处理损坏的数据包[SRC81]。
Packet corruption may be, and is, also caused by bugs in host and router hardware and software. Even if every subnetwork implemented strong error detection, it is still essential that end-to-end checksums are used at the receiving end host [SP2000].
数据包损坏也可能是由主机和路由器硬件和软件中的错误引起的。即使每个子网都实现了强错误检测，在接收端主机上使用端到端校验和仍然是至关重要的[SP2000]。
Designers of complex subnetworks consisting of internal links and packet switches should consider implementing error detection on an edge-to-edge basis to cover an entire SNDU (or IP packet). A CRC would be generated at the entry point to the subnetwork and checked at the exit endpoint. This may be used instead of, or in combination with, error detection at the interface to each physical link. An edge-to-edge check has the significant advantage of protecting against errors introduced anywhere within the subnetwork, not just within its transmission links. Examples of this approach include the way in which the Ethernet CRC-32 is handled by LAN bridges [802.1D]. ATM AAL5 [ITU-I363] also uses an edge-to-edge CRC-32.
由内部链路和分组交换机组成的复杂子网的设计者应该考虑在边缘到边缘的基础上实现错误检测，以覆盖整个SNDU（或IP分组）。CRC将在子网的入口点生成，并在出口端点进行检查。这可以代替或与每个物理链路接口处的错误检测结合使用。边到边检查具有防止子网络中任何地方引入的错误的显著优势，而不仅仅是在其传输链路中引入的错误。这种方法的示例包括以太网CRC-32由LAN网桥处理的方式[802.1D]。ATM AAL5[ITU-I363]也使用边到边CRC-32。
Some specific applications may be tolerant of residual errors in the data they exchange, but removal of the link CRC may expose the network to an undesirable increase in undetected errors in the IP and transport headers. Applications may also require a high level of error protection for control information exchanged by protocols acting above the transport layer. One example is a voice codec, which is robust against bit errors in the speech samples. For such mechanisms to work, the receiving application must be able to tolerate receiving corrupted data. This also requires that an application uses a mechanism to signal that payload corruption is permitted and to indicate the coverage (headers and data) required to be protected by the subnetwork CRC. The UDP-Lite protocol [RFC3828] is the first Internet standards track transport protocol supporting partial payload protection. Receipt of corrupt data by arbitrary
一些特定的应用程序可以容忍它们交换的数据中的残余错误，但是删除链路CRC可能使网络暴露于IP和传输报头中未检测到的错误的不希望的增加。应用程序还可能需要对传输层之上的协议交换的控制信息进行高级别的错误保护。一个例子是语音编解码器，它对语音样本中的位错误具有鲁棒性。要使这些机制工作，接收应用程序必须能够容忍接收损坏的数据。这还要求应用程序使用一种机制来发出允许有效负载损坏的信号，并指示子网CRC需要保护的覆盖范围（报头和数据）。UDP Lite协议[RFC3828]是第一个支持部分有效负载保护的互联网标准轨道传输协议。任意用户接收损坏的数据
application protocols carries a serious danger that a subnet delivers data with errors that remain undetected by the application and hence corrupt the communicated data [SRC81].
应用程序协议带来了一种严重的危险，即子网交付的数据中存在应用程序无法检测到的错误，因此会损坏通信数据[SRC81]。
One of TCP's functions is end-host based congestion control for the Internet. This is a critical part of the overall stability of the Internet, so it is important that link-layer designers understand TCP's congestion control algorithms.
TCP的功能之一是基于终端主机的Internet拥塞控制。这是互联网整体稳定性的关键部分，因此链路层设计者了解TCP的拥塞控制算法非常重要。
TCP assumes that, at the most abstract level, the network consists of links and queues. Queues provide output-buffering on links that are momentarily oversubscribed. They smooth instantaneous traffic bursts to fit the link bandwidth. When demand exceeds link capacity long enough to fill the queue, packets must be dropped. The traditional action of dropping the most recent packet ("tail dropping") is no longer recommended [RFC2309] [RFC2914], but it is still widely practiced.
TCP假定，在最抽象的层次上，网络由链路和队列组成。队列为暂时超额订阅的链接提供输出缓冲。它们平滑瞬时流量突发以适应链路带宽。当需求超过链路容量足以填满队列时，必须丢弃数据包。不再推荐删除最新数据包的传统操作（“尾部删除”），但仍然广泛使用[RFC2309][RFC2914]。
TCP uses sequence numbering and acknowledgments (ACKs) on an end-to-end basis to provide reliable, sequenced delivery. TCP ACKs are cumulative, i.e., each implicitly ACKs every segment received so far. If a packet with an unexpected sequence number is received, the ACK field in the packets returned by the receiver will cease to advance. Using an optional enhancement, TCP can send selective acknowledgments (SACKs) [RFC2018] to indicate which segments have arrived at the receiver.
TCP在端到端的基础上使用序列编号和确认（ACKs），以提供可靠、有序的交付。TCP确认是累积的，即每个隐式地确认到目前为止接收到的每个段。如果接收到具有意外序列号的数据包，则接收器返回的数据包中的ACK字段将停止前进。使用可选增强功能，TCP可以发送选择性确认（SACK）[RFC2018]以指示哪些段已到达接收器。
Since the most common cause of packet loss is congestion, TCP treats packet loss as an indication of potential Internet congestion along the path between TCP end hosts. This happens automatically, and the subnetwork need not know anything about IP or TCP. A subnetwork node simply drops packets whenever it must, though some packet-dropping strategies (e.g., RED) are more fair to competing flows than others.
由于数据包丢失的最常见原因是拥塞，TCP将数据包丢失视为TCP终端主机之间路径上潜在Internet拥塞的指示。这是自动发生的，子网不需要知道任何关于IP或TCP的信息。子网节点只是在必要时丢弃数据包，尽管某些数据包丢弃策略（如RED）对竞争流更公平。
TCP recovers from packet losses in two different ways. The most important mechanism is the retransmission timeout. If an ACK fails to arrive after a certain period of time, TCP retransmits the oldest unacked packet. Taking this as a hint that the network is congested, TCP waits for the retransmission to be ACKed before it continues, and it gradually increases the number of packets in flight as long as a timeout does not occur again.
TCP以两种不同的方式从数据包丢失中恢复。最重要的机制是重传超时。如果ACK在一段时间后未能到达，TCP将重新传输最早的未确认数据包。将此视为网络拥塞的提示，TCP等待重新传输确认后再继续，并且只要不再发生超时，它就会逐渐增加正在传输的数据包数量。
A retransmission timeout can impose a significant performance penalty, as the sender is idle during the timeout interval and restarts with a congestion window of one TCP segment following the
由于发送方在超时时间间隔内处于空闲状态，并在传输结束后的一个TCP段的拥塞窗口中重新启动，因此重传超时可能会造成严重的性能损失
timeout. To allow faster recovery from the occasional lost packet in a bulk transfer, an alternate scheme, known as "fast recovery", was introduced [RFC2581] [RFC2582] [RFC2914] [TCPF98].
超时。为了能够更快地从批量传输中偶尔丢失的数据包中恢复，引入了一种称为“快速恢复”的替代方案[RFC2581][RFC2582][RFC2914][TCPF98]。
Fast recovery relies on the fact that when a single packet is lost in a bulk transfer, the receiver continues to return ACKs to subsequent data packets that do not actually acknowledge any newly-received data. These are known as "duplicate acknowledgments" or "dupacks". The sending TCP can use dupacks as a hint that a packet has been lost and retransmit it without waiting for a timeout. Dupacks effectively constitute a negative acknowledgment (NAK) for the packet sequence number in the acknowledgment field. TCP waits until a certain number of dupacks (currently 3) are seen prior to assuming a loss has occurred; this helps avoid an unnecessary retransmission during out-of-sequence delivery.
快速恢复依赖于这样一个事实，即当一个数据包在批量传输中丢失时，接收方继续向后续数据包返回ack，这些数据包实际上不确认任何新接收的数据。这些被称为“重复确认”或“重复确认”。发送TCP可以使用DUPACK作为数据包丢失的提示，并在不等待超时的情况下重新传输数据包。Dupacks有效地构成了确认字段中数据包序列号的否定确认（NAK）。TCP会等到看到一定数量的重复包（目前为3个）后再假设发生了丢失；这有助于避免在无序传递期间进行不必要的重新传输。
A technique called "Explicit Congestion Notification" (ECN) [RFC3168] allows routers to directly signal congestion to hosts without dropping packets. This is done by setting a bit in the IP header. Since ECN support is likely to remain optional, the lack of an ECN bit must *never* be interpreted as a lack of congestion. Thus, for the foreseeable future, TCP must interpret a lost packet as a signal of congestion.
一种称为“显式拥塞通知”（ECN）[RFC3168]的技术允许路由器直接向主机发送拥塞信号，而无需丢弃数据包。这是通过在IP头中设置一个位来完成的。由于ECN支持可能仍然是可选的，因此缺少ECN位必须“永远”解释为缺少拥塞。因此，在可预见的未来，TCP必须将丢失的数据包解释为拥塞信号。
The TCP "congestion avoidance" [RFC2581] algorithm maintains a congestion window (cwnd) controlling the amount of data TCP may have in flight at any moment. Reducing cwnd reduces the overall bandwidth obtained by the connection; similarly, raising cwnd increases performance, up to the limit of the available capacity.
TCP“拥塞避免”[RFC2581]算法维护一个拥塞窗口（cwnd），控制TCP在任何时刻可能拥有的数据量。减少cwnd会减少连接获得的总带宽；类似地，提高cwnd可以提高性能，达到可用容量的极限。
TCP probes for available network capacity by initially setting cwnd to one or two packets and then increasing cwnd by one packet for each ACK returned from the receiver. This is TCP's "slow start" mechanism. When a packet loss is detected (or congestion is signaled by other mechanisms), cwnd is reset to one and the slow start process is repeated until cwnd reaches one half of its previous setting before the reset. Cwnd continues to increase past this point, but at a much slower rate than before. If no further losses occur, cwnd will ultimately reach the window size advertised by the receiver.
TCP通过最初将cwnd设置为一个或两个数据包，然后针对从接收器返回的每个ACK将cwnd增加一个数据包来探测可用的网络容量。这是TCP的“慢启动”机制。当检测到数据包丢失（或其他机制发出拥塞信号）时，cwnd重置为1，并重复慢启动过程，直到cwnd达到重置前其先前设置的一半。Cwnd继续增加超过这一点，但速度比以前慢得多。如果没有进一步的损失发生，cwnd最终将达到接收方公布的窗口大小。
This is an "Additive Increase, Multiplicative Decrease" (AIMD) algorithm. The steep decrease of cwnd in response to congestion provides for network stability; the AIMD algorithm also provides for fairness between long running TCP connections sharing the same path.
这是一种“加法递增，乘法递减”（AIMD）算法。cwnd因拥塞而急剧减少，从而保证了网络的稳定性；AIMD算法还提供共享同一路径的长时间运行的TCP连接之间的公平性。
Caveat
警告
Here we present a current "state-of-the-art" understanding of TCP performance. This analysis attempts to characterize the performance of TCP connections over links of varying characteristics.
这里，我们介绍了当前对TCP性能的“最新”理解。此分析试图描述不同特性链路上TCP连接的性能。
Link designers may wish to use the techniques in this section to predict what performance TCP/IP may achieve over a new link-layer design. Such analysis is encouraged. Because this is a relatively new analysis, and the theory is based on single-stream TCP connections under "ideal" conditions, it should be recognized that the results of such analysis may differ from actual performance in the Internet. That being said, we have done our best to provide the designers with helpful information to get an accurate picture of the capabilities and limitations of TCP under various conditions.
链路设计者可能希望使用本节中的技术来预测TCP/IP在新的链路层设计中可能实现的性能。鼓励进行这种分析。由于这是一个相对较新的分析，并且该理论基于“理想”条件下的单流TCP连接，因此应该认识到，此类分析的结果可能与Internet中的实际性能不同。也就是说，我们已经尽了最大努力为设计人员提供有用的信息，以便准确了解TCP在各种条件下的功能和局限性。
The performance of TCP's AIMD Congestion Avoidance algorithm has been extensively analyzed. The current best formula for the performance of the specific algorithms used by Reno TCP (i.e., the TCP specified in [RFC2581]) is given by Padhye, et al. [PFTK98]. This formula is:
对TCP的AIMD拥塞避免算法的性能进行了广泛的分析。Padhye等人[PFTK98]给出了雷诺TCP使用的特定算法（即[RFC2581]中规定的TCP）性能的当前最佳公式。这个公式是：
MSS
BW = --------------------------------------------------------
RTT*sqrt(1.33*p) + RTO*p*[1+32*p^2]*min[1,3*sqrt(.75*p)]
MSS
BW = --------------------------------------------------------
RTT*sqrt(1.33*p) + RTO*p*[1+32*p^2]*min[1,3*sqrt(.75*p)]
where
哪里
BW is the maximum TCP throughout achievable by an individual TCP flow MSS is the TCP segment size being used by the connection RTT is the end-to-end round trip time of the TCP connection RTO is the packet timeout (based on RTT) p is the packet loss rate for the path (i.e., .01 if there is 1% packet loss)
BW是单个TCP流可实现的最大TCP吞吐量MSS是连接使用的TCP段大小RTT是TCP连接的端到端往返时间RTO是数据包超时（基于RTT）p是路径的数据包丢失率（即，如果数据包丢失率为1%，则为.01）
Note that the speed of the links making up the Internet path does not explicitly appear in this formula. Attempting to send faster than the slowest link in the path causes the queue to grow at the transmitter driving the bottleneck. This increases the RTT, which in turn reduces the achievable throughput.
请注意，构成Internet路径的链接的速度在此公式中没有明确显示。尝试以比路径中最慢的链路更快的速度发送会导致在驱动瓶颈的发送器处队列增长。这会增加RTT，进而降低可实现的吞吐量。
This is currently considered to be the best approximate formula for Reno TCP performance. A further simplification of this formula is generally made by assuming that RTO is approximately 5*RTT.
目前，这被认为是雷诺TCP性能的最佳近似公式。通常通过假设RTO约为5*RTT来进一步简化该公式。
TCP is constantly being improved. A simpler formula, which gives an upper bound on the performance of any AIMD algorithm which is likely to be implemented in TCP in the future, was derived by Ott, et al. [MSMO97].
TCP正在不断改进。Ott等人推导了一个更简单的公式，该公式给出了未来可能在TCP中实现的任何AIMD算法的性能上限。[MSMO97]。
MSS 1
BW = C --- -------
RTT sqrt(p)
MSS 1
BW = C --- -------
RTT sqrt(p)
where C is 0.93.
其中C是0.93。
Both formulae assume that the TCP Receiver Window is not limiting the performance of the connection. Because the receiver window is entirely determined by end-hosts, we assume that hosts will maximize the announced receiver window to maximize their network performance.
这两个公式都假定TCP接收器窗口不会限制连接的性能。由于接收器窗口完全由终端主机决定，因此我们假设主机将最大化公布的接收器窗口以最大化其网络性能。
Both of these formulae allow BW to become infinite if there is no loss. However, an Internet path will drop packets at bottlenecked queues if the load is too high. Thus, a completely lossless TCP/IP network can never occur (unless the network is being underutilized).
如果没有损失，这两个公式都允许BW变为无穷大。但是，如果负载过高，Internet路径将在瓶颈队列中丢弃数据包。因此，完全无损的TCP/IP网络永远不会出现（除非网络未充分利用）。
The RTT used is the arithmetic average, including queuing delays.
使用的RTT是算术平均值，包括排队延迟。
The formulae are for a single TCP connection. If a path carries many TCP connections, each will follow the formulae above independently.
这些公式适用于单个TCP连接。如果一条路径承载多个TCP连接，则每个连接将独立地遵循上述公式。
The formulae assume long-running TCP connections. For connections that are extremely short (<10 packets) and don't lose any packets, performance is driven by the TCP slow-start algorithm. For connections of medium length, where on average only a few segments are lost, single connection performance will actually be slightly better than given by the formulae above.
这些公式假设长时间运行的TCP连接。对于极短（<10个数据包）且不丢失任何数据包的连接，性能由TCP慢速启动算法驱动。对于中等长度的连接件，平均只有几段丢失，单连接件的性能实际上略优于上述公式给出的性能。
The difference between the simple and complex formulae above is that the complex formula includes the effects of TCP retransmission timeouts. For very low levels of packet loss (significantly less than 1%), timeouts are unlikely to occur, and the formulae lead to very similar results. At higher packet losses (1% and above), the complex formula gives a more accurate estimate of performance (which will always be significantly lower than the result from the simple formula).
上述简单公式和复杂公式的区别在于，复杂公式包括TCP重传超时的影响。对于极低级别的数据包丢失（显著小于1%），不太可能发生超时，公式得出的结果非常相似。在较高的数据包丢失率（1%及以上）下，复杂公式给出了更准确的性能估计（这将始终显著低于简单公式的结果）。
Note that these formulae break down as p approaches 100%.
注意，当p接近100%时，这些公式会分解。
Consider the following example:
考虑下面的例子：
A designer invents a new wireless link layer which, on average, loses 1% of IP packets. The link layer supports packets of up to 1040 bytes, and has a one-way delay of 20 msec.
一位设计师发明了一种新的无线链路层，它平均会丢失1%的IP数据包。链路层支持高达1040字节的数据包，单向延迟为20毫秒。
If this link were to be used on an Internet path with a round trip time greater than 80ms, the upper bound may be computed by:
如果在往返时间大于80ms的互联网路径上使用该链路，则上限可通过以下公式计算：
For MSS, use 1000 bytes to exclude the 40 bytes of minimum IPv4 and TCP headers.
对于MSS，使用1000字节排除最小IPv4和TCP头的40字节。
For RTT, use 120 msec (80 msec for the Internet part, plus 20 msec each way for the new wireless link).
对于RTT，使用120毫秒（对于Internet部分为80毫秒，对于新的无线链路，每条路加20毫秒）。
For p, use .01. For C, assume 1.
对于p，使用.01。对于C，假设1。
The simple formula gives:
简单的公式给出：
BW = (1000 * 8 bits) / (.120 sec * sqrt(.01)) = 666 kbit/sec
BW = (1000 * 8 bits) / (.120 sec * sqrt(.01)) = 666 kbit/sec
The more complex formula gives:
更复杂的公式给出：
BW = 402.9 kbit/sec
BW=402.9千比特/秒
If this were a 2 Mb/s wireless LAN, the designers might be somewhat disappointed.
如果这是一个2MB/s的无线局域网，设计者可能会有些失望。
Some observations on performance:
关于业绩的一些意见：
1. We have assumed that the packet losses on the link layer are interpreted as congestion by TCP. This is a "fact of life" that must be accepted.
1. 我们假设链路层上的数据包丢失被TCP解释为拥塞。这是必须接受的“生活事实”。
2. The equations for TCP performance are all expressed in terms of packet loss, but many subnetwork designers think in terms of bit-error ratio. *If* channel bit errors are independent, then the probability of a packet being corrupted is:
2. TCP性能的方程都是用数据包丢失来表示的，但许多子网设计者都是用误码率来考虑的*如果*信道比特错误是独立的，则数据包被破坏的概率为：
p = 1 - ([1 - BER]^[FRAME_SIZE*8])
p = 1 - ([1 - BER]^[FRAME_SIZE*8])
Here we assume FRAME_SIZE is in bytes and "^" represents exponentiation. It includes the user data and all headers (TCP,IP and subnetwork). (Note: this analysis assumes the
这里我们假设帧_大小以字节为单位，“^”表示幂运算。它包括用户数据和所有标头（TCP、IP和子网络）。（注：本分析假设
subnetwork does not perform ARQ or transparent fragmentation [RFC3366].) If the inequality
子网不执行ARQ或透明分段[RFC3366]），如果
BER * [FRAME_SIZE*8] << 1
BER * [FRAME_SIZE*8] << 1
holds, the packet loss probability p can be approximated by:
保持，分组丢失概率p可近似为：
p = BER * [FRAME_SIZE*8]
p = BER * [FRAME_SIZE*8]
These equations can be used to apply BER to the performance equations above.
这些方程可用于将BER应用于上述性能方程。
Note that FRAME_SIZE can vary from one packet to the next. Small packets (such as TCP acks) generally have a smaller probability of packet error than, say, a TCP packet carrying one MSS (maximum segment size) of user data. A flow of small TCP acks can be expected to be slightly more reliable than a stream of larger TCP data segments.
请注意，帧大小可能因数据包而异。小数据包（例如TCP ACK）通常比承载一个MSS（最大段大小）用户数据的TCP数据包具有更小的数据包错误概率。小型TCP确认流可能比大型TCP数据段流更可靠。
It bears repeating that the above analysis assumes that bit errors are statistically independent. Because this is not true for many real links, our computation of p is actually an upper bound, not the exact probability of packet loss.
值得重复的是，上述分析假设比特错误在统计上是独立的。因为这对于许多实际链路是不正确的，所以我们对p的计算实际上是一个上界，而不是包丢失的确切概率。
There are many reasons why bit errors are not independent on real links. Many radio links are affected by propagation fading or by interference that lasts over many bit times. Also, links with Forward Error Correction (FEC) generally have very non-uniform bit error distributions that depend on the type of FEC, but in general the uncorrected errors tend to occur in bursts even when channel symbol errors are independent. In all such cases, our computation of p from BER can only place an upper limit on the packet loss rate.
比特错误与实际链路无关的原因有很多。许多无线链路受到传播衰落或持续多位时间的干扰的影响。此外，具有前向纠错（FEC）的链路通常具有非常不均匀的比特错误分布，这取决于FEC的类型，但是通常，即使信道符号错误是独立的，未经校正的错误也往往以突发的形式出现。在所有这些情况下，我们从BER计算p只能对丢包率设置一个上限。
If the distribution of errors under the FEC scheme is known, one could apply the same type of analysis as above, using the correct distribution function for the BER. It is more likely in these FEC cases, however, that empirical methods are needed to determine the actual packet loss rate.
如果已知FEC方案下的错误分布，则可以应用与上述相同类型的分析，使用正确的BER分布函数。然而，在这些FEC情况下，更可能需要经验方法来确定实际的分组丢失率。
3. Note that the packet size plays an important role. If the subnetwork loss characteristics are such that large packets have the same probability of loss as smaller packets, then larger packets will yield improved performance.
3. 请注意，数据包大小起着重要作用。如果子网丢失特性使得大数据包与小数据包具有相同的丢失概率，则大数据包将产生改进的性能。
4. We have chosen a specific RTT that might occur on a wide-area Internet path within the USA. It is important to recognize that a variety of RTT values are experienced in the Internet.
4. 我们选择了一种可能发生在美国广域互联网路径上的特定RTT。认识到互联网上存在各种RTT值是很重要的。
For example, RTTs are typically less than 10 msec in a wired LAN environment when communicating with a local host. International connections may have RTTs of 200 msec or more. Modems and other low-capacity links can add considerable delay due to their long packet transmission (serialisation) times.
例如，在有线LAN环境中，当与本地主机通信时，RTT通常小于10毫秒。国际连接可能具有200毫秒或以上的RTT。由于数据包传输（串行化）时间长，调制解调器和其他低容量链路可能会增加相当大的延迟。
Links over geostationary repeater satellites have one-way speed-of-light delays of around 250ms, a minimum of 125ms propagation delay up to the satellite and 125ms down. The RTT of an end-to-end TCP connection that includes such a link can be expected to be greater than 250ms.
地球同步转发器卫星上的链路具有约250ms的单向光速延迟，到卫星的传播延迟至少为125ms，向下的传播延迟至少为125ms。包含此类链路的端到端TCP连接的RTT预计将大于250ms。
Queues on heavily-congested links may back up, increasing RTTs. Finally, virtual private networks (VPNs) and other forms of encryption and tunneling can add significant end-to-end delay to network connections.
严重拥挤链路上的队列可能会备份，从而增加RTT。最后，虚拟专用网络（VPN）和其他形式的加密和隧道可以为网络连接增加显著的端到端延迟。
It is generally recognized that specific service guarantees are needed to support real-time multimedia, toll-quality telephony, and other performance-critical applications. The provision of such Quality of Service guarantees in the Internet is an active area of research and standardization. The IETF has not converged on a single service model, set of services, or single mechanism that will offer useful guarantees to applications and be scalable to the Internet. Indeed, the IETF does not have a single definition of Quality of Service. [RFC2990] represents a current understanding of the challenges in architecting QoS for the Internet.
人们普遍认为，支持实时多媒体、收费质量电话和其他性能关键型应用程序需要特定的服务保证。在互联网上提供这种服务质量保证是一个活跃的研究和标准化领域。IETF还没有融合到一个单一的服务模型、服务集或单一的机制上，这些服务模型、服务集或机制将为应用程序提供有用的保证，并可扩展到Internet。事实上，IETF对服务质量没有一个单一的定义。[RFC2990]代表了当前对互联网QoS架构挑战的理解。
There are presently two architectural approaches to providing mechanisms for QoS support in the Internet.
目前有两种体系结构方法来提供Internet中的QoS支持机制。
IP Integrated Services (Intserv) [RFC1633] provides fine-grained service guarantees to individual flows. Flows are identified by a flow specification (flowspec), which creates a stateful association between individual packets by matching fields in the packet header. Capacity is reserved for the flow, and appropriate traffic conditioning and scheduling is installed in routers along the path. The ReSerVation Protocol (RSVP) [RFC2205] [RFC2210] is usually, but need not necessarily be, used to install the flow QoS state. Intserv defines two services, in addition to the Default (best effort) service.
IP集成服务（Intserv）[RFC1633]为单个流提供细粒度服务保证。流由流规范（flowspec）标识，该规范通过匹配数据包头中的字段在各个数据包之间创建有状态关联。为流量预留容量，并在路径沿线的路由器中安装适当的流量调节和调度。保留协议（RSVP）[RFC2205][RFC2210]通常用于安装流QoS状态，但不一定需要。除了默认的（尽力而为）服务外，Intserv还定义了两个服务。
1. Guaranteed Service (GS) [RFC2212] offers hard upper bounds on delay to flows that conform to a traffic specification (TSpec). It uses a fluid-flow model to relate the TSpec and reserved bandwidth (RSpec) to variable delay. Non-conforming packets are forwarded on a best-effort basis.
1. 保证服务（GS）[RFC2212]为符合流量规范（TSpec）的流提供严格的延迟上限。它使用流体模型将TSpec和预留带宽（RSpec）与可变延迟联系起来。不符合要求的数据包将尽最大努力转发。
2. Controlled Load Service (CLS) [RFC2211] offers delay and packet loss equivalent to that of an unloaded network to flows that conform to a TSpec, but no hard bounds. Non-conforming packets are forwarded on a best-effort basis.
2. 受控负载服务（CLS）[RFC2211]为符合TSpec但无硬边界的流提供与未加载网络相同的延迟和数据包丢失。不符合要求的数据包将尽最大努力转发。
Intserv requires installation of state information in every participating router. Performance guarantees cannot be made unless this state is present in every router along the path. This, along with RSVP processing and the need for usage-based accounting, is believed to have scalability problems, particularly in the core of the Internet [RFC2208].
Intserv要求在每个参与路由器中安装状态信息。除非路径上的每个路由器都存在此状态，否则无法提供性能保证。这与RSVP处理和基于使用的计费需求一起，被认为存在可伸缩性问题，特别是在互联网的核心[RFC2208]。
IP Differentiated Services (Diffserv) [RFC2475] provides a "toolkit" offering coarse-grained controls to aggregates of flows. Diffserv in itself does *not* provide QoS guarantees, but can be used to construct services with QoS guarantees across a Diffserv domain. Diffserv attempts to address the scaling issues associated with Intserv by requiring state awareness only at the edge of a Diffserv domain. At the edge, packets are classified into flows, and the flows are conditioned (marked, policed, or shaped) to a traffic conditioning specification (TCS). A Diffserv Codepoint (DSCP), identifying a per-hop behavior (PHB), is set in each packet header. The DSCP is carried in the DS-field, subsuming six bits of the former Type-of-Service (ToS) byte [RFC791] of the IP header [RFC2474]. The PHB denotes the forwarding behavior to be applied to the packet in each node in the Diffserv domain. Although there is a "recommended" DSCP associated with each PHB, the mappings from DSCPs to PHBs are defined by the DS-domain. In fact, there can be several DSCPs associated with the same PHB. Diffserv presently defines three PHBs.
IP区分服务（Diffserv）[RFC2475]提供了一个“工具包”，为流的聚合提供粗粒度的控制。Diffserv本身*不*提供QoS保证，但可用于跨Diffserv域构造具有QoS保证的服务。Diffserv试图通过仅在Diffserv域的边缘要求状态感知来解决与Intserv相关的扩展问题。在边缘处，分组被分类为流，并且流根据流量调节规范（TCS）进行调节（标记、策略或成形）。在每个数据包报头中设置识别每跳行为（PHB）的区分服务码点（DSCP）。DSCP在DS字段中携带，包含IP报头[RFC2474]的前一服务类型（ToS）字节[RFC791]的六位。PHB表示要应用于Diffserv域中每个节点中的数据包的转发行为。尽管每个PHB都有一个“推荐”的DSCP，但从DSCP到PHB的映射是由DS域定义的。事实上，可以有多个DSCP与同一PHB关联。Diffserv目前定义了三个PHB。
1. The class selector PHB [RFC2474] replaces the IP precedence field of the former ToS byte. It offers relative forwarding priorities.
1. 类选择器PHB[RFC2474]替换前ToS字节的IP优先级字段。它提供了相对的转发优先级。
2. The Expedited Forwarding (EF) PHB [RFC3246] [RFC3248] guarantees that packets will have a well-defined minimum departure rate which, if not exceeded, ensures that the associated queues are short or empty. EF is intended to support services that offer tightly-bounded loss, delay, and delay jitter.
2. 快速转发（EF）PHB[RFC3246][RFC3248]保证数据包将具有定义明确的最小离开速率，如果不超过该速率，将确保相关队列短或空。EF旨在支持提供紧密有界损失、延迟和延迟抖动的服务。
3. The Assured Forwarding (AF) PHB group [RFC2597] offers different levels of forwarding assurance for each aggregated flow of packets. Each AF group is independently allocated forwarding resources. Packets are marked with one of three drop precedences; those with the highest drop precedence are dropped with lower probability than those marked with the lowest drop precedence. DSCPs are recommended for four independent AF groups, although a DS domain can have more or fewer AF groups.
3. 保证转发（AF）PHB组[RFC2597]为每个聚合的数据包流提供不同级别的转发保证。每个AF组被独立地分配转发资源。数据包标记有三个丢弃先例中的一个；那些具有最高丢弃优先级的被丢弃的概率低于那些具有最低丢弃优先级的被丢弃的概率。建议将DSCP用于四个独立的AF组，尽管DS域可以有更多或更少的AF组。
Ongoing work in the IETF is addressing ways to support Intserv with Diffserv. There is some belief (e.g., as expressed in [RFC2990]) that such an approach will allow individual flows to receive service guarantees and scale to the global Internet.
IETF中正在进行的工作是解决使用Diffserv支持Intserv的方法。有人相信（如[RFC2990]中所述），这种方法将允许单个流获得服务保证并扩展到全球互联网。
The QoS guarantees that can be offered by the IP layer are a product of two factors:
IP层可以提供的QoS保证是两个因素的产物：
1. the concatenation of the QoS guarantees offered by the subnets along the path of a flow. This implies that a subnet may wish to offer multiple services (with different QoS guarantees) to the IP layer, which can then determine which flows use which subnet service. To put it another way, forwarding behavior in the subnet needs to be "clued" by the forwarding behavior (service or PHB) at the IP layer, and
1. 子网沿流路径提供的QoS保证的串联。这意味着子网可能希望向IP层提供多个服务（具有不同的QoS保证），然后IP层可以确定哪些流使用哪个子网服务。换句话说，子网中的转发行为需要由IP层的转发行为（服务或PHB）来“确定”，并且
2. the operation of a set of cooperating mechanisms, such as bandwidth reservation and admission control, policy management, traffic classification, traffic conditioning (marking, policing and/or shaping), selective discard, queuing, and scheduling. Note that support for QoS in subnets may require similar mechanisms, especially when these subnets are general topology subnets (e.g., ATM, frame relay, or MPLS) or shared media subnets.
2. 一组协作机制的操作，如带宽预留和接纳控制、策略管理、流量分类、流量调节（标记、管理和/或整形）、选择性丢弃、排队和调度。请注意，子网中对QoS的支持可能需要类似的机制，特别是当这些子网是一般拓扑子网（例如ATM、帧中继或MPLS）或共享媒体子网时。
Many subnetwork designers face inherent tradeoffs between delay, throughput, reliability, and cost. Other subnetworks have parameters that manage bandwidth, internal connection state, and the like. Therefore, the following subnetwork capabilities may be desirable, although some might be trivial or moot if the subnet is a dedicated point-to-point link.
许多子网设计者面临延迟、吞吐量、可靠性和成本之间的内在权衡。其他子网具有管理带宽、内部连接状态等的参数。因此，以下子网功能可能是可取的，尽管如果子网是专用的点到点链路，则有些功能可能微不足道或没有意义。
1. The subnetwork should have the ability to reserve bandwidth for a connection or flow and schedule packets accordingly.
1. 子网应该能够为连接或流保留带宽，并相应地调度数据包。
2. Bandwidth reservations should be based on a one- or two-token bucket model, depending on whether the service is intended to support constant-rate or bursty traffic.
2. 带宽预留应基于一个或两个令牌桶模型，这取决于服务是支持恒定速率还是突发流量。
3. If a connection or flow does not use its reserved bandwidth at a given time, the unused bandwidth should be available for other flows.
3. 如果连接或流在给定时间未使用其保留带宽，则未使用的带宽应可用于其他流。
4. Packets in excess of a connection or flow's agreed rate should be forwarded as best-effort or discarded, depending on the service offered by the subnet to the IP layer.
4. 超过连接或流约定速率的数据包应尽最大努力转发或丢弃，具体取决于子网向IP层提供的服务。
5. If a subnet contains error control mechanisms (retransmission and/or FEC), it should be possible for the IP layer to influence the inherent tradeoffs between uncorrected errors, packet losses, and delay. These capabilities at the subnet/IP layer service boundary correspond to selection of more or less error control and/or to selection of particular error control mechanisms within the subnetwork.
5. 如果子网包含错误控制机制（重传和/或FEC），则IP层可能会影响未纠正错误、数据包丢失和延迟之间的固有权衡。子网/IP层服务边界处的这些功能对应于或多或少的错误控制的选择和/或子网内特定错误控制机制的选择。
6. The subnet layer should know, and be able to inform the IP layer, how much fixed delay and delay jitter it offers for a flow or connection. If the Intserv model is used, the delay jitter component may be best expressed in terms of the TSpec/RSpec model described in [RFC2212].
6. 子网层应该知道并能够通知IP层它为流或连接提供了多少固定延迟和延迟抖动。如果使用Intserv模型，则延迟抖动分量可以用[RFC2212]中所述的TSpec/RSpec模型来最好地表示。
7. Support of the Diffserv class selectors [RFC2474] suggests that the subnet might consider mechanisms that support priorities.
7. DiffServ类选择器[RFC2474]的支持表明子网可以考虑支持优先级的机制。
Subnetwork designers should be aware of the tradeoffs between fairness and efficiency inherent in many transmission scheduling algorithms. For example, many local area networks use contention protocols to resolve access to a shared transmission channel. These protocols represent overhead. While limiting the amount of data that a subnet node may transmit per contention cycle helps assure timely access to the channel for each subnet node, it also increases contention overhead per unit of data sent.
子网设计者应注意许多传输调度算法中固有的公平性和效率之间的权衡。例如，许多局域网使用竞争协议来解决对共享传输信道的访问。这些协议表示开销。虽然限制子网节点每个争用周期可能传输的数据量有助于确保每个子网节点对通道的及时访问，但它也会增加每个发送数据单元的争用开销。
In some mobile radio networks, capacity is limited by interference, which in turn depends on average transmitter power. Some receivers may require considerably more transmitter power (generating more interference and consuming more channel capacity) than others.
在一些移动无线电网络中，容量受到干扰的限制，而干扰又取决于发射机的平均功率。一些接收机可能需要比其他接收机多得多的发射机功率（产生更多干扰并消耗更多信道容量）。
In each case, the scheduling algorithm designer must balance competing objectives: providing a fair share of capacity to each subnet node while maximizing the total capacity of the network. One approach for balancing performance and fairness is outlined in [ES00].
在每种情况下，调度算法设计者必须平衡竞争目标：为每个子网节点提供公平的容量份额，同时最大化网络的总容量。[ES00]中概述了一种平衡性能和公平性的方法。
The TCP sender bases its retransmission timeout (RTO) on measurements of the round trip delay experienced by previous packets. This allows TCP to adapt automatically to the very wide range of delays found on the Internet. The recommended algorithms are described in [RFC2988]. Evaluations of TCP's retransmission timer can be found in [AP99] and [LS00].
TCP发送方将其重传超时（RTO）基于先前数据包经历的往返延迟的测量值。这使得TCP能够自动适应互联网上的大范围延迟。[RFC2988]中描述了推荐的算法。TCP重传计时器的评估可在[AP99]和[LS00]中找到。
These algorithms model the delay along an Internet path as a normally-distributed random variable with a slowly-varying mean and standard deviation. TCP estimates these two parameters by exponentially smoothing individual delay measurements, and it sets the RTO to the estimated mean delay plus some fixed number of standard deviations. (The algorithm actually uses mean deviation as an approximation to standard deviation, because it is easier to compute.)
这些算法将互联网路径上的延迟建模为正态分布的随机变量，具有缓慢变化的平均值和标准偏差。TCP通过指数平滑单个延迟测量来估计这两个参数，并将RTO设置为估计的平均延迟加上一些固定数量的标准偏差。（该算法实际上使用平均偏差作为标准偏差的近似值，因为它更容易计算。）
The goal is to compute an RTO that is small enough to detect and recover from packet losses while minimizing unnecessary ("spurious") retransmissions when packets are unexpectedly delayed but not lost. Although these goals conflict, the algorithm works well when the delay variance along the Internet path is low, or the packet loss rate is low.
目标是计算一个RTO，该RTO足够小，可以检测和恢复数据包丢失，同时在数据包意外延迟但未丢失时最小化不必要的（“虚假”）重传。虽然这些目标相互冲突，但当沿因特网路径的延迟变化较低或丢包率较低时，该算法工作良好。
If the path delay variance is high, TCP sets an RTO that is much larger than the mean of the measured delays. If the packet loss rate is low, the large RTO is of little consequence, as timeouts occur only rarely. Conversely, if the path delay variance is low, then TCP recovers quickly from lost packets; again, the algorithm works well. However, when delay variance and the packet loss rate are both high, these algorithms perform poorly, especially when the mean delay is also high.
如果路径延迟方差很高，TCP设置的RTO远远大于测量延迟的平均值。如果丢包率较低，则较大的RTO影响不大，因为超时很少发生。相反，如果路径延迟方差较低，则TCP会从丢失的数据包中快速恢复；同样，该算法运行良好。然而，当时延方差和丢包率都较高时，这些算法的性能较差，尤其是当平均时延也较高时。
Because TCP uses returning acknowledgments as a "clock" to time the transmission of additional data, excessively high delays (even if the delay variance is low) also affect TCP's ability to fully utilize a high-speed transmission pipe. It also slows the recovery of lost packets, even when delay variance is small.
由于TCP使用返回确认作为“时钟”来计时额外数据的传输，因此过高的延迟（即使延迟方差很低）也会影响TCP充分利用高速传输管道的能力。即使延迟变化很小，它也会减慢丢失数据包的恢复速度。
Subnetwork designers should therefore minimize all three parameters (delay, delay variance, and packet loss) as much as possible.
因此，子网设计者应该尽可能地最小化所有三个参数（延迟、延迟变化和数据包丢失）。
In many subnetworks, these parameters are inherently in conflict. For example, on a mobile radio channel, the subnetwork designer can use retransmission (ARQ) and/or forward error correction (FEC) to trade off delay, delay variance, and packet loss in an effort to improve TCP performance. While ARQ increases delay variance, FEC
在许多子网中，这些参数本质上是冲突的。例如，在移动无线信道上，子网设计者可以使用重传（ARQ）和/或前向纠错（FEC）来权衡延迟、延迟方差和分组丢失，以努力改进TCP性能。当ARQ增加延迟方差时，FEC
does not. However, FEC (especially when combined with interleaving) often increases mean delay, even on good channels where ARQ retransmissions are not needed and ARQ would not increase either the delay or the delay variance.
没有。然而，FEC（特别是与交织结合时）通常会增加平均延迟，即使在不需要ARQ重传且ARQ不会增加延迟或延迟方差的良好信道上也是如此。
The tradeoffs among these error control mechanisms and their interactions with TCP can be quite complex, and are the subject of much ongoing research. We therefore recommend that subnetwork designers provide as much flexibility as possible in the implementation of these mechanisms, and provide access to them as discussed above in the section on Quality of Service.
这些差错控制机制之间的权衡及其与TCP的交互可能相当复杂，并且是许多正在进行的研究的主题。因此，我们建议子网设计者在实施这些机制时提供尽可能多的灵活性，并提供访问这些机制的途径，如上文关于服务质量的部分所述。
Some subnetworks may provide asymmetric bandwidth (or may cause TCP packet flows to experience asymmetry in the capacity) and the Internet protocol suite will generally still work fine. However, there is a case when such a scenario reduces TCP performance. Since TCP data segments are "clocked" out by returning acknowledgments, TCP senders are limited by the rate at which ACKs can be returned [BPK98]. Therefore, when the ratio of the available capacity of the Internet path carrying the data to the bandwidth of the return path of the acknowledgments is too large, the slow return of the ACKs directly impacts performance. Since ACKs are generally smaller than data segments, TCP can tolerate some asymmetry, but as a general rule, designers of subnetworks should be aware that subnetworks with significant asymmetry can result in reduced performance, unless issues are taken to mitigate this [RFC3449].
一些子网可能提供不对称带宽（或可能导致TCP数据包流的容量不对称），Internet协议套件通常仍能正常工作。但是，这种情况会降低TCP性能。由于TCP数据段是通过返回确认来“计时”的，因此TCP发送方受到可返回确认的速率的限制[BPK98]。因此，当承载数据的因特网路径的可用容量与应答返回路径的带宽之比太大时，应答的缓慢返回直接影响性能。由于ACK通常比数据段小，TCP可以容忍一些不对称，但作为一般规则，子网设计者应意识到，具有显著不对称的子网可能会导致性能降低，除非采取措施缓解这种情况[RFC3449]。
Several strategies have been identified for reducing the impact of asymmetry of the network path between two TCP end hosts, e.g., [RFC3449]. These techniques attempt to reduce the number of ACKs transmitted over the return path (low bandwidth channel) by changes at the end host(s), and/or by modification of subnetwork packet forwarding. While these solutions may mitigate the performance issues caused by asymmetric subnetworks, they do have associated cost and may have other implications. A fuller discussion of strategies and their implications is provided in [RFC3449].
已经确定了几种减少两个TCP终端主机之间网络路径不对称影响的策略，例如[RFC3449]。这些技术试图通过改变终端主机和/或修改子网分组转发来减少通过返回路径（低带宽信道）传输的ack的数量。虽然这些解决方案可以缓解由非对称子网引起的性能问题，但它们确实有相关的成本，并且可能有其他影响。[RFC3449]中对战略及其影响进行了更全面的讨论。
Many subnets include multiple links with varying traffic demands and possibly different transmission speeds. At each link there must be a queuing system, including buffering, scheduling, and a capability to discard excess subnet packets. These queues may also be part of a subnet flow control or congestion control scheme.
许多子网包括具有不同流量需求和可能不同传输速度的多条链路。在每个链路上都必须有一个排队系统，包括缓冲、调度和丢弃多余子网数据包的能力。这些队列也可能是子网流量控制或拥塞控制方案的一部分。
For the purpose of this discussion, we talk about packets without regard to whether they refer to a complete IP packet or a subnetwork frame. At each queue, a packet experiences a delay that depends on competing traffic and the scheduling discipline, and is subjected to a local discarding policy.
在本讨论中，我们讨论数据包时不考虑它们是指完整的IP数据包还是子网帧。在每个队列中，数据包都会经历一个延迟，该延迟取决于竞争流量和调度规则，并受到本地丢弃策略的约束。
Some subnets may have flow or congestion control mechanisms in addition to packet dropping. Such mechanisms can operate on components in the subnet layer, such as schedulers, shapers, or discarders, and can affect the operation of IP forwarders at the edges of the subnet. However, with the exception of Explicit Congestion Notification [RFC3168] (discussed below), IP has no way to pass explicit congestion or flow control signals to TCP.
除了丢包之外，一些子网可能还具有流量或拥塞控制机制。这种机制可以在子网层的组件上运行，如调度器、整形器或丢弃器，并且可以影响子网边缘的IP转发器的运行。但是，除了显式拥塞通知[RFC3168]（下文讨论）之外，IP无法将显式拥塞或流控制信号传递给TCP。
TCP traffic, especially aggregated TCP traffic, is bursty. As a result, instantaneous queue depths can vary dramatically, even in nominally stable networks. For optimal performance, packets should be dropped in a controlled fashion, not just when buffer space is unavailable. How much buffer space should be supplied is still a matter of debate, but as a rule of thumb, each node should have enough buffering to hold one link_bandwidth*link_delay product's worth of data for each TCP connection sharing the link.
TCP流量，尤其是聚合TCP流量，是突发的。因此，即使在名义上稳定的网络中，瞬时队列深度也会发生巨大变化。为了获得最佳性能，应该以可控的方式丢弃数据包，而不仅仅是在缓冲区空间不可用时。应该提供多少缓冲区空间仍然是一个争论的问题，但根据经验，每个节点都应该有足够的缓冲区来容纳共享该链路的每个TCP连接的一个链路带宽*链路延迟乘积的数据。
This is often difficult to estimate, since it depends on parameters beyond the subnetwork's control or knowledge. Internet nodes generally do not implement admission control policies, and cannot limit the number of TCP connections that use them. In general, it is wise to err in favor of too much buffering rather than too little. It may also be useful for subnets to incorporate mechanisms that measure propagation delays to assist in buffer sizing calculations.
这通常很难估计，因为它取决于超出子网络控制或知识范围的参数。Internet节点通常不实现准入控制策略，并且不能限制使用它们的TCP连接数。一般来说，明智的做法是选择缓冲太多而不是太少。对于子网来说，将测量传播延迟的机制结合起来，以帮助进行缓冲区大小计算也是有用的。
There is a rough consensus in the research community that active queue management is important to improving fairness, link utilization, and throughput [RFC2309]. Although there are questions and concerns about the effectiveness of active queue management (e.g., [MBDL99]), it is widely considered an improvement over tail-drop discard policies.
研究界大致一致认为，主动队列管理对于提高公平性、链路利用率和吞吐量非常重要[RFC2309]。尽管对主动队列管理（例如[MBDL99]）的有效性存在疑问和担忧，但它被广泛认为是对尾部丢弃策略的改进。
One form of active queue management is the Random Early Detection (RED) algorithm [RED93], a family of related algorithms. In one version of RED, an exponentially-weighted moving average of the queue depth is maintained:
主动队列管理的一种形式是随机早期检测（RED）算法[RED93]，这是一系列相关算法。在RED的一个版本中，保持队列深度的指数加权移动平均值：
When this average queue depth is between a maximum threshold max_th and a minimum threshold min_th, the probability of packets that are dropped is proportional to the amount by which the average queue depth exceeds min_th.
当此平均队列深度介于最大阈值max_th和最小阈值min_th之间时，丢弃数据包的概率与平均队列深度超过min_th的量成正比。
When this average queue depth is equal to max_th, the drop probability is equal to a configurable parameter max_p.
当此平均队列深度等于max_th时，丢弃概率等于可配置参数max_p。
When this average queue depth is greater than max_th, packets are always dropped.
当此平均队列深度大于最大值时，数据包总是被丢弃。
Numerous variants on RED appear in the literature, and there are other active queue management algorithms which claim various advantages over RED [GM02].
文献中出现了许多关于RED的变体，并且还有其他主动队列管理算法声称其优于RED[GM02]。
With an active queue management algorithm, dropped packets become a feedback signal to trigger more appropriate congestion behavior by the TCPs in the end hosts. Randomization of dropping tends to break up the observed tendency of TCP windows belonging to different TCP connections to become synchronized by correlated drops, and it also imposes a degree of fairness on those connections that implement TCP congestion avoidance properly. Another important property of active queue management algorithms is that they attempt to keep average queue depths short while accommodating large short-term bursts.
通过主动队列管理算法，丢弃的数据包成为反馈信号，以触发终端主机中的TCP更合适的拥塞行为。丢弃的随机化倾向于打破属于不同TCP连接的TCP窗口被相关丢弃同步的观察趋势，并且它还对那些正确实现TCP拥塞避免的连接施加一定程度的公平性。主动队列管理算法的另一个重要特性是，它们试图保持平均队列深度较短，同时适应大型短期突发事件。
Since TCP neither knows nor cares whether congestive packet loss occurs at the IP layer or in a subnet, it may be advisable for subnets that perform queuing and discarding to consider implementing some form of active queue management. This is especially true if large aggregates of TCP connections are likely to share the same queue. However, active queue management may be less effective in the case of many queues carrying smaller aggregates of TCP connections, e.g., in an ATM switch that implements per-VC queuing.
由于TCP既不知道也不关心拥塞包丢失发生在IP层或子网中，对于执行排队和丢弃的子网，考虑实施某种形式的主动队列管理可能是明智的。如果TCP连接的大型聚合可能共享同一队列，则尤其如此。然而，在许多队列承载较小的TCP连接聚合的情况下，主动队列管理可能不太有效，例如，在实现每VC队列的ATM交换机中。
Note that the performance of active queue management algorithms is highly sensitive to settings of configurable parameters, and also to factors such as RTT [MBB00] [FB00].
请注意，主动队列管理算法的性能对可配置参数的设置以及RTT[MBB00][FB00]等因素非常敏感。
Some subnets, most notably ATM, perform segmentation and reassembly at the subnetwork edges. Care should be taken here in designing discard policies. If the subnet discards a fragment of an IP packet, then the remaining fragments become an unproductive load on the subnet that can markedly degrade end-to-end performance [RF95]. Subnetworks should therefore attempt to discard these extra fragments whenever one of them must be discarded. If the IP packet has already been partially forwarded when discarding becomes necessary, then every remaining fragment except the one marking the end of the IP packet should also be discarded. For ATM subnets, this specifically means using Early Packet Discard and Partial Packet Discard [ATMFTM].
一些子网，尤其是ATM，在子网边缘执行分段和重组。在设计丢弃策略时应注意这一点。如果子网丢弃IP数据包的一个片段，则剩余的片段将成为子网上的非生产性负载，这会显著降低端到端性能[RF95]。因此，每当必须丢弃其中一个片段时，子网络应尝试丢弃这些额外片段。如果在需要丢弃时IP数据包已经部分转发，那么除了标记IP数据包结束的片段外，其余的所有片段也应该丢弃。对于ATM子网，这特别意味着使用早期数据包丢弃和部分数据包丢弃[ATMFTM]。
Some subnets include flow control mechanisms that effectively require that the rate of traffic flows be shaped upon entry to the subnet. One example of such a subnet mechanism is in the ATM Available Bit
一些子网包括流量控制机制，这些机制有效地要求在进入子网时调整流量速率。这种子网机制的一个例子是ATM可用位
rate (ABR) service category [ATMFTM]. Such flow control mechanisms have the effect of making the subnet nearly lossless by pushing congestion into the IP routers at the edges of the subnet. In such a case, adequate buffering and discard policies are needed in these routers to deal with a subnet that appears to have varying bandwidth. Whether there is a benefit in this kind of flow control is controversial; there are numerous simulation and analytical studies that go both ways. It appears that some of the issues leading to such different results include sensitivity to ABR parameters, use of binary rather than explicit rate feedback, use (or not) of per-VC queuing, and the specific ATM switch algorithms selected for the study. Anecdotally, some large networks that used IP over ABR to carry TCP traffic have claimed it to be successful, but have published no results.
速率（ABR）服务类别[ATMFTM]。这种流量控制机制通过将拥塞推送到子网边缘的IP路由器，使子网几乎无损。在这种情况下，在这些路由器中需要足够的缓冲和丢弃策略来处理似乎具有不同带宽的子网。这种流量控制是否有好处存在争议；有许多模拟和分析研究是双向的。似乎导致这些不同结果的一些问题包括对ABR参数的敏感性、使用二进制而非显式速率反馈、使用（或不使用）每VC队列以及为研究选择的特定ATM交换机算法。有趣的是，一些使用IP over ABR传输TCP流量的大型网络声称这是成功的，但没有公布任何结果。
Another possible approach to flow control in the subnet would be to work with TCP Explicit Congestion Notification (ECN) semantics [RFC3168] through utilizing explicit congestion indicators in subnet frames. Routers at the edges of the subnet, rather than shaping, would set the explicit congestion bit in those IP packets that are received in subnet frames that have an ECN indication. Nodes in the subnet would need to implement an active queue management protocol that marks subnet frames instead of dropping them.
子网中流量控制的另一种可能方法是通过在子网帧中使用显式拥塞指示器来使用TCP显式拥塞通知（ECN）语义[RFC3168]。位于子网边缘的路由器（而不是整形）将在那些在具有ECN指示的子网帧中接收的IP数据包中设置显式拥塞位。子网中的节点需要实现一个活动队列管理协议，该协议标记子网帧而不是丢弃它们。
ECN is currently a proposed standard, but it is not yet widely deployed.
ECN目前是一个提议的标准，但尚未广泛部署。
Application data compression is a function that can usually be omitted in the subnetwork. The endpoints typically have more CPU and memory resources to run a compression algorithm and a better understanding of what is being compressed. End-to-end compression benefits every network element in the path, while subnetwork-layer compression, by definition, benefits only a single subnetwork.
应用程序数据压缩是一项在子网中通常可以忽略的功能。端点通常有更多的CPU和内存资源来运行压缩算法，并更好地理解压缩的内容。端到端压缩有益于路径中的每个网络元素，而根据定义，子网层压缩只有益于单个子网。
Data presented to the subnetwork layer may already be in a compressed format (e.g., a JPEG file), compressed at the application layer (e.g., the optional "gzip", "compress", and "deflate" compression in HTTP/1.1 [RFC2616]), or compressed at the IP layer (the IP Payload Compression Protocol [RFC3173] supports DEFLATE [RFC2394] and LZS [RFC2395]). Compression at the subnetwork edges is of no benefit for any of these cases.
呈现给子网络层的数据可能已经是压缩格式（例如，JPEG文件），在应用层压缩（例如，HTTP/1.1[RFC2616]中可选的“gzip”、“compress”和“deflate”压缩），或者在IP层压缩（IP有效载荷压缩协议[RFC3173]支持deflate[RFC2394]和LZS[RFC2395]）。在这些情况下，子网络边缘的压缩对任何一种情况都没有好处。
The subnetwork may also process data that has been encrypted by the application (OpenPGP [RFC2440] or S/MIME [RFC2633]), just above TCP (SSL, TLS [RFC2246]), or just above IP (IPsec ESP [RFC2406]).
子网还可以处理由应用程序加密的数据（OpenPGP[RFC2440]或S/MIME[RFC2633]）、TCP（SSL、TLS[RFC2246]）之上或IP（IPsec ESP[RFC2406]）。
Ciphers generate high-entropy bit streams lacking any patterns that can be exploited by a compression algorithm.
密码生成的高熵比特流缺少任何可被压缩算法利用的模式。
However, much data is still transmitted uncompressed over the Internet, so subnetwork compression may be beneficial. Any subnetwork compression algorithm must not expand uncompressible data, e.g., data that has already been compressed or encrypted.
然而，许多数据仍然在互联网上未经压缩传输，因此子网压缩可能是有益的。任何子网压缩算法不得扩展不可压缩的数据，例如，已压缩或加密的数据。
We make a strong recommendation that subnetworks operating at low speed or with small MTUs compress IP and transport-level headers (TCP and UDP) using several header compression schemes developed within the IETF [RFC3150]. An uncompressed 40-byte TCP/IP header takes about 33 milliseconds to send at 9600 bps. "VJ" TCP/IP header compression [RFC1144] compresses most headers to 3-5 bytes, reducing transmission time to several milliseconds on dialup modem links. This is especially beneficial for small, latency-sensitive packets in interactive sessions.
我们强烈建议以低速或小MTU运行的子网使用IETF[RFC3150]中开发的几种报头压缩方案压缩IP和传输级报头（TCP和UDP）。未压缩的40字节TCP/IP报头以9600 bps的速度发送大约需要33毫秒。“VJ”TCP/IP报头压缩[RFC1144]将大多数报头压缩到3-5字节，从而将拨号调制解调器链路上的传输时间缩短到几毫秒。这对于交互式会话中对延迟敏感的小数据包尤其有益。
Similarly, RTP compression schemes, such as CRTP [RFC2508] and ROHC [RFC3095], compress most IP/UDP/RTP headers to 1-4 bytes. The resulting savings are especially significant when audio packets are kept small to minimize store-and-forward latency.
类似地，RTP压缩方案，如CRTP[RFC2508]和ROHC[RFC3095]，将大多数IP/UDP/RTP头压缩到1-4字节。当音频包保持较小以最小化存储和转发延迟时，由此产生的节省尤其显著。
Designers should consider the effect of the subnetwork error rate on the performance of header compression. TCP ordinarily recovers from lost packets by retransmitting only those packets that were actually lost; packets arriving correctly after a packet loss are kept on a resequencing queue and do not need to be retransmitted. In VJ TCP/IP [RFC1144] header compression, however, the receiver cannot explicitly notify a sender of data corruption and subsequent loss of synchronization between compressor and decompressor. It relies instead on TCP retransmission to re-synchronize the decompressor. After a packet is lost, the decompressor must discard every subsequent packet, even if the subnetwork makes no further errors, until the sending TCP retransmits to re-synchronize the decompressor. This effect can substantially magnify the effect of subnetwork packet losses if the sending TCP window is large, as it will often be on a path with a large bandwidth*delay product [LRKOJ99].
设计人员应考虑子网错误率对报头压缩性能的影响。TCP通常通过只重新传输那些实际丢失的数据包来恢复丢失的数据包；数据包丢失后正确到达的数据包保留在重新排序队列中，不需要重新传输。然而，在VJ TCP/IP[RFC1144]报头压缩中，接收方无法明确通知发送方数据损坏以及压缩器和解压缩器之间的同步丢失。相反，它依赖TCP重新传输来重新同步解压缩程序。数据包丢失后，解压器必须丢弃每个后续数据包，即使子网没有进一步的错误，直到发送TCP重新传输以重新同步解压器。如果发送TCP窗口较大，此效应会显著放大子网数据包丢失的影响，因为它通常位于带宽*延迟乘积较大的路径上[LRKOJ99]。
Alternate header compression schemes, such as those described in [RFC2507], include an explicit request for retransmission of an uncompressed packet to allow decompressor resynchronization without waiting for a TCP retransmission. However, these schemes are not yet in widespread use.
备选报头压缩方案，如[RFC2507]中所述，包括明确请求重新传输未压缩数据包，以允许解压器在不等待TCP重新传输的情况下重新同步。然而，这些方案尚未得到广泛使用。
Both TCP header compression schemes do not compress widely-used TCP options such as selective acknowledgements (SACK). Both fail to compress TCP traffic that makes use of explicit congestion
两种TCP报头压缩方案都不压缩广泛使用的TCP选项，例如选择性确认（SACK）。两者都无法压缩利用显式拥塞的TCP流量
notification (ECN). Work is under way in the IETF ROHC WG to address these shortcomings in a ROHC header compression scheme for TCP [RFC3095] [RFC3096].
通知（ECN）。IETF ROHC工作组正在努力解决TCP[RFC3095][RFC3096]ROHC头压缩方案中的这些缺陷。
The subnetwork error rate also is important for RTP header compression. CRTP uses delta encoding, so a packet loss on the link causes uncertainty about the subsequent packets, which often must be discarded until the decompressor has notified the compressor and the compressor has sent re-synchronizing information. This typically takes slightly more than the end-to-end path round-trip time. For links that combine significant error rates with latencies that require multiple packets to be in flight at a time, this leads to significant error propagation, i.e., subsequent losses caused by an initial loss.
子网错误率对于RTP报头压缩也很重要。CRTP使用增量编码，因此链路上的数据包丢失会导致后续数据包的不确定性，这些数据包通常必须丢弃，直到解压器通知压缩器并且压缩器发送了重新同步信息。这通常比端到端路径往返时间稍长。对于将显著错误率与延迟结合在一起的链路，一次需要传输多个数据包，这会导致显著错误传播，即初始丢失导致的后续损失。
For links that are both high-latency (multiple packets in flight from a typical RTP stream) and error-prone, RTP ROHC provides a more robust way of RTP header compression, at a cost of higher complexity at the compressor and decompressor. For example, within a talk spurt, only extended losses of (depending on the mode chosen) 12-64 packets typically cause error propagation.
对于既有高延迟（来自典型RTP流的多个数据包正在传输）又容易出错的链路，RTP ROHC提供了一种更健壮的RTP报头压缩方式，但代价是压缩机和解压器的复杂性更高。例如，在通话突发中，通常只有12-64个数据包（取决于选择的模式）的扩展丢失会导致错误传播。
The Internet architecture does not guarantee that packets will arrive in the same order in which they were originally transmitted; transport protocols like TCP must take this into account.
互联网架构不保证数据包将以最初传输的相同顺序到达；像TCP这样的传输协议必须考虑到这一点。
However, reordering does come at a cost with TCP as it is currently defined. Because TCP returns a cumulative acknowledgment (ACK) indicating the last in-order segment that has arrived, out-of-order segments cause a TCP receiver to transmit a duplicate acknowledgment. When the TCP sender notices three duplicate acknowledgments, it assumes that a segment was dropped by the network and uses the fast retransmit algorithm [Jac90] [RFC2581] to resend the segment. In addition, the congestion window is reduced by half, effectively halving TCP's sending rate. If a subnetwork reorders segments significantly such that three duplicate ACKs are generated, the TCP sender needlessly reduces the congestion window and performance suffers.
然而，按照TCP目前的定义，重新排序确实要付出代价。由于TCP返回一个累计确认（ACK），指示最后一个到达的顺序段，因此顺序段错误会导致TCP接收器发送重复确认。当TCP发送方注意到三个重复的确认时，它假定网络丢弃了一个段，并使用快速重传算法[Jac90][RFC2581]重新发送该段。此外，拥塞窗口减少了一半，有效地将TCP的发送速率减半。如果子网络对段进行了显著的重新排序，从而生成了三个重复的ack，那么TCP发送方将不必要地减少拥塞窗口，从而影响性能。
Packet reordering frequently occurs in parts of the Internet, and it seems to be difficult or impossible to eliminate [BPS99]. For this reason, research on improving TCP's behavior in the face of packet reordering [LK00] [BA02] has begun.
数据包重新排序经常发生在互联网的某些部分，似乎很难或不可能消除[BPS99]。因此，针对数据包重排序[LK00][BA02]改进TCP行为的研究已经开始。
[BPS99] cites reasons why it may even be undesirable to eliminate reordering. There are situations where average packet latency can be reduced, link efficiency can be increased, and/or reliability can be improved if reordering is permitted. Examples include certain high speed switches within the Internet backbone and the parallel links used over many Internet paths for load splitting and redundancy.
[BPS99]列举了消除重新排序可能不可取的原因。在某些情况下，如果允许重新排序，则可以减少平均数据包延迟、提高链路效率和/或提高可靠性。例如，Internet主干网内的某些高速交换机以及在许多Internet路径上用于负载拆分和冗余的并行链路。
This suggests that subnetwork implementers should try to avoid packet reordering whenever possible, but not if doing so compromises efficiency, impairs reliability, or increases average packet delay.
这表明子网实现者应尽可能避免数据包重新排序，但如果这样做会降低效率、降低可靠性或增加平均数据包延迟，则不应这样做。
Note that every header compression scheme currently standardized for the Internet requires in-order packet delivery on the link between compressor and decompressor. PPP is frequently used to carry compressed TCP/IP packets; since it was originally designed for point-to-point and dialup links, it is assumed to provide in-order delivery. For this reason, subnetwork implementers who provide PPP interfaces to VPNs and other more complex subnetworks, must also maintain in-order delivery of PPP frames.
请注意，当前为Internet标准化的每个报头压缩方案都需要在压缩器和解压缩器之间的链路上进行有序的数据包传递。PPP经常用于承载压缩的TCP/IP数据包；由于它最初是为点对点和拨号连接设计的，因此假定它提供按订单交付。因此，向VPN和其他更复杂的子网提供PPP接口的子网实施者也必须维护PPP帧的有序交付。
Internet users are increasingly mobile. Not only are many Internet nodes laptop computers, but pocket organizers and mobile embedded systems are also becoming nodes on the Internet. These nodes may connect to many different access points on the Internet over time, and they expect this to be largely transparent to their activities. Except when they are not connected to the Internet at all, and for performance differences when they are connected, they expect that everything will "just work" regardless of their current Internet attachment point or local subnetwork technology.
互联网用户的移动性越来越强。不仅有许多互联网节点——笔记本电脑，还有口袋组织者和移动嵌入式系统——也正在成为互联网上的节点。随着时间的推移，这些节点可能会连接到Internet上的许多不同接入点，他们希望这对他们的活动基本上是透明的。除非他们根本没有连接到Internet，并且由于连接时的性能差异，他们希望无论当前的Internet连接点或本地子网技术如何，一切都“正常工作”。
Changing a host's Internet attachment point involves one or more of the following steps.
更改主机的Internet连接点涉及以下一个或多个步骤。
First, if use of the local subnetwork is restricted, the user's credentials must be verified and access granted. There are many ways to do this. A trivial example would be an "Internet cafe" that grants physical access to the subnetwork for a fee. Subnetworks may implement technical access controls of their own; one example is IEEE 802.11 Wireless Equivalent Privacy [IEEE80211]. It is common practice for both cellular telephone and Internet service providers (ISPs) to agree to serve one anothers' users; RADIUS [RFC2865] is the standard method for ISPs to exchange authorization information.
首先，如果本地子网的使用受到限制，则必须验证用户的凭据并授予访问权限。有很多方法可以做到这一点。一个不起眼的例子是一家“网吧”，它向子网提供付费的物理访问。子网可实施其自身的技术访问控制；一个例子是IEEE 802.11无线等效隐私[IEEE80211]。蜂窝电话和互联网服务提供商（ISP）都同意为彼此的用户提供服务，这是常见的做法；RADIUS[RFC2865]是ISP交换授权信息的标准方法。
Second, the host may have to be reconfigured with IP parameters appropriate for the local subnetwork. This usually includes setting an IP address, default router, and domain name system (DNS) servers.
其次，可能必须使用适合本地子网的IP参数重新配置主机。这通常包括设置IP地址、默认路由器和域名系统（DNS）服务器。
On multiple-access networks, the Dynamic Host Configuration Protocol (DHCP) [RFC2131] is almost universally used for this purpose. On PPP links, these functions are performed by the IP Control Protocol (IPCP) [RFC1332].
在多址网络上，动态主机配置协议（DHCP）[RFC2131]几乎普遍用于此目的。在PPP链路上，这些功能由IP控制协议（IPCP）[RFC1332]执行。
Third, traffic destined for the mobile host must be routed to its current location. This roaming function is the most common meaning of the term "Internet mobility".
第三，目的地为移动主机的流量必须路由到其当前位置。这种漫游功能是“互联网移动”一词最常见的含义。
Internet mobility can be provided at any of several layers in the Internet protocol stack, and there is ongoing debate as to which is the most appropriate and efficient. Mobility is already a feature of certain application layer protocols; the Post Office Protocol (POP) [RFC1939] and the Internet Message Access Protocol (IMAP) [RFC3501] were created specifically to provide mobility in the receipt of electronic mail.
互联网移动性可以在互联网协议栈中的任何一层提供，关于哪一层最合适、最有效，目前仍存在争议。移动性已经是某些应用层协议的一个特性；邮政局协议（POP）[RFC1939]和互联网消息访问协议（IMAP）[RFC3501]专门用于在接收电子邮件时提供移动性。
Mobility can also be provided at the IP layer [RFC3344]. This mechanism provides greater transparency, viz., IP addresses that remain fixed as the nodes move, but at the cost of potentially significant network overhead and increased delay because of the sub-optimal network routing and tunneling involved.
也可以在IP层提供移动性[RFC3344]。这种机制提供了更高的透明度，即IP地址在节点移动时保持不变，但由于涉及次优的网络路由和隧道，因此可能会产生巨大的网络开销和增加的延迟。
Some subnetworks may provide internal mobility, transparent to IP, as a feature of their own internal routing mechanisms. To the extent that these simplify routing at the IP layer, reduce the need for mechanisms like Mobile IP, or exploit mechanisms unique to the subnetwork, this is generally desirable. This is especially true when the subnetwork covers a relatively small geographic area and the users move rapidly between the attachment points within that area. Examples of internal mobility schemes include Ethernet switching and intra-system handoff in cellular telephony.
一些子网可以提供内部移动性，对IP透明，作为其自身内部路由机制的一个特征。在某种程度上，这些简化了IP层的路由，减少了对移动IP等机制的需求，或者利用了子网特有的机制，这通常是可取的。当子网络覆盖相对较小的地理区域且用户在该区域内的连接点之间快速移动时，尤其如此。内部移动性方案的示例包括蜂窝电话中的以太网交换和系统内切换。
However, if the subnetwork is physically large and connects to other parts of the Internet at multiple geographic points, care should be taken to optimize the wide-area routing of packets between nodes on the external Internet and nodes on the subnet. This is generally done with "nearest exit" routing strategies. Because a given subnetwork may be unaware of the actual physical location of a destination on another subnetwork, it simply routes packets bound for the other subnetwork to the nearest router between the two. This implies some awareness of IP addressing and routing within the subnetwork. The subnetwork may wish to use IP routing internally for wide area routing and restrict subnetwork-specific routing to constrained geographic areas where the effects of suboptimal routing are minimized.
但是，如果子网的物理规模较大，并且在多个地理点连接到Internet的其他部分，则应注意优化外部Internet上的节点与子网上的节点之间的数据包广域路由。这通常是通过“最近出口”路由策略完成的。由于给定的子网可能不知道目的地在另一个子网上的实际物理位置，因此它只是将绑定到另一个子网的数据包路由到两个子网之间最近的路由器。这意味着对子网内的IP寻址和路由有一定的了解。子网可能希望在内部使用IP路由进行广域路由，并将特定于子网的路由限制到受约束的地理区域，在这些区域中次优路由的影响最小化。
Subnetworks connecting more than two systems must provide their own internal Layer-2 forwarding mechanisms, either implicitly (e.g., broadcast) or explicitly (e.g., switched). Since routing is the major function of the Internet layer, the question naturally arises as to the interaction between routing at the Internet layer and routing in the subnet, and proper division of function between the two.
连接两个以上系统的子网必须提供自己的内部第二层转发机制，无论是隐式（如广播）还是显式（如交换）。由于路由是互联网层的主要功能，因此，互联网层的路由与子网中的路由之间的相互作用以及两者之间的功能划分问题自然会出现。
Layer-2 subnetworks can be point-to-point, connecting two systems, or multipoint. Multipoint subnetworks can be broadcast (e.g., shared media or emulated) or non-broadcast. Generally, IP considers multipoint subnetworks as broadcast, with shared-medium Ethernet as the canonical (and historical) example, and point-to-point subnetworks as a degenerate case. Non-broadcast subnetworks may require additional mechanisms, e.g., above IP at the routing layer [RFC2328].
第二层子网络可以是点对点、连接两个系统或多点。多点子网可以是广播（例如，共享媒体或模拟）或非广播。通常，IP将多点子网视为广播，共享媒体以太网是典型（和历史）示例，点到点子网是退化情况。非广播子网可能需要额外的机制，例如，在路由层的IP之上[RFC2328]。
IP is ignorant of the topology of the subnetwork layer. In particular, reconfiguration of subnetwork paths is not tracked by the IP layer. IP is only affected by whether it can send/receive packets sent to the remotely connected systems via the subnetwork interface (i.e., the reachability from one router to another). IP further considers that subnetworks are largely static -- that both their membership and existence are stable at routing timescales (tens of seconds); changes to these are considered re-provisioning, rather than routing.
IP不知道子网层的拓扑结构。特别是，IP层不跟踪子网路径的重新配置。IP仅受其是否能够通过子网接口发送/接收发送到远程连接系统的数据包（即，从一个路由器到另一个路由器的可达性）的影响。IP进一步考虑到子网在很大程度上是静态的——它们的成员和存在在路由时间尺度（几十秒）上都是稳定的；对这些的更改被视为重新配置，而不是路由。
Routing functionality in a subnetwork is related to addressing in that subnetwork. Resolution of addresses on subnetwork links is required for forwarding IP packets across links (e.g., ARP for IPv4, or ND for IPv6). There is unlikely to be direct interaction between subnetwork routing and IP routing. Where broadcast is provided or explicitly emulated, address resolution can be used directly; where not provided, the link layer routing may interface to a protocol for resolution, e.g., to the Next-Hop Resolution Protocol [RFC2322] to provide context-dependent address resolution capabilities.
子网中的路由功能与该子网中的寻址相关。子网链路上的地址解析是跨链路转发IP数据包所必需的（例如，对于IPv4为ARP，对于IPv6为ND）。子网路由和IP路由之间不太可能存在直接交互。在提供广播或显式模拟广播的情况下，可以直接使用地址解析；在未提供的情况下，链路层路由可以连接到用于解析的协议，例如，连接到下一跳解析协议[RFC2322]，以提供上下文相关的地址解析能力。
Subnetwork routing can either complement or compete with IP routing. It complements IP when a subnetwork encapsulates its internal routing, and where the effects of that routing are not visible at the IP layer. However, if different paths in the subnetwork have characteristics that affect IP routing, it can affect or even inhibit the convergence of IP routing.
子网路由既可以补充IP路由，也可以与IP路由竞争。当子网封装其内部路由，并且该路由的效果在IP层不可见时，它补充了IP。但是，如果子网中的不同路径具有影响IP路由的特性，则可能会影响甚至抑制IP路由的收敛。
Routing protocols generally consider Layer-2 subnetworks, i.e., with subnet masks and no intermediate IP hops, to have uniform routing metrics to all members. Routing can break when a link's characteristics do not match the routing metric, in this case, e.g., when some member pairs have different path characteristics. Consider a virtual Ethernet subnetwork that includes both nearby (sub-millisecond latency) and remote (100's of milliseconds away) systems. Presenting that group as a single subnetwork means that some routing protocols will assume that all pairs have the same delay, and that that delay is small. Because this is not the case, the routing tables constructed may be suboptimal or may even fail to converge.
路由协议通常考虑第二层子网络，即子网掩码和中间IP跳，对所有成员具有统一的路由度量。当链路的特性与路由度量不匹配时，路由可能中断，在这种情况下，例如，当某些成员对具有不同的路径特性时。考虑一个虚拟以太网子网，它包括附近（子毫秒延迟）和远程（100毫秒）系统。将该组表示为单个子网意味着一些路由协议将假定所有对具有相同的延迟，并且该延迟很小。由于情况并非如此，因此构建的路由表可能是次优的，甚至可能无法收敛。
When a subnetwork is used for transit between a set of routers, it conventionally provides the equivalent of a full mesh of point-to-point links. Simplicity of the internal subnet structure can be used (e.g., via NHRP [RFC2332]) to reduce the size of address resolution tables, but routing exchanges will continue to reflect the full mesh they emulate. In general, subnetworks should not be used as a transit among a set of routers where routing protocols would break if a full mesh of equivalent point-to-point links were used.
当一个子网用于在一组路由器之间传输时，它通常提供点到点链路的完整网格。可以使用内部子网结构的简单性（例如，通过NHRP[RFC2332]）来减小地址解析表的大小，但路由交换将继续反映它们模拟的完整网格。一般来说，子网不应被用作一组路由器之间的传输，如果使用等效点到点链路的完整网格，则路由协议将中断。
Some subnetworks have special features that allow the use of more effective or responsive routing mechanisms that cannot be implemented in IP because of its need for generality. One example is the self-learning bridge algorithm widely used in Ethernet networks. Learning bridges perform Layer-2 subnetwork forwarding, avoiding the need for dynamic routing at each subnetwork hop. Another is the "handoff" mechanism in cellular telephone networks, particularly the "soft handoff" scheme in IS-95 CDMA.
一些子网具有特殊功能，允许使用更有效或响应性更强的路由机制，这些机制由于需要通用性而无法在IP中实现。一个例子是在以太网中广泛使用的自学习桥接算法。学习网桥执行第2层子网转发，避免了在每个子网跃点进行动态路由的需要。另一个是蜂窝电话网络中的“切换”机制，特别是is-95CDMA中的“软切换”方案。
Subnetworks that cover large geographic areas or include links of widely-varying capabilities should be avoided. IP routing generally considers all multipoint subnets equivalent to a local, shared-medium link with uniform metrics between any pair of systems, and ignores internal subnetwork topology. Where a subnetwork diverges from that assumption, it is the obligation of subnetwork designers to provide compensating mechanisms. Not doing so can affect the scalability and convergence of IP routing, as noted above.
应避免覆盖较大地理区域或包含能力差异很大的链路的子网。IP路由通常考虑所有多点子网，这些子网等效于本地共享介质链路，在任何一对系统之间具有统一的度量，而忽略内部子网拓扑。当子网络偏离该假设时，子网络设计者有义务提供补偿机制。如上所述，不这样做可能会影响IP路由的可伸缩性和收敛性。
The subnetwork designer who decides to implement internal routing should consider whether a custom routing algorithm is warranted, or if an existing Internet routing algorithm or protocol may suffice. The designer should consider whether this decision is to reduce the address resolution table size (possible, but with additional protocol support required), or is trying to reduce routing table complexity. The latter may be better achieved by partitioning the subnetwork, either physically or logically, and using network-layer protocols to support partitioning (e.g., AS's in BGP). Protocols and routing
决定实现内部路由的子网设计者应该考虑是否需要自定义路由算法，或者是否现有的因特网路由算法或协议可能满足。设计者应该考虑这个决定是为了减少地址解析表的大小（可能的话，但是需要额外的协议支持），还是试图减少路由表的复杂性。后者可以通过对子网进行物理或逻辑分区，并使用网络层协议支持分区（例如，BGP中的AS）来更好地实现。协议和路由
algorithms can be notoriously subtle, complex, and difficult to implement correctly. Much work can be avoided if existing protocols or implementations can be readily reused.
算法可能是出了名的微妙、复杂，并且难以正确实现。如果现有的协议或实现可以很容易地重用，那么可以避免很多工作。
Security has become a high priority in the design and operation of the Internet. The Internet is vast, and countless organizations and individuals own and operate its various components. A consensus has emerged for what might be called a "security placement principle": a security mechanism is most effective when it is placed as close as possible to, and under the direct control of the owner of the asset that it protects.
安全性已成为互联网设计和运营的重中之重。互联网是巨大的，无数的组织和个人拥有并运营着它的各种组件。对于所谓的“安全安置原则”已经达成共识：当安全机制尽可能靠近其所保护资产的所有者并受其直接控制时，安全机制最为有效。
A corollary of this principle is that end-to-end security (e.g., confidentiality, authentication, integrity, and access control) cannot be ensured with subnetwork security mechanisms. Not only are end-to-end security mechanisms much more closely associated with the end-user assets they protect, they are also much more comprehensive. For example, end-to-end security mechanisms cover gaps that can appear when otherwise good subnetwork mechanisms are concatenated. This is an important application of the end-to-end principle [SRC81].
这一原则的推论是，端到端安全性（例如，机密性、身份验证、完整性和访问控制）无法通过子网安全机制来确保。端到端安全机制不仅与它们所保护的最终用户资产密切相关，而且更加全面。例如，端到端安全机制覆盖了连接其他良好子网络机制时可能出现的漏洞。这是端到端原理的一个重要应用[SRC81]。
Several security mechanisms that can be used end-to-end have already been deployed in the Internet and are enjoying increasing use. The most important are the Secure Sockets Layer (SSL) [SSL2] [SSL3] and TLS [RFC2246] primarily used to protect web commerce, Pretty Good Privacy (PGP) [RFC1991] and S/MIME [RFCs-2630-2634], primarily used to protect and authenticate email and software distributions, the Secure Shell (SSH), used for secure remote access and file transfer, and IPsec [RFC2401], a general purpose encryption and authentication mechanism that sits just above IP and can be used by any IP application. (IPsec can actually be used either on an end-to-end basis or between security gateways that do not include either or both end systems.)
一些可以端到端使用的安全机制已经部署在互联网上，并且正在得到越来越多的使用。最重要的是安全套接字层（SSL）[SSL2][SSL3]和TLS[RFC2246]，主要用于保护web商务、相当好的隐私（PGP）[RFC1991]和S/MIME[RFCs-2630-2634]，主要用于保护和验证电子邮件和软件分发；安全外壳（SSH），用于安全的远程访问和文件传输，IPsec[RFC2401]，一种位于IP之上的通用加密和身份验证机制，可供任何IP应用程序使用。（IPsec实际上可以在端到端的基础上使用，也可以在不包括任何一个或两个端系统的安全网关之间使用。）
Nonetheless, end-to-end security mechanisms are not used as widely as might be desired. However, the group could not reach consensus on whether subnetwork designers should be actively encouraged to implement mechanisms to protect user data.
尽管如此，端到端安全机制的使用还没有达到预期的程度。然而，专家组未能就是否应积极鼓励子网设计者实施保护用户数据的机制达成共识。
The clear consensus of the working group held that subnetwork security mechanisms, especially when weak or incorrectly implemented [BGW01], may actually be counterproductive. The argument is that subnetwork security mechanisms can lull end users into a false sense of security, diminish the incentive to deploy effective end-to-end
工作组的明确共识认为，子网安全机制，特别是在薄弱或实施不当[BGW01]的情况下，实际上可能适得其反。其论点是，子网安全机制可以诱使最终用户产生错误的安全感，降低部署有效端到端的激励
mechanisms, and encourage "risky" uses of the Internet that would not be made if users understood the inherent limits of subnetwork security mechanisms.
并鼓励“冒险”使用互联网，如果用户了解子网络安全机制的固有限制，就不会使用互联网。
The other point of view encourages subnetwork security on the principle that it is better than the default situation, which all too often is no security at all. Users of especially vulnerable subnets (such as consumers who have wireless home networks and/or shared media Internet access) often have control over at most one endpoint -- usually a client -- and therefore cannot enforce the use of end-to-end mechanisms. However, subnet security can be entirely adequate for protecting low-valued assets against the most likely threats. In any event, subnet mechanisms do not preclude the use of end-to-end mechanisms, which are typically used to protect highly-valued assets. This viewpoint recognizes that many security policies implicitly assume that the entire end-to-end path is composed of a series of concatenated links that are nominally physically secured. That is, these policies assume that all endpoints of all links are trusted, and that access to the physical medium by attackers is difficult. To meet the assumptions of such policies, explicit mechanisms are needed for links (especially shared medium links) that lack physical protection. This, for example, is the rationale that underlies Wired Equivalent Privacy (WEP) in the IEEE 802.11 [IEEE80211] wireless LAN standard, and the Baseline Privacy Interface in the DOCSIS [DOCSIS1] [DOCSIS2] data over cable television networks standards.
另一种观点鼓励子网安全，其原则是它优于默认情况，而默认情况往往根本不安全。特别脆弱子网的用户（例如拥有无线家庭网络和/或共享媒体互联网访问的用户）通常最多可以控制一个端点（通常是客户端），因此无法强制使用端到端机制。但是，子网安全性完全足以保护低价值资产免受最可能的威胁。无论如何，子网机制并不排除使用端到端机制，端到端机制通常用于保护高价值资产。这种观点认识到，许多安全策略隐式地假设整个端到端路径由一系列名义上物理安全的连接链接组成。也就是说，这些策略假设所有链接的所有端点都是可信的，并且攻击者很难访问物理介质。为了满足这些策略的假设，需要为缺乏物理保护的链路（尤其是共享介质链路）提供明确的机制。例如，这是IEEE 802.11[IEEE80211]无线LAN标准中有线等效隐私（WEP）的基本原理，以及DOCSIS[DOCSIS1][DOCSIS2]有线电视网络数据标准中的基线隐私接口。
We therefore recommend that subnetwork designers who choose to implement security mechanisms to protect user data be as candid as possible with the details of such security mechanisms and the inherent limits of even the most secure mechanisms when implemented in a subnetwork rather than on an end-to-end basis.
因此，我们建议选择实施安全机制以保护用户数据的子网设计师在子网中实施时，而不是在端到端的基础上，尽可能坦诚地了解此类安全机制的细节以及即使是最安全的机制的固有限制。
In keeping with the "placement principle", a clear consensus exists for another subnetwork security role: the protection of the subnetwork itself. Possible threats to subnetwork assets include theft of service and denial of service; shared media subnets tend to be especially vulnerable to such attacks. In some cases, mechanisms that protect subnet assets can also improve (but cannot ensure) end-to-end security.
根据“布局原则”，对于另一个子网安全角色存在着明确的共识：保护子网本身。子网络资产可能面临的威胁包括服务盗窃和拒绝服务；共享媒体子网往往特别容易受到此类攻击。在某些情况下，保护子网资产的机制也可以改善（但不能确保）端到端安全性。
One security service can be provided by the subnetwork that will aid in the solution of an overall Internet problem: subnetwork security should provide a mechanism to authenticate the source of a subnetwork frame. This function is missing in some current protocols, e.g., the use of ARP [RFC826] to associate an IPv4 address with a MAC address. The IPv6 Neighbor Discovery (ND) [RFC2461] performs a similar function.
子网可以提供一种安全服务，这将有助于解决整个互联网问题：子网安全应提供一种机制来验证子网框架的来源。某些当前协议中缺少此功能，例如，使用ARP[RFC826]将IPv4地址与MAC地址关联。IPv6邻居发现（ND）[RFC2461]执行类似的功能。
There are well-known security flaws with this address resolution mechanism [Wilbur89]. However, the inclusion of subnetwork frame source authentication will permit a secure subnetwork address.
这种地址解析机制存在众所周知的安全缺陷[Wilbur89]。但是，包含子网帧源身份验证将允许安全的子网地址。
Another potential role for subnetwork security is to protect users against traffic analysis, i.e., identifying the communicating parties and determining their communication patterns and volumes even when their actual contents are protected by strong end-to-end security mechanisms. Lower-layer security can be more effective against traffic analysis due to its inherent ability to aggregate the communications of multiple parties sharing the same physical facilities while obscuring higher-layer protocol information that indicates specific end points, such as IP addresses and TCP/UDP port numbers.
子网安全的另一个潜在作用是保护用户免受流量分析的影响，即识别通信方并确定其通信模式和通信量，即使其实际内容受到强大的端到端安全机制的保护。低层安全性可以更有效地防止流量分析，因为它固有的能力是聚合共享相同物理设施的多方的通信，同时隐藏指示特定端点的高层协议信息，如IP地址和TCP/UDP端口号。
However, traffic analysis is a notoriously subtle and difficult threat to understand and defeat, far more so than threats to confidentiality and integrity. We therefore urge extreme care in the design of subnetwork security mechanisms specifically intended to thwart traffic analysis.
然而，流量分析是一个众所周知的微妙而难以理解和击败的威胁，远远超过对机密性和完整性的威胁。因此，我们敦促在设计专门用于阻止流量分析的子网安全机制时格外小心。
Subnetwork designers must keep in mind that design and implementation for security is difficult [Schneier00]. [Schneier95] describes protocols and algorithms which are considered well-understood and believed to be sound.
子网设计者必须记住，安全性的设计和实现是困难的[Schneier00]。[Schneier95]描述了被广泛理解并被认为是可靠的协议和算法。
Poor design process, subtle design errors and flawed implementation can result in gaping vulnerabilities. In recent years, a number of subnet standards have had problems exposed. The following are examples of mistakes that have been made:
糟糕的设计过程、细微的设计错误和有缺陷的实现都可能导致漏洞不断扩大。近年来，一些子网标准已经暴露出问题。以下是所犯错误的示例：
1. Use of weak and untested algorithms [Crypto9912] [BGW01]. For a variety of reasons, algorithms were chosen which had subtle flaws, making them vulnerable to a variety of attacks.
1. 使用弱且未经测试的算法[Crypto9912][BGW01]。出于各种原因，选择了具有细微缺陷的算法，使其容易受到各种攻击。
2. Use of "security by obscurity" [Schneier00] [Crypto9912]. One common mistake is to assume that keeping cryptographic algorithms secret makes them more secure. This is intuitive, but wrong. Full public disclosure early in the design process attracts peer review by knowledgeable cryptographers. Exposure of flaws by this review far outweighs any imagined benefit from forcing attackers to reverse engineer security algorithms.
2. 使用“默示安全”[Schneier00][Crypto9912]。一个常见的错误是认为加密算法保密会使它们更安全。这是直观的，但却是错误的。在设计过程的早期完全公开披露吸引了知识渊博的密码学家的同行审查。此次审查暴露的缺陷远远超过了迫使攻击者对安全算法进行反向工程所带来的任何想象中的好处。
3. Inclusion of trapdoors [Schneier00] [Crypto9912]. Trapdoors are flaws surreptitiously left in an algorithm to allow it to be broken. This might be done to recover lost keys or to permit surreptitious access by governmental agencies. Trapdoors can be discovered and exploited by malicious attackers.
3. 包括活板门[Schneier00][Crypto9912]。活板门是算法中秘密留下的缺陷，可以让它被破坏。这可能是为了找回丢失的钥匙或允许政府机构秘密进入。陷阱可以被恶意攻击者发现和利用。
4. Sending passwords or other identifying information as clear text. For many years, analog cellular telephones could be cloned and used to steal service. The cloners merely eavesdropped on the registration protocols that exchanged everything in clear text.
4. 以明文形式发送密码或其他标识信息。多年来，模拟蜂窝电话可能被克隆并用于窃取服务。克隆人只是窃听以明文形式交换一切的注册协议。
5. Keys which are common to all systems on a subnet [BGW01].
5. 子网上所有系统通用的密钥[BGW01]。
6. Incorrect use of a sound mechanism. For example [BGW01], one subnet standard includes an initialization vector which is poorly designed and poorly specified. A determined attacker can easily recover multiple ciphertexts encrypted with the same key stream and perform statistical attacks to decipher them.
6. 不正确使用声音机制。例如[BGW01]，一个子网标准包括一个设计和指定不当的初始化向量。确定的攻击者可以轻松恢复使用相同密钥流加密的多个密文，并执行统计攻击来解密它们。
7. Identifying information sent in clear text that can be resolved to an individual, identifiable device. This creates a vulnerability to attacks targeted to that device (or its owner).
7. 以明文形式发送的可解析为单个可识别设备的识别信息。这会造成针对该设备（或其所有者）的攻击漏洞。
8. Inability to renew and revoke shared secret information.
8. 无法更新和撤销共享的机密信息。
9. Insufficient key length.
9. 键长度不足。
10. Failure to address "man-in-the-middle" attacks, e.g., with mutual authentication.
10. 未能解决“中间人”攻击，例如通过相互身份验证。
11. Failure to provide a form of replay detection, e.g., to prevent a receiver from accepting packets from an attacker that simply resends previously captured network traffic.
11. 未能提供某种形式的重播检测，例如，防止接收者接受来自攻击者的数据包，而攻击者只是重新发送先前捕获的网络流量。
12. Failure to provide integrity mechanisms when providing confidentiality schemes [Bel98].
12. 提供保密方案时未能提供完整性机制[Bel98]。
This list is by no means comprehensive. Design problems are difficult to avoid, but expert review is generally invaluable in avoiding problems.
这份清单并不全面。设计问题很难避免，但专家评审在避免问题方面通常是非常宝贵的。
In addition, well-designed security protocols can be compromised by implementation defects. Examples of such defects include use of predictable pseudo-random numbers [RFC1750], vulnerability to buffer overflow attacks due to unsafe use of certain I/O system calls [WFBA2000], and inadvertent exposure of secret data.
此外，设计良好的安全协议可能会因实现缺陷而受损。此类缺陷的示例包括使用可预测的伪随机数[RFC1750]，由于不安全地使用某些I/O系统调用[WFBA2000]而容易受到缓冲区溢出攻击，以及无意中泄露机密数据。
This document represents a consensus of the members of the IETF Performance Implications of Link Characteristics (PILC) working group.
本文件代表了IETF链路特性性能影响（PILC）工作组成员的共识。
This document would not have been possible without the contributions of a great number of people in the Performance Implications of Link Characteristics Working Group. In particular, the following people provided major contributions of text, editing, and advice on this document: Mark Allman provided the final editing to complete this document. Carsten Bormann provided text on robust header compression. Gorry Fairhurst provided text on broadcast and multicast issues, routing, and many valuable comments on the entire document. Aaron Falk provided text on bandwidth on demand. Dan Grossman provided text on many facets of the document. Reiner Ludwig provided thorough document review and text on TCP vs. Link-Layer Retransmission. Jamshid Mahdavi provided text on TCP performance calculations. Saverio Mascolo provided feedback on the document. Gabriel Montenegro provided feedback on the document. Marie-Jose Montpetit provided text on bandwidth on demand. Joe Touch provided text on multicast, broadcast, and routing, and Lloyd Wood provided many valuable comments on versions of the document.
如果没有链接特征工作组的性能影响方面的大量人员的贡献，本文件是不可能的。特别是，以下人员对本文件的文本、编辑和建议做出了重大贡献：Mark Allman提供了完成本文件的最终编辑。Carsten Bormann提供了关于健壮的头压缩的文本。戈里·费尔赫斯特（Gorry Fairhurst）提供了关于广播和多播问题、路由以及对整个文档的许多有价值的评论的文本。Aaron Falk按需提供了关于带宽的文本。丹·格罗斯曼就文件的许多方面提供了文本。Reiner Ludwig提供了关于TCP与链路层重传的全面文档审查和文本。Jamshid Mahdavi提供了关于TCP性能计算的文本。萨维里奥·马斯科洛提供了对该文件的反馈。加布里埃尔·黑山就文件提供了反馈意见。Marie Jose Montpetit按需提供了关于带宽的文本。Joe Touch提供了关于多播、广播和路由的文本，Lloyd Wood提供了许多关于文档版本的宝贵意见。
References of the form RFCnnnn are Internet Request for Comments (RFC) documents available online at www.rfc-editor.org.
RFCnnnn表格的参考资料是可在www.RFC-editor.org在线获取的互联网征求意见（RFC）文件。
[802.1D] Information Technology Telecommunications and information exchange between systems Local and metropolitan area networks, Common specifications Media access control (MAC) bridges, IEEE 802.1D, 1998. ISO 15802-3.
[802.1D]系统局域网和城域网之间的信息技术电信和信息交换，通用规范媒体访问控制（MAC）网桥，IEEE 802.1D，1998年。ISO 15802-3。
[802.1p] IEEE, 802.1p, Standard for Local and Metropolitan Area Networks - Supplement to Media Access Control (MAC) Bridges: Traffic Class Expediting and Multicast.
[802.1p]IEEE，802.1p，局域网和城域网标准-媒体访问控制（MAC）网桥补充：流量等级加速和多播。
[AP99] Allman, M. and V. Paxson, On Estimating End-to-End Network Path Properties, In Proceedings of ACM SIGCOMM 99.
[AP99]Allman，M.和V.Paxson，关于估算端到端网络路径属性，发表于ACM SIGCOMM 99会议录。
[AR02] Acar, G. and C. Rosenberg, Weighted Fair Bandwidth-on-Demand (WFBoD) for Geo-Stationary Satellite Networks with On-Board Processing, Computer Networks, 39(1), 2002.
[AR02]Acar，G.和C.Rosenberg，带星上处理的地球静止卫星网络加权公平带宽按需分配（WFBoD），计算机网络，39（1），2002年。
[ATMFTM] The ATM Forum, "Traffic Management Specification, Version 4.0", April 1996, document af-tm-0056.000. http://www.atmforum.com/
[ATMFTM]ATM论坛，“交通管理规范，版本4.0”，1996年4月，文件af-tm-0056.000。http://www.atmforum.com/
[BA02] Blanton, E. and M. Allman, On Making TCP More Robust to Packet Reordering. ACM Computer Communication Review, 32(1), January 2002.
[BA02]Blanton，E.和M.Allman，关于使TCP对数据包重新排序更具鲁棒性的研究。ACM计算机通信评论，32（1），2002年1月。
[Bel98] Bellovin, S., "Cryptography and the Internet", in
Proceedings of CRYPTO '98, August 1998.
http://www.research.att.com/~smb/papers/inet-crypto.pdf
[Bel98] Bellovin, S., "Cryptography and the Internet", in
Proceedings of CRYPTO '98, August 1998.
http://www.research.att.com/~smb/papers/inet-crypto.pdf
[BGW01] Borisov, N., Goldberg, I. and D. Wagner, "Intercepting Mobile Communications: The Insecurity of 802.11," In Proceedings of ACM MobiCom, July 2001.
[BGW01]Borisov，N.，Goldberg，I.和D.Wagner，“拦截移动通信：802.11的不安全性”，ACM MobiCom会议记录，2001年7月。
[BPK98] Balakrishnan, H., Padmanabhan, V. and R. Katz. "The Effects of Asymmetry on TCP Performance." ACM Mobile Networks and Applications (MONET), 1998.
[BPK98]Balakrishnan，H.，Padmanabhan，V.和R.Katz。“不对称对TCP性能的影响”，《ACM移动网络与应用》（MONET），1998年。
[BPS99] Bennet,, J.C.R., Partridge, C. and N. Shectman, "Packet Reordering is Not Pathological Network Behavior", IEEE/ACM Transactions on Networking, Vol. 7, No. 6, December 1999.
[BPS99]Bennet，J.C.R.，Partridge，C.和N.Shectman，“数据包重新排序不是病态的网络行为”，IEEE/ACM网络交易，第7卷，第6期，1999年12月。
[CGMP] Farinacci D., Tweedly A. and T. Speakman, "Cisco Group
Management Protocol (CGMP)", 1996/1997.
ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt
[CGMP] Farinacci D., Tweedly A. and T. Speakman, "Cisco Group
Management Protocol (CGMP)", 1996/1997.
ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt
[Crypto9912] Schneier, B., "European Cellular Encryption Algorithms" Crypto-Gram, December 15, 1999. http://www.counterpane.com
[Crypto9912]Schneier，B.，“欧洲蜂窝加密算法”密码，1999年12月15日。http://www.counterpane.com
[DIX82] Digital Equipment Corp, Intel Corp, Xerox Corp, Ethernet Local Area Network Specification Version 2.0, November 1982.
[DIX82]数字设备公司、英特尔公司、施乐公司，以太网局域网规范版本2.0，1982年11月。
[DOCSIS1] Data-Over-Cable Service Interface Specifications, Radio Frequency Interface Specification 1.0, SP-RFI-I05- 991105, November 1999, Cable Television Laboratories, Inc.
[DOCSIS1]有线数据服务接口规范，射频接口规范1.0，SP-RFI-I05-991105，1999年11月，有线电视实验室有限公司。
[DOCSIS2] Data-Over-Cable Service Interface Specifications, Radio Frequency Interface Specification 1.1, SP-RFIv1.1-I05- 000714, July 2000, Cable Television Laboratories, Inc.
[DOCSIS2]有线数据服务接口规范，射频接口规范1.1，SP-RFIv1.1-I05-0007142000年7月，有线电视实验室有限公司。
[DOCSIS3] Lai, W.S., "DOCSIS-Based Cable Networks: Impact of Large Data Packets on Upstream Capacity", 14th ITC Specialists Seminar on Access Networks and Systems, Barcelona, Spain, April 25-27, 2001.
[DOCSIS3]Lai，W.S.，“基于DOCSIS的电缆网络：大数据包对上游容量的影响”，第14届ITC接入网络和系统专家研讨会，西班牙巴塞罗那，2001年4月25-27日。
[EN301192] ETSI, European Broadcasting Union, Digital Video Broadcasting (DVB); DVB Specification for Data Broadcasting, European Standard (Telecommunications Series) EN 301 192 v1.2.1(1999-06).
[EN301192]ETSI，欧洲广播联盟，数字视频广播（DVB）；数据广播DVB规范，欧洲标准（电信系列）EN 301 192 v1.2.1（1999-06）。
[ES00] Eckhardt, D. and P. Steenkiste, "Effort-limited Fair (ELF) Scheduling for Wireless Networks, Proceedings of IEEE Infocom 2000.
[ES00]Eckhardt，D.和P.Steenkiste，“无线网络的有限努力公平（ELF）调度，IEEE Infocom 2000年会议记录。
[FB00] Firoiu V. and M. Borden, "A Study of Active Queue Management for Congestion Control" to appear in Infocom 2000.
[FB00]Firoiu V.和M.Borden，“用于拥塞控制的主动队列管理研究”，将发表在Infocom 2000中。
[GM02] Grieco1, L. and S. Mascolo, "TCP Westwood and Easy RED to Improve Fairness in High-Speed Networks", Proceedings of the 7th International Workshop on Protocols for High-Speed Networks, April 2002.
[GM02]Grieco1，L.和S.Mascolo，“TCP Westwood和Easy RED改善高速网络中的公平性”，第七届高速网络协议国际研讨会论文集，2002年4月。
[IEEE8023] IEEE 802.3 CSMA/CD Access Method.
http://standards.ieee.org/
[IEEE8023] IEEE 802.3 CSMA/CD Access Method.
http://standards.ieee.org/
[IEEE80211] IEEE 802.11 Wireless LAN standard.
http://standards.ieee.org/
[IEEE80211] IEEE 802.11 Wireless LAN standard.
http://standards.ieee.org/
[ISO3309] ISO/IEC 3309:1991(E), "Information Technology - Telecommunications and information exchange between systems - High-level data link control (HDLC) procedures - Frame structure", International Organization For Standardization, Fourth edition 1991- 06-01.
[ISO3309]ISO/IEC 3309:1991（E），“信息技术-系统间电信和信息交换-高级数据链路控制（HDLC）程序-帧结构”，国际标准化组织，第四版，1991-06-01。
[ISO13818] ISO/IEC, ISO/IEC 13818-1:2000(E) Information Technology - Generic coding of moving pictures and associated audio information: Systems, Second edition, 2000-12-01 International Organization for Standardization and International Electrotechnical Commission.
[ISO13818]ISO/IEC，ISO/IEC 13818-1:2000（E）信息技术-运动图像和相关音频信息的通用编码：系统，第二版，2000-12-01国际标准化组织和国际电工委员会。
[ITU-I363] ITU-T I.363.5 B-ISDN ATM Adaptation Layer Specification Type AAL5, International Standards Organisation (ISO), 1996.
[ITU-I363]ITU-T I.363.5 B-ISDN ATM适配层规范AAL5型，国际标准化组织（ISO），1996年。
[Jac90] Jacobson, V., Modified TCP Congestion Avoidance Algorithm. Email to the end2end-interest mailing list, April 1990. ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt
[Jac90]Jacobson，V.，修改的TCP拥塞避免算法。1990年4月发送至End2 End interest邮件列表的电子邮件。ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt
[KY02] Khafizov, F. and M. Yavuz, Running TCP Over IS-2000, Proceedings of IEEE ICC, 2002.
[KY02]Khafizov，F.和M.Yavuz，在IS-2000上运行TCP，IEEE ICC会议记录，2002年。
[LK00] Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions", ACM Computer Communication Review, Vol. 30, No. 1, January 2000.
[LK00]Ludwig，R.和R.H.Katz，“Eifel算法：使TCP对伪重传具有鲁棒性”，ACM计算机通信评论，第30卷，第1期，2000年1月。
[LKJK02] Ludwig, R., Konrad, A., Joseph, A. D. and R. H. Katz, "Optimizing the End-to-End Performance of Reliable Flows over Wireless Links", Kluwer/ACM Wireless Networks Journal, Vol. 8, Nos. 2/3, pp. 289-299, March-May 2002.
[LKJK02]Ludwig，R.，Konrad，A.，Joseph，A.D.和R.H.Katz，“优化无线链路上可靠流的端到端性能”，Kluwer/ACM无线网络杂志，第8卷，第2/3期，第289-299页，2002年3月至5月。
[LRKOJ99] Ludwig, R., Rathonyi, B., Konrad, A., Oden, K. and A. Joseph, Multi-Layer Tracing of TCP over a Reliable Wireless Link, pp. 144-154, In Proceedings of ACM SIGMETRICS 99.
[LRKOJ99]Ludwig，R.，Rathonyi，B.，Konrad，A.，Oden，K.和A.Joseph，可靠无线链路上TCP的多层跟踪，第144-154页，ACM SIGMETRICS 99会议录。
[LS00] Ludwig, R. and K. Sklower, The Eifel Retransmission Timer, ACM Computer Communication Review, Vol. 30, No. 3, July 2000.
[LS00]Ludwig，R.和K.Sklower，《Eifel重传计时器》，ACM计算机通信评论，第30卷，第3期，2000年7月。
[MAGMA-PROXY] Fenner, B., He, H., Haberman, B. and H. Sandick, "IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying")", Work in Progress.
[MAGMA-PROXY]Fenner，B.，He，H.，Haberman，B.和H.Sandick，“基于IGMP/MLD的多播转发（“IGMP/MLD代理”）”，工作正在进行中。
[MAGMA-SNOOP] Christensen, M., Kimball, K. and F. Solensky, "Considerations for IGMP and MLD Snooping Switches", Work in Progress.
[MAGMA-SNOOP]Christensen，M.，Kimball，K.和F.Solensky，“IGMP和MLD窥探开关的注意事项”，正在进行中。
[MBB00] May, M., Bonald, T. and J-C. Bolot, "Analytic Evaluation of RED Performance", INFOCOM 2000.
[MBB00]May，M.，Bonald，T.和J-C.Bolot，“红色绩效的分析评估”，INFOCOM 2000。
[MBDL99] May, M., Bolot, J., Diot, C. and B. Lyles, "Reasons not to deploy RED", Proc. of 7th. International Workshop on Quality of Service (IWQoS'99), June 1999.
[MBDL99]May，M.，Bolot，J.，Diot，C.和B.Lyles，“不部署RED的原因”，程序。第七届。服务质量国际讲习班（IWQoS'99），1999年6月。
[MSMO97] Mathis, M., Semke, J., Mahdavi, J. and T. Ott, "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm", Computer Communication Review, Vol. 27, number 3, July 1997.
[MSMO97]Mathis，M.，Semke，J.，Mahdavi，J.和T.Ott，“TCP拥塞避免算法的宏观行为”，计算机通信评论，第27卷，第3期，1997年7月。
[MYR95] Boden, N., Cohen, D., Felderman, R., Kulawik, A., Seitz, C., et al. MYRINET: A Gigabit per Second Local Area Network, IEEE-Micro, Vol. 15, No.1, February 1995, pp. 29-36.
[MYR95]Boden，N.，Cohen，D.，Felderman，R.，Kulawik，A.，Seitz，C.，et al.MYRINET:千兆每秒局域网，IEEE Micro，第15卷，第1期，1995年2月，第29-36页。
[PFTK98] Padhye, J., Firoiu, V., Towsley, D. and J. Kurose, "Modeling TCP Throughput: a Simple Model and its Empirical Validation", UMASS CMPSCI Tech Report TR98- 008, Feb. 1998.
[PFTK98]Padhye，J.，Firoiu，V.，Towsley，D.和J.Kurose，“TCP吞吐量建模：一个简单模型及其经验验证”，麻省大学CMPSCI技术报告TR98-008，1998年2月。
[RED93] Floyd, S. and V. Jacobson, "Random Early Detection
gateways for Congestion Avoidance", IEEE/ACM
Transactions in Networking, Vol. 1 No. 4, August 1993.
http://www.aciri.org/floyd/papers/red/red.html
[RED93] Floyd, S. and V. Jacobson, "Random Early Detection
gateways for Congestion Avoidance", IEEE/ACM
Transactions in Networking, Vol. 1 No. 4, August 1993.
http://www.aciri.org/floyd/papers/red/red.html
[RF95] Romanow, A. and S. Floyd, "Dynamics of TCP Traffic over ATM Networks". IEEE Journal of Selected Areas in Communication, Vol.13 No. 4, May 1995, p. 633-641.
[RF95]Romanow，A.和S.Floyd，“ATM网络上TCP流量的动力学”。IEEE通信选定领域杂志，第13卷第4期，1995年5月，第页。633-641.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC826] Plummer, D.C., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48-bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC826]Plummer，D.C.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC1071] Braden, R., Borman, D. and C. Partridge, "Computing the Internet checksum", RFC 1071, September 1988.
[RFC1071]Braden，R.，Borman，D.和C.Partridge，“计算互联网校验和”，RFC 10711988年9月。
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]Jacobson，V.，“压缩低速串行链路的TCP/IP头”，RFC1144，1990年2月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1332] McGregor, C., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]McGregor，C.，“PPP互联网协议控制协议（IPCP）”，RFC1332，1992年5月。
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[RFC1435]Knowles，S.，“来自Path MTU发现经验的IESG建议”，RFC 1435，1993年3月。
[RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]Braden，R.，Clark，D.和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC 16331994年6月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC1662] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC1662]辛普森，W.，编辑，“HDLC类框架中的PPP”，标准51，RFC1662，1994年7月。
[RFC1750] Eastlake 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]Eastlake 3rd，D.，Crocker，S.和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，Ed.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996.
[RFC1991]Atkins，D.，Stallings，W.和P.Zimmermann，“PGP消息交换格式”，RFC 1991，1996年8月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[RFC2018]Mathis，M.，Mahdavi，J.，Floyd，S.和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O`Dell, M., Romanow, A., Weinrib, A. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, September 1997.
[RFC2208]Mankin，A.，Baker，F.，Braden，B.，Bradner，S.，O`Dell，M.，Romanow，A.，Weinrib，A.和L.Zhang，“资源保留协议（RSVP）--版本1适用性声明—一些部署指南”，RFC 2208，1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC2211]Wroclawski，J.，“受控负荷网元服务规范”，RFC2211，1997年9月。
[RFC2212] Shenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212]Shenker，S.，Partridge，C.和R.Guerin，“保证服务质量规范”，RFC 2212，1997年9月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2309] 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.
[RFC2309]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月。
[RFC2322] van den Hout, K., Koopal, A. and R. van Mook, "Management of IP numbers by peg-dhcp", RFC 2322, 1 April 1998.
[RFC2322]van den Hout，K.，Koopal，A.和R.van Mook，“通过peg dhcp管理IP号码”，RFC 2322，1998年4月1日。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[RFC2332]Luciani，J.，Katz，D.，Piscitello，D.，Cole，B.和N.Doraswamy，“NBMA下一跳解析协议（NHRP）”，RFC 2332，1998年4月。
[RFC2364] Gross, G., Kaycee, M., Li, A., Malis, A. and J. Stephens, "PPP Over AAL5", RFC 2364, July 1998.
[RFC2364]Gross，G.，Kaycee，M.，Li，A.，Malis，A.和J.Stephens，“AAL5上的购买力平价”，RFC 2364，1998年7月。
[RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, December 1998.
[RFC2394]Pereira，R.，“使用DEFLATE的IP有效载荷压缩”，RFC 2394，1998年12月。
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, December 1998.
[RFC2395]Friend，R.和R.Monsour，“使用LZS的IP有效负载压缩”，RFC 2395，1998年12月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[RFC2440]Callas，J.，Donnerhacke，L.，Finney，H.和R.Thayer，“OpenPGP消息格式”，RFC 24401998年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507]Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508]Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[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月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597]Heinanen，J.，Baker，F.，Weiss，W.和J.Wroclawski，“保付PHB集团”，RFC 25971999年6月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[RFC2630]Housley，R.，“加密消息语法”，RFC2630，1999年6月。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631]Rescorla，E.，“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
[RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate Handling", RFC 2632, June 1999.
[RFC2632]Ramsdell，B.，Ed.，“S/MIME版本3证书处理”，RFC 2632，1999年6月。
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[RFC2633]Ramsdell，B.，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
[RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[RFC2634]Hoffman，P.，“S/MIME的增强安全服务”，RFC 2634，1999年6月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684]Grossman，D.和J.Heinanen，“ATM适配层5上的多协议封装”，RFC 2684，1999年9月。
[RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[RFC2686]Bormann，C.，“多链路PPP的多类扩展”，RFC2686，1999年9月。
[RFC2687] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.
[RFC2687]Bormann，C.，“实时定向HDLC样帧中的PPP”，RFC2687，1999年9月。
[RFC2689] Bormann, C., "Providing Integrated Services over Low-bitrate Links", RFC 2689, September 1999.
[RFC2689]Bormann，C.，“通过低比特率链路提供综合服务”，RFC2689，1999年9月。
[RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]Lahey，K.，“路径MTU发现的TCP问题”，RFC 29232000年9月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
[RFC2990]Huston，G.，“IP QoS架构的下一步”，RFC 29902000年11月。
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S. and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[RFC3048]Whetten，B.，Vicisano，L.，Kermode，R.，Handley，M.，Floyd，S.和M.Luby，“一对多批量数据传输的可靠多播传输构建块”，RFC 3048，2001年1月。
[RFC3095] Bormann, C., Ed., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095]Bormann，C.，Ed.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP和未压缩”，RFC 3095，2001年7月。
[RFC3096] Degermark, M., Ed., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
[RFC3096]Degermark，M.，编辑，“鲁棒IP/UDP/RTP报头压缩的要求”，RFC 3096，2001年7月。
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
[RFC3150]Dawkins，S.，黑山，G.，Kojo，M.和V.Magret，“慢链路的端到端性能影响”，BCP 48，RFC 3150，2001年7月。
[RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and N. Vaidya, "End-to-end Performance Implications of Links with Errors", BCP 50, RFC 3155, August 2001.
[RFC3155]Dawkins，S.，黑山，G.，Kojo，M.，Magret，V.和N.Vaidya，“带错误链接的端到端性能影响”，BCP 50，RFC 3155，2001年8月。
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3173] Shacham, A., Monsour, B., Pereira, R. and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
[RFC3173]Shacham，A.，Monsour，B.，Pereira，R.和M.Thomas，“IP有效载荷压缩协议（IPComp）”，RFC 31732001年9月。
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.C.R.，Benson，K.，Le Boudec，J.Y.，Courtney，W.，Davari，S.，Firoiu，V.和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[RFC3248] Armitage, G., Carpenter, B., Casati, A., Crowcroft, J., Halpern, J., Kumar, B. and J. Schnizlein, "A Delay Bound alternative revision of RFC 2598", RFC 3248, March 2002.
[RFC3248]Armitage，G.，Carpenter，B.，Casati，A.，Crowcroft，J.，Halpern，J.，Kumar，B.和J.Schnizlein，“RFC 2598的延迟约束替代版本”，RFC 3248，2002年3月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]Perkins，C.，Ed.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.
[RFC3366]Fairhurst，G.和L.Wood，“链接自动重复请求（ARQ）对链接设计者的建议”，BCP 62，RFC 3366，2002年8月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", BCP 69, RFC 3449, December 2002.
[RFC3449]Balakrishnan，H.，Padmanabhan，V.，Fairhurst，G.和M.Sooriyabandara，“网络路径不对称对TCP性能的影响”，BCP 69，RFC 3449，2002年12月。
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[RFC3450]Luby，M.，Gemmell，J.，Vicisano，L.，Rizzo，L.和J.Crowcroft，“异步分层编码（ALC）协议实例化”，RFC 3450，2002年12月。
[RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002.
[RFC3451]Luby，M.，Gemmell，J.，Vicisano，L.，Rizzo，L.，Handley，M.和J.Crowcroft，“分层编码传输（LCT）构建块”，RFC 34512002年12月。
[RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[RFC3452]Luby，M.，Vicisano，L.，Gemmell，J.，Rizzo，L.，Handley，M.和J.Crowcroft，“前向纠错（FEC）构建块”，RFC 3452，2002年12月。
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3453]Luby，M.，Vicisano，L.，Gemmell，J.，Rizzo，L.，Handley，M.和J.Crowcroft，“在可靠多播中使用前向纠错（FEC）”，RFC 3453，2002年12月。
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group Management Protocol (RGMP)", RFC 3488, February 2003.
[RFC3488]Wu，I.和T.Eckert，“思科系统路由器端口组管理协议（RGMP）”，RFC 3488，2003年2月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed. and G. Fairhurst, Ed., "The User Datagram Protocol (UDP)-Lite Protocol", RFC 3828, June 2004.
[RFC3828]Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，Ed.和G.Fairhurst，Ed.，“用户数据报协议（UDP）-Lite协议”，RFC 38282004年6月。
[Schneier95] Schneier, B., Applied Cryptography: Protocols, Algorithms and Source Code in C (John Wiley and Sons, October 1995).
[Schneier95]Schneier，B.，应用密码学：C语言中的协议、算法和源代码（John Wiley and Sons，1995年10月）。
[Schneier00] Schneier, B., Secrets and Lies: Digital Security in a Networked World (John Wiley and Sons, August 2000).
[Schneier00]Schneier，B.《秘密与谎言：网络世界中的数字安全》（John Wiley and Sons，2000年8月）。
[SP2000] Stone, J. and C. Partridge, "When the CRC and TCP
Checksum Disagree", ACM SIGCOMM, September 2000.
http://www.acm.org/sigcomm/sigcomm2000/conf/
paper/sigcomm2000-9-1.pdf
[SP2000] Stone, J. and C. Partridge, "When the CRC and TCP
Checksum Disagree", ACM SIGCOMM, September 2000.
http://www.acm.org/sigcomm/sigcomm2000/conf/
paper/sigcomm2000-9-1.pdf
[SRC81] Saltzer, J., Reed D. and D. Clark, "End-to-End Arguments in System Design". Second International Conference on Distributed Computing Systems (April, 1981) pages 509-512. Published with minor changes in ACM Transactions in Computer Systems 2, 4, November, 1984, pages 277-288. Reprinted in Craig Partridge, editor Innovations in internetworking. Artech House, Norwood, MA, 1988, pages 195-206. ISBN 0-89006-337-0.
[SRC81]Saltzer，J.，Reed D.和D.Clark，“系统设计中的端到端参数”。第二届分布式计算系统国际会议（1981年4月）第509-512页。1984年11月2日、4日出版，第277-288页，计算机系统中的ACM交易有微小变化。《互联网创新》编辑克雷格·帕特里奇转载。马萨诸塞州诺伍德市阿泰奇大厦，1988年，第195-206页。ISBN 0-89006-337-0。
[SSL2] Hickman, K., "The SSL Protocol", Netscape Communications Corp., Feb 9, 1995.
[SSL2]Hickman，K.，“SSL协议”，网景通信公司，1995年2月9日。
[SSL3] Frier, A., Karlton, P. and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996.
[SSL3]Frier，A.，Karlton，P.和P.Kocher，“SSL 3.0协议”，网景通信公司，1996年11月18日。
[TCPF98] Lin, D. and H.T. Kung, "TCP Fast Recovery Strategies:
Analysis and Improvements", IEEE Infocom, March 1998.
http://www.eecs.harvard.edu/networking/papers/infocom-
tcp-final-198.pdf
[TCPF98] Lin, D. and H.T. Kung, "TCP Fast Recovery Strategies:
Analysis and Improvements", IEEE Infocom, March 1998.
http://www.eecs.harvard.edu/networking/papers/infocom-
tcp-final-198.pdf
[WFBA2000] Wagner, D., Foster, J., Brewer, E. and A. Aiken, "A
First Step Toward Automated Detection of Buffer Overrun
Vulnerabilities", Proceedings of NDSS2000.
http://www.isoc.org/isoc/conferences/ndss/
2000/proceedings/039.pdf
[WFBA2000] Wagner, D., Foster, J., Brewer, E. and A. Aiken, "A
First Step Toward Automated Detection of Buffer Overrun
Vulnerabilities", Proceedings of NDSS2000.
http://www.isoc.org/isoc/conferences/ndss/
2000/proceedings/039.pdf
[Wilbur89] Wilbur, Steve R., Jon Crowcroft, and Yuko Murayama. "MAC layer Security Measures in Local Area Networks", Local Area Network Security, Workshop LANSEC '89 Proceedings, Springer-Verlag, April 1989, pp. 53-64.
[Wilbur89]Wilbur、Steve R、Jon Crowcroft和Yuko Murayama。“局域网中的MAC层安全措施”，局域网安全，LANSEC'89研讨会论文集，Springer Verlag，1989年4月，第53-64页。
Aaron Falk USC/Information Sciences Institute 4676 Admiralty Way Marina Del Rey, CA 90292
Aaron Falk USC/信息科学研究所4676金钟路Marina Del Rey，加利福尼亚州90292
Phone: 310-448-9327 EMail: falk@isi.edu
电话：310-448-9327电子邮件：falk@isi.edu
Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica, Politecnico di Bari Via Orabona 4, 70125 Bari, Italy
意大利巴里经Orabona路巴里理工学院电气保护区萨维里奥·马斯科洛公寓，邮编：70125
Phone: +39 080 596 3621
EMail: mascolo@poliba.it
URL: http://www-dee.poliba.it/dee-web/Personale/mascolo.html
Phone: +39 080 596 3621
EMail: mascolo@poliba.it
URL: http://www-dee.poliba.it/dee-web/Personale/mascolo.html
Marie-Jose Montpetit MJMontpetit.com
玛丽·何塞·蒙佩蒂MJMontpetit.com
EMail: marie@mjmontpetit.com
EMail: marie@mjmontpetit.com
Phil Karn, Editor Qualcomm 5775 Morehouse Drive San Diego CA 92121
Phil Karn，高通公司编辑，加利福尼亚州圣地亚哥Morehouse大道5775号，邮编92121
Phone: 858 587 1121 EMail: karn@qualcomm.com
电话：8585871121电子邮件：karn@qualcomm.com
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
德国不来梅卡斯滕·鲍曼大学邮政学院330440 D-28334
Phone: +49 421 218 7024
Fax: +49 421 218 7000
EMail: cabo@tzi.org
Phone: +49 421 218 7024
Fax: +49 421 218 7000
EMail: cabo@tzi.org
Godred (Gorry) Fairhurst Department of Engineering, University of Aberdeen, Aberdeen, AB24 3UE, United Kingdom
GoRead（Gorry）阿伯丁大学费尔赫斯特工程系，阿伯丁，英国AB24 3UE
EMail: gorry@erg.abdn.ac.uk
URL: http://www.erg.abdn.ac.uk/users/gorry
EMail: gorry@erg.abdn.ac.uk
URL: http://www.erg.abdn.ac.uk/users/gorry
Dan Grossman Motorola, Inc. 111 Locke Drive Marlboro, MA 01752
丹格罗斯曼摩托罗拉公司，地址：马萨诸塞州万宝路洛克大道111号01752
EMail: Dan.Grossman@motorola.com
EMail: Dan.Grossman@motorola.com
Reiner Ludwig Ericsson Research Ericsson Allee 1 52134 Herzogenrath, Germany
Reiner Ludwig Ericsson Research Ericsson Allee 1 52134 Herzogenrath，德国
Phone: +49 2407 575 719
EMail: Reiner.Ludwig@ericsson.com
Phone: +49 2407 575 719
EMail: Reiner.Ludwig@ericsson.com
Jamshid Mahdavi Novell, Inc.
Jamshid Mahdavi Novell公司。
EMail: jmahdavi@earthlink.net
EMail: jmahdavi@earthlink.net
Gabriel Montenegro Sun Microsystems Laboratories, Europe 180, Avenue de l'Europe 38334 Saint Ismier CEDEX France
加布里埃尔黑山太阳微系统实验室，欧洲180号，欧洲大道38334号，法国圣伊斯梅尔塞德斯
EMail: gab@sun.com
EMail: gab@sun.com
Joe Touch USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey CA 90292
Joe Touch USC/信息科学研究所4676金钟路马里纳德雷加利福尼亚州90292
Phone: 310 448 9151
EMail: touch@isi.edu
URL: http://www.isi.edu/touch
Phone: 310 448 9151
EMail: touch@isi.edu
URL: http://www.isi.edu/touch
Lloyd Wood Cisco Systems 9 New Square Park, Bedfont Lakes Feltham TW14 8HA United Kingdom
Lloyd Wood Cisco Systems 9新广场公园，Bedfont Lakes Feltham TW14 8HA英国
Phone: +44 (0)20 8824 4236
EMail: lwood@cisco.com
URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/
Phone: +44 (0)20 8824 4236
EMail: lwood@cisco.com
URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。