Internet Engineering Task Force (IETF) R. Bless
Request for Comments: 8622 KIT
Obsoletes: 3662 June 2019
Updates: 4594, 8325
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Bless
Request for Comments: 8622 KIT
Obsoletes: 3662 June 2019
Updates: 4594, 8325
Category: Standards Track
ISSN: 2070-1721
A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services
区分服务的较低每跳努力行为（LE PHB）
Abstract
摘要
This document specifies properties and characteristics of a Lower-Effort Per-Hop Behavior (LE PHB). The primary objective of this LE PHB is to protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, BE traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise-unused resources only. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non-time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard Differentiated Services Code Point (DSCP) value for the LE PHB.
本文档指定了较低每跳工作量行为（LE PHB）的属性和特征。此LE PHB的主要目标是在拥塞情况下保护最大努力（BE）流量（使用默认PHB转发的数据包）不受LE流量的影响，即，当资源变得稀缺时，BE流量优先于LE流量，并可能抢占它。或者，由LE PHB转发的分组可以与清道夫服务类相关联，即，它们仅清道夫未使用的资源。此PHB有多种用途，例如，用于低优先级的后台流量，例如低优先级的批量数据传输、非时间关键型备份、大型软件更新、从web服务器收集信息时的web搜索引擎等。本文档为LE PHB推荐标准差分服务代码点（DSCP）值。
This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification.
本规范废除RFC 3662，并更新RFC 4594和8325中建议的DSCP，以使用本规范中指定的DSCP。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8622.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8622.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Applicability ...................................................3
4. PHB Description .................................................6
5. Traffic-Conditioning Actions ....................................7
6. Recommended DSCP ................................................7
7. Deployment Considerations .......................................8
8. Re-marking to Other DSCPs/PHBs ..................................9
9. Multicast Considerations .......................................10
10. The Updates to RFC 4594 .......................................11
11. The Updates to RFC 8325 .......................................12
12. IANA Considerations ...........................................13
13. Security Considerations .......................................14
14. References ....................................................15
14.1. Normative References .....................................15
14.2. Informative References ...................................15
Appendix A. History of the LE PHB .................................18
Acknowledgments ...................................................18
Author's Address ..................................................18
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Applicability ...................................................3
4. PHB Description .................................................6
5. Traffic-Conditioning Actions ....................................7
6. Recommended DSCP ................................................7
7. Deployment Considerations .......................................8
8. Re-marking to Other DSCPs/PHBs ..................................9
9. Multicast Considerations .......................................10
10. The Updates to RFC 4594 .......................................11
11. The Updates to RFC 8325 .......................................12
12. IANA Considerations ...........................................13
13. Security Considerations .......................................14
14. References ....................................................15
14.1. Normative References .....................................15
14.2. Informative References ...................................15
Appendix A. History of the LE PHB .................................18
Acknowledgments ...................................................18
Author's Address ..................................................18
This document defines a Differentiated Services (DS) per-hop behavior [RFC2474] called "Lower-Effort Per-Hop Behavior" (LE PHB), which is intended for traffic of sufficiently low urgency that all other traffic takes precedence over the LE traffic in consumption of network link bandwidth. Low-urgency traffic has a low priority for timely forwarding; note, however, that this does not necessarily imply that it is generally of minor importance. From this viewpoint, it can be 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.
本文档定义了一种区分服务（DS）每跳行为[RFC2474]，称为“每跳较低努力行为”（LE PHB），该行为适用于紧急程度足够低的流量，使得所有其他流量在网络链路带宽消耗方面优先于LE流量。低紧急流量对及时转发的优先级较低；然而，请注意，这并不一定意味着它通常不重要。从这个观点来看，它可以被视为一个网络，相当于操作系统中进程的后台优先级。可能有也可能没有为这种类型的通信分配内存（缓冲区）资源。
Some networks carry packets that ought to consume network resources only when no other traffic is demanding them. From this point of view, packets forwarded by the LE PHB scavenge otherwise-unused resources only; this led to the name "scavenger service" in early Internet2 deployments (see Appendix A). Other commonly used names for LE PHB types of services are "Lower than best effort" [Carlberg-LBE-2001] or "Less than best effort" [Chown-LBE-2003]. In summary, with the above-mentioned feature, the LE PHB has two important properties: it should scavenge residual capacity, and it must be preemptable by the default PHB (or other elevated PHBs) in case they need more resources. Consequently, the effect of this type of traffic on all other network traffic is strictly limited (the "no harm" property). 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 an LE DS PHB for handling this "optional" traffic in a DS node.
有些网络携带的数据包只有在没有其他流量需要时才应该消耗网络资源。从这个角度来看，由LE-PHB转发的数据包只清除其他未使用的资源；在早期的Internet2部署中，这导致了“清道夫服务”的名称（见附录A）。LE PHB服务类型的其他常用名称为“低于最大努力”[Carlberg-LBE-2001]或“低于最大努力”[Chown-LBE-2003]。总之，通过上述特性，LE PHB有两个重要特性：它应该清除剩余容量，并且在需要更多资源的情况下，它必须可以被默认PHB（或其他提升的PHB）抢占。因此，此类流量对所有其他网络流量的影响受到严格限制（“无害”属性）。这与“尽力而为”（BE）流量不同，因为网络不承诺交付LE数据包。与此相反，BE通信收到至少一些可用网络资源的隐含“善意”承诺。本文档建议使用LE DS PHB来处理DS节点中的“可选”流量。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
An LE PHB is applicable for many applications that otherwise use BE delivery. More specifically, it is suitable for traffic and services that can tolerate strongly varying throughput for their data flows, especially periods of very low throughput or even starvation (i.e., long interruptions due to significant or even complete packet loss). Therefore, an application sending an LE-marked flow needs to be able to tolerate short or (even very) long interruptions due to the
LE PHB适用于许多使用BE交付的应用程序。更具体地说，它适用于能够容忍其数据流的吞吐量剧烈变化的流量和服务，特别是非常低的吞吐量或甚至饥饿的时期（即，由于显著或甚至完全的数据包丢失而导致的长时间中断）。因此，发送LE标记流的应用程序需要能够容忍由于错误导致的短时间或（甚至）长时间中断
presence of severe congestion conditions during the transmission of the flow. Thus, there ought to be an expectation that packets of the LE PHB could be excessively delayed or dropped when any other traffic is present. Whether or not a lack of progress is considered to be a failure is application dependent (e.g., if a transport connection fails due to timing out, the application may try several times to reestablish the transport connection in order to resume the application session before finally giving up). The LE PHB is suitable for sending traffic of low urgency across a DS domain or DS region.
在流量传输过程中出现严重拥堵情况。所以，当存在任何其他业务时，应该期望LE-PHB的分组可能被过度延迟或丢弃。是否将缺少进度视为失败取决于应用程序（例如，如果传输连接因超时而失败，则应用程序可能会尝试多次重新建立传输连接，以便在最终放弃之前恢复应用程序会话）。LE PHB适合于跨DS域或DS区域发送低紧急度的通信量。
Just like BE traffic, LE traffic SHOULD be congestion controlled (i.e., use a congestion controlled transport or implement an appropriate congestion control method [RFC2914] [RFC8085]). Since LE traffic could be starved completely for a longer period of time, transport protocols or applications (and their related congestion control mechanisms) SHOULD be able to detect and react to such a starvation situation. An appropriate reaction would be to resume the transfer instead of aborting it, i.e., an LE-optimized transport ought to use appropriate retry strategies (e.g., exponential back-off with an upper bound) as well as corresponding retry and timeout limits in order to avoid the loss of the connection due to the above-mentioned starvation periods. While it is desirable to achieve a quick resumption of the transfer as soon as resources become available again, it may be difficult to achieve this in practice. In the case of a lack of a transport protocol and congestion control that are adapted to LE, applications can also use existing common transport protocols and implement session resumption by trying to reestablish failed connections. Congestion control is not only useful for letting the flows within the LE Behavior Aggregate (BA) adapt to the available bandwidth, which may be highly fluctuating; it is also essential if LE traffic is mapped to the default PHB in DS domains that do not support LE. In this case, the use of background transport protocols, e.g., similar to Low Extra Delay Background Transport (LEDBAT) [RFC6817], is expedient.
与BE流量一样，LE流量也应受到拥塞控制（即，使用拥塞控制的传输或实施适当的拥塞控制方法[RFC2914][RFC8085]）。由于LE流量可能会在较长时间内完全耗尽，因此传输协议或应用程序（及其相关的拥塞控制机制）应该能够检测到这种耗尽情况并作出反应。适当的反应是恢复传输而不是中止传输，即，LE优化的传输应该使用适当的重试策略（例如，指数退避上限）以及相应的重试和超时限制，以避免由于上述饥饿期而丢失连接。虽然在资源再次可用时尽快恢复移交是可取的，但在实践中可能很难做到这一点。在缺少适合LE的传输协议和拥塞控制的情况下，应用程序还可以使用现有的通用传输协议，并通过尝试重新建立失败的连接来实现会话恢复。拥塞控制不仅有助于让LE行为聚合（BA）中的流适应可能高度波动的可用带宽；如果LE流量映射到不支持LE的DS域中的默认PHB，则这一点也很重要。在这种情况下，使用后台传输协议，例如，类似于低额外延迟后台传输（LEDBAT）[RFC6817]是有利的。
The use of the LE PHB might assist a network operator in moving certain kinds of traffic or users to off-peak times. Furthermore, packets can be designated for the LE PHB 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 PHB SHOULD NOT be used for a customer's "normal Internet" traffic and packets SHOULD NOT be "downgraded" to the LE PHB instead of being dropped, particularly when the packets are unauthorized traffic. The LE PHB is expected to have applicability in networks that have at least some unused capacity during certain periods.
使用LE PHB可能有助于网络运营商将某些类型的流量或用户转移到非高峰时间。此外，当目标是保护所有其他分组流量不与LE聚合竞争，同时不完全禁止来自网络的LE流量时，可以为LE PHB指定分组。LE PHB不应用于客户的“正常互联网”流量，数据包不应“降级”到LE PHB而不是丢弃，尤其是当数据包是未经授权的流量时。预计LE PHB适用于在特定时期内至少有一些未使用容量的网络。
The LE PHB allows networks to protect themselves from selected types of traffic as a complement to giving preferential treatment to other selected traffic aggregates. LE ought not be used for the general case of downgraded traffic, but it could be used by design, e.g., to protect an internal network from untrusted external traffic sources. In this case, there is no way for attackers to preempt internal (non-LE) traffic by flooding. Another use case in this regard is the forwarding of multicast traffic from untrusted sources. Multicast forwarding is currently enabled within domains only for specific sources within a domain -- not for sources from anywhere in the Internet. One major problem is that multicast routing creates traffic sources at (mostly) unpredictable branching points within a domain, potentially leading to congestion and packet loss. In the case where multicast traffic packets from untrusted sources are forwarded as LE traffic, they will not harm traffic from non-LE BAs. A further related use case is mentioned in [RFC3754]: preliminary forwarding of non-admitted multicast traffic.
LE PHB允许网络保护自己不受选定类型流量的影响，作为对其他选定流量总量给予优惠待遇的补充。LE不应用于流量降级的一般情况，但它可用于设计，例如，保护内部网络免受不受信任的外部流量源的影响。在这种情况下，攻击者无法通过洪水抢占内部（非LE）流量。这方面的另一个用例是从不受信任的源转发多播流量。多播转发目前仅在域内为域内的特定源启用，而不为来自Internet任何位置的源启用。一个主要问题是，多播路由在域内（大部分）不可预测的分支点上创建流量源，可能导致拥塞和数据包丢失。如果来自不受信任来源的多播流量数据包作为LE流量转发，则它们不会损害来自非LE BAs的流量。[RFC3754]中还提到了另一个相关的用例：非允许多播流量的初步转发。
There is no intrinsic reason to limit the applicability of the LE PHB to any particular application or type of traffic. It is intended as an additional traffic engineering tool for network administrators. For instance, it can be used to fill protection capacity of transmission links that is otherwise unused. Some network providers keep link utilization below 50% to ensure that all traffic is forwarded without loss after rerouting caused by a link failure (cf. Section 6 of [RFC3439]). LE-marked traffic can utilize the normally unused capacity and will be preempted automatically in the case of link failure when 100% of the link capacity is required for all other traffic. Ideally, applications mark their packets as LE traffic, because they know the urgency of flows. Since LE traffic may be starved for longer periods of time, it is probably less suitable for real-time and interactive applications.
没有内在理由限制LE PHB对任何特定应用或交通类型的适用性。它旨在作为网络管理员的附加流量工程工具。例如，它可用于填充未使用的传输链路的保护容量。一些网络提供商将链路利用率保持在50%以下，以确保在链路故障引起的重新路由后，所有流量都能在不丢失的情况下转发（参见[RFC3439]第6节）。LE标记的流量可以利用通常未使用的容量，并且当所有其他流量需要100%的链路容量时，在链路故障的情况下将自动抢占。理想情况下，应用程序将其数据包标记为LE流量，因为它们知道流的紧迫性。由于LE流量可能需要更长的时间，因此它可能不太适合实时和交互式应用程序。
Example uses for the LE PHB:
用于LE PHB的示例：
o For traffic caused by World Wide Web search engines while they gather information from web servers.
o 当万维网搜索引擎从网络服务器收集信息时，会造成流量。
o For software updates or dissemination of new releases of operating systems.
o 用于软件更新或发布新版本的操作系统。
o For reporting errors or telemetry data from operating systems or applications.
o 用于报告来自操作系统或应用程序的错误或遥测数据。
o For backup traffic, non-time-critical synchronization, or mirroring traffic.
o 用于备份流量、非时间关键型同步或镜像流量。
o For content distribution transfers between caches.
o 用于缓存之间的内容分发传输。
o For preloading or prefetching objects from web sites.
o 用于从网站预加载或预取对象。
o For network news and other "bulk mail" of the Internet.
o 用于网络新闻和互联网上的其他“批量邮件”。
o For "downgraded" traffic from some other PHB when this does not violate the operational objectives of the other PHB.
o 在不违反其他PHB运营目标的情况下，针对来自其他PHB的“降级”流量。
o For multicast traffic from untrusted (e.g., non-local) sources.
o 用于来自不受信任（例如，非本地）源的多播流量。
The LE PHB is defined in relation to the default PHB (BE). A packet forwarded with the LE PHB SHOULD have lower precedence than packets forwarded with the default PHB, i.e., in the case of congestion, LE-marked traffic SHOULD be dropped prior to dropping any default PHB traffic. Ideally, LE packets would be forwarded only when no packet with any other PHB is awaiting transmission. This means that in the case of link resource contention LE traffic can be starved completely, which may not always be desired by the network operator's policy. A scheduler used to implement the LE PHB may reflect this policy accordingly.
LE PHB是相对于默认PHB（BE）定义的。使用LE PHB转发的数据包的优先级应低于使用默认PHB转发的数据包的优先级，即，在发生拥塞的情况下，在丢弃任何默认PHB流量之前，应丢弃带有LE标记的流量。理想情况下，LE数据包将仅在没有任何其他PHB数据包等待传输时转发。这意味着，在链路资源争用的情况下，LE流量可能会完全耗尽，这可能并不总是网络运营商的策略所期望的。用于实现LE PHB的调度器可以相应地反映该策略。
A straightforward implementation could be a simple priority scheduler serving the default PHB queue with higher priority than the LE PHB queue. Alternative implementations may use scheduling algorithms that assign a very small weight to the LE class. This, however, could sometimes cause better service for LE packets compared to BE packets in cases when the BE share is fully utilized and the LE share is not.
一个简单的实现可以是一个简单的优先级调度器，它为默认PHB队列提供比LE PHB队列更高的优先级。替代实现可以使用调度算法，为LE类分配很小的权重。然而，在BE共享被充分利用而LE共享未被充分利用的情况下，这有时可能导致与BE分组相比，LE分组的服务更好。
If a dedicated LE queue is not available, an active queue management mechanism within a common BE/LE queue could also be used. This could drop all arriving LE packets as soon as certain queue length or sojourn time thresholds are exceeded.
如果专用LE队列不可用，也可以使用公共BE/LE队列中的活动队列管理机制。一旦超过某个队列长度或逗留时间阈值，这可能会丢弃所有到达的LE数据包。
Since congestion control is also useful within the LE traffic class, Explicit Congestion Notification (ECN) [RFC3168] SHOULD be used for LE packets, too. More specifically, an LE implementation SHOULD also apply Congestion Experienced (CE) marking for ECT-marked packets ("ECT" stands for ECN-Capable Transport), and transport protocols used for LE SHOULD support and employ ECN. For more information on the benefits of using ECN, see [RFC8087].
由于拥塞控制在LE通信类中也很有用，因此显式拥塞通知（ECN）[RFC3168]也应该用于LE数据包。更具体地说，LE实现还应该为带有ECT标记的数据包应用拥塞体验（CE）标记（“ECT”表示支持ECN的传输），并且用于LE的传输协议应该支持并使用ECN。有关使用ECN的好处的更多信息，请参阅[RFC8087]。
If possible, packets SHOULD be pre-marked in DS-aware end systems by applications due to their specific knowledge about the particular precedence of packets. There is no incentive for DS domains to distrust this initial marking, because letting LE traffic enter a DS domain causes no harm. Thus, any policing, such as limiting the rate of LE traffic, is not necessary at the DS boundary.
如果可能，应用程序应在DS感知终端系统中预先标记数据包，因为它们对数据包的特定优先级有特定的了解。DS域没有不信任此初始标记的动机，因为让LE流量进入DS域不会造成伤害。因此，在DS边界不需要任何警务，例如限制LE流量。
As for most other PHBs, an initial classification and marking can also be performed at the first DS boundary node according to the DS domain's own policies (e.g., as a protection measure against untrusted sources). However, non-LE traffic (e.g., BE traffic) SHOULD NOT be re-marked to LE. Re-marking traffic from another PHB results in that traffic being "downgraded". This changes the way the network treats this traffic, and it is important not to violate the operational objectives of the original PHB. See Sections 3 and 8 for notes related to downgrading.
对于大多数其他phb，也可以根据DS域自己的策略（例如，作为针对不可信源的保护措施）在第一DS边界节点处执行初始分类和标记。但是，不应将非LE流量（例如BE流量）重新标记为LE。重新标记来自另一PHB的流量会导致该流量“降级”。这改变了网络处理此流量的方式，重要的是不要违反原始PHB的操作目标。有关降级的注释，请参见第3节和第8节。
The RECOMMENDED codepoint for the LE PHB is '000001'.
LE PHB的建议代码点为“000001”。
Earlier specifications (e.g., [RFC4594]) recommended the use of Class Selector 1 (CS1) as the codepoint (as mentioned in [RFC3662]). This is problematic, since it may cause a priority inversion in Diffserv domains that treat CS1 as originally proposed in [RFC2474], resulting in forwarding LE packets with higher precedence than BE packets. Existing implementations SHOULD transition to use the unambiguous LE codepoint '000001' whenever possible.
早期规范（如[RFC4594]）建议使用类选择器1（CS1）作为代码点（如[RFC3662]中所述）。这是有问题的，因为它可能会导致区分服务域中的优先级反转，该区分服务域按照[RFC2474]中最初提出的方法处理CS1，从而导致以比BE数据包更高的优先级转发LE数据包。现有实现应尽可能过渡到使用明确的LE代码点“000001”。
This particular codepoint was chosen due to measurements on the currently observable Differentiated Services Code Point (DSCP) re-marking behavior in the Internet [IETF99-Secchi]. Since some network domains set the former IP Precedence bits to zero, it is possible that some other standardized DSCPs get mapped to the LE PHB DSCP if it were taken from the DSCP Standards Action Pool 1 (xxxxx0) [RFC2474] [RFC8436].
之所以选择此特定代码点，是因为对互联网中当前可观察到的区分服务代码点（DSCP）重新标记行为进行了测量[IETF99 Secchi]。由于某些网络域将以前的IP优先级位设置为零，因此，如果从DSCP标准操作池1（XXXXX 0）[RFC2474][RFC8436]获取其他一些标准化DSCP，则可能会将其映射到LE PHB DSCP。
In order to enable LE support, DS nodes typically only need
为了支持LE，DS节点通常只需要
o A BA classifier (see [RFC2475]) that classifies packets according to the LE DSCP
o 根据LE DSCP对数据包进行分类的BA分类器（参见[RFC2475]）
o A dedicated LE queue
o 专用队列
o A suitable scheduling discipline, e.g., simple priority queueing
o 适当的调度规程，例如，简单优先级排队
Alternatively, implementations could use active queue management mechanisms instead of a dedicated LE queue, e.g., dropping all arriving LE packets when certain queue length or sojourn time thresholds are exceeded.
或者，实现可以使用主动队列管理机制而不是专用LE队列，例如，当超过特定队列长度或逗留时间阈值时，丢弃所有到达的LE数据包。
Internet-wide deployment of the LE PHB is eased by the following properties:
LE PHB在互联网范围内的部署因以下特性而变得容易：
o No harm to other traffic: since the LE PHB has the lowest forwarding priority, it does not consume resources from other PHBs. Deployment across different provider domains with LE support causes no trust issues or attack vectors to existing (non-LE) traffic. Thus, providers can trust LE markings from end systems, i.e., there is no need to police or re-mark incoming LE traffic.
o 对其他流量无害：由于LE PHB具有最低的转发优先级，因此它不会消耗其他PHB的资源。使用LE支持跨不同提供商域部署不会对现有（非LE）流量造成信任问题或攻击向量。因此，提供商可以信任来自终端系统的LE标记，也就是说，不需要对传入的LE流量进行监控或重新标记。
o No PHB parameters or configuration of traffic profiles: the LE PHB itself possesses no parameters that need to be set or configured. Similarly, since LE traffic requires no admission or policing, it is not necessary to configure traffic profiles.
o 没有PHB参数或流量配置文件配置：LE PHB本身没有需要设置或配置的参数。同样，由于LE流量不需要准入或监管，因此无需配置流量配置文件。
o No traffic-conditioning mechanisms: the LE PHB requires no traffic meters, droppers, or shapers. See also Section 5 for further discussion.
o 无流量调节机制：LE PHB不需要流量计、滴管或整形器。进一步讨论请参见第5节。
Operators of DS domains that cannot or do not want to implement the LE PHB (e.g., because there is no separate LE queue available in the corresponding nodes) SHOULD NOT drop packets marked with the LE DSCP. They SHOULD map packets with this DSCP to the default PHB and SHOULD preserve the LE DSCP marking. DS domain operators that do not implement the LE PHB should be aware that they violate the "no harm" property of LE. See also Section 8 for further discussion of forwarding LE traffic with the default PHB instead of the LE PHB.
无法或不希望实现LE PHB的DS域的运营商（例如，因为相应节点中没有单独的LE队列可用）不应丢弃标有LE DSCP的数据包。它们应将带有此DSCP的数据包映射到默认PHB，并应保留LE DSCP标记。未实现LE PHB的DS域运营商应意识到他们违反了LE的“无害”属性。有关使用默认PHB而不是LE PHB转发LE流量的进一步讨论，请参见第8节。
"DSCP bleaching", i.e., setting the DSCP to '000000' (default PHB) is NOT RECOMMENDED for this PHB. This may cause effects that are in contrast to the original intent to protect BE traffic from LE traffic (the "no harm" property). In the case that a DS domain does not support the LE PHB, its nodes SHOULD treat LE-marked packets with the default PHB instead (by mapping the LE DSCP to the default PHB), but they SHOULD do so without re-marking to DSCP '000000'. This is because DS domains that are traversed later may then still have the opportunity to treat such packets according to the LE PHB.
不建议对此PHB使用“DSCP漂白”，即将DSCP设置为“000000”（默认PHB）。这可能会造成与保护BE流量免受LE流量（“无害”属性）影响的初衷相反的影响。在DS域不支持LE PHB的情况下，其节点应改为使用默认PHB处理LE标记的数据包（通过将LE DSCP映射到默认PHB），但不应重新标记为DSCP“000000”。这是因为稍后遍历的DS域可能仍然有机会根据LE PHB处理此类分组。
Operators of DS domains that forward LE traffic within the BE aggregate need to be aware of the implications, i.e., induced congestion situations and QoS degradation of the original BE traffic. In this case, the LE property of not harming other traffic is no longer fulfilled. To limit the impact in such cases, traffic policing of the LE aggregate MAY be used.
在BE聚合中转发LE流量的DS域的运营商需要了解其影响，即原始BE流量的诱导拥塞情况和QoS降级。在这种情况下，不损害其他交通的LE属性不再满足。为限制此类情况下的影响，可使用LE骨料的交通管制。
In the case that LE-marked packets are effectively carried with the default PHB (i.e., forwarded as BE traffic), they get a better forwarding treatment than expected. For some applications and services, it is favorable if the transmission is finished earlier than expected. However, in some cases, it may be against the original intention of the LE PHB user to strictly send the traffic only if otherwise-unused resources are available. In the case that LE traffic is mapped to the default PHB, LE traffic may compete with BE traffic for the same resources and thus adversely affect the original BE aggregate. Applications that want to ensure the lower precedence compared to BE traffic even in such cases SHOULD additionally use a corresponding lower-than-BE transport protocol [RFC6297], e.g., LEDBAT [RFC6817].
在使用默认PHB（即，作为BE流量转发）有效地携带LE标记的数据包的情况下，它们得到了比预期更好的转发处理。对于某些应用和服务，如果传输比预期提前完成，则是有利的。然而，在某些情况下，只有在其他未使用资源可用的情况下，LE PHB用户才严格发送通信量，这可能违背其初衷。在LE流量映射到默认PHB的情况下，LE流量可能与BE流量竞争相同的资源，从而对原始BE聚合产生不利影响。即使在这种情况下，希望确保比BE流量优先级更低的应用程序也应另外使用相应的低于BE的传输协议[RFC6297]，例如LEDBAT[RFC6817]。
A DS domain that still uses DSCP CS1 for marking LE traffic (including Low-Priority Data as defined in [RFC4594] or the old definition in [RFC3662]) SHOULD re-mark traffic to the LE DSCP '000001' at the egress to the next DS domain. This increases the probability that the DSCP is preserved end to end, whereas a CS1-marked packet may be re-marked by the default DSCP if the next domain is applying Diffserv-Interconnection [RFC8100].
仍然使用DSCP CS1标记LE流量（包括[RFC4594]中定义的低优先级数据或[RFC3662]中的旧定义）的DS域应在下一个DS域出口处重新标记LE DSCP“000001”的流量。这增加了DSCP被端到端保留的可能性，而如果下一个域应用Diffserv互连[RFC8100]，则CS1标记的数据包可能被默认DSCP重新标记。
Basically, the multicast considerations in [RFC3754] apply. However, using the LE PHB for multicast requires paying special attention to how packets get replicated inside routers. Due to multicast packet replication, resource contention may actually occur even before a packet is forwarded to its output port. In the worst case, these forwarding resources are missing for higher-priority multicast or even unicast packets.
基本上，[RFC3754]中的多播注意事项适用。然而，使用lephb进行多播需要特别注意如何在路由器内复制数据包。由于多播数据包复制，甚至在数据包被转发到其输出端口之前，实际上可能会发生资源争用。在最坏的情况下，对于更高优先级的多播甚至单播数据包，这些转发资源丢失。
Several forward error correction coding schemes, such as fountain codes (e.g., [RFC5053]), allow reliable data delivery even in environments with a potentially high amount of packet loss in transmission. When used, for example, over satellite links or other broadcast media, this means that receivers that lose 80% of packets in transmission simply need five times longer to receive the complete data than those receivers experiencing no loss (without any receiver feedback required).
一些前向纠错编码方案，例如喷泉码（例如，[RFC5053]），即使在传输中可能存在大量数据包丢失的环境中，也允许可靠的数据传输。例如，当通过卫星链路或其他广播媒体使用时，这意味着在传输过程中丢失80%数据包的接收机接收完整数据所需的时间是没有丢失的接收机（无需任何接收机反馈）的五倍。
Superficially viewed, it may sound very attractive to use IP multicast with the LE PHB to build this type of opportunistic reliable distribution in IP networks, but it can only be usefully deployed with routers that do not experience forwarding/replication resource starvation when a large amount of packets (virtually) need to be replicated to links where the LE queue is full.
从表面上看，将IP多播与LE PHB结合使用在IP网络中构建这种机会主义可靠分布可能听起来非常有吸引力，但它只能有效地部署在路由器上，当大量数据包（实际上）出现时，路由器不会经历转发/复制资源不足需要复制到LE队列已满的链接。
Thus, a packet replication mechanism for LE-marked packets should consider the situation at the respective output links: it is a waste of internal forwarding resources if a packet is replicated to output links that have no resources left for LE forwarding. In those cases, a packet would have been replicated just to be dropped immediately after finding a filled LE queue at the respective output port. Such behavior could be avoided -- for example, by using a conditional internal packet replication: a packet would then only be replicated in cases where the output link is not fully used. This conditional replication, however, is probably not widely implemented.
因此，针对LE标记分组的分组复制机制应该考虑在各个输出链路上的情况：如果分组被复制到没有用于LE转发的资源的输出链路，则是内部转发资源的浪费。在这些情况下，数据包将被复制，以便在相应的输出端口找到已填充的LE队列后立即丢弃。这样的行为可以避免——例如，通过使用有条件的内部数据包复制：数据包只有在输出链接没有完全使用的情况下才会被复制。然而，这种有条件的复制可能没有得到广泛的实施。
While the resource contention problem caused by multicast packet replication is also true for other Diffserv PHBs, LE forwarding is special, because often it is assumed that LE packets only get forwarded in the case of available resources at the output ports. The previously mentioned redundancy data traffic could suitably use the varying available residual bandwidth being utilized by the LE PHB, but only if the specific requirements stated above for conditional replication in the internal implementation of the network devices are considered.
虽然多播数据包复制引起的资源争用问题对于其他Diffserv PHB也是如此，但LE转发是特殊的，因为通常假定LE数据包仅在输出端口有可用资源的情况下才能转发。前面提到的冗余数据业务可以适当地使用LE PHB正在使用的变化的可用剩余带宽，但仅当考虑了上述网络设备内部实现中的条件复制的特定要求时。
[RFC4594] recommended the use of CS1 as the codepoint in its Section 4.10, whereas CS1 was defined in [RFC2474] to have a higher precedence than CS0, i.e., the default PHB. Consequently, Diffserv domains implementing CS1 according to [RFC2474] will cause a priority inversion for LE packets that contradicts the original purpose of LE. Therefore, every occurrence of the CS1 DSCP is replaced by the LE DSCP.
[RFC4594]在其第4.10节中建议使用CS1作为代码点，而[RFC2474]中定义CS1的优先级高于CS0，即默认PHB。因此，根据[RFC2474]实现CS1的Diffserv域将导致LE包的优先级反转，这与LE的原始目的相矛盾。因此，每次出现的CS1 DSCP都被LE DSCP替换。
Changes:
变化：
o This update to RFC 4594 removes the following entry from its Figure 3:
o RFC 4594的此次更新从其图3中删除了以下条目：
|---------------+---------+-------------+--------------------------|
| Low-Priority | CS1 | 001000 | Any flow that has no BW |
| Data | | | assurance |
------------------------------------------------------------------
|---------------+---------+-------------+--------------------------|
| Low-Priority | CS1 | 001000 | Any flow that has no BW |
| Data | | | assurance |
------------------------------------------------------------------
and replaces it with the following entry:
并将其替换为以下条目：
|---------------+---------+-------------+--------------------------|
| Low-Priority | LE | 000001 | Any flow that has no BW |
| Data | | | assurance |
------------------------------------------------------------------
|---------------+---------+-------------+--------------------------|
| Low-Priority | LE | 000001 | Any flow that has no BW |
| Data | | | assurance |
------------------------------------------------------------------
o This update to RFC 4594 extends the Notes text below Figure 3 that currently states "Notes for Figure 3: Default Forwarding (DF) and Class Selector 0 (CS0) provide equivalent behavior and use the same DS codepoint, '000000'." to state "Notes for Figure 3: Default Forwarding (DF) and Class Selector 0 (CS0) provide equivalent behavior and use the same DSCP, '000000'. The prior recommendation to use the CS1 DSCP for Low-Priority Data has been replaced by the current recommendation to use the LE DSCP, '000001'."
o RFC 4594的更新扩展了图3下面的注释文本，该文本当前表示“图3的注释：默认转发（DF）和类选择器0（CS0）提供等效行为并使用相同的DS代码点“000000”。“to state”图3的注释：默认转发（DF）和类选择器0（CS0）提供等效的行为并使用相同的DSCP“000000”。先前关于低优先级数据使用CS1 DSCP的建议已被当前关于使用LE DSCP“000001”的建议所取代。”
o This update to RFC 4594 removes the following entry from its Figure 4:
o RFC 4594的更新从图4中删除了以下条目：
|---------------+------+-------------------+---------+--------+----|
| Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | |
------------------------------------------------------------------
|---------------+------+-------------------+---------+--------+----|
| Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | |
------------------------------------------------------------------
and replaces it with the following entry:
并将其替换为以下条目：
|---------------+------+-------------------+----------+--------+----|
| Low-Priority | LE | Not applicable | RFC 8622 | Rate | Yes|
| Data | | | | | |
-------------------------------------------------------------------
|---------------+------+-------------------+----------+--------+----|
| Low-Priority | LE | Not applicable | RFC 8622 | Rate | Yes|
| Data | | | | | |
-------------------------------------------------------------------
o Section 2.3 of [RFC4594] specifies the following: "In network segments that use IP precedence marking, only one of the two service classes can be supported, High-Throughput Data or Low-Priority Data. We RECOMMEND that the DSCP value(s) of the unsupported service class be changed to 000xx1 on ingress and changed back to original value(s) on egress of the network segment that uses precedence marking. For example, if Low-Priority Data is mapped to Standard service class, then 000001 DSCP marking MAY be used to distinguish it from Standard marked packets on egress." This document removes this recommendation, because by using the LE DSCP defined herein, such re-marking is not necessary. So, even if Low-Priority Data is unsupported (i.e., mapped to the default PHB), the LE DSCP should be kept across the domain as RECOMMENDED in Section 8. That removed text is replaced by the following: "In network segments that use IP Precedence marking, the Low-Priority Data service class receives the same Diffserv QoS as the Standard service class when the LE DSCP is used for Low-Priority Data traffic. This is acceptable behavior for the Low-Priority Data service class, although it is not the preferred behavior."
o [RFC4594]第2.3节规定如下：“在使用IP优先标记的网段中，只能支持两种服务类别中的一种，即高吞吐量数据或低优先级数据。我们建议在进入时将不支持的服务类别的DSCP值更改为000xx1，并更改回原始值使用优先标记的网段出口。例如，如果低优先级数据映射到标准服务类别，则000001 DSCP标记可用于将其与出口上的标准标记数据包区分开来。”本文件删除了此建议，因为通过使用本文定义的LE DSCP，这种重新标记是没有必要的。因此，即使低优先级数据不受支持（即映射到默认PHB），也应按照第8节中的建议在整个域中保留LE DSCP。删除的文本将替换为以下内容：“在使用IP优先标记的网段中，当LE DSCP用于低优先级数据通信时，低优先级数据服务类别接收与标准服务类别相同的Diffserv QoS。这是低优先级数据服务类可以接受的行为，但不是首选行为。”
o This document removes the following line in Section 4.10 of RFC 4594: "The RECOMMENDED DSCP marking is CS1 (Class Selector 1)." and replaces it with the following text: "The RECOMMENDED DSCP marking is LE (Lower Effort), which replaces the prior recommendation for CS1 (Class Selector 1) marking."
o 本文件删除了RFC 4594第4.10节中的以下行：“建议的DSCP标记为CS1（类别选择器1）”，并将其替换为以下文本：“建议的DSCP标记为LE（较低的努力程度），它取代了先前建议的CS1（类别选择器1）标记。”
Section 4.2.10 of RFC 8325 [RFC8325] specifies that "[RFC3662] and [RFC4594] both recommend Low-Priority Data be marked CS1 DSCP." This is updated to "[RFC3662] recommends that Low-Priority Data be marked CS1 DSCP. [RFC4594], as updated by RFC 8622, recommends that Low-Priority Data be marked LE DSCP."
RFC 8325[RFC8325]的第4.2.10节规定“[RFC3662]和[RFC4594]都建议将低优先级数据标记为CS1 DSCP。”这更新为“[RFC3662]建议将低优先级数据标记为CS1 DSCP。[RFC4594]，由RFC 8622更新，建议将低优先级数据标记为LE DSCP。”
This document removes the following paragraph in Section 4.2.10 of [RFC8325], because this document makes the anticipated change: "Note: This marking recommendation may change in the future, as [LE-PHB] defines a Lower Effort (LE) PHB for Low-Priority Data traffic and recommends an additional DSCP for this traffic."
本文件删除了[RFC8325]第4.2.10节中的以下段落，因为本文件做出了预期的更改：“注：本标记建议将来可能会发生变化，因为[LE-PHB]为低优先级数据通信定义了较低努力（LE）PHB，并为该通信推荐了额外的DSCP。”
Section 4.2.10 of RFC 8325 [RFC8325] specifies that "therefore, it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP 1", which is updated to "therefore, it is RECOMMENDED to map Low-Priority Data traffic marked with LE DSCP or legacy CS1 DSCP to UP 1".
RFC 8325[RFC8325]的第4.2.10节规定，“因此，建议将标记为CS1 DSCP的低优先级数据通信映射到UP 1”，更新为“因此，建议将标记为LE DSCP或传统CS1 DSCP的低优先级数据通信映射到UP 1”。
This update to RFC 8325 replaces the following entry from its Figure 1:
RFC 8325的此更新将替换图1中的以下条目：
+---------------+------+----------+------------+--------------------+
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
| Data | | | | |
+-------------------------------------------------------------------+
+---------------+------+----------+------------+--------------------+
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
| Data | | | | |
+-------------------------------------------------------------------+
with the following entries:
包括以下项目：
+---------------+------+----------+------------+--------------------+
| Low-Priority | LE | RFC 8622 | 1 | AC_BK (Background) |
| Data | | | | |
+-------------------------------------------------------------------+
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
| Data (legacy) | | | | |
+-------------------------------------------------------------------+
+---------------+------+----------+------------+--------------------+
| Low-Priority | LE | RFC 8622 | 1 | AC_BK (Background) |
| Data | | | | |
+-------------------------------------------------------------------+
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
| Data (legacy) | | | | |
+-------------------------------------------------------------------+
This document assigns the Differentiated Services Field Codepoint (DSCP) '000001' from the "Differentiated Services Field Codepoints (DSCP)" registry (https://www.iana.org/assignments/dscp-registry/) ("DSCP Pool 3 Codepoints", Codepoint Space xxxx01, Standards Action) [RFC8126] to the LE PHB. This document uses a DSCP from Pool 3 in order to avoid problems for other PHB-marked flows, where they could become accidentally re-marked as LE PHB, e.g., due to partial DSCP bleaching. See [RFC8436] regarding reclassifying Pool 3 for Standards Action.
本文档从“差异化服务字段代码点（DSCP）”注册表中分配差异化服务字段代码点（DSCP）“000001”(https://www.iana.org/assignments/dscp-registry/)（“DSCP池3代码点”，代码点空间XX01，标准行动）[RFC8126]至LE PHB。本文档使用池3中的DSCP，以避免其他带有PHB标记的流出现问题，这些流可能会意外地重新标记为LE PHB，例如，由于部分DSCP漂白。参见[RFC8436]关于标准行动的第3池重新分类。
IANA has updated this registry as follows:
IANA已将此注册表更新如下：
o Name: LE
o 姓名：乐
o Value (Binary): 000001
o 值（二进制）：000001
o Value (Decimal): 1
o 数值（十进制）：1
o Reference: RFC 8622
o 参考：RFC 8622
There are no specific security exposures for this PHB. Since it defines a new class that is of low forwarding priority, re-marking other traffic as LE traffic may lead to QoS degradation of such traffic. Thus, any attacker that is able to modify the DSCP of a packet to LE may carry out a downgrade attack. See the general security considerations in [RFC2474] and [RFC2475].
此PHB没有特定的安全风险。由于它定义了一个低转发优先级的新类，因此将其他流量重新标记为LE流量可能会导致此类流量的QoS降低。因此，任何能够将数据包的DSCP修改为LE的攻击者都可能实施降级攻击。请参阅[RFC2474]和[RFC2475]中的一般安全注意事项。
With respect to privacy, an attacker could use the information from the DSCP to infer that the transferred (probably even encrypted) content is considered of low priority or low urgency by a user if the DSCP was set per the user's request. On the one hand, this disclosed information is useful only if correlation with metadata (such as the user's IP address) and/or other flows reveal a user's identity. On the other hand, it might help an observer (e.g., a state-level actor) who is interested in learning about the user's behavior from observed traffic: LE-marked background traffic (such as software downloads, operating system updates, or telemetry data) may be less interesting for surveillance than general web traffic. Therefore, the LE marking may help the observer to focus on potentially more interesting traffic (however, the user may exploit this particular assumption and deliberately hide interesting traffic in the LE aggregate). Apart from such considerations, the impact of disclosed information by the LE DSCP is likely negligible in most cases, given the numerous traffic analysis possibilities and general privacy threats (e.g., see [RFC6973]).
关于隐私，如果DSCP是根据用户的请求设置的，攻击者可以使用DSCP中的信息推断用户认为传输的（甚至可能是加密的）内容具有低优先级或低紧急性。一方面，仅当与元数据（例如用户的IP地址）和/或其他流的关联揭示了用户的身份时，该公开的信息才有用。另一方面，它可能有助于有兴趣从观察到的流量中了解用户行为的观察者（例如，州一级的参与者）：标记的后台流量（如软件下载、操作系统更新或遥测数据）对于监视来说可能不如一般web流量有趣。因此，LE标记可以帮助观察者关注潜在的更有趣的通信量（然而，用户可以利用这个特定的假设并故意在LE聚合中隐藏有趣的通信量）。除此之外，考虑到大量流量分析可能性和一般隐私威胁（例如，参见[RFC6973]），LE DSCP披露信息的影响在大多数情况下可能可以忽略不计。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[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, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 2474，DOI 10.17487/RFC2474，1998年12月<https://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 2475，DOI 10.17487/RFC2475，1998年12月<https://www.rfc-editor.org/info/rfc2475>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[Carlberg-LBE-2001] Carlberg, K., Gevros, P., and J. Crowcroft, "Lower than best effort: a design and implementation", ACM SIGCOMM Computer Communication Review, Volume 31 Issue 2 supplement, DOI 10.1145/844193.844208, April 2001, <https://dl.acm.org/citation.cfm?doid=844193.844208>.
[Carlberg-LBE-2001]Carlberg，K.，Gevros，P.，和J.Crowcroft，“低于最佳努力：设计和实施”，《ACM SIGCOMM计算机通信评论》，第31卷第2期补充，DOI 10.1145/844193.844208，2001年4月<https://dl.acm.org/citation.cfm?doid=844193.844208>.
[Chown-LBE-2003] Chown, T., Ferrari, T., Leinen, S., Sabatino, R., Simar, N., and S. Venaas, "Less than Best Effort: Application Scenarios and Experimental Results", Proceedings of the Second International Workshop on Quality of Service in Multiservice IP Networks (QoS-IP 2003), Lecture Notes in Computer Science, vol 2601, Springer, Berlin, Heidelberg, Pages 131-144, DOI 10.1007/3-540-36480-3_10, February 2003, <https://link.springer.com/chapter/ 10.1007%2F3-540-36480-3_10>.
[Chown-LBE-2003]Chown，T.，Ferrari，T.，Leinen，S.，Sabatino，R.，Simar，N.，和S.Venaas，“不尽最大努力：应用场景和实验结果”，第二届多服务IP网络服务质量国际研讨会论文集（QoS IP 2003），计算机科学讲稿，第2601卷，柏林斯普林格，海德堡，第131-144页，内政部10.1007/3-540-36480-3_10，2003年2月<https://link.springer.com/chapter/ 10.1007%2F3-540-36480-3_10>。
[Diffserv-LBE-PHB] Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop Behavior", Work in Progress, draft-bless-diffserv-lbe-phb-00, September 1999.
[Diffserv LBE PHB]Bless，R.和K.Wehrle，“低于每跳最大努力的行为”，正在进行的工作，草稿-Bless-Diffserv-LBE-PHB-00，1999年9月。
[IETF99-Secchi] Secchi, R., Venne, A., and A. Custura, "Measurements concerning the DSCP for a LE PHB", Presentation held at the 99th IETF Meeting, TSVWG, Prague, July 2017, <https://datatracker.ietf.org/meeting/99/materials/ slides-99-tsvwg-sessb-31measurements-concerning-the-dscp-for-a-le-phb-00>.
[IETF99 Secchi]Secchi，R.，Venne，A.，和A.Custura，“与乐PHB的DSCP有关的测量”，在2017年7月布拉格TSVWG第99届IETF会议上举行的演讲<https://datatracker.ietf.org/meeting/99/materials/ 幻灯片-99-tsvwg-sessb-31measurements-about-the-dscp-for-a-le-phb-00>。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <https://www.rfc-editor.org/info/rfc2914>.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，DOI 10.17487/RFC2914，2000年9月<https://www.rfc-editor.org/info/rfc2914>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，DOI 10.17487/RFC3168，2001年9月<https://www.rfc-editor.org/info/rfc3168>.
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, DOI 10.17487/RFC3439, December 2002, <https://www.rfc-editor.org/info/rfc3439>.
[RFC3439]Bush，R.和D.Meyer，“一些互联网架构指南和哲学”，RFC 3439，DOI 10.17487/RFC3439，2002年12月<https://www.rfc-editor.org/info/rfc3439>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, DOI 10.17487/RFC3662, December 2003, <https://www.rfc-editor.org/info/rfc3662>.
[RFC3662]Bless，R.，Nichols，K.和K.Wehrle，“区分服务的低域行为（PDB）”，RFC 3662，DOI 10.17487/RFC3662，2003年12月<https://www.rfc-editor.org/info/rfc3662>.
[RFC3754] Bless, R. and K. Wehrle, "IP Multicast in Differentiated Services (DS) Networks", RFC 3754, DOI 10.17487/RFC3754, April 2004, <https://www.rfc-editor.org/info/rfc3754>.
[RFC3754]Bless，R.和K.Wehrle，“区分服务（DS）网络中的IP多播”，RFC 3754，DOI 10.17487/RFC3754，2004年4月<https://www.rfc-editor.org/info/rfc3754>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <https://www.rfc-editor.org/info/rfc4594>.
[RFC4594]Babiarz，J.，Chan，K.，和F.Baker，“区分服务服务类的配置指南”，RFC 4594，DOI 10.17487/RFC4594，2006年8月<https://www.rfc-editor.org/info/rfc4594>.
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, "Raptor Forward Error Correction Scheme for Object Delivery", RFC 5053, DOI 10.17487/RFC5053, October 2007, <https://www.rfc-editor.org/info/rfc5053>.
[RFC5053]Luby，M.，Shokrollahi，A.，Watson，M.，和T.Stockhammer，“用于对象交付的猛禽前向纠错方案”，RFC 5053，DOI 10.17487/RFC5053，2007年10月<https://www.rfc-editor.org/info/rfc5053>.
[RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 2011, <https://www.rfc-editor.org/info/rfc6297>.
[RFC6297]Welzl，M.和D.Ros，“低于最大努力传输协议的调查”，RFC 6297，DOI 10.17487/RFC6297，2011年6月<https://www.rfc-editor.org/info/rfc6297>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <https://www.rfc-editor.org/info/rfc6817>.
[RFC6817]Shalunov，S.，Hazel，G.，Iyengar，J.，和M.Kuehlewind，“低额外延迟背景传输（LEDBAT）”，RFC 6817，DOI 10.17487/RFC6817，2012年12月<https://www.rfc-editor.org/info/rfc6817>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 6973，DOI 10.17487/RFC6973，2013年7月<https://www.rfc-editor.org/info/rfc6973>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085]Eggert，L.，Fairhurst，G.和G.Shepherd，“UDP使用指南”，BCP 145，RFC 8085，DOI 10.17487/RFC8085，2017年3月<https://www.rfc-editor.org/info/rfc8085>.
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using Explicit Congestion Notification (ECN)", RFC 8087, DOI 10.17487/RFC8087, March 2017, <https://www.rfc-editor.org/info/rfc8087>.
[RFC8087]Fairhurst，G.和M.Welzl，“使用显式拥塞通知（ECN）的好处”，RFC 8087，DOI 10.17487/RFC8087，2017年3月<https://www.rfc-editor.org/info/rfc8087>.
[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, March 2017, <https://www.rfc-editor.org/info/rfc8100>.
[RFC8100]Geib，R.，Ed.和D.Black，“区分服务互连类别和实践”，RFC 8100，DOI 10.17487/RFC8100，2017年3月<https://www.rfc-editor.org/info/rfc8100>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February 2018, <https://www.rfc-editor.org/info/rfc8325>.
[RFC8325]Szigeti，T.，Henry，J.，和F.Baker，“将Diffserv映射到IEEE 802.11”，RFC 8325，DOI 10.17487/RFC8325，2018年2月<https://www.rfc-editor.org/info/rfc8325>.
[RFC8436] Fairhurst, G., "Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry", RFC 8436, DOI 10.17487/RFC8436, August 2018, <https://www.rfc-editor.org/info/rfc8436>.
[RFC8436]Fairhurst，G.，“差异化服务领域代码点（DSCP）注册表中池3值的IANA注册程序更新”，RFC 8436，DOI 10.17487/RFC8436，2018年8月<https://www.rfc-editor.org/info/rfc8436>.
A first draft version of this PHB was suggested by Roland Bless and Klaus Wehrle in September 1999 [Diffserv-LBE-PHB], named "A Lower Than Best-Effort Per-Hop Behavior". After some discussion in the Diffserv Working Group, Brian Carpenter and Kathie Nichols proposed a "bulk handling" per-domain behavior and believed a PHB was not necessary. Eventually, "Lower Effort" was specified as per-domain behavior and finally became [RFC3662]. More detailed information about its history can be found in Section 10 of [RFC3662].
罗兰·布莱斯（Roland Bless）和克劳斯·韦勒（Klaus Wehrle）于1999年9月提出了该PHB的初稿版本[Diffserv LBE PHB]，命名为“低于每跳最大努力的行为”。在Diffserv工作组进行了一些讨论之后，Brian Carpenter和Kathie Nichols提出了每个域的“批量处理”行为，并认为PHB是不必要的。最终，根据域行为指定了“较低的努力”，并最终成为[RFC3662]。有关其历史的更多详细信息，请参见[RFC3662]第10节。
There are several other names in use for this type of PHB or associated service classes. Well known is the QBone Scavenger Service (QBSS) that was proposed in March 2001 within the Internet2 QoS Working Group. Alternative names are "Lower than best effort" [Carlberg-LBE-2001] or "Less than best effort" [Chown-LBE-2003].
对于这种类型的PHB或相关服务类，还有其他几个名称在使用。众所周知的是QBone清道夫服务（QBSS），该服务于2001年3月在Internet2QoS工作组中提出。备选名称为“低于最佳努力”[Carlberg-LBE-2001]或“低于最佳努力”[Chown-LBE-2003]。
Acknowledgments
致谢
Since text is partially borrowed from earlier Internet-Drafts and RFCs, the coauthors of previous specifications are acknowledged here: Kathie Nichols and Klaus Wehrle. David Black, Olivier Bonaventure, Spencer Dawkins, Toerless Eckert, Gorry Fairhurst, Ruediger Geib, and Kyle Rose provided helpful comments and (partially also text) suggestions.
由于文本部分借用了早期互联网草稿和RFC，因此在此确认了先前规范的合著者：凯西·尼科尔斯和克劳斯·韦勒。David Black、Olivier Bonaventure、Spencer Dawkins、Toerless Eckert、Gorry Fairhurst、Ruediger Geib和Kyle Rose提供了有益的评论和（部分也是文本）建议。
Author's Address
作者地址
Roland Bless Karlsruhe Institute of Technology (KIT) Institute of Telematics (TM) Kaiserstr. 12 Karlsruhe 76131 Germany
罗兰·布莱斯·卡尔斯鲁厄技术研究所（KIT）远程信息处理研究所（TM）Kaiserstr。12德国卡尔斯鲁厄76131
Phone: +49 721 608 46413
Email: roland.bless@kit.edu
Phone: +49 721 608 46413
Email: roland.bless@kit.edu