Network Working Group V. Jacobson
Request for Comments: 2598 K. Nichols
Category: Standards Track Cisco Systems
K. Poduri
Bay Networks
June 1999
Network Working Group V. Jacobson
Request for Comments: 2598 K. Nichols
Category: Standards Track Cisco Systems
K. Poduri
Bay Networks
June 1999
An Expedited Forwarding PHB
快速转发PHB
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group. This document describes a PHB called Expedited Forwarding. We show the generality of this PHB by noting that it can be produced by more than one mechanism and give an example of its use to produce at least one service, a Virtual Leased Line. A recommended codepoint for this PHB is given.
PHB（每跳转发行为）的定义是Diffserv工作组工作的关键部分。本文档描述了一种称为快速转发的PHB。我们注意到PHB可以由多个机制产生，并给出了使用PHB产生至少一个服务（虚拟租用线路）的示例，从而展示了PHB的通用性。给出了该PHB的建议代码点。
A pdf version of this document is available at
ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf
A pdf version of this document is available at
ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf
Network nodes that implement the differentiated services enhancements to IP use a codepoint in the IP header to select a per-hop behavior (PHB) as the specific forwarding treatment for that packet [RFC2474, RFC2475]. This memo describes a particular PHB called expedited forwarding (EF). The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service through DS domains. Such a service appears to the endpoints like a point-to-point connection or a "virtual leased line". This service has also been described as Premium service [2BIT].
对IP实施区分服务增强的网络节点使用IP报头中的代码点选择每跳行为（PHB）作为该数据包的特定转发处理[RFC2474，RFC2475]。本备忘录描述了一种称为快速转发（EF）的特殊PHB。EF PHB可用于通过DS域构建低损耗、低延迟、低抖动、有保证的带宽、端到端服务。这样的服务在端点看来就像点对点连接或“虚拟租用线路”。这项服务也被称为高级服务[2BIT]。
Loss, latency and jitter are all due to the queues traffic experiences while transiting the network. Therefore providing low loss, latency and jitter for some traffic aggregate means ensuring that the aggregate sees no (or very small) queues. Queues arise when (short-term) traffic arrival rate exceeds departure rate at some node. Thus a service that ensures no queues for some aggregate is equivalent to bounding rates such that, at every transit node, the aggregate's maximum arrival rate is less than that aggregate's minimum departure rate.
丢失、延迟和抖动都是由于网络传输过程中的队列流量体验造成的。因此，为某些流量聚合提供低损耗、延迟和抖动意味着确保聚合不会看到（或非常小的）队列。当（短期）流量到达率超过某个节点的离开率时，会出现排队。因此，确保某个集合没有队列的服务相当于边界速率，这样，在每个公交节点上，集合的最大到达速率小于该集合的最小离开速率。
Creating such a service has two parts:
创建此类服务包括两个部分：
1) Configuring nodes so that the aggregate has a well-defined minimum departure rate. ("Well-defined" means independent of the dynamic state of the node. In particular, independent of the intensity of other traffic at the node.)
1) 配置节点，使聚合具有定义良好的最小离开率。（“定义良好”是指独立于节点的动态状态，特别是独立于节点上其他流量的强度。）
2) Conditioning the aggregate (via policing and shaping) so that its arrival rate at any node is always less than that node's configured minimum departure rate.
2) 调节聚合（通过控制和整形），使其在任何节点的到达率始终小于该节点配置的最小离开率。
The EF PHB provides the first part of the service. The network boundary traffic conditioners described in [RFC2475] provide the second part.
EF PHB提供服务的第一部分。[RFC2475]中描述的网络边界流量调节器提供了第二部分。
The EF PHB is not a mandatory part of the Differentiated Services architecture, i.e., a node is not required to implement the EF PHB in order to be considered DS-compliant. However, when a DS-compliant node claims to implement the EF PHB, the implementation must conform to the specification given in this document.
EF PHB不是区分服务体系结构的强制性部分，即，节点不需要实现EF PHB才能被视为DS兼容。但是，当DS兼容节点声称实现EF PHB时，实现必须符合本文档中给出的规范。
The next sections describe the EF PHB in detail and give examples of how it might be implemented. The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [Bradner97].
下一节将详细描述EF PHB，并举例说明如何实现它。本文件中出现的关键词“必须”、“不得”、“必需”、“应该”、“不应该”和“可能”应按照[Bradner97]中所述进行解释。
The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate's packets from any diffserv node must equal or exceed a configurable rate. The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node. It SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate. (Behavior at time scales shorter than a packet time at the configured rate is
EF PHB被定义为特定diffserv聚合的转发处理，其中聚合的数据包从任何diffserv节点的离开率必须等于或超过可配置的速率。EF通信量应接收该速率，该速率与试图通过节点的任何其他通信量的强度无关。当在任何时间间隔上测量时，它至少应平均配置的速率，该时间间隔等于或大于以配置的速率发送输出链路MTU大小的数据包所需的时间。（以配置的速率，时间尺度短于数据包时间的行为是
deliberately not specified.) The configured minimum rate MUST be settable by a network administrator (using whatever mechanism the node supports for non-volatile configuration).
网络管理员必须设置配置的最低速率（使用节点支持的任何非易失性配置机制）。
If the EF PHB is implemented by a mechanism that allows unlimited preemption of other traffic (e.g., a priority queue), the implementation MUST include some means to limit the damage EF traffic could inflict on other traffic (e.g., a token bucket rate limiter). Traffic that exceeds this limit MUST be discarded. This maximum EF rate, and burst size if appropriate, MUST be settable by a network administrator (using whatever mechanism the node supports for non-volatile configuration). The minimum and maximum rates may be the same and configured by a single parameter.
如果EF PHB由允许无限抢占其他流量（例如，优先级队列）的机制实现，则该实现必须包括一些限制EF流量可能对其他流量造成的损害的手段（例如，令牌桶速率限制器）。超过此限制的流量必须丢弃。此最大EF速率和突发大小（如果合适）必须由网络管理员设置（使用节点支持的任何非易失性配置机制）。最小速率和最大速率可以相同，并且由单个参数配置。
The Appendix describes how this PHB can be used to construct end-to-end services.
附录描述了如何使用此PHB构建端到端服务。
Several types of queue scheduling mechanisms may be employed to deliver the forwarding behavior described in section 2.1 and thus implement the EF PHB. A simple priority queue will give the appropriate behavior as long as there is no higher priority queue that could preempt the EF for more than a packet time at the configured rate. (This could be accomplished by having a rate policer such as a token bucket associated with each priority queue to bound how much the queue can starve other traffic.)
可以使用几种类型的队列调度机制来传递第2.1节中描述的转发行为，从而实现EF PHB。只要没有更高优先级的队列能够以配置的速率抢占EF超过一个数据包时间，简单优先级队列就会给出适当的行为。（这可以通过使用速率策略（如与每个优先级队列关联的令牌桶）来实现，以限制队列可以使其他通信量不足的程度。）
It's also possible to use a single queue in a group of queues serviced by a weighted round robin scheduler where the share of the output bandwidth assigned to the EF queue is equal to the configured rate. This could be implemented, for example, using one PHB of a Class Selector Compliant set of PHBs [RFC2474].
也可以在由加权循环调度程序服务的队列组中使用单个队列，其中分配给EF队列的输出带宽份额等于配置的速率。例如，可以使用一组符合类选择器的PHB[RFC2474]中的一个PHB来实现这一点。
Another possible implementation is a CBQ [CBQ] scheduler that gives the EF queue priority up to the configured rate.
另一种可能的实现是CBQ[CBQ]调度程序，它将EF队列优先级提高到配置的速率。
All of these mechanisms have the basic properties required for the EF PHB though different choices result in different ancillary behavior such as jitter seen by individual microflows. See Appendix A.3 for simulations that quantify some of these differences.
所有这些机制都具有EF PHB所需的基本特性，尽管不同的选择会导致不同的辅助行为，如单个微流所看到的抖动。有关量化这些差异的模拟，请参见附录A.3。
Codepoint 101110 is recommended for the EF PHB.
建议EF PHB使用代码点101110。
Packets marked for EF PHB MAY be remarked at a DS domain boundary only to other codepoints that satisfy the EF PHB. Packets marked for EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS domain.
标记为EF-PHB的分组可以仅在DS域边界处对满足EF-PHB的其他码点进行注释。DS域不应将标记为EF PHB的数据包降级或升级到另一个PHB。
When EF packets are tunneled, the tunneling packets must be marked as EF.
当EF数据包被隧道化时，隧道化数据包必须标记为EF。
Other PHBs and PHB groups may be deployed in the same DS node or domain with the EF PHB as long as the requirement of section 2.1 is met.
只要满足第2.1节的要求，其他PHB和PHB组可以部署在与EF PHB相同的DS节点或域中。
To protect itself against denial of service attacks, the edge of a DS domain MUST strictly police all EF marked packets to a rate negotiated with the adjacent upstream domain. (This rate must be <= the EF PHB configured rate.) Packets in excess of the negotiated rate MUST be dropped. If two adjacent domains have not negotiated an EF rate, the downstream domain MUST use 0 as the rate (i.e., drop all EF marked packets).
为了保护自身免受拒绝服务攻击，DS域的边缘必须严格按照与相邻上游域协商的速率对所有EF标记的数据包进行监控。（此速率必须<=EF PHB配置速率。）超过协商速率的数据包必须丢弃。如果两个相邻域尚未协商EF速率，则下游域必须使用0作为速率（即，丢弃所有EF标记的数据包）。
Since the end-to-end premium service constructed from the EF PHB requires that the upstream domain police and shape EF marked traffic to meet the rate negotiated with the downstream domain, the downstream domain's policer should never have to drop packets. Thus these drops SHOULD be noted (e.g., via SNMP traps) as possible security violations or serious misconfiguration. Similarly, since the aggregate EF traffic rate is constrained at every interior node, the EF queue should never overflow so if it does the drops SHOULD be noted as possible attacks or serious misconfiguration.
由于由EF PHB构建的端到端高级服务要求上游域管理和塑造EF标记的流量，以满足与下游域协商的速率，因此下游域的管理者不必丢弃数据包。因此，应注意这些丢弃（例如，通过SNMP陷阱）可能存在的安全违规或严重配置错误。类似地，由于聚合EF流量率在每个内部节点都受到限制，EF队列永远不会溢出，因此如果发生溢出，则应将丢弃视为可能的攻击或严重的错误配置。
This document allocates one codepoint, 101110, in Pool 1 of the code space defined by [RFC2474].
本文档在[RFC2474]定义的代码空间的池1中分配一个代码点101110。
[Bradner97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bradner97]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Black，D.，Blake，S.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet",
Work in Progress, ftp://ftp.ee.lbl.gov/papers/dsarch.pdf
[2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet",
Work in Progress, ftp://ftp.ee.lbl.gov/papers/dsarch.pdf
[CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, Vol. 3 no. 4, pp. 365-386, August 1995.
[CBQ]S.Floyd和V.Jacobson，“分组网络的链路共享和资源管理模型”，IEEE/ACM网络交易，第3卷第4期，第365-386页，1995年8月。
[RFC2415] Poduri, K. and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
[RFC2415]Poduri，K.和K.Nichols，“增加初始TCP窗口大小的模拟研究”，RFC 2415，1998年9月。
[LCN] K. Nichols, "Improving Network Simulation with Feedback", Proceedings of LCN '98, October 1998.
[LCN]K.Nichols，“利用反馈改进网络模拟”，LCN'98会议录，1998年10月。
Van Jacobson Cisco Systems, Inc 170 W. Tasman Drive San Jose, CA 95134-1706
Van Jacobson Cisco Systems，Inc.加利福尼亚州圣何塞塔斯曼大道西170号，邮编95134-1706
EMail: van@cisco.com
EMail: van@cisco.com
Kathleen Nichols Cisco Systems, Inc 170 W. Tasman Drive San Jose, CA 95134-1706
凯瑟琳·尼科尔斯思科系统公司，加利福尼亚州圣何塞塔斯曼大道西170号，邮编95134-1706
EMail: kmn@cisco.com
EMail: kmn@cisco.com
Kedarnath Poduri Bay Networks, Inc. 4401 Great America Parkway Santa Clara, CA 95052-8185
美国加利福尼亚州圣克拉拉大美洲大道4401号凯达纳-波杜里湾网络公司，邮编95052-8185
EMail: kpoduri@baynetworks.com
EMail: kpoduri@baynetworks.com
Appendix A: Example use of and experiences with the EF PHB
附录A：EF PHB的使用示例和经验
A VLL Service, also known as Premium service [2BIT], is quantified by a peak bandwidth.
VLL服务，也称为高级服务[2BIT]，通过峰值带宽进行量化。
A prototype of the VLL service has been deployed on DOE's ESNet backbone. This uses weighted-round-robin queuing features of Cisco 75xx series routers to implement the EF PHB. The early tests have been very successful and work is in progress to make the service available on a routine production basis (see ftp://ftp.ee.lbl.gov/talks/vj-doeqos.pdf and ftp://ftp.ee.lbl.gov/talks/vj-i2qos-may98.pdf for details).
VLL服务的原型已部署在DOE的ESNet主干网上。这使用Cisco 75xx系列路由器的加权循环排队功能来实现EF PHB。早期测试非常成功，目前正在进行工作，以便在常规生产基础上提供服务（请参阅ftp://ftp.ee.lbl.gov/talks/vj-doeqos.pdf 和ftp://ftp.ee.lbl.gov/talks/vj-i2qos-may98.pdf 详细信息）。
In section 2.2, we pointed out that a number of mechanisms might be used to implement the EF PHB. The simplest of these is a priority queue (PQ) where the arrival rate of the queue is strictly less than its service rate. As jitter comes from the queuing delay along the path, a feature of this implementation is that EF-marked microflows will see very little jitter at their subscribed rate since packets spend little time in queues. The EF PHB does not have an explicit jitter requirement but it is clear from the definition that the expected jitter in a packet stream that uses a service based on the EF PHB will be less with PQ than with best-effort delivery. We used simulation to explore how weighted round-robin (WRR) compares to PQ in jitter. We chose these two since they"re the best and worst cases, respectively, for jitter and we wanted to supply rough guidelines for EF implementers choosing to use WRR or similar mechanisms.
在第2.2节中，我们指出可以使用许多机制来实现EF PHB。其中最简单的是优先级队列（PQ），其中队列的到达率严格小于其服务率。由于抖动来自路径上的排队延迟，此实现的一个特点是，EF标记的微流在其订阅速率下将看到非常小的抖动，因为数据包在队列中花费的时间很少。EF-PHB没有明确的抖动要求，但是从定义中可以清楚地看出，使用基于EF-PHB的服务的分组流中的预期抖动在PQ情况下将小于在尽力而为的交付情况下。我们使用模拟来探索加权循环（WRR）与PQ在抖动方面的比较。我们之所以选择这两种，是因为它们分别是抖动的最佳和最差情况，我们希望为选择使用WRR或类似机制的EF实现者提供粗略的指导。
Our simulation model is implemented in a modified ns-2 described in [RFC2415] and [LCN]. We used the CBQ modules included with ns-2 as a basis to implement priority queuing and WRR. Our topology has six hops with decreasing bandwidth in the direction of a single 1.5 Mbps bottleneck link (see figure 6). Sources produce EF-marked packets at an average bit rate equal to their subscribed packet rate. Packets are produced with a variation of +-10% from the interpacket spacing at the subscribed packet rate. The individual source rates were picked aggregate to 30% of the bottleneck link or 450 Kbps. A mixture of FTPs and HTTPs is then used to fill the link. Individual EF packet sources produce either all 160 byte packets or all 1500 byte packets.
我们的仿真模型在[RFC2415]和[LCN]中描述的改进ns-2中实现。我们使用ns-2中包含的CBQ模块作为实现优先级队列和WRR的基础。我们的拓扑结构有六个跃点，带宽沿单个1.5 Mbps瓶颈链路的方向递减（见图6）。源以等于其订阅的数据包速率的平均比特率生成EF标记的数据包。以订阅的数据包速率，从数据包间间隔产生+-10%的数据包。单个源速率被选为瓶颈链路的30%或450 Kbps。然后使用FTP和HTTPs的混合来填充链接。单个EF数据包源产生所有160字节数据包或所有1500字节数据包。
Though we present the statistics of flows with one size of packet, all of the experiments used a mixture of short and long packet EF sources so the EF queues had a mix of both packet lengths.
虽然我们提供了具有一个数据包大小的流的统计数据，但所有实验都使用了短数据包EF源和长数据包EF源的混合，因此EF队列具有两种数据包长度的混合。
We defined jitter as the absolute value of the difference between the arrival times of two adjacent packets minus their departure times, |(aj-dj) - (ai-di)|. For the target flow of each experiment, we record the median and 90th percentile values of jitter (expressed as % of the subscribed EF rate) in a table. The pdf version of this document contains graphs of the jitter percentiles.
我们将抖动定义为两个相邻数据包的到达时间减去它们的离开时间之差的绝对值，|（aj dj）-（ai di）|。对于每个实验的目标流，我们在表格中记录抖动的中值和第90个百分位值（表示为订阅EF率的百分比）。本文档的pdf版本包含抖动百分比图。
Our experiments compared the jitter of WRR and PQ implementations of the EF PHB. We assessed the effect of different choices of WRR queue weight and number of queues on jitter. For WRR, we define the service-to-arrival rate ratio as the service rate of the EF queue (or the queue"s minimum share of the output link) times the output link bandwidth divided by the peak arrival rate of EF-marked packets at the queue. Results will not be stable if the WRR weight is chosen to exactly balance arrival and departure rates thus we used a minimum service-to-arrival ratio of 1.03. In our simulations this means that the EF queue gets at least 31% of the output links. In WRR simulations we kept the link full with other traffic as described above, splitting the non-EF-marked traffic among the non-EF queues. (It should be clear from the experiment description that we are attempting to induce worst-case jitter and do not expect these settings or traffic to represent a "normal" operating point.)
我们的实验比较了EF PHB的WRR和PQ实现的抖动。我们评估了WRR队列权重和队列数量的不同选择对抖动的影响。对于WRR，我们将服务到达率比率定义为EF队列的服务率（或队列在输出链路中的最小份额）乘以输出链路带宽除以队列中EF标记数据包的峰值到达率。如果选择WRR权重来精确平衡到达率和离开率，则结果将不稳定，因此我们使用的最小服务到达率为1.03。在我们的模拟中，这意味着EF队列至少获得31%的输出链路。在WRR模拟我们如上所述保持链路充满其他流量，在非EF队列中分割非EF标记的流量。（从实验描述中可以清楚地看出，我们试图引起最坏情况下的抖动，并且不期望这些设置或流量代表“正常”操作点。）
Our first set of experiments uses the minimal service-to-arrival ratio of 1.06 and we vary the number of individual microflows composing the EF aggregate from 2 to 36. We compare these to a PQ implementation with 24 flows. First, we examine a microflow at a subscribed rate of 56 Kbps sending 1500 byte packets, then one at the same rate but sending 160 byte packets. Table 1 shows the 50th and 90th percentile jitter in percent of a packet time at the subscribed rate. Figure 1 plots the 1500 byte flows and figure 2 the 160 byte flows. Note that a packet-time for a 1500 byte packet at 56 Kbps is 214 ms, for a 160 byte packet 23 ms. The jitter for the large packets rarely exceeds half a subscribed rate packet-time, though most jitters for the small packets are at least one subscribed rate packet-time. Keep in mind that the EF aggregate is a mixture of small and large packets in all cases so short packets can wait for long packets in the EF queue. PQ gives a very low jitter.
我们的第一组实验使用最小服务到达比1.06，我们将构成EF聚合的单个微流的数量从2变为36。我们将其与具有24个流的PQ实现进行比较。首先，我们检查订阅速率为56kbps的微流，发送1500字节的数据包，然后检查速率相同但发送160字节数据包的微流。表1显示了订阅速率下数据包时间的第50和第90百分位抖动百分比。图1绘制了1500字节流，图2绘制了160字节流。注意，对于56 Kbps的1500字节数据包，数据包时间为214 ms，对于160字节数据包，数据包时间为23 ms。大数据包的抖动很少超过订阅速率数据包时间的一半，尽管小数据包的大多数抖动至少是一个订阅速率数据包时间。请记住，EF聚合在所有情况下都是大小数据包的混合，因此短数据包可以等待EF队列中的长数据包。PQ提供非常低的抖动。
Table 1: Variation in jitter with number of EF flows: Service/arrival ratio of 1.06 and subscription rate of 56 Kbps (all values given as % of subscribed rate)
表1：抖动随EF流数量的变化：服务/到达比率为1.06，订阅速率为56 Kbps（所有值均以订阅速率的百分比表示）
1500 byte pack. 160 byte packet # EF flows 50th % 90th % 50th % 90th % PQ (24) 1 5 17 43 2 11 47 96 513 4 12 35 100 278 8 10 25 96 126 24 18 47 96 143
1500字节的包。160字节数据包#EF流第50%90%50%90%PQ（24）1 5 17 43 2 11 47 96 513 4 12 35 100 278 10 25 96 126 24 18 47 96 143
Next we look at the effects of increasing the service-to-arrival ratio. This means that EF packets should remain enqueued for less time though the bandwidth available to the other queues remains the same. In this set of experiments the number of flows in the EF aggregate was fixed at eight and the total number of queues at five (four non-EF queues). Table 2 shows the results for 1500 and 160 byte flows. Figures 3 plots the 1500 byte results and figure 4 the 160 byte results. Performance gains leveled off at service-to-arrival ratios of 1.5. Note that the higher service-to-arrival ratios do not give the same performance as PQ, but now 90% of packets experience less than a subscribed packet-time of jitter even for the small packets.
接下来，我们来看看提高服务到达率的效果。这意味着尽管其他队列的可用带宽保持不变，EF数据包应保持排队时间更短。在这组实验中，EF聚合中的流数固定为8，队列总数固定为5（4个非EF队列）。表2显示了1500和160字节流的结果。图3显示了1500字节的结果，图4显示了160字节的结果。服务到达率为1.5时，性能提升趋于平稳。请注意，较高的服务到达率并不能提供与PQ相同的性能，但现在90%的数据包经历的抖动时间小于订阅的数据包时间，即使对于较小的数据包也是如此。
Table 2: Variation in Jitter of EF flows: service/arrival ratio varies, 8 flow aggregate, 56 Kbps subscribed rate
表2:EF流抖动的变化：服务/到达比率变化，8流聚合，56 Kbps订阅速率
WRR 1500 byte pack. 160 byte packet Ser/Arr 50th % 90th % 50th % 90th % PQ 1 3 17 43 1.03 14 27 100 178 1.30 7 21 65 113 1.50 5 13 57 104 1.70 5 13 57 100 2.00 5 13 57 104 3.00 5 13 57 100
WRR 1500字节包。160字节数据包Ser/Arr第50%90%50%90%PQ 1 3 17 43 1.03 14 27 100 178 1.30 7 21 65 113 1.50 5 13 57 104 1.70 5 13 57 100 2.00 5 13 57 104 3.00 5 13 57 100
Increasing the number of queues at the output interfaces can lead to more variability in the service time for EF packets so we carried out an experiment varying the number of queues at each output port. We fixed the number of flows in the aggregate to eight and used the minimal 1.03 service-to-arrival ratio. Results are shown in figure 5 and table 3. Figure 5 includes PQ with 8 flows as a baseline.
增加输出接口处的队列数量会导致EF数据包的服务时间发生更大的变化，因此我们进行了一项实验，以改变每个输出端口处的队列数量。我们将总流量固定为8，并使用最小的1.03服务到达率。结果如图5和表3所示。图5包括以8个流程作为基线的PQ。
Table 3: Variation in Jitter with Number of Queues at Output Interface: Service-to-arrival ratio is 1.03, 8 flow aggregate
表3：抖动随输出接口处队列数量的变化：服务到达率为1.03，8流量聚合
# EF 1500 byte packet flows 50th % 90th % PQ (8) 1 3 2 7 21 4 7 21 6 8 22 8 10 23
#EF 1500字节数据包流第50%90%PQ（8）1 3 2 7 21 4 7 21 6 8 22 8 10 23
It appears that most jitter for WRR is low and can be reduced by a proper choice of the EF queue's WRR share of the output link with respect to its subscribed rate. As noted, WRR is a worst case while PQ is the best case. Other possibilities include WFQ or CBQ with a fixed rate limit for the EF queue but giving it priority over other queues. We expect the latter to have performance nearly identical with PQ though future simulations are needed to verify this. We have not yet systematically explored effects of hop count, EF allocations other than 30% of the link bandwidth, or more complex topologies. The information in this section is not part of the EF PHB definition but provided simply as background to guide implementers.
似乎WRR的大多数抖动都很低，并且可以通过适当选择EF队列的输出链路WRR份额相对于其订阅速率来降低。如前所述，WRR是最坏的情况，而PQ是最好的情况。其他可能性包括WFQ或CBQ，EF队列具有固定速率限制，但优先于其他队列。我们希望后者的性能与PQ几乎相同，尽管需要未来的仿真来验证这一点。我们还没有系统地研究跳数、EF分配（链路带宽的30%除外）或更复杂拓扑的影响。本节中的信息不是EF PHB定义的一部分，只是作为指导实施者的背景提供的。
We used simulation to see how well a VLL service built from the EF PHB behaved, that is, does it look like a `leased line' at the subscribed rate. In the simulations of the last section, none of the EF packets were dropped in the network and the target rate was always achieved for those CBR sources. However, we wanted to see if VLL really looks like a `wire' to a TCP using it. So we simulated long-lived FTPs using a VLL service. Table 4 gives the percentage of each link allocated to EF traffic (bandwidths are lower on the links with fewer EF microflows), the subscribed VLL rate, the average rate for the same type of sender-receiver pair connected by a full duplex dedicated link at the subscribed rate and the average of the VLL flows for each simulation (all sender-receiver pairs had the same value). Losses only occur when the input shaping buffer overflows but not in the network. The target rate is not achieved due to the well-known TCP behavior.
我们使用模拟来观察从EF PHB构建的VLL服务的性能，也就是说，它在订阅速率下是否看起来像“租用线路”。在最后一部分的模拟中，网络中没有任何EF数据包被丢弃，并且这些CBR源始终达到目标速率。然而，我们想看看VLL是否真的看起来像TCP使用它的“电线”。因此，我们使用VLL服务模拟了长寿命FTP。表4给出了分配给EF流量的每个链路的百分比（EF微流量较少的链路上的带宽较低）、订阅的VLL速率、以订阅速率由全双工专用链路连接的相同类型的发送方-接收方对的平均速率以及每个模拟的VLL流的平均值（所有发送方-接收方对具有相同的值）。仅当输入整形缓冲区溢出时才会发生丢失，但在网络中不会发生。由于众所周知的TCP行为，无法达到目标速率。
Table 4: Performance of FTPs using a VLL service
表4：使用VLL服务的FTP性能
% link Average delivered rate (Kbps) to EF Subscribed Dedicated VLL 20 100 90 90 40 150 143 143 60 225 213 215
%EF订阅专用VLL 20 100 90 40 150 143 143 60 225 213 215的链路平均交付速率（Kbps）
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。