Network Working Group N. Spring
Request for Comments: 3540 D. Wetherall
Category: Experimental D. Ely
University of Washington
June 2003
Network Working Group N. Spring
Request for Comments: 3540 D. Wetherall
Category: Experimental D. Ely
University of Washington
June 2003
Robust Explicit Congestion Notification (ECN) Signaling with Nonces
具有nonce的鲁棒显式拥塞通知（ECN）信令
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts.
本说明描述了显式拥塞通知（ECN）-nonce，它是ECN的一个可选添加项，用于防止TCP发送方意外或恶意隐藏标记的数据包。它通过防止接收机利用ECN获得不公平的网络带宽份额，提高了拥塞控制的鲁棒性。ECN nonce使用IP报头的ECN字段中的两个支持ECN的传输（ECT）代码点，并且需要TCP报头中的标志。它对路由器和主机都具有计算效率。
Statement of Intent
意向书
This specification describes an optional addition to Explicit Congestion Notification [RFC3168] improving its robustness against malicious or accidental concealment of marked packets. It has not been deployed widely. One goal of publication as an Experimental RFC is to be prudent, and encourage use and deployment prior to publication in the standards track. Another consideration is to give time for firewall developers to recognize and accept the pattern presented by the nonce. It is the intent of the Transport Area Working Group to re-submit this specification as an IETF Proposed Standard in the future after more experience has been gained.
本规范描述了显式拥塞通知[RFC3168]的可选附加功能，提高了其对恶意或意外隐藏标记数据包的鲁棒性。它尚未得到广泛部署。作为实验性RFC出版的一个目标是谨慎，鼓励在标准轨道出版之前使用和部署。另一个考虑因素是给防火墙开发人员留出时间来识别和接受nonce提供的模式。运输区工作组的目的是在获得更多经验后，在未来重新提交本规范作为IETF提议的标准。
The correct operation of ECN requires the cooperation of the receiver to return Congestion Experienced signals to the sender, but the protocol lacks a mechanism to enforce this cooperation. This raises the possibility that an unscrupulous or poorly implemented receiver could always clear ECN-Echo and simply not return congestion signals to the sender. This would give the receiver a performance advantage at the expense of competing connections that behave properly. More generally, any device along the path (NAT box, firewall, QOS bandwidth shapers, and so forth) could remove congestion marks with impunity.
ECN的正确运行需要接收方的合作，以将经历拥塞的信号返回给发送方，但该协议缺乏强制这种合作的机制。这就增加了这样一种可能性，即一个不道德或执行不善的接收器可能总是清除ECN回波，而只是不向发送方返回拥塞信号。这将在牺牲正常运行的竞争连接的情况下为接收器提供性能优势。更一般地说，路径上的任何设备（NAT盒、防火墙、QOS带宽整形器等）都可以消除拥塞标记而不受惩罚。
The above behaviors may or may not constitute a threat to the operation of congestion control in the Internet. However, given the central role of congestion control, it is prudent to design the ECN signaling loop to be robust against as many threats as possible. In this way, ECN can provide a clear incentive for improvement over the prior state-of-the-art without potential incentives for abuse. The ECN-nonce is a simple, efficient mechanism to eliminate the potential abuse of ECN.
上述行为可能对互联网拥塞控制的运行构成威胁，也可能不构成威胁。然而，考虑到拥塞控制的核心作用，谨慎的做法是将ECN信令环路设计为对尽可能多的威胁具有鲁棒性。通过这种方式，ECN可以提供一种明确的激励，使其比现有的技术水平有所改进，而不会产生滥用的潜在激励。ECN nonce是一种简单、有效的机制，可以消除ECN的潜在滥用。
The ECN-nonce enables the sender to verify the correct behavior of the ECN receiver and that there is no other interference that conceals marked (or dropped) packets in the signaling path. The ECN-nonce protects against both implementation errors and deliberate abuse. The ECN-nonce:
ECN nonce使发送方能够验证ECN接收器的正确行为，并且没有其他干扰隐藏信令路径中标记（或丢弃）的数据包。ECN nonce可防止实现错误和故意滥用。ECN暂时：
- catches a misbehaving receiver with a high probability, and never implicates an innocent receiver.
- 以高概率抓住行为不端的接受者，从不牵连无辜的接受者。
- does not change other aspects of ECN, nor does it reduce the benefits of ECN for behaving receivers.
- 不会改变ECN的其他方面，也不会降低ECN对行为接收者的好处。
- is cheap in both per-packet overhead (one TCP header flag) and processing requirements.
- 在每包开销（一个TCP头标志）和处理要求方面都很便宜。
- is simple and, to the best of our knowledge, not prone to other attacks.
- 简单，据我们所知，不容易受到其他攻击。
We also note that use of the ECN-nonce has two additional benefits, even when only drop-tail routers are used. First, packet drops cannot be concealed from the sender. Second, it prevents optimistic acknowledgements [Savage], in which TCP segments are acknowledged before they have been received. These benefits also serve to increase the robustness of congestion control from attacks. We do not elaborate on these benefits in this document.
我们还注意到，使用ECN nonce还有两个额外的好处，即使只使用掉尾路由器。首先，不能对发送方隐藏数据包丢失。第二，它防止乐观确认[Savage]，在乐观确认中，TCP段在被接收之前被确认。这些好处也有助于提高拥塞控制对攻击的鲁棒性。我们在本文件中不详细说明这些好处。
The rest of this document describes the ECN-nonce. We present an overview followed by detailed behavior at senders and receivers.
本文档的其余部分描述了ECN nonce。我们提供了一个概述，然后是发送方和接收方的详细行为。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照[RFC2119]中的说明进行解释。
The ECN-nonce builds on the existing ECN-Echo and Congestion Window Reduced (CWR) signaling mechanism. Familiarity with ECN [ECN] is assumed. For simplicity, we describe the ECN-nonce in one direction only, though it is run in both directions in parallel.
ECN nonce建立在现有ECN回声和拥塞窗口缩减（CWR）信令机制的基础上。假设熟悉ECN[ECN]。为简单起见，我们仅在一个方向上描述ECN nonce，尽管它在两个方向上并行运行。
The ECN protocol for TCP remains unchanged, except for the definition of a new field in the TCP header. As in [RFC3168], ECT(0) or ECT(1) (ECN-Capable Transport) is set in the ECN field of the IP header on outgoing packets. Congested routers change this field to CE (Congestion Experienced). When TCP receivers notice CE, the ECE (ECN-Echo) flag is set in subsequent acknowledgements until receiving a CWR flag. The CWR flag is sent on new data whenever the sender reacts to congestion.
TCP的ECN协议保持不变，除了TCP头中定义了一个新字段。与[RFC3168]中一样，在传出数据包的IP报头的ECN字段中设置ECT（0）或ECT（1）（支持ECN的传输）。拥塞路由器将此字段更改为CE（经历拥塞）。当TCP接收器通知CE时，ECE（ECN Echo）标志将在后续确认中设置，直到接收到CWR标志。每当发送方对拥塞做出反应时，就会在新数据上发送CWR标志。
The ECN-nonce adds to this protocol, and enables the receiver to demonstrate to the sender that segments being acknowledged were received unmarked. A random one-bit value (a nonce) is encoded in the two ECT codepoints. The one-bit sum of these nonces is returned in a TCP header flag, the nonce sum (NS) bit. Packet marking erases the nonce value in the ECT codepoints because CE overwrites both ECN IP header bits. Since each nonce is required to calculate the sum, the correct nonce sum implies receipt of only unmarked packets. Not only are receivers prevented from concealing marked packets, middle-boxes along the network path cannot unmark a packet without successfully guessing the value of the original nonce.
ECN nonce添加到该协议中，并使接收方能够向发送方证明被确认的段是未标记的。在两个ECT码点中对随机一位值（nonce）进行编码。这些nonce的一位和在TCP头标志中返回，即nonce和（NS）位。数据包标记会擦除ECT代码点中的nonce值，因为CE会覆盖两个ECN IP头位。由于计算和需要每个nonce，因此正确的nonce和意味着只接收未标记的数据包。不仅防止接收者隐藏标记的数据包，网络路径上的中间框也无法在未成功猜测原始nonce值的情况下取消标记数据包。
The sender can verify the nonce sum returned by the receiver to ensure that congestion indications in the form of marked (or dropped) packets are not being concealed. Because the nonce sum is only one bit long, senders have a 50-50 chance of catching a lying receiver whenever an acknowledgement conceals a mark. Because each acknowledgement is an independent trial, cheaters will be caught quickly if there are repeated congestion signals.
发送方可以验证接收方返回的nonce和，以确保标记（或丢弃）数据包形式的拥塞指示不会被隐藏。因为当前和只有一位长，所以只要确认隐藏了标记，发送方就有50%的机会捕获说谎的接收方。因为每一次确认都是一次独立的试验，如果出现重复的拥塞信号，作弊者将很快被抓获。
The following paragraphs describe aspects of the ECN-nonce protocol in greater detail.
以下段落更详细地描述了ECN nonce协议的各个方面。
Each acknowledgement carries a nonce sum, which is the one bit sum (exclusive-or, or parity) of nonces over the byte range represented by the acknowledgement. The sum is used because not every packet is acknowledged individually, nor are packets acknowledged reliably. If a sum were not used, the nonce in an unmarked packet could be echoed to prove to the sender that the individual packet arrived unmarked. However, since these acks are not reliably delivered, the sender could not distinguish a lost ACK from one that was never sent in order to conceal a marked packet. The nonce sum prevents the receiver from concealing individual marked packets by not acknowledging them. Because the nonce and nonce sum are both one bit quantities, the sum is no easier to guess than the individual nonces. We show the nonce sum calculation below in Figure 1.
每个确认都携带一个nonce和，它是由确认表示的字节范围内的一位nonce和（异或或奇偶校验）。之所以使用总和，是因为不是每个数据包都被单独确认，也不是可靠地确认数据包。如果未使用总和，则可以回显未标记数据包中的nonce，以向发送方证明单个数据包未标记到达。但是，由于这些ACK没有可靠地传递，发送方无法区分丢失的ACK和从未发送过的ACK，以隐藏标记的数据包。nonce和防止接收器通过不确认单个标记的数据包来隐藏这些数据包。因为nonce和nonce和都是一位量，所以和并不比单个nonce更容易猜测。我们在下面的图1中显示了nonce sum计算。
Sender Receiver
initial sum = 1
-- 1:4 ECT(0) --> NS = 1 + 0(1:4) = 1(:4)
<- ACK 4, NS=1 ---
-- 4:8 ECT(1) --> NS = 1(:4) + 1(4:8) = 0(:8)
<- ACK 8, NS=0 ---
-- 8:12 ECT(1) -> NS = 0(:8) + 1(8:12) = 1(:12)
<- ACK 12, NS=1 --
-- 12:16 ECT(1) -> NS = 1(:12) + 1(12:16) = 0(:16)
<- ACK 16, NS=0 --
Sender Receiver
initial sum = 1
-- 1:4 ECT(0) --> NS = 1 + 0(1:4) = 1(:4)
<- ACK 4, NS=1 ---
-- 4:8 ECT(1) --> NS = 1(:4) + 1(4:8) = 0(:8)
<- ACK 8, NS=0 ---
-- 8:12 ECT(1) -> NS = 0(:8) + 1(8:12) = 1(:12)
<- ACK 12, NS=1 --
-- 12:16 ECT(1) -> NS = 1(:12) + 1(12:16) = 0(:16)
<- ACK 16, NS=0 --
Figure 1: The calculation of nonce sums at the receiver.
图1：接收器处的nonce和的计算。
After congestion has occurred and packets have been marked or lost, resynchronization of the sender and receiver nonce sums is needed. When packets are marked, the nonce is cleared, and the sum of the nonces at the receiver will no longer match the sum at the sender. Once nonces have been lost, the difference between sender and receiver nonce sums is constant until there is further loss. This means that it is possible to resynchronize the sender and receiver after congestion by having the sender set its nonce sum to that of the receiver. Because congestion indications do not need to be conveyed more frequently than once per round trip, the sender suspends checking while the CWR signal is being delivered and resets its nonce sum to the receiver's when new data is acknowledged. This has the benefit that the receiver is not explicitly involved in the re-synchronization process. The resynchronization process is shown in Figure 2 below. Note that the nonce sum returned in ACK 12 (NS=0) differs from that in the previous example (NS=1), and it continues to differ for ACK 16.
在拥塞发生且数据包被标记或丢失后，需要重新同步发送方和接收方的非同步和。标记数据包时，nonce被清除，接收方的nonce之和将不再与发送方的nonce之和匹配。一旦nonce丢失，发送方和接收方nonce和之间的差值将保持不变，直到进一步丢失为止。这意味着，通过让发送方将其nonce和设置为接收方的nonce和，可以在拥塞后重新同步发送方和接收方。由于拥塞指示的传输频率不需要超过每次往返一次，因此在发送CWR信号时，发送方暂停检查，并在确认新数据时将其nonce sum重置为接收方的nonce sum。这样做的好处是，接收机没有明确参与重新同步过程。重新同步过程如下图2所示。请注意，在ACK 12中返回的nonce和（NS=0）与上一示例中的不同（NS=1），对于ACK 16，它继续不同。
Sender Receiver
initial sum = 1
-- 1:4 ECT(0) -> NS = 1 + 0(1:4) = 1(:4)
<- ACK 4, NS=1 --
-- 4:8 ECT(1) -> CE -> NS = 1(:4) + ?(4:8) = 1(:8)
<- ACK 8, ECE NS=1 --
-- 8:12 ECT(1), CWR -> NS = 1(:8) + 1(8:12) = 0(:12)
<- ACK 12, NS=0 --
-- 12:16 ECT(1) -> NS = 0(:12) + 1(12:16) = 1(:16)
<- ACK 16, NS=1 --
Sender Receiver
initial sum = 1
-- 1:4 ECT(0) -> NS = 1 + 0(1:4) = 1(:4)
<- ACK 4, NS=1 --
-- 4:8 ECT(1) -> CE -> NS = 1(:4) + ?(4:8) = 1(:8)
<- ACK 8, ECE NS=1 --
-- 8:12 ECT(1), CWR -> NS = 1(:8) + 1(8:12) = 0(:12)
<- ACK 12, NS=0 --
-- 12:16 ECT(1) -> NS = 0(:12) + 1(12:16) = 1(:16)
<- ACK 16, NS=1 --
Figure 2: The calculation of nonce sums at the receiver when a packet (4:8) is marked. The receiver may calculate the wrong nonce sum when the original nonce information is lost after a packet is marked.
图2：标记数据包（4:8）时，接收器处的nonce和的计算。当在分组被标记之后原始的nonce信息丢失时，接收机可能计算错误的nonce和。
Third, we need to reconcile that nonces are sent with packets but acknowledgements cover byte ranges. Acknowledged byte boundaries need not match the transmitted boundaries, and information can be retransmitted in packets with different byte boundaries. We discuss the first issue, how a receiver sets a nonce when acknowledging part of a segment, in Section 6.1. The second question, what nonce to send when retransmitting smaller segments as a large segment, has a simple answer: ECN is disabled for retransmissions, so can carry no nonce. Because retransmissions are associated with congestion events, nonce checking is suspended until after CWR is acknowledged and the congestion event is over.
第三，我们需要协调nonce与数据包一起发送，但确认覆盖字节范围。确认的字节边界不需要与传输的边界匹配，信息可以在具有不同字节边界的数据包中重新传输。我们将在第6.1节中讨论第一个问题，即接收器在确认部分段时如何设置nonce。第二个问题，当将较小的段作为较大的段重新传输时，要发送什么nonce，有一个简单的答案：ECN对于重新传输是禁用的，因此不能携带nonce。因为重传与拥塞事件相关，所以在确认CWR并且拥塞事件结束之前，暂停当前检查。
The next sections describe the detailed behavior of senders, routers and receivers, starting with sender transmit behavior, then around the ECN signaling loop, and finish with sender acknowledgement processing.
下一节将描述发送方、路由器和接收机的详细行为，从发送方传输行为开始，然后围绕ECN信令循环，最后是发送方确认处理。
Senders manage CWR and ECN-Echo as before. In addition, they must place nonces on packets as they are transmitted and check the validity of the nonce sums in acknowledgments as they are received. This section describes the transmit process.
发送方像以前一样管理CWR和ECN回显。此外，它们必须在传输数据包时在数据包上放置nonce，并在收到确认时检查nonce和的有效性。本节描述传输过程。
To place a one bit nonce value on every ECN-capable IP packet, the sender uses the two ECT codepoints: ECT(0) represents a nonce of 0, and ECT(1) a nonce of 1. As in ECN, retransmissions are not ECN-capable, so carry no nonce.
要在每个支持ECN的IP数据包上放置一位nonce值，发送方使用两个ECT代码点：ECT（0）表示nonce为0，ECT（1）表示nonce为1。与在ECN中一样，重传不支持ECN，因此不携带nonce。
The sender maintains a mapping from each packet's end sequence number to the expected nonce sum (not the nonce placed in the original transmission) in the acknowledgement bearing that sequence number.
发送方维护从每个数据包的结束序列号到带有该序列号的确认中预期的nonce和（而不是原始传输中放置的nonce）的映射。
Routers behave as specified in [RFC3168]. By marking packets to signal congestion, the original value of the nonce, in ECT(0) or ECT(1), is removed. Neither the receiver nor any other party can unmark the packet without successfully guessing the value of the original nonce.
路由器的行为符合[RFC3168]中的规定。通过将数据包标记为信号拥塞，可以删除ECT（0）或ECT（1）中的nonce的原始值。如果不成功猜测原始nonce的值，则接收方或任何其他方都不能取消标记数据包。
ECN-nonce receivers maintain the nonce sum as in-order packets arrive and return the current nonce sum in each acknowledgement. Receiver behavior is otherwise unchanged from [RFC3168]. Returning the nonce sum is optional, but recommended, as senders are allowed to discontinue sending ECN-capable packets to receivers that do not support the ECN-nonce.
ECN nonce接收器在数据包到达时维护nonce和，并在每个确认中返回当前nonce和。接收器行为在[RFC3168]中没有改变。返回nonce和是可选的，但建议这样做，因为允许发送方停止向不支持ECN nonce的接收方发送支持ECN的数据包。
As packets are removed from the queue of out-of-order packets to be acknowledged, the nonce is recovered from the IP header. The nonce is added to the current nonce sum as the acknowledgement sequence number is advanced for the recent packet.
当从要确认的无序数据包队列中删除数据包时，将从IP报头恢复nonce。随着最近数据包的确认序列号提前，nonce被添加到当前nonce和中。
In the case of marked packets, one or more nonce values may be unknown to the receiver. In this case the missing nonce values are ignored when calculating the sum (or equivalently a value of zero is assumed) and ECN-Echo will be set to signal congestion to the sender.
在标记分组的情况下，接收机可能不知道一个或多个nonce值。在这种情况下，在计算和时忽略缺少的nonce值（或假设相等的值为零），ECN Echo将被设置为向发送方发送拥塞信号。
Returning the nonce sum corresponding to a given acknowledgement is straightforward. It is carried in a single "NS" (Nonce Sum) bit in the TCP header. This bit is adjacent to the CWR and ECN-Echo bits, set as Bit 7 in byte 13 of the TCP header, as shown below:
返回与给定确认相对应的nonce和非常简单。它在TCP报头中的单个“NS”（Nonce Sum）位中携带。该位与CWR和ECN回波位相邻，在TCP头的字节13中设置为位7，如下所示：
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | N | C | E | U | A | P | R | S | F |
| Header Length | Reserved | S | W | C | R | C | S | S | Y | I |
| | | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | N | C | E | U | A | P | R | S | F |
| Header Length | Reserved | S | W | C | R | C | S | S | Y | I |
| | | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 3: The new definition of bytes 13 and 14 of the TCP Header.
图3:TCP头字节13和14的新定义。
The initial nonce sum is 1, and is included in the SYN/ACK and ACK of the three way TCP handshake. This allows the other endpoint to infer nonce support, but is not a negotiation, in that the receiver of the SYN/ACK need not check if NS is set to decide whether to set NS in the subsequent ACK.
初始nonce和为1，并包含在三向TCP握手的SYN/ACK和ACK中。这允许另一个端点推断nonce支持，但不是协商，因为SYN/ACK的接收器不需要检查是否设置了NS来决定是否在后续ACK中设置NS。
This section completes the description of sender behavior by describing how senders check the validity of the nonce sums.
本节通过描述发送者如何检查nonce和的有效性来完成发送者行为的描述。
The nonce sum is checked when an acknowledgement of new data is received, except during congestion recovery when additional ECN-Echo signals would be ignored. Checking consists of comparing the correct nonce sum stored in a buffer to that carried in the acknowledgement, with a correction described in the following subsection.
当接收到新数据的确认时，将检查nonce sum，除非在拥塞恢复期间忽略其他ECN回波信号。检查包括将缓冲区中存储的正确的非同步和与确认中携带的非同步和进行比较，并进行以下小节中描述的更正。
If ECN-Echo is not set, the receiver claims to have received no marked packets, and can therefore compute and return the correct nonce sum. To conceal a mark, the receiver must successfully guess the sum of the nonces that it did not receive, because at least one packet was marked and the corresponding nonce was erased. Provided the individual nonces are equally likely to be 0 or 1, their sum is equally likely to be 0 or 1. In other words, any guess is equally likely to be wrong and has a 50-50 chance of being caught by the sender. Because each new acknowledgement is an independent trial, a cheating receiver is likely to be caught after a small number of lies.
如果未设置ECN Echo，则接收器声称未接收到标记的数据包，因此可以计算并返回正确的nonce和。要隐藏标记，接收器必须成功猜测其未接收到的nonce之和，因为至少有一个数据包被标记，并且相应的nonce被擦除。假设各个nonce的值相等可能为0或1，则它们的总和相等可能为0或1。换句话说，任何猜测都有可能是错误的，并且有50%的几率被发送者抓住。因为每一次新的确认都是一次独立的审判，一个作弊的接收者很可能在少量的谎言之后被抓住。
If ECN-Echo is set, the receiver is sending a congestion signal and it is not necessary to check the nonce sum. The congestion window will be halved, CWR will be set on the next packet with new data sent, and ECN-Echo will be cleared once the CWR signal is received, as in [RFC3168]. During this recovery process, the sum may be incorrect because one or more nonces were not received. This does not matter during recovery, because TCP invokes congestion mechanisms at most once per RTT, whether there are one or more losses during that period.
如果设置了ECN Echo，则接收器正在发送拥塞信号，无需检查当前和。拥塞窗口将减半，CWR将在发送新数据的下一个数据包上设置，一旦收到CWR信号，ECN回波将被清除，如[RFC3168]所示。在此恢复过程中，总和可能不正确，因为未收到一个或多个nonce。这在恢复期间并不重要，因为TCP在每个RTT中最多调用一次拥塞机制，无论在该期间是否有一个或多个丢失。
After recovery, it is necessary to re-synchronize the sender and receiver nonce sums so that further acknowledgments can be checked. When the receiver's sum is incorrect, it will remain incorrect until further loss.
恢复后，有必要重新同步发送方和接收方的nonce和，以便检查进一步的确认。当接收者的总和不正确时，它将保持不正确，直到进一步损失。
This leads to a simple re-synchronization mechanism where the sender resets its nonce sum to that of the receiver when it receives an acknowledgment for new data sent after the congestion window was reduced. When responding to explicit congestion signals, this will be the first acknowledgement without the ECN-Echo flag set: the acknowledgement of the packet containing the CWR flag.
这导致了一种简单的重新同步机制，其中发送方在收到拥塞窗口减小后发送的新数据的确认时，将其nonce和重置为接收方的nonce和。当响应显式拥塞信号时，这将是未设置ECN Echo标志的第一个确认：包含CWR标志的数据包的确认。
Sender Receiver
initial sum = 1
-- 1:4 ECT(0) -> NS = 1 + 0(1:4) = 1(:4)
<- ACK 4, NS=1 --
-- 4:8 ECT(1) -> LOST
-- 8:12 ECT(1) -> nonce sum calculation deferred
until in-order data received
<- ACK 4, NS=0 --
-- 12:16 ECT(1) -> nonce sum calculation deferred
<- ACK 4, NS=0 --
-- 4:8 retransmit -> NS = 1(:4) + ?(4:8) +
1(8:12) + 1(12:16) = 1(:16)
<- ACK 16, NS=1 --
-- 16:20 ECT(1) CWR ->
<- ACK 20, NS=0 -- NS = 1(:16) + 1(16:20) = 0(:20)
Sender Receiver
initial sum = 1
-- 1:4 ECT(0) -> NS = 1 + 0(1:4) = 1(:4)
<- ACK 4, NS=1 --
-- 4:8 ECT(1) -> LOST
-- 8:12 ECT(1) -> nonce sum calculation deferred
until in-order data received
<- ACK 4, NS=0 --
-- 12:16 ECT(1) -> nonce sum calculation deferred
<- ACK 4, NS=0 --
-- 4:8 retransmit -> NS = 1(:4) + ?(4:8) +
1(8:12) + 1(12:16) = 1(:16)
<- ACK 16, NS=1 --
-- 16:20 ECT(1) CWR ->
<- ACK 20, NS=0 -- NS = 1(:16) + 1(16:20) = 0(:20)
Figure 4: The calculation of nonce sums at the receiver when a packet is lost, and resynchronization after loss. The nonce sum is not changed until the cumulative acknowledgement is advanced.
图4：当数据包丢失时，接收器处的nonce和的计算，以及丢失后的重新同步。在累积确认提前之前，不会更改当前和。
In practice, resynchronization can be accomplished by storing a bit that has the value one if the expected nonce sum stored by the sender and the received nonce sum in the acknowledgement of CWR differ, and zero otherwise. This synchronization offset bit can then be used in the comparison between expected nonce sum and received nonce sum.
在实践中，如果发送方存储的预期非同步和与CWR确认中接收到的非同步和不同，则可以通过存储值为1的位来实现重新同步，否则为零。然后，该同步偏移位可用于预期的非同步和与接收的非同步和之间的比较。
The sender should ignore the nonce sum returned on any acknowledgements bearing the ECN-echo flag.
发送方应忽略任何带有ECN echo标志的确认返回的nonce和。
When an acknowledgment covers only a portion of a segment, such as when a middlebox resegments at the TCP layer instead of fragmenting IP packets, the sender should accept the nonce sum expected at the next segment boundary. In other words, an acknowledgement covering part of an original segment will include the nonce sum expected when the entire segment is acknowledged.
当确认仅覆盖一段的一部分时，例如当中间盒在TCP层重新分段而不是对IP数据包进行分段时，发送方应接受下一段边界处预期的nonce和。换言之，覆盖原始段一部分的确认将包括在确认整个段时预期的当前和。
Finally, in ECN, senders can choose not to indicate ECN capability on some packets for any reason. An ECN-nonce sender must resynchronize after sending such ECN-incapable packets, as though a CWR had been sent with the first new data after the ECN-incapable packets. The sender loses protection for any unacknowledged packets until resynchronization occurs.
最后，在ECN中，发送方可以出于任何原因选择不在某些数据包上指示ECN能力。ECN nonce发送方在发送此类ECN NONCABLE数据包后必须重新同步，就好像CWR已与ECN NONCABLE数据包之后的第一个新数据一起发送一样。在发生重新同步之前，发送方将失去对任何未确认数据包的保护。
The sender's response to an incorrect nonce is a matter of policy. It is separate from the checking mechanism and does not need to be handled uniformly by senders. Further, checking received nonce sums at all is optional, and may be disabled.
发送方对不正确的nonce的响应是一个策略问题。它独立于检查机制，不需要发送者统一处理。此外，检查接收到的nonce和是可选的，并且可能被禁用。
If the receiver has never sent a non-zero nonce sum, the sender can infer that the receiver does not understand the nonce, and rate limit the connection, place it in a lower-priority queue, or cease setting ECT in outgoing segments.
如果接收方从未发送过非零nonce sum，则发送方可以推断接收方不理解nonce，并对连接进行速率限制，将其置于较低优先级队列中，或停止在传出段中设置ECT。
If the received nonce sum has been set in a previous acknowledgement, the sender might infer that a network device has interfered with correct ECN signaling between ECN-nonce supporting endpoints. The minimum response to an incorrect nonce is the same as the response to a received ECE. However, to compensate for hidden congestion signals, the sender might reduce the congestion window to one segment and cease setting ECT in outgoing segments. An incorrect nonce sum is a sign of misbehavior or error between ECN-nonce supporting endpoints.
如果在先前的确认中设置了接收到的nonce和，则发送方可能推断网络设备干扰了支持ECN nonce的端点之间的正确ECN信令。对不正确nonce的最小响应与对接收到的ECE的响应相同。然而，为了补偿隐藏的拥塞信号，发送方可能会将拥塞窗口减少到一个段，并停止在传出段中设置ECT。不正确的nonce和是ECN nonce支持端点之间行为不当或错误的标志。
The ECN-nonce can provide robustness beyond checking that marked packets are signaled to the sender. It also ensures that dropped packets cannot be concealed from the sender (because their nonces have been lost). Drops could potentially be concealed by a faulty TCP implementation, certain attacks, or even a hypothetical TCP accelerator. Such an accelerator could gamble that it can either successfully "fast start" to a preset bandwidth quickly, retry with another connection, or provide reliability at the application level. If robustness against these faults is also desired, then the ECN-nonce should not be disabled. Instead, reducing the congestion window to one, or using a low-priority queue, would penalize faulty operation while providing continued checking.
ECN nonce除了检查标记的数据包是否以信号形式发送给发送方之外，还可以提供健壮性。它还确保丢弃的数据包不能对发送方隐藏（因为它们的nonce已经丢失）。丢包可能被错误的TCP实现、某些攻击、甚至假设的TCP加速器所隐藏。这样的加速器可以赌它可以成功地快速“快速启动”到预设带宽，使用另一个连接重试，或者在应用程序级别提供可靠性。如果还需要对这些故障的鲁棒性，则不应禁用ECN nonce。相反，将拥塞窗口减少到一个，或使用低优先级队列，将在提供持续检查的同时惩罚错误操作。
The ECN-nonce can also detect misbehavior in Eifel [Eifel], a recently proposed mechanism for removing the retransmission ambiguity to improve TCP performance. A misbehaving receiver might claim to have received only original transmissions to convince the sender to undo congestion actions. Since retransmissions are sent without ECT, and thus no nonce, returning the correct nonce sum confirms that only original transmissions were received.
ECN nonce还可以检测Eifel[Eifel]中的错误行为，Eifel是最近提出的一种消除重传模糊性以提高TCP性能的机制。行为不端的接收方可能会声称只接收到原始传输，以说服发送方撤销拥塞操作。由于发送重传时没有ECT，因此没有nonce，因此返回正确的nonce和将确认只接收到原始传输。
As described in RFC3168, use of the Don't Fragment bit with ECN is recommended. Receivers that receive unmarked fragments can reconstruct the original nonce to conceal a marked fragment. The ECN-nonce cannot protect against misbehaving receivers that conceal marked fragments, so some protection is lost in situations where Path MTU discovery is disabled.
如RFC3168所述，建议在ECN中使用不分段位。接收未标记片段的接收器可以重建原始nonce以隐藏标记片段。ECN nonce无法防止隐藏标记片段的行为不端的接收器，因此在禁用路径MTU发现的情况下会丢失一些保护。
When responding to a small path MTU, the sender will retransmit a smaller frame in place of a larger one. Since these smaller packets are retransmissions, they will be ECN-incapable and bear no nonce. The sender should resynchronize on the first newly transmitted packet.
当响应小路径MTU时，发送方将重新传输较小的帧来代替较大的帧。因为这些较小的数据包是重传的，所以它们将不能进行ECN，并且不具有nonce。发送方应重新同步第一个新传输的数据包。
Selective acknowledgements allow receivers to acknowledge out of order segments as an optimization. It is not necessary to modify the selective acknowledgment option to fit per-range nonce sums, because SACKs cannot be used by a receiver to hide a congestion signal. The nonce sum corresponds only to the data acknowledged by the cumulative acknowledgement.
选择性确认允许接收机将无序段确认为优化。无需修改选择性确认选项以适应每范围非同步和，因为接收器不能使用SACK隐藏拥塞信号。当前和仅对应于累积确认确认的数据。
Although the IPv4 header is protected by a checksum, this is not the case with IPv6, making undetected bit errors in the IPv6 header more likely. Bit errors that compromise the integrity of the congestion notification fields may cause an incorrect nonce to be received, and an incorrect nonce sum to be returned.
虽然IPv4报头受校验和保护，但IPv6的情况并非如此，这使得IPv6报头中更可能出现未检测到的位错误。危及拥塞通知字段完整性的位错误可能会导致接收不正确的nonce，并返回不正确的nonce和。
The random one-bit nonces need not be from a cryptographic-quality pseudo-random number generator. A strong random number generator would compromise performance. Consequently, the sequence of random nonces should not be used for any other purpose.
随机一位nonce不需要来自密码质量伪随机数生成器。强随机数生成器会影响性能。因此，随机nonce序列不应用于任何其他目的。
Conversely, the pseudo-random bit sequence should not be generated by a linear feedback shift register [Schneier], or similar scheme that would allow an adversary who has seen several previous bits to infer the generation function and thus its future output.
相反，伪随机位序列不应由线性反馈移位寄存器[Schneier]或类似方案生成，该方案将允许看到多个先前位的对手推断生成函数，从而推断其未来输出。
Although the ECN-nonce protects against concealment of congestion signals and optimistic acknowledgement, it provides no additional protection for the integrity of the connection.
尽管ECN nonce可以防止拥塞信号和乐观确认的隐藏，但它没有为连接的完整性提供额外的保护。
The Nonce Sum (NS) is carried in a reserved TCP header bit that must be allocated. This document describes the use of Bit 7, adjacent to the other header bits used by ECN.
Nonce和（NS）在必须分配的保留TCP头比特中携带。本文档描述了与ECN使用的其他标头位相邻的第7位的使用。
The codepoint for the NS flag in the TCP header is specified by the Standards Action of this RFC, as is required by RFC 2780. The IANA has added the following to the registry for "TCP Header Flags":
根据RFC 2780的要求，TCP标头中NS标志的代码点由该RFC的标准操作指定。IANA在注册表中添加了以下“TCP头标志”：
RFC 3540 defines bit 7 from the Reserved field to be used for the Nonce Sum, as follows:
RFC 3540定义了保留字段中用于当前和的第7位，如下所示：
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | N | C | E | U | A | P | R | S | F |
| Header Length | Reserved | S | W | C | R | C | S | S | Y | I |
| | | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | N | C | E | U | A | P | R | S | F |
| Header Length | Reserved | S | W | C | R | C | S | S | Y | I |
| | | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
TCP Header Flags
TCP头标志
Bit Name Reference
--- ---- ---------
7 NS (Nonce Sum) [RFC 3540]
Bit Name Reference
--- ---- ---------
7 NS (Nonce Sum) [RFC 3540]
The ECN-nonce is a simple modification to the ECN signaling mechanism that improves ECN's robustness by preventing receivers from concealing marked (or dropped) packets. The intent of this work is to help improve the robustness of congestion control in the Internet. The modification retains the character and simplicity of existing ECN signaling. It is also practical for deployment in the Internet. It uses the ECT(0) and ECT(1) codepoints and one TCP header flag (as well as CWR and ECN-Echo) and has simple processing rules.
ECN nonce是对ECN信令机制的简单修改，它通过防止接收机隐藏标记（或丢弃）的数据包来提高ECN的健壮性。这项工作的目的是帮助提高互联网拥塞控制的鲁棒性。修改保留了现有ECN信令的特点和简单性。它也适用于在互联网上部署。它使用ECT（0）和ECT（1）代码点和一个TCP头标志（以及CWR和ECN Echo），并具有简单的处理规则。
[ECN] "The ECN Web Page", URL "http://www.icir.org/floyd/ecn.html".
[ECN]“ECN网页”，URLhttp://www.icir.org/floyd/ecn.html".
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The addition of explicit congestion notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[Eifel] R. Ludwig and R. Katz. The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions. Computer Communications Review, January, 2000.
[Eifel]R.路德维希和R.卡茨。Eifel算法：使TCP对伪重传具有鲁棒性。计算机通信评论，2000年1月。
[B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[B97]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[Savage] S. Savage, N. Cardwell, D. Wetherall, T. Anderson. TCP congestion control with a misbehaving receiver. SIGCOMM CCR, October 1999.
S.萨维奇，N.卡德威尔，D.韦瑟拉尔，T.安德森。使用行为不正常的接收器进行TCP拥塞控制。SIGCOMM CCR，1999年10月。
[Schneier] Bruce Schneier. Applied Cryptography, 2nd ed., 1996
布鲁斯·施奈尔。应用密码学，第二版，1996年
This note grew out of research done by Stefan Savage, David Ely, David Wetherall, Tom Anderson and Neil Spring. We are very grateful for feedback and assistance from Sally Floyd.
这张便条出自斯特凡·萨维奇、大卫·伊利、大卫·韦瑟拉尔、汤姆·安德森和尼尔·斯普林的研究。我们非常感谢Sally Floyd的反馈和帮助。
Neil Spring EMail: nspring@cs.washington.edu
尼尔·斯普林电子邮件：nspring@cs.washington.edu
David Wetherall Department of Computer Science and Engineering, Box 352350 University of Washington Seattle WA 98195-2350 EMail: djw@cs.washington.edu
华盛顿大学计算机科学与工程学院David Wetherall Department，第352350卷西雅图华盛顿大学WA98195-250电子邮件：djw@cs.washington.edu
David Ely Computer Science and Engineering, 352350 University of Washington Seattle, WA 98195-2350 EMail: ely@cs.washington.edu
戴维伊利计算机科学与工程，352350华盛顿大学西雅图，WA98195-250电子邮件：ely@cs.washington.edu
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 assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。