Network Working Group E. Blanton
Request for Comments: 3708 Purdue University
Category: Experimental M. Allman
ICIR
February 2004
Network Working Group E. Blanton
Request for Comments: 3708 Purdue University
Category: Experimental M. Allman
ICIR
February 2004
Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions
使用TCP重复选择确认（DSACKs）和流控制传输协议（SCTP）重复传输序列号（TSN）来检测虚假重传
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 (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
TCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate Selective Acknowledgement (DSACKs) and Duplicate Transmission Sequence Number (TSN) notification, respectively. This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications.
TCP和流控制传输协议（SCTP）分别通过重复选择确认（DSACKs）和重复传输序列号（TSN）通知提供重复段接收通知。本文档介绍了使用此信息识别各种应用中不必要的重新传输的保守方法。
TCP [RFC793] and SCTP [RFC2960] provide notification of duplicate segment receipt through duplicate selective acknowledgment (DSACK) [RFC2883] and Duplicate TSN notifications, respectively. Using this information, a TCP or SCTP sender can generally determine when a retransmission was sent in error. This document presents two methods for using duplicate notifications. The first method is simple and can be used for accounting applications. The second method is a conservative algorithm to disambiguate unnecessary retransmissions from loss events for the purpose of undoing unnecessary congestion control changes.
TCP[RFC793]和SCTP[RFC2960]分别通过重复选择确认（DSACK）[RFC2883]和重复TSN通知提供重复段接收通知。使用此信息，TCP或SCTP发送方通常可以确定何时发送了错误的重传。本文档介绍了使用重复通知的两种方法。第一种方法简单，可用于会计应用。第二种方法是一种保守的算法，用于消除丢失事件中不必要的重新传输的歧义，从而取消不必要的拥塞控制更改。
This document is intended to outline reasonable and safe algorithms for detecting spurious retransmissions and discuss some of the considerations involved. It is not intended to describe the only possible method for achieving the goal, although the guidelines in this document should be taken into consideration when designing alternate algorithms. Additionally, this document does not outline what a TCP or SCTP sender may do after a spurious retransmission is detected. A number of proposals have been developed (e.g., [RFC3522], [SK03], [BDA03]), but it is not yet clear which of these proposals are appropriate. In addition, they all rely on detecting spurious retransmits and so can share the algorithm specified in this document.
本文档旨在概述用于检测虚假重传的合理和安全的算法，并讨论其中涉及的一些注意事项。虽然在设计替代算法时应考虑本文件中的指南，但本文件并不打算描述实现目标的唯一可能方法。此外，本文档并未概述TCP或SCTP发送方在检测到虚假重传后可能做的事情。已经制定了许多提案（例如，[RFC3522]、[SK03]、[BDA03]），但尚不清楚这些提案中哪些是合适的。此外，它们都依赖于检测伪重传，因此可以共享本文中指定的算法。
Finally, we note that to simplify the text much of the following discussion is in terms of TCP DSACKs, while applying to both TCP and SCTP.
最后，我们注意到，为了简化文本，下面的大部分讨论都是关于TCP数据包的，同时适用于TCP和SCTP。
Terminology
术语
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
For certain applications a straight count of duplicate notifications will suffice. For instance, if a stack simply wants to know (for some reason) the number of spuriously retransmitted segments, counting all duplicate notifications for retransmitted segments should work well. Another application of this strategy is to monitor and adapt transport algorithms so that the transport is not sending large amounts of spurious data into the network. For instance, monitoring duplicate notifications could be used by the Early Retransmit [AAAB03] algorithm to determine whether fast retransmitting [RFC2581] segments with a lower than normal duplicate ACK threshold is working, or if segment reordering is causing spurious retransmits.
对于某些应用程序，直接计数重复通知就足够了。例如，如果堆栈只是想知道（出于某种原因）错误重新传输的段的数量，那么对重新传输的段的所有重复通知进行计数应该是可行的。该策略的另一个应用是监控和调整传输算法，以便传输不会向网络发送大量虚假数据。例如，早期重传[AAAB03]算法可以使用监视重复通知来确定具有低于正常重复ACK阈值的快速重传[RFC2581]段是否工作，或者段重新排序是否导致伪重传。
More speculatively, duplicate notification has been proposed as an integral part of estimating TCP's total loss rate [AEO03] for the purposes of mitigating the impact of corruption-based losses on transport protocol performance. [EOA03] proposes altering the transport's congestion response to the fraction of losses that are actually due to congestion by requiring the network to provide the corruption-based loss rate and making the transport sender estimate the total loss rate. Duplicate notifications are a key part of estimating the total loss rate accurately [AEO03].
更具推测性的是，重复通知被提议作为估计TCP总丢失率[AEO03]的一个组成部分，以减轻基于损坏的丢失对传输协议性能的影响。[EOA03]建议通过要求网络提供基于损坏的丢失率并让传输发送方估计总丢失率，将传输的拥塞响应更改为实际由拥塞造成的损失的分数。重复通知是准确估计总损失率的关键部分[AEO03]。
When the purpose of detecting spurious retransmissions is to "undo" unnecessary changes made to the congestion control state, as suggested in [RFC2883], the data sender ideally needs to determine:
当检测虚假重传的目的是“撤销”对拥塞控制状态所做的不必要更改时，如[RFC2883]中所建议，数据发送方理想情况下需要确定：
(a) That spurious retransmissions in a particular window of data do not mask real segment loss (congestion).
(a) 在特定数据窗口中的伪重传不会掩盖实际的段丢失（拥塞）。
For example, assume segments N and N+1 are retransmitted even though only segment N was dropped by the network (thus, segment N+1 was needlessly retransmitted). When the sender receives the notification that segment N+1 arrived more than once it can conclude that segment N+1 was needlessly resent. However, it cannot conclude that it is appropriate to revert the congestion control state because the window of data contained at least one valid congestion indication (i.e., segment N was lost).
例如，假设即使网络仅丢弃了段N，也重新传输了段N和N+1（因此，段N+1被不必要地重新传输）。当发送方收到N+1段多次到达的通知时，可以断定N+1段是不必要的重新发送。然而，由于数据窗口至少包含一个有效的拥塞指示（即，段N丢失），因此不能断定恢复拥塞控制状态是合适的。
(b) That network duplication is not the cause of the duplicate notification.
(b) 网络重复不是重复通知的原因。
Determining whether a duplicate notification is caused by network duplication of a packet or a spurious retransmit is a nearly impossible task in theory. Since [Pax97] shows that packet duplication by the network is rare, the algorithm in this section simply ceases to function when network duplication is detected (by receiving a duplication notification for a segment that was not retransmitted by the sender).
从理论上讲，确定重复通知是由数据包的网络复制还是伪重传引起几乎是不可能的任务。由于[Pax97]表明网络的数据包复制很少，因此当检测到网络复制时（通过接收发送方未重新传输的数据段的复制通知），本节中的算法将停止工作。
The algorithm specified below gives reasonable, but not complete, protection against both of these cases.
下面指定的算法针对这两种情况提供了合理但不完整的保护。
We assume the TCP sender has a data structure to hold selective acknowledgment information (e.g., as outlined in [RFC3517]). The following steps require an extension of such a 'scoreboard' to incorporate a slightly longer history of retransmissions than called for in [RFC3517]. The following steps MUST be taken upon the receipt of each DSACK or duplicate TSN notification:
我们假设TCP发送方有一个数据结构来保存选择性确认信息（如[RFC3517]中所述）。以下步骤需要扩展此类“记分牌”，以包含比[RFC3517]中要求的稍长的重传历史。在收到每个DSACK或重复的TSN通知后，必须采取以下步骤：
(A) Check the corresponding sequence range or TSN to determine whether the segment has been retransmitted.
（A） 检查相应的序列范围或TSN，以确定该段是否已重新传输。
(A.1) If the SACK scoreboard is empty (i.e., the TCP sender has received no SACK information from the receiver) and the left edge of the incoming DSACK is equal to SND.UNA, processing of this DSACK MUST be terminated and the congestion control state MUST NOT be reverted during the current window of data. This clause intends to cover the
（A.1）如果SACK记分板为空（即TCP发送方未从接收方收到SACK信息），且传入DSACK的左边缘等于SND.UNA，则必须终止对该DSACK的处理，并且在当前数据窗口期间不得恢复拥塞控制状态。本条款旨在涵盖以下内容：
case when an entire window of acknowledgments have been dropped by the network. In such a case, the reverse path seems to be in a congested state and so reducing TCP's sending rate is the conservative approach.
网络删除整个确认窗口时的情况。在这种情况下，反向路径似乎处于拥塞状态，因此降低TCP的发送速率是保守的方法。
(A.2) If the segment was retransmitted exactly one time, mark it as a duplicate.
（A.2）如果该段仅重新传输了一次，则将其标记为副本。
(A.3) If the segment was retransmitted more than once processing of this DSACK MUST be terminated and the congestion control state MUST NOT be reverted to its previous state during the current window of data.
（A.3）如果段被重传不止一次，则必须终止此数据包的处理，并且在当前数据窗口期间，不得将拥塞控制状态恢复到其以前的状态。
(A.4) If the segment was not retransmitted the incoming DSACK indicates that the network duplicated the segment in question. Processing of this DSACK MUST be terminated. In addition, the algorithm specified in this document MUST NOT be used for the remainder of the connection, as future DSACK reports may be indicating network duplication rather than unnecessary retransmission. Note that some techniques to further disambiguate network duplication from unnecessary retransmission (e.g., the TCP timestamp option [RFC1323]) may be used to refine the algorithm in this document further. Using such a technique in conjunction with an algorithm similar to the one presented herein may allow for the continued use of the algorithm in the face of duplicated segments. We do not delve into such an algorithm in this document due the current rarity of network duplication. However, future work should include tackling this problem.
（A.4）如果未重新传输该段，则传入的DSACK表示网络复制了该段。必须终止对此数据包的处理。此外，本文档中指定的算法不得用于连接的其余部分，因为未来的DSACK报告可能会指示网络重复，而不是不必要的重新传输。注意，可以使用一些技术（例如，TCP时间戳选项[RFC1323]）来进一步消除网络复制与不必要的重传之间的歧义，以进一步完善本文档中的算法。将这种技术与类似于本文所述的算法结合使用可允许在重复段的情况下继续使用该算法。由于目前网络复制的罕见性，我们在本文档中不深入研究这种算法。然而，今后的工作应包括解决这一问题。
(B) Assuming processing is allowed to continue (per the (A) rules), check all retransmitted segments in the previous window of data.
（B） 假设允许继续处理（根据（A）规则），检查上一个数据窗口中所有重新传输的段。
(B.1) If all segments or chunks marked as retransmitted have also been marked as acknowledged and duplicated, we conclude that all retransmissions in the previous window of data were spurious and no loss occurred.
（B.1）如果标记为重新传输的所有段或块也被标记为已确认和重复，则我们得出结论，前一个数据窗口中的所有重新传输都是虚假的，没有发生丢失。
(B.2) If any segment or chunk is still marked as retransmitted but not marked as duplicate, there are outstanding retransmissions that could indicate loss within this window of data. We can make no conclusions based on this particular DSACK/duplicate TSN notification.
（B.2）如果任何段或块仍标记为已重新传输，但未标记为重复，则存在未完成的重新传输，这可能表明此数据窗口内的数据丢失。基于此特定的DSACK/duplicate TSN通知，我们无法得出任何结论。
In addition to keeping the state mentioned in [RFC3517] (for TCP) and [RFC2960] (for SCTP), an implementation of this algorithm must track
除了保持[RFC3517]（对于TCP）和[RFC2960]（对于SCTP）中提到的状态外，还必须跟踪此算法的实现
all sequence numbers or TSNs that have been acknowledged as duplicates.
已确认为重复的所有序列号或TSN。
In addition to the mechanism for detecting spurious retransmits outlined in this document, several other proposals for finding needless retransmits have been developed.
除了本文件中概述的用于检测虚假重传的机制外，还开发了一些用于查找不必要重传的其他建议。
[BA02] uses the algorithm outlined in this document as the basis for investigating several methods to make TCP more robust to reordered packets.
[BA02]使用本文档中概述的算法作为研究几种方法的基础，以使TCP对重新排序的数据包更具鲁棒性。
The Eifel detection algorithm [RFC3522] uses the TCP timestamp option [RFC1323] to determine whether the ACK for a given retransmit is for the original transmission or a retransmission. More generally, [LK00] outlines the benefits of detecting spurious retransmits and reverting from needless congestion control changes using the timestamp-based scheme or a mechanism that uses a "retransmit bit" to flag retransmits (and ACKs of retransmits). The Eifel detection algorithm can detect spurious retransmits more rapidly than a DSACK-based scheme. However, the tradeoff is that the overhead of the 12- byte timestamp option must be incurred in every packet transmitted for Eifel to function.
Eifel检测算法[RFC3522]使用TCP时间戳选项[RFC1323]来确定给定重传的ACK是用于原始传输还是重传。更一般而言，[LK00]概述了使用基于时间戳的方案或使用“重传位”标记重传（和重传的ack）的机制检测虚假重传和从不必要的拥塞控制更改恢复的好处。Eifel检测算法可以比基于DSACK的方案更快地检测伪重传。然而，折衷的办法是，12字节时间戳选项的开销必须在每个传输的数据包中产生，以便Eifel正常工作。
The F-RTO scheme [SK03] slightly alters TCP's sending pattern immediately following a retransmission timeout and then observes the pattern of the returning ACKs. This pattern can indicate whether the retransmitted segment was needed. The advantage of F-RTO is that the algorithm only needs to be implemented on the sender side of the TCP connection and that nothing extra needs to cross the network (e.g., DSACKs, timestamps, special flags, etc.). The downside is that the algorithm is a heuristic that can be confused by network pathologies (e.g., duplication or reordering of key packets). Finally, note that F-RTO only works for spurious retransmits triggered by the transport's retransmission timer.
F-RTO方案[SK03]在重传超时后立即略微改变TCP的发送模式，然后观察返回ACK的模式。此模式可以指示是否需要重新传输的段。F-RTO的优点是，该算法只需要在TCP连接的发送方实现，不需要跨网络执行任何额外操作（例如，数据包、时间戳、特殊标志等）。缺点是该算法是一种启发式算法，可能会被网络病理（例如，密钥包的复制或重新排序）所混淆。最后，请注意，F-RTO仅适用于由传输的重传计时器触发的伪重传。
Finally, [AP99] briefly investigates using the time between retransmitting a segment via the retransmission timeout and the arrival of the next ACK as an indicator of whether the retransmit was needed. The scheme compares this time delta with a fraction (f) of the minimum RTT observed thus far on the connection. If the time delta is less than f*minRTT then the retransmit is labeled spurious. When f=1/2 the algorithm identifies roughly 59% of the needless retransmission timeouts and identifies needed retransmits only 2.5% of the time. As with F-RTO, this scheme only detects spurious retransmits sent by the transport's retransmission timer.
最后，[AP99]简要地研究了使用通过重传超时重传一个段和到达下一个ACK之间的时间作为是否需要重传的指示器。该方案将该时间增量与迄今为止在连接上观察到的最小RTT的分数（f）进行比较。如果时间增量小于f*minRTT，则重传被标记为伪。当f=1/2时，该算法识别出大约59%的不必要的重传超时，并且仅识别出2.5%的需要的重传超时。与F-RTO一样，该方案仅检测由传输的重传计时器发送的虚假重传。
It is possible for the receiver to falsely indicate spurious retransmissions in the case of actual loss, potentially causing a TCP or SCTP sender to inaccurately conclude that no loss took place (and possibly cause inappropriate changes to the senders congestion control state).
在实际丢失的情况下，接收机可能错误地指示虚假的重新传输，这可能导致TCP或SCTP发送方错误地得出没有发生丢失的结论（并且可能导致发送方拥塞控制状态的不适当改变）。
Consider the following scenario: A receiver watches every segment or chunk that arrives and acknowledges any segment that arrives out of order by more than some threshold amount as a duplicate, assuming that it is a retransmission. A sender using the above algorithm will assume that the retransmission was spurious.
考虑下面的场景：接收者观察到达的每一个段或块，并确认任何超出顺序的超过一个阈值的段作为一个副本，假设它是重传。使用上述算法的发送方将假定重传是虚假的。
The ECN nonce sum proposal [RFC3540] could possibly help mitigate the ability of the receiver to hide real losses from the sender with modest extension. In the common case of receiving an original transmission and a spurious retransmit a receiver will have received the nonce from the original transmission and therefore can "prove" to the sender that the duplication notification is valid. In the case when the receiver did not receive the original and is trying to improperly induce the sender into transmitting at an inappropriately high rate, the receiver will not know the ECN nonce from the original segment and therefore will probabilistically not be able to fool the sender for long. [RFC3540] calls for disabling nonce sums on duplicate ACKs, which means that the nonce sum is not directly suitable for use as a mitigation to the problem of receivers lying about DSACK information. However, future efforts may be able to use [RFC3540] as a starting point for building protection should it be needed.
ECN当前和建议[RFC3540]可能有助于减轻接收方通过适度扩展向发送方隐藏实际损失的能力。在接收原始传输和伪重传的常见情况下，接收机将已经从原始传输接收到nonce，因此可以向发送方“证明”复制通知是有效的。在接收机没有接收到原始数据并且试图不适当地诱导发送方以不适当的高速率进行传输的情况下，接收机将不知道来自原始段的ECN时刻，因此很可能无法长时间欺骗发送方。[RFC3540]要求禁用重复ack上的nonce sum，这意味着nonce sum不直接适用于缓解接收器谎报DSACK信息的问题。但是，如果需要，未来的工作可能会将[RFC3540]用作建筑物保护的起点。
Sourabh Ladha and Reiner Ludwig made several useful comments on an earlier version of this document. The second author thanks BBN Technologies and NASA's Glenn Research Center for supporting this work.
Sourabh Ladha和Reiner Ludwig对本文件的早期版本发表了几点有用的评论。第二作者感谢BBN技术公司和美国宇航局格伦研究中心对这项工作的支持。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[RFC2883]Floyd，S.，Mahdavi，J.，Mathis，M.和M.Podolsky，“TCP选择性确认（SACK）选项的扩展”，RFC 28832000年7月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[AAAB03] Allman, M., Avrachenkov, K., Ayesta, U. and J. Blanton, "Early Retransmit for TCP", Work in Progress, June 2003.
[AAAB03]Allman，M.，Avrachenkov，K.，Ayesta，U.和J.Blanton，“TCP的早期重传”，正在进行的工作，2003年6月。
[AEO03] Allman, M., Eddy, E. and S. Ostermann, "Estimating Loss Rates With TCP", Work in Progress, August 2003.
[AEO03]Allman，M.，Eddy，E.和S.Ostermann，“使用TCP估算损失率”，正在进行的工作，2003年8月。
[AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM 99.
[AP99]Allman，M.和V.Paxson，“关于估算端到端网络路径属性”，SIGCOMM 99。
[BA02] Blanton, E. and M. Allman. On Making TCP More Robust to Packet Reordering. ACM Computer Communication Review, 32(1), January 2002.
[BA02]布兰顿，E.和M.奥尔曼。使TCP对数据包重新排序更具鲁棒性。ACM计算机通信评论，32（1），2002年1月。
[BDA03] Blanton, E., Dimond, R. and M. Allman, "Practices for TCP Senders in the Face of Segment Reordering", Work in Progress, February 2003.
[BDA03]Blanton，E.，Dimond，R.和M.Allman，“TCP发送者面对段重新排序的实践”，正在进行的工作，2003年2月。
[EOA03] Eddy, W., Ostermann, S. and M. Allman, "New Techniques for Making Transport Protocols Robust to Corruption-Based Loss", Work in Progress, July 2003.
[EOA03]Eddy，W.，Ostermann，S.和M.Allman，“使传输协议对基于腐败的丢失具有鲁棒性的新技术”，正在进行的工作，2003年7月。
[LK00] R. Ludwig, R. H. Katz. The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions. ACM Computer Communication Review, 30(1), January 2000.
[LK00]R.路德维希，R.H.卡茨。Eifel算法：使TCP对伪重传具有鲁棒性。ACM计算机通信评论，30（1），2000年1月。
[Pax97] V. Paxson. End-to-End Internet Packet Dynamics. In ACM SIGCOMM, September 1997.
[Pax97]V.帕克森。端到端Internet数据包动态。在ACM SIGCOMM，1997年9月。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，R.和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[RFC3517] Blanton, E., Allman, M., Fall, K. and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC3517]Blanton，E.，Allman，M.，Fall，K.和L.Wang，“基于保守选择确认（SACK）的TCP丢失恢复算法”，RFC 3517，2003年4月。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP," RFC 3522, April 2003.
[RFC3522]Ludwig，R.和M.Meyer，“TCP的Eifel检测算法”，RFC 3522，2003年4月。
[RFC3540] Spring, N., Wetherall, D. and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540]Spring，N.，Weterral，D.和D.Ely，“带有nonce的鲁棒显式拥塞通知（ECN）信令”，RFC 35402003年6月。
[SK03] Sarolahti, P. and M. Kojo, "F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP", Work in Progress, June 2003.
[SK03]Sarolahti，P.和M.Kojo，“F-RTO：使用TCP和SCTP检测虚假重传超时的算法”，正在进行的工作，2003年6月。
Ethan Blanton Purdue University Computer Sciences 1398 Computer Science Building West Lafayette, IN 47907
伊桑·布兰顿·普渡大学计算机科学1398计算机科学大楼西拉斐特，47907年
EMail: eblanton@cs.purdue.edu
EMail: eblanton@cs.purdue.edu
Mark Allman ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704-1198 Phone: 216-243-7361
Mark Allman ICSI互联网研究中心1947加利福尼亚州伯克利中心街600室94704-1198电话：216-243-7361
EMail: mallman@icir.org
http://www.icir.org/mallman/
EMail: mallman@icir.org
http://www.icir.org/mallman/
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。