Network Working Group R. Bless
Request for Comments: 3662 Univ. of Karlsruhe
Category: Informational K. Nichols
Consultant
K. Wehrle
Univ. of Tuebingen/ICSI
December 2003
Network Working Group R. Bless
Request for Comments: 3662 Univ. of Karlsruhe
Category: Informational K. Nichols
Consultant
K. Wehrle
Univ. of Tuebingen/ICSI
December 2003
A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services
用于区分服务的较低的每域努力行为（PDB）
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document proposes a differentiated services per-domain behavior (PDB) whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a "lower" priority than the normal "best-effort" Internet traffic, thus the PDB is called "Lower Effort" (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on "best-effort"/"normal" or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic.
本文档提出了一种按域区分服务的行为（PDB），在正常运行的网络中，其流量可能会“饥饿”（尽管不严格要求饥饿）。这与互联网的“尽力而为”或“正常互联网流量”模式形成了对比，在这种模式下，长期的饥饿意味着网络问题。从这个意义上讲，所提议的PDB的流量以比正常的“尽力而为”因特网流量“更低”的优先级转发，因此PDB被称为“更低的努力”（LE）。使用此PDB允许网络运营商严格限制其流量对“尽力而为”/“正常”或所有其他互联网流量的影响。本文件给出了一些使用示例，但不建议将PDB的使用限制为任何特定类型的流量。
This document proposes a differentiated services per-domain behavior [RFC3086] called "Lower Effort" (LE) which is intended for traffic of sufficiently low value (where "value" may be interpreted in any useful way by the network operator), in which all other traffic takes precedence over LE traffic in consumption of network link bandwidth. One possible interpretation of "low value" traffic is its low priority in time, which does not necessarily imply that it is generally of minor importance. From this viewpoint, it can be
本文件提出了一种称为“较低努力”（LE）的按域区分服务行为[RFC3086]，该行为适用于价值足够低的流量（其中“价值”可由网络运营商以任何有用的方式解释），其中，在网络链路带宽的消耗中，所有其他流量优先于LE流量。“低价值”流量的一种可能解释是其时间优先级较低，这并不一定意味着其重要性一般较小。从这个角度来看，它可以是
considered as a network equivalent to a background priority for processes in an operating system. There may or may not be memory (buffer) resources allocated for this type of traffic.
被认为是一个网络，相当于操作系统中进程的后台优先级。可能有也可能没有为这种类型的通信分配内存（缓冲区）资源。
Some networks carry traffic for which delivery is considered optional; that is, packets of this type of traffic ought to consume network resources only when no other traffic is present. Alternatively, the effect of this type of traffic on all other network traffic is strictly limited. This is distinct from "best-effort" (BE) traffic since the network makes no commitment to deliver LE packets. In contrast, BE traffic receives an implied "good faith" commitment of at least some available network resources. This document proposes a Lower Effort Differentiated Services per-domain behavior (LE PDB) [RFC3086] for handling this "optional" traffic in a differentiated services domain.
有些网络承载的流量被认为是可选的；也就是说，只有在不存在其他流量时，此类流量的数据包才应该消耗网络资源。或者，此类流量对所有其他网络流量的影响受到严格限制。这与“尽力而为”（BE）流量不同，因为网络不承诺交付LE数据包。与此相反，BE通信收到至少一些可用网络资源的隐含“善意”承诺。本文档提出了一种较低工作量的每域区分服务行为（LE PDB）[RFC3086]，用于在区分服务域中处理此“可选”流量。
There is no intrinsic reason to limit the applicability of the LE PDB to any particular application or type of traffic. It is intended as an additional tool for administrators in engineering networks.
没有内在理由限制LE PDB对任何特定应用或交通类型的适用性。它旨在作为工程网络中管理员的附加工具。
Note: where not otherwise defined, terminology used in this document is defined as in [RFC2474].
注：如果没有其他定义，本文件中使用的术语定义见[RFC2474]。
A Lower Effort (LE) PDB is for sending extremely non-critical traffic across a DS domain or DS region. There should be an expectation that packets of the LE PDB may be delayed or dropped when other traffic is present. Use of the LE PDB might assist a network operator in moving certain kinds of traffic or users to off-peak times. Alternatively, or in addition, packets can be designated for the LE PDB when the goal is to protect all other packet traffic from competition with the LE aggregate, while not completely banning LE traffic from the network. An LE PDB should not be used for a customer's "normal internet" traffic, nor should packets be "downgraded" to the LE PDB for use as a substitute for dropping packets that ought to simply be dropped as unauthorized. The LE PDB is expected to be applicable to networks that have some unused capacity at some times of day.
较低工作量（LE）PDB用于跨DS域或DS区域发送非常非关键的流量。当存在其他业务时，应该期望LE-PDB的分组可能被延迟或丢弃。使用LE PDB可能有助于网络运营商将某些类型的流量或用户转移到非高峰时间。或者，或者另外，当目标是保护所有其他分组流量不与LE聚合竞争时，可以为LE PDB指定分组，同时不完全禁止来自网络的LE流量。LE PDB不应用于客户的“正常互联网”流量，也不应将数据包“降级”到LE PDB，以替代应作为未经授权丢弃的数据包。预计LE PDB将适用于在一天中的某些时间具有一些未使用容量的网络。
This is a PDB that allows networks to protect themselves from selected types of traffic rather than giving a selected traffic aggregate preferential treatment. Moreover, it may also exploit all unused resources from other PDBs.
这是一种PDB，允许网络保护自己不受选定流量类型的影响，而不是给予选定流量聚合优惠待遇。此外，它还可以利用来自其他PDB的所有未使用资源。
There are no required traffic profiles governing the rate and bursts of packets beyond the limits imposed by the ingress link. It is not necessary to limit the LE aggregate using edge techniques since its PHB is configured such that packets of the aggregate will be dropped in the network if no forwarding resources are available. The differentiated services architecture [RFC2475] allows packets to be marked upstream of the DS domain or at the DS domain's edge. When packets arrive pre-marked with the DSCP used by the LE PDB, it should not be necessary for the DS domain boundary to police that marking; further (MF) classification for such packets would only be required if there was some reason for the packets to be marked with a different DSCP.
没有必要的流量配置文件来控制超出入口链路限制的数据包的速率和突发。无需使用边缘技术限制LE聚合，因为其PHB被配置为如果没有可用的转发资源，则聚合的分组将在网络中丢弃。区分服务体系结构[RFC2475]允许在DS域上游或DS域边缘标记数据包。当数据包到达时预先标记了LE PDB使用的DSCP，DS域边界不必监督该标记；仅当有某些原因需要使用不同的DSCP标记这些数据包时，才需要对这些数据包进行进一步（MF）分类。
If there is not an agreement on a DSCP marking with the upstream domain for a DS domain using the LE PDB, the boundary must include a classifier that selects the appropriate LE target group of packets out of all arriving packets and steers them to a marker that sets the appropriate DSCP. No other traffic conditioning is required.
如果未就使用LE PDB的DS域的上游域的DSCP标记达成协议，则边界必须包括一个分类器，该分类器从所有到达的数据包中选择适当的LE目标数据包组，并将其导向设置适当DSCP的标记。不需要其他交通条件。
Either a Class Selector (CS) PHB [RFC2474], an Experimental/Local Use (EXP/LU) PHB [RFC2474], or an Assured Forwarding (AF) PHB [RFC2597] may be used as the PHB for the LE traffic aggregate. This document does not specify the exact DSCP to use inside a domain, but instead specifies the necessary properties of the PHB selected by the DSCP. If a CS PHB is used, Class Selector 1 (DSCP=001000) is suggested.
类选择器（CS）PHB[RFC2474]、实验/本地使用（EXP/LU）PHB[RFC2474]或保证转发（AF）PHB[RFC2597]可以用作LE流量聚合的PHB。本文档未指定要在域内使用的确切DSCP，而是指定由DSCP选择的PHB的必要属性。如果使用CS PHB，建议使用类别选择器1（DSCP=001000）。
The PHB used by the LE aggregate inside a DS domain should be configured so that its packets are forwarded onto the node output link when the link would otherwise be idle; conceptually, this is the behavior of a weighted round-robin scheduler with a weight of zero.
DS域内LE聚合使用的PHB应进行配置，以便在链路空闲时将其数据包转发到节点输出链路上；从概念上讲，这是权重为零的加权循环调度程序的行为。
An operator might choose to configure a very small link share for the LE aggregate and still achieve the desired goals. That is, if the output link scheduler permits, a small fixed rate might be assigned to the PHB, but the behavior beyond that configured rate should be that packets are forwarded only when the link would otherwise be idle. This behavior could be obtained, for example, by using a CBQ [CBQ] scheduler with a small share and with borrowing permitted. A PHB that allows packets of the LE aggregate to send more than the configured rate when packets of other traffic aggregates are waiting for the link is not recommended.
运营商可能会选择为LE聚合配置非常小的链接共享，并且仍然可以实现所需的目标。也就是说，如果输出链路调度器允许，可能会为PHB分配一个小的固定速率，但超出该配置速率的行为应该是，只有在链路空闲时才转发数据包。例如，可以通过使用CBQ[CBQ]调度器来获得这种行为，该调度器具有较小的共享空间，并且允许借用。当其他流量聚合的数据包等待链路时，不建议使用允许LE聚合的数据包发送超过配置速率的PHB。
If a CS PHB is used, note that this configuration will violate the "SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will have a less timely forwarding than CS0. An operator's goal of providing an LE PDB is sufficient cause for violating the SHOULD. If an AF PHB is used, it must be configured and a DSCP assigned such that it does not violate the "MUST" of paragraph three of section 2 of RFC 2597 [RFC2597] which provides for a "minimum amount of forwarding resources".
如果使用CS PHB，请注意，此配置将违反RFC 2474[RFC2474]第4.2.2.2节的“应该”，因为CS1的转发比CS0的及时。运营商提供LE PDB的目标足以导致违反本协议。如果使用了AF PHB，则必须对其进行配置并分配DSCP，以确保其不会违反RFC 2597[RFC2597]第2节第3段的“必须”，该段规定了“最小转发资源量”。
The ingress and egress flow of the LE aggregate can be measured but there are no absolute or statistical attributes that arise from the PDB definition. A particular network operator may configure the DS domain in such a way that a statistical metric can be associated with that DS domain. When the DS domain is known to be heavily congested with traffic of other PDBs, a network operator should expect to see no (or very few) packets of the LE PDB egress from the domain. When there is no other traffic present, the proportion of the LE aggregate that successfully crosses the domain should be limited only by the capacity of the network relative to the ingress LE traffic aggregate.
可以测量LE骨料的入口和出口流量，但PDB定义中没有绝对或统计属性。特定网络运营商可以这样配置DS域，即统计度量可以与该DS域相关联。当已知DS域被其他PDB的流量严重拥塞时，网络运营商应该期望不看到（或很少看到）来自该域的LE-PDB出口的分组。当不存在其他流量时，成功穿越域的LE聚合的比例应仅受网络相对于入口LE流量聚合的容量的限制。
None required.
不需要。
A properly functioning network.
正常运行的网络。
o Multimedia applications [this example edited from Yoram Bernet]:
o 多媒体应用程序[此示例由Yoram Bernet编辑]：
Many network managers want to protect their networks from certain applications, in particular, from multimedia applications that typically use such non-adaptive protocols as UDP.
许多网络管理者希望保护他们的网络不受某些应用程序的影响，特别是不受通常使用UDP等非自适应协议的多媒体应用程序的影响。
Most of the focus in quality-of-service is on achieving attributes that are better than Best Effort. These approaches can provide network managers with the ability to control the amount of multimedia traffic that is given this improved performance with excess relegated to Best Effort. This excess traffic can wreak havoc with network resources even when it is relegated to Best Effort because it is non-adaptive and because it can be significant in volume and duration. These characteristics permit it to seize network resources, thereby compromising the performance of other, more important applications that are
服务质量的大部分重点是实现比尽力而为更好的属性。这些方法可以为网络管理者提供控制多媒体通信量的能力，从而提高性能，并尽最大努力。这种过多的流量可能会对网络资源造成严重破坏，即使是在将其降级为“尽力而为”时也是如此，因为它是非自适应的，而且在容量和持续时间上都可能非常重要。这些特性允许it抓住网络资源，从而影响其他更重要的应用程序的性能
included in the Best Effort traffic aggregate but that use adaptive protocols (e.g., TCP). As a result, network managers often simply refuse to allow multimedia applications to be deployed in resource constrained parts of their network.
包含在尽力而为流量聚合中，但使用自适应协议（例如TCP）。因此，网络管理者往往干脆拒绝将多媒体应用程序部署在其网络中资源受限的部分。
The LE PDB enables a network manager to allow the deployment of multimedia applications without losing control of network resources. A limited amount of multimedia traffic may (or may not) be assigned to PDBs with attributes that are better than Best Effort. Excess multimedia traffic can be prevented from wreaking havoc with network resources by forcing it to the LE PDB.
LE PDB使网络管理器能够在不失去对网络资源控制的情况下部署多媒体应用程序。有限数量的多媒体通信可以（也可以不）分配给具有比尽力而为更好的属性的pdb。通过将过量的多媒体流量强制传输到LE PDB，可以防止其对网络资源造成严重破坏。
o For Netnews and other "bulk mail" of the Internet.
o 用于网络新闻和互联网上的其他“批量邮件”。
o For "downgraded" traffic from some other PDB when this does not violate the operational objectives of the other PDB or the overall network. As noted in section 2, LE should not be used for the general case of downgraded traffic, but may be used by design, e.g., when multicast is used with a value-added DS-service and consequently the Neglected Reservation Subtree problem [NRS] arises.
o 当不违反其他PDB或整个网络的运营目标时，针对来自其他PDB的“降级”流量。如第2节所述，LE不应用于降级流量的一般情况，但可通过设计使用，例如，当多播与增值DS服务一起使用时，因此会出现被忽略的保留子树问题[NRS]。
o For content distribution, peer-to-peer file sharing traffic, and the like.
o 用于内容分发、对等文件共享流量等。
o For traffic caused by world-wide web search engines while they gather information from web servers.
o 当万维网搜索引擎从网络服务器收集信息时，会导致流量增加。
The authors solicit further experiences for this section. Results from simulations are presented and discussed in Appendix A.
作者为本节征求进一步的经验。附录A中给出并讨论了模拟结果。
There are no specific security exposures for this PDB. See the general security considerations in [RFC2474] and [RFC2475].
此PDB没有特定的安全风险。请参阅[RFC2474]和[RFC2475]中的一般安全注意事项。
The previous name of this PDB, "bulk handling", was loosely based on the United States' Postal Service term for very low priority mail, sent at a reduced rate: it denotes a lower-cost delivery where the items are not handled with the same care or delivered with the same timeliness as items with first-class postage. Finally, the name was changed to "lower effort", because the authors and other DiffServ Working Group members believe that the name should be more generic in order to not imply constraints on the PDB's use to a particular type
该PDB的前一个名称“批量处理”大致基于美国邮政服务术语，即极低优先级的邮件，以较低的费率发送：它表示较低的成本交付，其中邮件的处理和交付与一流邮资的邮件不一样谨慎或不一样及时。最后，该名称改为“较低的努力”，因为作者和其他DiffServ工作组成员认为，该名称应更通用，以避免对PDB对特定类型的使用产生限制
of traffic (namely that of bulk data).
流量（即批量数据的流量）。
The notion of having something "lower than Best Effort" was raised in the Diffserv Working Group, most notably by Roland Bless and Klaus Wehrle in their Internet Drafts [LBE] and [LE] and by Yoram Bernet for enterprise multimedia applications. One of its first applications was to re-mark packets within multicast groups [NRS]. Therefore, previous discussions centered on the creation of a new PHB. However, the original authors (Brian Carpenter and Kathleen Nichols) believe this is not required and this document was written to specifically explain how to get less than Best Effort without a new PHB.
Diffserv工作组提出了“低于最佳努力”的概念，最著名的是罗兰·布莱斯（Roland Bless）和克劳斯·韦勒（Klaus Wehrle）在其互联网草案[LBE]和[LE]中以及约拉姆·伯内特（Yoram Bernet）在企业多媒体应用中提出的。它最早的应用之一是在多播组[NRS]中重新标记数据包。因此，以前的讨论集中在创建新的PHB上。然而，最初的作者（Brian Carpenter和Kathleen Nichols）认为这并不是必需的，本文档的目的是专门解释如何在没有新PHB的情况下获得低于最佳的努力。
Yoram Bernet contributed significant amounts of text for the "Examples" section of this document and provided other useful comments that helped in editing. Other Diffserv WG members suggested that the LE PDB is needed for Napster traffic, particularly at universities. Special thanks go to Milena Neumann for her extensive efforts in performing the simulations that are described in Appendix A.
Yoram Bernet为本文件的“示例”部分提供了大量文本，并提供了有助于编辑的其他有用评论。其他Diffserv工作组成员建议，Napster流量需要LE PDB，尤其是在大学。特别感谢Milena Neumann在执行附录A中描述的模拟方面所做的大量努力。
The intention of this appendix is to show that a Lower Effort PDB with a behavior as described in this document can be realized with different implementations and PHBs respectively. Overall, each of these variants show the desired behavior but also show minor differences in certain traffic load situations. This comparison could make the choice of a realization variant interesting for a network operator.
本附录的目的是表明，具有本文档所述行为的较低工作量PDB可以分别通过不同的实现和PHB实现。总的来说，这些变体中的每一个都显示了所需的行为，但在某些流量负载情况下也显示出细微的差异。这种比较可以使网络运营商对实现变量的选择感兴趣。
The small DiffServ domain shown in Figure 1 was used to simulate the LE PDB. There are three main sources of traffic (S1-S3) depicted on the left side of the figure. Source S1 sends five aggregated TCP flows (A1-A5) to the receivers R1-R5 respectively. Each aggregated flow Ax consists of 20 TCP connections, where each aggregate experiences a different round trip time between 10ms and 250ms. There are two sources of bulk traffic. B1 consists of 100 TCP connections sending as much data as possible to R6 and B2 is a single UDP flow also sending as much as possible to R7.
图1所示的小型DiffServ域用于模拟LE PDB。图左侧描述了三个主要的流量源（S1-S3）。源S1分别向接收器R1-R5发送五个聚合TCP流（A1-A5）。每个聚合流Ax由20个TCP连接组成，其中每个聚合在10ms和250ms之间经历不同的往返时间。批量流量有两个来源。B1由100个TCP连接组成，向R6发送尽可能多的数据，B2是一个UDP流，也向R7发送尽可能多的数据。
...................
. . R1
. . /
. . /-R2
. . /
S1==**=>[BR1] [BR4]==**==>---R3
. \\ // . \
. \\ // . \-R4
. ** ** . \
. \\ // . R5
. \\ // .
S2=++=>[BR2]-++-[IR1]==**==++==::==[IR2] .
(Bulk) . // \\ .
. // :: .
. :: \\ .
. // ++ .
.// \\.
S3==::==>[BR3] [BR5]==++==>R6
(UDP) . . ||
. . ||
. . ::
.................... ||
VV
R7
...................
. . R1
. . /
. . /-R2
. . /
S1==**=>[BR1] [BR4]==**==>---R3
. \\ // . \
. \\ // . \-R4
. ** ** . \
. \\ // . R5
. \\ // .
S2=++=>[BR2]-++-[IR1]==**==++==::==[IR2] .
(Bulk) . // \\ .
. // :: .
. :: \\ .
. // ++ .
.// \\.
S3==::==>[BR3] [BR5]==++==>R6
(UDP) . . ||
. . ||
. . ::
.................... ||
VV
R7
Figure 1: A DiffServ domain with different flows
图1：具有不同流的DiffServ域
In order to show the benefit of using the LE PDB instead of the normal Best Effort (BE) PDB [RFC3086], different scenarios are used:
为了展示使用LE PDB而不是正常尽力而为（BE）PDB[RFC3086]的好处，使用了不同的场景：
A) B1 and B2 are not present, i.e., the "normal" situation without bulk data present. A1-A5 use the BE PDB.
A） B1和B2不存在，即不存在批量数据的“正常”情况。A1-A5使用BE PDB。
B) B1 and B2 use the BE PDB for their traffic, too.
B） B1和B2的流量也使用BE PDB。
C) B1 and B2 use LE PDB for their traffic with different PHB implementations:
C） B1和B2使用LE PDB实现不同PHB实现的流量：
1) PHB with Priority Queueing (PQ) 2) PHB with Weighted Fair Queueing (WFQ) 3) PHB with Weighted RED (WRED) 4) PHB with WFQ and RED
1) 具有优先级排队（PQ）的PHB 2）具有加权公平排队（WFQ）的PHB 3）具有加权红色（WRED）的PHB 4）具有加权公平排队（WFQ）和红色的PHB
C1) represents the case where there are no allocated resources for the LE PDB, i.e., LE traffic is only forwarded if there are unused resources. In scenarios C2)-C4), a bandwidth share of 10% has been allocated for the LE PDB. RED parameters were set to w_q=0.1 and max_p=0.2. In scenario C2), two tail drop queues were used for BE and LE and WFQ scheduling was set up with a weight of 9:1 for the ratio of BE:LE. In scenario C3), a total queue length of 200000 bytes was used with the following thresholds: min_th_BE=19000, max_th_BE=63333, min_th_LE=2346, max_th=7037. WRED allows to mark packets with BE or LE within the same microflow (e.g., letting applications pre-mark packets according to their importance) without causing a reordering of packets within the microflow. In scenario C4), each queue had a length of 50000 bytes with the same thresholds of min_th=18000 and max_th=48000 bytes. WFQ parameters were the same as in C2).
C1）表示没有为LE PDB分配资源的情况，即，仅当存在未使用的资源时才转发LE业务。在场景C2）-C4）中，已为LE PDB分配了10%的带宽共享。红色参数设置为w_q=0.1和max_p=0.2。在场景C2）中，BE和LE使用了两个尾部丢弃队列，WFQ调度的权重为BE:LE的9:1。在场景C3）中，使用了200000字节的总队列长度和以下阈值：最小值=19000，最大值=63333，最小值=2346，最大值=7037。WRED允许在同一微流中使用BE或LE标记数据包（例如，让应用程序根据其重要性预先标记数据包），而不会导致微流中数据包的重新排序。在场景C4）中，每个队列的长度为50000字节，最小值为18000字节，最大值为48000字节。WFQ参数与C2中的相同）。
The link bandwidth between IR1 and IR2 is limited to 1200 kbit/s, thus creating the bottleneck in the network for the following situations. In all situations, the 20 TCP connections within each aggregated flow Ax (flowing from S1 to Rx) used the Best Effort PDB. Sender S2 transmitted bulk flow B1 (consisting of 100 TCP connections to R6) with an aggregated rate of 550 kbit/s, whereas the UDP sender S3 transmitted with a rate of 50 kbit/s.
IR1和IR2之间的链路带宽限制为1200 kbit/s，因此在以下情况下会造成网络瓶颈。在所有情况下，每个聚合流Ax（从S1流到Rx）中的20个TCP连接都使用最大努力PDB。发送方S2以550 kbit/s的聚合速率传输大容量流B1（包括到R6的100个TCP连接），而UDP发送方S3以50 kbit/s的速率传输。
The following four different situations with varying traffic load for the Ax flows (at application level) were simulated.
模拟了以下四种不同情况下Ax流的不同流量负载（在应用程序级别）。
Situation | I | II | III | IV |
----------------------------+------+------+------+------|
Sender Rate S1 [kbit/s] | 1200 | 1080 | 1800 | 800 |
Sender Rate S2 [kbit/s] | 550 | 550 | 550 | 550 |
Sender Rate S3 [kbit/s] | 50 | 50 | 50 | 50 |
Bandwidth IR1 -> IR2 | 1200 | 1200 | 1200 | 1200 |
Best Effort Load (S1) | 100% | 90% | 150% | 67% |
Total load for link IR1->IR2| 150% | 140% | 200% | 117% |
Situation | I | II | III | IV |
----------------------------+------+------+------+------|
Sender Rate S1 [kbit/s] | 1200 | 1080 | 1800 | 800 |
Sender Rate S2 [kbit/s] | 550 | 550 | 550 | 550 |
Sender Rate S3 [kbit/s] | 50 | 50 | 50 | 50 |
Bandwidth IR1 -> IR2 | 1200 | 1200 | 1200 | 1200 |
Best Effort Load (S1) | 100% | 90% | 150% | 67% |
Total load for link IR1->IR2| 150% | 140% | 200% | 117% |
In situation I, there are no unused resources left for the B1 and B2 flows. In situation II, there is a residual bandwidth of 10% of the bottleneck link between IR1 and IR2. In situation III, the traffic load of A1-A5 is 50% higher than the bottleneck link capacity. In situation IV, A1-A5 consume only 2/3 of the bottleneck link capacity. B1 and B2 require together 50% of the bottleneck link capacity.
在情况I中，B1和B2流没有剩余的未使用资源。在情况II中，IR1和IR2之间的剩余带宽为瓶颈链路的10%。在情况III中，A1-A5的流量负载比瓶颈链路容量高50%。在情况IV中，A1-A5仅消耗瓶颈链路容量的2/3。B1和B2总共需要50%的瓶颈链路容量。
The simulations were performed with the freely available discrete event simulation tool OMNeT++ and a suitable set of QoS mechanisms [SimKIDS]. Results from the different simulation scenarios are discussed in the next section.
使用免费提供的离散事件模拟工具OMNeT++和一组合适的QoS机制[SimKIDS]进行模拟。下一节将讨论不同模拟场景的结果。
QoS parameters listed in the following tables are averaged over the first 160s of the transmission. Results of situation I are shown in Figure 2. When the BE PDB is used for transmission of bulk flows B1 and B2 in case B), one can see that flows A1-A5 throttle their sending rate to allow transmission of bulk flows B1 and B2. In case C1), not a single packet is transmitted to the receiver because all packets get dropped within IR1, thereby protecting Ax flows from Bx flows. In case C2), B1 and B2 consume all resources up to the configured limit of 10% of the link bandwidth, but not more. C3) also limits the share of B1 and B2 flows, but not as precisely as with WFQ. C4) shows slightly higher packet losses for Ax flows due to the active queue management.
下表中列出的QoS参数是传输前160秒的平均值。情况I的结果如图2所示。在情况B）中，当BE PDB用于传输大量流B1和B2时，可以看到流A1-A5调节其发送速率以允许传输大量流B1和B2。在情况C1）中，没有向接收机发送单个分组，因为所有分组都在IR1中丢弃，从而保护Ax流不受Bx流的影响。在案例C2）中，B1和B2消耗的所有资源最多为配置的链路带宽的10%，但不超过10%。C3）也限制B1和B2流量的份额，但不像WFQ那样精确。C4）显示由于活动队列管理，Ax流的数据包丢失略高。
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 240 | 71 | 240 | 214 | 225 | 219 |
| | A2 | 240 | 137 | 240 | 216 | 223 | 218 |
| | A3 | 240 | 209 | 240 | 224 | 220 | 217 |
| Throughput | A4 | 239 | 182 | 239 | 222 | 215 | 215 |
| [kbit/s] | A5 | 238 | 70 | 238 | 202 | 201 | 208 |
| | B1 | - | 491 | 0 | 82 | 85 | 84 |
| | B2 | - | 40 | 0 | 39 | 31 | 38 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 1197 | 669 | 1197 | 1078 | 1084 | 1078 |
| [kbit/s] | bulk | - | 531 | 0 | 122 | 116 | 122 |
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 0 | 19.3 | 0 | 6.3 | 5.7 | 8.6 |
| | A2 | 0 | 17.5 | 0 | 6.0 | 5.9 | 8.9 |
| | A3 | 0 | 10.2 | 0 | 3.2 | 6.2 | 9.1 |
| Paket Loss | A4 | 0 | 12.5 | 0 | 4.5 | 6.6 | 9.3 |
| [%] | A5 | 0 | 22.0 | 0 | 6.0 | 5.9 | 9.0 |
| | B1 | - | 10.5 | 100 | 33.6 | 38.4 | 33.0 |
| | B2 | - | 19.6 | 100 | 19.9 | 37.7 | 22.2 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 0 | 14.9 | 0 | 5.2 | 6.1 | 9.0 |
| Loss Rate [%] | bulk | 0 | 11.4 | 100 | 29.5 | 38.2 | 29.7 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 21.9 | 12.6 | 21.9 | 19.6 | 20.3 | 20.3 |
+----------------+--------+--------+------+------+------+------+-------+
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 240 | 71 | 240 | 214 | 225 | 219 |
| | A2 | 240 | 137 | 240 | 216 | 223 | 218 |
| | A3 | 240 | 209 | 240 | 224 | 220 | 217 |
| Throughput | A4 | 239 | 182 | 239 | 222 | 215 | 215 |
| [kbit/s] | A5 | 238 | 70 | 238 | 202 | 201 | 208 |
| | B1 | - | 491 | 0 | 82 | 85 | 84 |
| | B2 | - | 40 | 0 | 39 | 31 | 38 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 1197 | 669 | 1197 | 1078 | 1084 | 1078 |
| [kbit/s] | bulk | - | 531 | 0 | 122 | 116 | 122 |
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 0 | 19.3 | 0 | 6.3 | 5.7 | 8.6 |
| | A2 | 0 | 17.5 | 0 | 6.0 | 5.9 | 8.9 |
| | A3 | 0 | 10.2 | 0 | 3.2 | 6.2 | 9.1 |
| Paket Loss | A4 | 0 | 12.5 | 0 | 4.5 | 6.6 | 9.3 |
| [%] | A5 | 0 | 22.0 | 0 | 6.0 | 5.9 | 9.0 |
| | B1 | - | 10.5 | 100 | 33.6 | 38.4 | 33.0 |
| | B2 | - | 19.6 | 100 | 19.9 | 37.7 | 22.2 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 0 | 14.9 | 0 | 5.2 | 6.1 | 9.0 |
| Loss Rate [%] | bulk | 0 | 11.4 | 100 | 29.5 | 38.2 | 29.7 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 21.9 | 12.6 | 21.9 | 19.6 | 20.3 | 20.3 |
+----------------+--------+--------+------+------+------+------+-------+
Figure 2: Situation I - Best Effort traffic uses 100% of the available bandwidth
图2：情况I-尽力而为流量使用100%的可用带宽
Results of situation II are shown in Figure 3. In case C1), LE traffic gets exactly the 10% residual bandwidth that is not used by the Ax flows. Cases C2) and C4) show similar results compared to C1), whereas case C3) also drops packets from flows A1-A5 due to active queue management.
情况二的结果如图3所示。在案例C1）中，LE通信量正好获得Ax流未使用的10%剩余带宽。案例C2）和C4）显示了与C1）类似的结果，而案例C3）也由于主动队列管理而从流A1-A5丢弃数据包。
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 216 | 193 | 216 | 216 | 211 | 216 |
| | A2 | 216 | 171 | 216 | 216 | 211 | 216 |
| | A3 | 216 | 86 | 216 | 216 | 210 | 216 |
| Throughput | A4 | 215 | 121 | 215 | 215 | 211 | 215 |
| [kbit/s] | A5 | 215 | 101 | 215 | 215 | 210 | 215 |
| | B1 | - | 488 | 83 | 83 | 114 | 84 |
| | B2 | - | 39 | 39 | 39 | 33 | 38 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 1078 | 672 | 1077 | 1077 | 1053 | 1077 |
| [kbit/s] | bulk | - | 528 | 122 | 122 | 147 | 122 |
+----------------+--------+--------+------+------+------+----+-+-------+
| | A1 | 0 | 9.4 | 0 | 0 | 1.8 | 0 |
| | A2 | 0 | 14.6 | 0 | 0 | 2.0 | 0 |
| | A3 | 0 | 22.4 | 0 | 0 | 2.1 | 0 |
| Paket Loss | A4 | 0 | 15.5 | 0 | 0 | 1.8 | 0 |
| [%] | A5 | 0 | 17.4 | 0 | 0 | 1.9 | 0 |
| | B1 | - | 11.0 | 32.4 | 32.9 | 35.7 | 33.1 |
| | B2 | - | 21.1 | 20.3 | 20.7 | 34.0 | 22.2 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 0 | 14.9 | 0 | 0 | 1.9 | 0 |
| Loss Rate [%] | bulk | - | 12.0 | 28.7 | 29.1 | 35.3 | 29.8 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 19.8 | 12.8 | 19.8 | 19.8 | 19.5 | 19.8 |
+----------------+--------+--------+------+------+------+------+-------+
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 216 | 193 | 216 | 216 | 211 | 216 |
| | A2 | 216 | 171 | 216 | 216 | 211 | 216 |
| | A3 | 216 | 86 | 216 | 216 | 210 | 216 |
| Throughput | A4 | 215 | 121 | 215 | 215 | 211 | 215 |
| [kbit/s] | A5 | 215 | 101 | 215 | 215 | 210 | 215 |
| | B1 | - | 488 | 83 | 83 | 114 | 84 |
| | B2 | - | 39 | 39 | 39 | 33 | 38 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 1078 | 672 | 1077 | 1077 | 1053 | 1077 |
| [kbit/s] | bulk | - | 528 | 122 | 122 | 147 | 122 |
+----------------+--------+--------+------+------+------+----+-+-------+
| | A1 | 0 | 9.4 | 0 | 0 | 1.8 | 0 |
| | A2 | 0 | 14.6 | 0 | 0 | 2.0 | 0 |
| | A3 | 0 | 22.4 | 0 | 0 | 2.1 | 0 |
| Paket Loss | A4 | 0 | 15.5 | 0 | 0 | 1.8 | 0 |
| [%] | A5 | 0 | 17.4 | 0 | 0 | 1.9 | 0 |
| | B1 | - | 11.0 | 32.4 | 32.9 | 35.7 | 33.1 |
| | B2 | - | 21.1 | 20.3 | 20.7 | 34.0 | 22.2 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 0 | 14.9 | 0 | 0 | 1.9 | 0 |
| Loss Rate [%] | bulk | - | 12.0 | 28.7 | 29.1 | 35.3 | 29.8 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 19.8 | 12.8 | 19.8 | 19.8 | 19.5 | 19.8 |
+----------------+--------+--------+------+------+------+------+-------+
Figure 3: Situation II - Best Effort traffic uses 90% of the available bandwidth
图3：情况二-尽力而为流量使用90%的可用带宽
Results of simulations for situation III are depicted in Figure 4. Due to overload caused by flows A1-A5, packets get dropped in all cases. Bulk flows B1 and B2 nearly get their maximum throughput in case B). As one would expect, in case C1) all packets from B1 and B2 are dropped, in cases C2) and C4) resource consumption of bulk data is limited to the configured share of 10%. Again the WRED implementation in C3) is not as accurate as the WFQ variants and lets more BE traffic pass through IR1.
情况III的模拟结果如图4所示。由于流A1-A5导致的过载，所有情况下都会丢弃数据包。在情况B）中，批量流B1和B2几乎达到最大吞吐量。正如人们所期望的，在C1）的情况下，来自B1和B2的所有数据包都被丢弃，在C2）和C4）的情况下，大容量数据的资源消耗被限制在10%的配置份额内。同样，C3）中的WRED实现不如WFQ变体那样精确，并且让更多的BE流量通过IR1。
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 303 | 136 | 241 | 298 | 244 | 276 |
| | A2 | 316 | 234 | 286 | 299 | 240 | 219 |
| | A3 | 251 | 140 | 287 | 259 | 236 | 225 |
| Throughput | A4 | 168 | 84 | 252 | 123 | 209 | 219 |
| [kbit/s] | A5 | 159 | 82 | 132 | 101 | 166 | 141 |
| | B1 | - | 483 | 0 | 83 | 73 | 83 |
| | B2 | - | 41 | 0 | 38 | 31 | 38 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 1199 | 676 | 1199 | 1079 | 1096 | 1079 |
| [kbit/s] | bulk | - | 524 | 0 | 121 | 104 | 121 |
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 9.6 | 17.6 | 12.1 | 9.3 | 8.6 | 12.8 |
| | A2 | 8.5 | 13.6 | 8.4 | 9.8 | 8.1 | 14.5 |
| | A3 | 8.8 | 18.7 | 7.7 | 11.6 | 7.8 | 13.6 |
| Paket Loss | A4 | 14.9 | 22.3 | 11.2 | 18.9 | 8.2 | 12.4 |
| [%] | A5 | 12.8 | 19.0 | 15.6 | 19.7 | 8.3 | 14.3 |
| | B1 | - | 11.9 | 100 | 32.1 | 39.5 | 33.0 |
| | B2 | - | 17.3 | 100 | 22.5 | 37.7 | 22.8 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 10.4 | 17.3 | 10.3 | 12.2 | 8.2 | 13.4 |
| Loss Rate [%] | bulk | - | 12.4 | 100 | 29.1 | 39.0 | 29.9 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 22.0 | 12.6 | 22.0 | 20.2 | 20.6 | 20.3 |
+----------------+--------+--------+------+------+------+------+-------+
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 303 | 136 | 241 | 298 | 244 | 276 |
| | A2 | 316 | 234 | 286 | 299 | 240 | 219 |
| | A3 | 251 | 140 | 287 | 259 | 236 | 225 |
| Throughput | A4 | 168 | 84 | 252 | 123 | 209 | 219 |
| [kbit/s] | A5 | 159 | 82 | 132 | 101 | 166 | 141 |
| | B1 | - | 483 | 0 | 83 | 73 | 83 |
| | B2 | - | 41 | 0 | 38 | 31 | 38 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 1199 | 676 | 1199 | 1079 | 1096 | 1079 |
| [kbit/s] | bulk | - | 524 | 0 | 121 | 104 | 121 |
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 9.6 | 17.6 | 12.1 | 9.3 | 8.6 | 12.8 |
| | A2 | 8.5 | 13.6 | 8.4 | 9.8 | 8.1 | 14.5 |
| | A3 | 8.8 | 18.7 | 7.7 | 11.6 | 7.8 | 13.6 |
| Paket Loss | A4 | 14.9 | 22.3 | 11.2 | 18.9 | 8.2 | 12.4 |
| [%] | A5 | 12.8 | 19.0 | 15.6 | 19.7 | 8.3 | 14.3 |
| | B1 | - | 11.9 | 100 | 32.1 | 39.5 | 33.0 |
| | B2 | - | 17.3 | 100 | 22.5 | 37.7 | 22.8 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 10.4 | 17.3 | 10.3 | 12.2 | 8.2 | 13.4 |
| Loss Rate [%] | bulk | - | 12.4 | 100 | 29.1 | 39.0 | 29.9 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 22.0 | 12.6 | 22.0 | 20.2 | 20.6 | 20.3 |
+----------------+--------+--------+------+------+------+------+-------+
Figure 4: Situation III - Best Effort traffic load is 150%
图4：情况三-尽力而为的交通负荷为150%
In situation IV, 33% or 400 kbit/s are not used by Ax flows and the results are listed in Figure 5. In case B) where bulk data flows B1 and B2 use the BE PDB, packets of Ax flows are dropped, whereas in cases C1)-C4) flows Ax are protected from bulk flows B1 and B2. Therefore, by using the LE PDB for Bx flows, the latter get only the residual bandwidth of 400 kbit/s but not more. Packets of Ax flows are not affected by Bx traffic in these cases.
在情况IV中，Ax流不使用33%或400 kbit/s，结果如图5所示。在情况B）中，批量数据流B1和B2使用BE-PDB，Ax流的数据包被丢弃，而在情况C1）-C4）中，Ax流受到批量数据流B1和B2的保护。因此，通过对Bx流使用LE PDB，后者仅获得400 kbit/s的剩余带宽，而不是更多。在这些情况下，Ax流的数据包不受Bx流量的影响。
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 160 | 140 | 160 | 160 | 160 | 160 |
| | A2 | 160 | 124 | 160 | 160 | 160 | 160 |
| | A3 | 160 | 112 | 160 | 160 | 160 | 160 |
| Throughput | A4 | 160 | 137 | 160 | 160 | 159 | 160 |
| [kbit/s] | A5 | 159 | 135 | 159 | 159 | 159 | 159 |
| | B1 | - | 509 | 361 | 362 | 364 | 362 |
| | B2 | - | 43 | 40 | 39 | 38 | 40 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 798 | 648 | 798 | 798 | 797 | 798 |
| [kbit/s] | bulk | - | 551 | 401 | 401 | 402 | 401 |
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 0 | 9.2 | 0 | 0 | 0 | 0 |
| | A2 | 0 | 12.2 | 0 | 0 | 0 | 0 |
| | A3 | 0 | 14.0 | 0 | 0 | 0 | 0 |
| Paket Loss | A4 | 0 | 9.3 | 0 | 0 | 0 | 0 |
| [%] | A5 | 0 | 6.6 | 0 | 0 | 0 | 0 |
| | B1 | - | 7.3 | 21.2 | 21.8 | 25.0 | 21.3 |
| | B2 | - | 14.3 | 19.4 | 20.7 | 24.5 | 20.7 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 0 | 10.2 | 0 | 0 | 0 | 0 |
| Loss Rate [%] | bulk | - | 8.0 | 21.0 | 21.7 | 25.0 | 21.2 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 14.8 | 12.1 | 14.8 | 14.8 | 14.7 | 14.7 |
+----------------+--------+--------+------+------+------+------+-------+
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 160 | 140 | 160 | 160 | 160 | 160 |
| | A2 | 160 | 124 | 160 | 160 | 160 | 160 |
| | A3 | 160 | 112 | 160 | 160 | 160 | 160 |
| Throughput | A4 | 160 | 137 | 160 | 160 | 159 | 160 |
| [kbit/s] | A5 | 159 | 135 | 159 | 159 | 159 | 159 |
| | B1 | - | 509 | 361 | 362 | 364 | 362 |
| | B2 | - | 43 | 40 | 39 | 38 | 40 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 798 | 648 | 798 | 798 | 797 | 798 |
| [kbit/s] | bulk | - | 551 | 401 | 401 | 402 | 401 |
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 0 | 9.2 | 0 | 0 | 0 | 0 |
| | A2 | 0 | 12.2 | 0 | 0 | 0 | 0 |
| | A3 | 0 | 14.0 | 0 | 0 | 0 | 0 |
| Paket Loss | A4 | 0 | 9.3 | 0 | 0 | 0 | 0 |
| [%] | A5 | 0 | 6.6 | 0 | 0 | 0 | 0 |
| | B1 | - | 7.3 | 21.2 | 21.8 | 25.0 | 21.3 |
| | B2 | - | 14.3 | 19.4 | 20.7 | 24.5 | 20.7 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 0 | 10.2 | 0 | 0 | 0 | 0 |
| Loss Rate [%] | bulk | - | 8.0 | 21.0 | 21.7 | 25.0 | 21.2 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 14.8 | 12.1 | 14.8 | 14.8 | 14.7 | 14.7 |
+----------------+--------+--------+------+------+------+------+-------+
Figure 5: Situation IV - Best Effort traffic load is 67%
图5：情况四-尽力而为的流量负载为67%
In summary, all the different scenarios show that the "normal" BE traffic can be protected from traffic in the LE PDB effectively. Either no packets get through if no residual bandwidth is left (LE traffic is starved), or traffic of the LE PDB can only consume resources up to a configurable limit.
综上所述，所有不同的场景都表明“正常”BE流量可以有效地从LE PDB中的流量中得到保护。若并没有剩余带宽，则并没有数据包通过（LE通信量不足），或者LE PDB的通信量只能在可配置的限制内消耗资源。
Furthermore, the results substantiate that mass data transfer can adversely affect "normal" BE traffic (e.g., 14.9% packet loss in situations I and II, even 10.2% in situation IV) in situations without using the LE PDB.
此外，结果证实，在不使用LE PDB的情况下，大量数据传输会对“正常”BE流量产生不利影响（例如，情况I和II中的数据包丢失率为14.9%，情况IV中的数据包丢失率为10.2%）。
Thus, while all presented variants of realizing the LE PDB meet the desired behavior of protecting BE traffic, they also show small differences in detail. A network operator has the opportunity to choose a realization method to fit the desired behavior (showing this is - after the proof of LE's efficacy - the second designation of this appendix). For instance, if operators want to starve LE traffic completely in times of congestion, they could choose PQ. This causes LE traffic to be completely starved and not a single packet would get through in case of full load or overload.
因此，虽然所有呈现的实现LE-PDB的变体满足保护BE通信量的期望行为，但它们在细节上也显示出小的差异。网络运营商有机会选择适合预期行为的实现方法（证明LE有效后，这是本附录的第二个名称）。例如，如果运营商希望在拥堵时完全饿死LE流量，他们可以选择PQ。这会导致LE通信量完全耗尽，在满载或过载的情况下，没有一个数据包能够通过。
On the other hand, for network operators who want to permit some small amount of throughput in the LE PDB, one of the other variants would be a better choice.
另一方面，对于希望在LE PDB中允许少量吞吐量的网络运营商，其他变体之一将是更好的选择。
Referring to this, the WFQ implementation showed a slightly more robust behavior with PQ, but had problems with synchronized TCP flows. WRED behavior is highly dependent on the actual traffic characteristics and packet loss rates are often higher compared to other implementations, while the fairness between TCP connections is better. The combined solution of WFQ with RED showed the overall best behavior, when an operator's intent is to keep a small but noticeable throughput in the LE PDB.
与此相关，WFQ实现在PQ中表现出稍微更健壮的行为，但在同步TCP流中存在问题。WRED行为高度依赖于实际流量特性，与其他实现相比，数据包丢失率通常更高，而TCP连接之间的公平性更好。当运营商的意图是在LE PDB中保持较小但明显的吞吐量时，WFQ与RED的组合解决方案显示出总体最佳性能。
Normative References
规范性引用文件
[RFC3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[RFC3086]Nichols，K.和B.Carpenter，“每域区分服务行为的定义及其规范规则”，RFC 3086，2001年4月。
[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月。
Informative References
资料性引用
[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月。
[CBQ] Floyd, S. 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]Floyd，S.和V.Jacobson，“分组网络的链路共享和资源管理模型”，IEEE/ACM网络交易，第3卷，第4期，第365-386页，1995年8月。
[LBE] Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop Behavior", Work in Progress, September 1999.
[LBE]Bless，R.和K.Wehrle，“低于每跳最大努力的行为”，进展中的工作，1999年9月。
[LE] Bless, R. and K. Wehrle, "A Limited Effort Per-Hop Behavior", Work in Progress, February 2001.
[LE]Bless，R.和K.Wehrle，“每跳的有限努力行为”，进展中的工作，2001年2月。
[SimKIDS] Wehrle, K., Reber, J. and V. Kahmann, "A simulation suite for Internet nodes with the ability to integrate arbitrary Quality of Service behavior", in Proceedings of Communication Networks And Distributed Systems Modeling And Simulation Conference (CNDS 2001), Phoenix (AZ), USA, pp. 115-122, January 2001.
[SimKIDS]Wehrle，K.，Reber，J.和V.Kahmann，“具有集成任意服务质量行为能力的互联网节点模拟套件”，载于《通信网络和分布式系统建模与仿真会议论文集》（CNDS 2001），美国凤凰城（亚利桑那州），第115-122页，2001年1月。
[NRS] Bless, R. and K. Wehrle, "Group Communication in Differentiated Services Networks", in Proceedings of IEEE International Workshop on "Internet QoS", Brisbane, Australia, IEEE Press, pp. 618-625, May 2001.
[NRS]Bless，R.和K.Wehrle，“差异化服务网络中的群通信”，载于IEEE国际研讨会论文集“互联网QoS”，澳大利亚布里斯班，IEEE出版社，第618-625页，2001年5月。
Authors' Addresses
作者地址
Roland Bless Institute of Telematics, Universitaet Karlsruhe (TH) Zirkel 2 76128 Karlsruhe Germany
德国卡尔斯鲁厄大学罗兰·布莱斯远程信息处理研究所（TH）Zirkel 2 76128
EMail: bless@tm.uka.de
URI: http://www.tm.uka.de/~bless/
EMail: bless@tm.uka.de
URI: http://www.tm.uka.de/~bless/
Kathleen Nichols 325M Sharon Park Drive #214 Menlo Park, CA 94025
Kathleen Nichols 325M莎伦公园大道214号门洛公园，加利福尼亚州94025
EMail: knichols@ieee.org
EMail: knichols@ieee.org
Klaus Wehrle University of Tuebingen, Computer Networks and Internet Morgenstelle 10c, 72076 Tuebingen, Germany & International Computer Science Institute (ICSI) 1947 Center Street, Berkeley, CA, 94704, USA
克劳斯韦勒大学TuebInn，计算机网络和互联网MynStel10C，72076 TuebInn，德国和国际计算机科学研究所（ICSI）1947中心街，伯克利，CA，94704，美国
EMail: Klaus.Wehrle@uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/~wehrle/
EMail: Klaus.Wehrle@uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/~wehrle/
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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编辑功能的资金目前由互联网协会提供。