[要約] RFC 7786は、Congestion Exposure（ConEx）のためのTCPの修正に関するものであり、TCPの拡張機能を提供して、ネットワークの過負荷状態を検出し、制御することを目的としています。
Internet Engineering Task Force (IETF) M. Kuehlewind, Ed.
Request for Comments: 7786 ETH Zurich
Category: Experimental R. Scheffenegger
ISSN: 2070-1721 NetApp, Inc.
May 2016
TCP Modifications for Congestion Exposure (ConEx)
輻輳露出（ConEx）のTCP変更
Abstract
概要
Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP).
Congestion Exposure（ConEx）は、同じフロー内の以前のパケットからの輻輳フィードバックに基づいて、送信者が予想される輻輳についてネットワークに通知するメカニズムです。このドキュメントでは、伝送制御プロトコル（TCP）でConExを使用するために必要な変更について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7786.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7786で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Sender-Side Modifications . . . . . . . . . . . . . . . . . . 4
3. Counting Congestion . . . . . . . . . . . . . . . . . . . . . 5
3.1. Loss Detection . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Without SACK Support . . . . . . . . . . . . . . . . 7
3.2. Explicit Congestion Notification (ECN) . . . . . . . . . 8
3.2.1. Accurate ECN Feedback . . . . . . . . . . . . . . . . 10
3.2.2. Classic ECN Support . . . . . . . . . . . . . . . . . 10
4. Setting the ConEx Flags . . . . . . . . . . . . . . . . . . . 11
4.1. Setting the E or the L Flag . . . . . . . . . . . . . . . 11
4.2. Setting the Credit Flag . . . . . . . . . . . . . . . . . 11
5. Loss of ConEx Information . . . . . . . . . . . . . . . . . . 14
6. Timeliness of the ConEx Signals . . . . . . . . . . . . . . . 14
7. Open Areas for Experimentation . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. ConEx concepts and use cases are further explained in [RFC6789]. The abstract ConEx mechanism is explained in [RFC7713]. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP).
Congestion Exposure（ConEx）は、同じフロー内の以前のパケットからの輻輳フィードバックに基づいて、送信者が予想される輻輳についてネットワークに通知するメカニズムです。 ConExの概念と使用例は、[RFC6789]でさらに説明されています。抽象的なConExメカニズムは[RFC7713]で説明されています。このドキュメントでは、伝送制御プロトコル（TCP）でConExを使用するために必要な変更について説明します。
The markings for ConEx signaling are defined in the ConEx Destination Option (CDO) for IPv6 [RFC7837]. Specifically, the use of four flags is defined: X (ConEx-capable), L (loss experienced), E (ECN experienced), and C (credit).
ConExシグナリングのマーキングは、IPv6のConEx宛先オプション（CDO）で定義されています[RFC7837]。具体的には、X（ConEx対応）、L（損失経験）、E（ECN経験）、C（クレジット）の4つのフラグの使用が定義されています。
ConEx signaling is based on the use of either loss or Explicit Congestion Notification (ECN) marks [RFC3168] as congestion indication. The sender collects this congestion information based on existing TCP feedback mechanisms from the receiver to the sender. No changes are needed at the receiver side to implement ConEx signaling. Therefore, no additional negotiation is needed to implement and use ConEx at the sender side. This document specifies the sender's actions that are needed to provide meaningful ConEx information to the network.
ConExシグナリングは、損失または明示的輻輳通知（ECN）マーク[RFC3168]を輻輳表示として使用することに基づいています。送信者は、受信者から送信者への既存のTCPフィードバックメカニズムに基づいて、この輻輳情報を収集します。 ConExシグナリングを実装するために、受信側で変更を行う必要はありません。したがって、送信側でConExを実装して使用するために追加のネゴシエーションは必要ありません。このドキュメントでは、意味のあるConEx情報をネットワークに提供するために必要な送信者のアクションを指定します。
Section 2 provides an overview of the modifications needed for TCP senders to implement ConEx. First, congestion information has to be extracted from TCP's loss or ECN feedback as described in Section 3. Section 4 details how to set the CDO marking based on this congestion information. Section 5 discusses the loss of packets carrying ConEx information. Section 6 discusses the timeliness of the ConEx feedback signal, given that congestion is a temporary state.
セクション2では、TCP送信者がConExを実装するために必要な変更の概要を説明します。まず、セクション3で説明されているように、TCPの損失またはECNフィードバックから輻輳情報を抽出する必要があります。セクション4では、この輻輳情報に基づいてCDOマーキングを設定する方法を詳しく説明します。セクション5では、ConEx情報を含むパケットの損失について説明します。セクション6では、輻輳が一時的な状態であると仮定して、ConExフィードバック信号の適時性について説明します。
This document describes congestion accounting for TCP with and without the Selective Acknowledgement (SACK) extension [RFC2018] (in Section 3.1). However, ConEx benefits from the more accurate information that SACK provides about the number of bytes dropped in the network, and it is therefore preferable to use the SACK extension when using TCP with ConEx. The detailed mechanism to set the L flag in response to the loss-based congestion feedback signal is given in Section 4.1.
このドキュメントでは、選択的確認応答（SACK）拡張[RFC2018]を使用する場合と使用しない場合のTCPの輻輳アカウンティングについて説明します（セクション3.1）。ただし、ConExは、ネットワークでドロップされたバイト数についてSACKが提供するより正確な情報の恩恵を受けるため、ConExでTCPを使用する場合はSACK拡張を使用することが推奨されます。損失ベースの輻輳フィードバック信号に応答してLフラグを設定する詳細なメカニズムについては、セクション4.1で説明します。
While loss has to be minimized, ECN can provide more fine-grained feedback information. ConEx-based traffic measurement or management mechanisms could benefit from this. Unfortunately, the current ECN feedback mechanism does not reflect multiple congestion markings if they occur within the same Round-Trip Time (RTT). A more accurate feedback extension to ECN (AccECN) is proposed in a separate document [ACCURATE], as this is also useful for other mechanisms.
損失を最小限に抑える必要がありますが、ECNはより詳細なフィードバック情報を提供できます。 ConExベースのトラフィック測定または管理メカニズムは、この恩恵を受けることができます。残念ながら、現在のECNフィードバックメカニズムは、同じ往復時間（RTT）内で発生した場合、複数の輻輳マークを反映しません。 ECN（AccECN）へのより正確なフィードバック拡張機能は、別のドキュメント[ACCURATE]で提案されています。これは他のメカニズムにも役立ちます。
Congestion accounting for both classic ECN feedback and AccECN feedback is explained in detail in Section 3.2. Setting the E flag in response to ECN-based congestion feedback is again detailed in Section 4.1.
従来のECNフィードバックとAccECNフィードバックの両方を考慮した輻輳については、セクション3.2で詳しく説明しています。 ECNベースの輻輳フィードバックに応じてEフラグを設定する方法については、セクション4.1で詳しく説明します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This section gives an overview of actions that need to be taken by a TCP sender modified to use ConEx signaling.
このセクションでは、ConExシグナリングを使用するように変更されたTCP送信者が実行する必要があるアクションの概要を示します。
In the TCP handshake, a ConEx sender MUST negotiate for SACK and ECN preferably with AccECN feedback. Therefore, a ConEx sender MUST also implement SACK and ECN. Depending on the capability of the receiver, the following operation modes exist:
TCPハンドシェイクでは、ConEx送信者は、SACKおよびECNについて、できればAccECNフィードバックを使用してネゴシエートする必要があります。したがって、ConEx送信者はSACKとECNも実装する必要があります。レシーバーの機能に応じて、以下の操作モードが存在します。
o SACK-accECN-ConEx (SACK and accurate ECN feedback)
o SACK-accECN-ConEx（SACKおよび正確なECNフィードバック）
o SACK-ECN-ConEx (SACK and classic instead of accurate ECN)
o SACK-ECN-ConEx（正確なECNではなくSACKおよびクラシック）
o accECN-ConEx (no SACK but accurate ECN feedback)
o acc ECN-ConEx（SACはないが正確なECNフィードバック）
o ECN-ConEx (no SACK and no accurate ECN feedback, but classic ECN)
o ECN-ConEx（SACKおよび正確なECNフィードバックはありませんが、従来のECN）
o SACK-ConEx (SACK but no ECN at all)
o SACK-ConEx（SACKですが、ECNはまったくありません）
o Basic-ConEx (neither SACK nor ECN)
o Basic-ConEx（SACKでもECNでもない）
A ConEx sender MUST expose all congestion information to the network according to the congestion information received by ECN or based on loss information provided by the TCP feedback loop. A TCP sender SHOULD count congestion byte-wise (rather than packet-wise; see next paragraph). After any congestion notification, a sender MUST mark subsequent packets with the appropriate ConEx flag in the IP header. Furthermore, a ConEx sender must send enough credit to cover all experienced congestion for the connection so far, as well as the risk of congestion for the current transmission (see Section 4.2).
ConEx送信者は、ECNによって受信された輻輳情報に従って、またはTCPフィードバックループによって提供された損失情報に基づいて、すべての輻輳情報をネットワークに公開する必要があります。 TCP送信者は、パケット単位ではなくバイト単位で輻輳をカウントする必要があります（次の段落を参照）。輻輳通知の後、送信者はIPヘッダーの適切なConExフラグで後続のパケットをマークする必要があります。さらに、ConEx送信者は、これまでに接続で発生したすべての輻輳と、現在の送信での輻輳のリスクをカバーするのに十分なクレジットを送信する必要があります（セクション4.2を参照）。
With SACK the number of lost payload bytes is known, but not the number of packets carrying these bytes. With classic ECN only an indication is given that a marking occurred, but not the exact number of payload bytes nor packets. As network congestion is usually byte-congestion [RFC7141], the byte-size of a packet marked with a CDO flag is defined to represent that number of bytes of congestion signaling [RFC7837]. Therefore, the exact number of bytes should be taken into account, if available, to make the ConEx Signal as exact as possible.
SACKでは、失われたペイロードバイトの数はわかりますが、これらのバイトを運ぶパケットの数はわかりません。従来のECNでは、マーキングが発生したことだけが示されますが、ペイロードバイトやパケットの正確な数は示されません。ネットワークの輻輳は通常バイト輻輳[RFC7141]であるため、CDOフラグでマークされたパケットのバイトサイズは、輻輳シグナリングのそのバイト数を表すように定義されます[RFC7837]。したがって、可能な場合は、正確なバイト数を考慮して、ConEx信号を可能な限り正確にする必要があります。
Detailed mechanisms for congestion counting in each operation mode are described in the next section.
各動作モードでの輻輳カウントの詳細なメカニズムについては、次のセクションで説明します。
A ConEx TCP sender maintains two counters: one that counts congestion based on the information retrieved by loss detection, and a second that accounts for ECN-based congestion feedback. These counters hold the number of outstanding bytes that should be ConEx-Marked with, respectively, the E flag or the L flag in subsequent packets.
ConEx TCP送信者は2つのカウンターを維持します。1つは損失検出によって取得された情報に基づいて輻輳をカウントし、もう1つはECNベースの輻輳フィードバックを考慮します。これらのカウンターは、それぞれ後続のパケットのEフラグまたはLフラグでConExマークを付ける必要がある未処理のバイト数を保持します。
The outstanding bytes for congestion indications based on loss are maintained in the Loss Exposure Gauge (LEG), as explained in Section 3.1.
セクション3.1で説明されているように、損失に基づく輻輳表示の未処理バイトは、損失露出ゲージ（LEG）で維持されます。
The outstanding bytes counted based on ECN feedback information are maintained in the Congestion Exposure Gauge (CEG), as explained in Section 3.2.
セクション3.2で説明されているように、ECNフィードバック情報に基づいてカウントされた未処理のバイトは、輻輳露出ゲージ（CEG）に保持されます。
When the sender sends a ConEx-capable packet with the E or L flag set, it reduces the respective counter by the byte-size of the packet. This is explained for both counters in Section 4.1.
送信者がEまたはLフラグが設定されたConEx対応パケットを送信すると、パケットのバイトサイズによってそれぞれのカウンターが減少します。これについては、セクション4.1で両方のカウンタについて説明しています。
Note that all bytes of an IP packet must be counted in the LEG or CEG to capture the right number of bytes that should be marked. Therefore, the sender SHOULD take the payload and headers into account, up to and including the IP header. However, in TCP the information regarding how large the headers of a lost or marked packet were is usually not available, as only payload data will be acknowledged.
マークする必要のある正しいバイト数をキャプチャするには、LEGまたはCEGでIPパケットのすべてのバイトをカウントする必要があることに注意してください。したがって、送信者は、IPヘッダーまでのペイロードとヘッダーを考慮する必要があります（SHOULD）。ただし、TCPでは、ペイロードデータのみが確認応答されるため、失われたパケットまたはマークされたパケットのヘッダーの大きさに関する情報は通常利用できません。
If equal-sized packets, or at least equally distributed packet sizes, can be assumed, the sender MAY only add and subtract TCP payload bytes. In this case, there should be about the same number of ConEx-Marked packets as the original packets that were causing the congestion. Thus, both contain about the same number of header bytes so they will cancel out. This case is assumed for simplicity in the following sections.
等しいサイズのパケット、または少なくとも均等に分散されたパケットサイズを想定できる場合、送信者はTCPペイロードバイトのみを加算および減算できます（MAY）。この場合、輻輳を引き起こしていた元のパケットとほぼ同じ数のConEx-Markedパケットが存在するはずです。したがって、両方ともほぼ同じ数のヘッダーバイトを含んでいるため、キャンセルされます。このケースは、以降のセクションでは簡単にするために想定されています。
Otherwise, if a sender sends different sized packets (with unequally distributed packet sizes), the sender needs to memorize or estimate the number of lost or ECN-marked packets. If the sender has sufficient memory available, the most accurate way to reconstruct the number of lost or marked packets is to remember the sequence number of all sent but not acknowledged packets. In this case, a sender is able to reconstruct the number of packets, and thus the header bytes that were sent during the last RTT. Otherwise (e.g., if not enough memory is available), the sender would need to estimate the packet size. The average packet size can be estimated if the distribution pattern of packet sizes in the last RTT is known; alternatively, the minimum packet size seen in the last RTT can be used as the most conservative estimate.
それ以外の場合、送信者が異なるサイズのパケットを送信すると（パケットサイズが不均等に分散されます）、送信者は、失われたパケットまたはECNでマークされたパケットの数を記憶または推定する必要があります。送信側に十分なメモリがある場合、失われたパケットまたはマークされたパケットの数を再構築する最も正確な方法は、すべての送信されたが確認応答されていないパケットのシーケンス番号を覚えておくことです。この場合、送信者はパケット数を再構築でき、最後のRTT中に送信されたヘッダーバイトを再構築できます。それ以外の場合（たとえば、十分なメモリが利用できない場合）、送信者はパケットサイズを推定する必要があります。最後のRTTでのパケットサイズの分散パターンがわかっている場合、平均パケットサイズを推定できます。または、最後のRTTで確認された最小パケットサイズを最も控えめな推定値として使用できます。
If the number of newly sent-out packets with the ConEx L or E flag set is smaller (or larger) than this estimated number of lost/ECN-marked packets, the additional header bytes should be added to (or can be subtracted from) the respective gauge.
ConEx LまたはEフラグが設定された新しく送信されたパケットの数が、この失われた/ ECNマークの付いたパケットの推定数よりも少ない（または多い）場合は、追加のヘッダーバイトを追加する（または差し引くことができる）それぞれのゲージ。
This section applies whether or not SACK support is available. The following subsection (Section 3.1.1) handles the case when SACK is not available.
このセクションは、SACKサポートが利用可能かどうかに関係なく適用されます。次のサブセクション（セクション3.1.1）は、SACKが使用できない場合の処理です。
A TCP sender detects losses and subsequently retransmits the lost data. Therefore, the ConEx sender can simply set the ConEx L flag on all retransmissions in order to at least cover the amount of bytes lost. If this approach is taken, no LEG is needed.
TCP送信側は損失を検出し、その後、失われたデータを再送信します。したがって、ConEx送信側は、失われたバイト量を少なくともカバーするために、すべての再送信にConEx Lフラグを設定するだけで済みます。このアプローチを採用する場合、LEGは必要ありません。
However, any retransmission may be spurious. In this case, more bytes have been marked than necessary. To compensate for this effect, a ConEx sender can maintain a local signed counter (the LEG) that indicates the number of outstanding bytes to be sent with the ConEx L flag and also can become negative.
ただし、再送信は偽である可能性があります。この場合、必要以上のバイトがマークされています。この影響を補うために、ConEx送信者は、ConEx Lフラグで送信される未処理のバイト数を示すローカルの署名済みカウンター（LEG）を維持でき、負になることもあります。
Using the LEG, when a TCP sender decides that a data segment needs to be retransmitted, it will increase the LEG by the size of the TCP payload bytes in the retransmission (assuming equal sized segments such that the retransmitted packet will have the same number of header bytes as the original ones):
LEGを使用して、TCP送信者がデータセグメントを再送信する必要があると判断すると、再送信のTCPペイロードバイトのサイズだけLEGを増やします（再送信されるパケットが同じ数になるように、同じサイズのセグメントを想定）元のヘッダーバイト）：
For each retransmission:
再送信ごとに：
LEG += payload
LEG + =ペイロード
Note how the LEG is reduced when the ConEx L marking is set as described in Section 4.
セクション4で説明されているようにConEx Lマーキングが設定されている場合、LEGがどのように減少するかに注意してください。
Further, to accommodate spurious retransmissions, a ConEx sender SHOULD make use of heuristics to detect such spurious retransmissions (e.g., F-RTO [RFC5682], DSACK [RFC3708], and Eifel [RFC3522], [RFC4015]), if already available in a given implementation. If no mechanism for detecting spurious retransmissions is available, the ConEx sender MAY chose to implement one of the mechanisms stated above. However, given the inaccuracy that ConEx may have anyway and the timeliness of ConEx information, a ConEx MAY also chose not to compensate for spurious retransmission. In this case, if spurious retransmissions occur, the ConEx sender has simply sent too many ConEx Signals which, e.g., would decrease the congestion allowance in a ConEx policer unnecessarily.
さらに、偽の再送信に対応するために、ConEx送信者は、そのような偽の再送信（F-RTO [RFC5682]、DSACK [RFC3708]、Eifel [RFC3522]、[RFC4015]など）をすでに発見している場合は、発見的手法を使用して検出する必要があります（SHOULD）。特定の実装。偽の再送信を検出するメカニズムが利用できない場合、ConEx送信者は上記のメカニズムの1つを実装することを選択してもよい（MAY）。ただし、とにかくConExが持つ可能性のある不正確さとConEx情報の適時性を考慮して、ConExは偽の再送信を補償しないことも選択できます（MAY）。この場合、偽の再送信が発生した場合、ConEx送信者は単にConEx信号を送信しすぎたため、たとえば、ConExポリサーでの輻輳許容量が不必要に減少します。
If a heuristic method is used to detect spurious retransmission and has determined that a certain number of packets were retransmitted erroneously, the ConEx sender subtracts the payload size of these TCP packets from LEG.
ヒューリスティックな方法を使用して偽の再送信を検出し、特定の数のパケットが誤って再送信されたと判断した場合、ConEx送信者はこれらのTCPパケットのペイロードサイズをLEGから差し引きます。
If a spurious retransmission is detected:
偽の再送信が検出された場合：
LEG -= payload
LEG-=ペイロード
Note that LEG can become negative if too many L markings have already been sent. This case is further discussed in Section 6.
送信されたLマーキングが多すぎると、LEGがネガティブになる可能性があることに注意してください。このケースについては、セクション6でさらに説明します。
If multiple losses occur within one RTT and SACK is not used, it may take several RTTs until all lost data is retransmitted. With the scheme described above, the ConEx information will be delayed considerably, but timeliness is important for ConEx. For ConEx, it is important to know how much data was lost; it is not important to know what data is lost. During the first RTT after the initial loss detection, the amount of received data, and thus also the amount of lost data, can be estimated based on the number of received ACKs.
1つのRTT内で複数の損失が発生し、SACKが使用されない場合、失われたすべてのデータが再送信されるまで、いくつかのRTTがかかる場合があります。上記のスキームでは、ConEx情報はかなり遅れますが、適時性はConExにとって重要です。 ConExの場合、失われたデータの量を知ることが重要です。どのデータが失われたかを知ることは重要ではありません。最初の損失検出後の最初のRTT中に、受信されたACKの数に基づいて、受信されたデータの量、したがって失われたデータの量も推定できます。
Therefore, a ConEx sender can use the following algorithm to estimated the number of lost bytes with an additional delay of one RTT using an additional Loss Estimation Counter (LEC):
したがって、ConEx送信者は、次のアルゴリズムを使用して、追加のLoss Estimation Counter（LEC）を使用し、1つのRTTの遅延で失われたバイト数を推定できます。
flight_bytes: current flight size in bytes retransmit_bytes: payload size of the retransmission At the first retransmission in a congestion event, LEC is set:
flight_bytes：現在のフライトサイズ（バイト単位）retransmit_bytes：再送信のペイロードサイズ輻輳イベントでの最初の再送信時に、LECが設定されます。
LEC = flight_bytes - 3*SMSS
(At this point in the transmission, in the worst case, all packets in flight minus three that triggered the dupACks could have been lost.)
（送信のこの時点で、最悪の場合、dupACksをトリガーした3を引いた飛行中のすべてのパケットが失われた可能性があります。）
Then, during the first RTT of the congestion event:
次に、輻輳イベントの最初のRTTの間に：
For each retransmission:
LEG += retransmit_bytes
LEC -= retransmit_bytes
For each ACK: LEC -= SMSS
各ACKに対して：LEC-= SMSS
After one RTT:
1つのRTTの後：
LEG += LEC
LEG + = LEC
(The LEC now estimates the number of outstanding bytes that should be ConEx L-marked.)
（LECは、ConEx Lマークを付ける必要がある未処理のバイト数を推定します。）
After the first RTT for each following retransmissions:
次の再送信ごとの最初のRTTの後：
if (LEC > 0): LEC -= retransmit_bytes
else if (LEC==0): LEG += retransmit_bytes
if (LEC < 0): LEG += -LEC
(The LEG is not increased for those bytes that were already counted.)
（LEGは、すでにカウントされているバイトについては増加しません。）
ECN [RFC3168] is an IP/TCP mechanism that allows network nodes to mark packets with the Congestion Experienced (CE) mark instead of dropping them when congestion occurs.
ECN [RFC3168]は、ネットワークノードが輻輳の発生時にパケットをドロップするのではなく、輻輳経験（CE）マークでパケットをマークできるようにするIP / TCPメカニズムです。
A receiver might support classic ECN, the more accurate ECN feedback scheme (AccECN), or neither. In the case that ECN is not supported for a connection, of course no ECN marks will occur; thus, the sender will never set the E flag. Otherwise, a ConEx sender needs to maintain a signed counter, the Congestion Exposure Gauge (CEG), for the number of outstanding bytes that have to be ConEx-Marked with the E flag.
レシーバーは、クラシックECN、より正確なECNフィードバック方式（AccECN）、またはどちらもサポートしない場合があります。接続でECNがサポートされていない場合、もちろんECNマークは発生しません。したがって、送信者はEフラグを設定しません。それ以外の場合、ConEx送信者は、EフラグでConExマークを付ける必要がある未処理のバイト数に対して、署名済みカウンターであるCongestion Exposure Gauge（CEG）を維持する必要があります。
The CEG is increased when ECN information is received from an ECN-capable receiver supporting the classic ECN scheme or the accurate ECN feedback scheme. When the ConEx sender receives an ACK indicating one or more segments were received with a CE mark, CEG is increased by the appropriate number of bytes as described further below.
クラシックECNスキームまたは正確なECNフィードバックスキームをサポートするECN対応レシーバーからECN情報を受信すると、CEGが増加します。 ConEx送信者が1つ以上のセグメントがCEマーク付きで受信されたことを示すACKを受信すると、CEGは、以下でさらに説明するように、適切なバイト数だけ増加します。
Unfortunately, in case of duplicate acknowledgements, the number of newly acknowledged bytes will be zero even though (CE-marked) data has been received. Therefore, we increase the CEG by DeliveredData, as defined below:
残念ながら、確認応答が重複している場合、（CEマーク付きの）データを受信しても、新しく確認応答されたバイト数はゼロになります。したがって、以下に定義するように、DeliveredDataだけCEGを増やします。
DeliveredData = acked_bytes + SACK_diff + (is_dup)*1SMSS -
(is_after_dup)*num_dup*1SMSS
DeliveredData covers the number of bytes that has been newly delivered to the receiver. Therefore, on each arrival of an ACK, DeliveredData will be increased by the newly acknowledged bytes (acked_bytes) as indicated by the current ACK, relative to all past ACKs. The formula depends on whether SACK is available: if SACK is not available, SACK_diff is always zero, whereas if ACK information is available, is_dup and is_after_dup are always zero.
DeliveredDataは、レシーバーに新たに配信されたバイト数をカバーします。したがって、ACKが到着するたびに、過去のすべてのACKと比較して、現在のACKで示されるように、DeliveredDataが新しく確認応答されたバイト（acked_bytes）だけ増加します。式は、SACKが使用可能かどうかによって異なります。SACKが使用できない場合、SACK_diffは常にゼロですが、ACK情報が使用可能な場合、is_dupとis_after_dupは常にゼロです。
With SACK, DeliveredData is increased by the number of bytes provided by (new) SACK information (SACK_diff). Note that if less unacknowledged bytes are announced in the new SACK information than in the previous ACK, SACK_diff can be negative. In this case, data is newly acknowledged (in acked_bytes) that was previously accumulated into DeliveredData, based on SACK information.
SACKでは、DeliveredDataは（新しい）SACK情報（SACK_diff）によって提供されるバイト数だけ増加します。新しいSACK情報でアナウンスされていないバイトが以前のACKよりも少ない場合、SACK_diffは負になる可能性があることに注意してください。この場合、SACK情報に基づいて、以前にDeliveredDataに蓄積されたデータが（acked_bytesで）新たに確認されます。
Otherwise without SACK, DeliveredData is increased by 1 Sender Maximum Segment Size (SMSS) on duplicate acknowledgements because duplicate acknowledgements do not acknowledge any new data (and acked_bytes will be zero). For the subsequent partial or full ACK, acked_bytes cover all newly acknowledged bytes including those already accounted for with the receipt of any duplicate acknowledgement. Therefore, DeliveredData is reduced by one SMSS for each preceding duplicate ACK. Consequently, is_dup is one if the current ACK is a duplicated ACK without SACK, and zero otherwise. is_after_dup is only one for the next full or partial ACK after a number of duplicated ACKs without SACK and num_dup counts the number of duplicated ACKs in a row (which usually is 3 or more).
それ以外の場合、SACKを使用しないと、重複した確認応答は新しいデータを確認しないため（acked_bytesはゼロになるため）、重複した確認応答でDeliveredDataが1送信者最大セグメントサイズ（SMSS）ずつ増加します。後続の部分的または完全なACKの場合、acked_bytesは、重複する確認応答の受信ですでに説明されているバイトを含む、新しく確認されたすべてのバイトをカバーします。したがって、DeliveredDataは、先行する重複するACKごとにSMSSが1つ減ります。したがって、現在のACKがSACKなしの重複ACKである場合、is_dupは1であり、それ以外の場合は0です。 is_after_dupは、SACKなしの重複したACKの数の後の次の完全または部分的なACKの1つだけであり、num_dupは行内の重複したACKの数（通常は3以上）をカウントします。
With classic ECN, one congestion-marked packet causes continuous congestion feedback for a whole round trip, thus hiding the arrival of any further congestion-marked packets during that round trip. A more accurate ECN feedback scheme (AccECN) is needed to ensure that feedback properly reflects the extent of congestion marking. The two cases, with and without a receiver capable of AccECN, are discussed in the following sections.
従来のECNでは、1つの輻輳マーク付きパケットにより、ラウンドトリップ全体で継続的な輻輳フィードバックが発生するため、そのラウンドトリップ中にさらに輻輳マーク付きパケットが到着することはありません。フィードバックが輻輳マーキングの範囲を適切に反映するようにするには、より正確なECNフィードバックスキーム（AccECN）が必要です。 AccECN対応の受信機がある場合とない場合の2つのケースについて、次のセクションで説明します。
With a more accurate ECN feedback scheme (AccECN) that is supported by the receiver, either the number of marked packets or the number of marked bytes will be fed back from the receiver to the sender and, therefore is known at the sender side. In the latter case, the CEG can be increased directly by the number of marked bytes. Otherwise if D is assumed to be the number of marks, the gauge (CEG) will be conservatively increased by one SMSS for each marking or, at the maximum, the number of newly acknowledged bytes:
レシーバーでサポートされているより正確なECNフィードバックスキーム（AccECN）を使用すると、マークされたパケット数またはマークされたバイト数がレシーバーからセンダーにフィードバックされるため、センダー側で認識されます。後者の場合、マークされたバイト数によってCEGを直接増やすことができます。それ以外の場合、Dがマークの数であると想定される場合、ゲージ（CEG）は、各マークに対して1 SMSS、または最大で、新しく確認されたバイト数によって控えめに増加します。
CEG += min(SMSS*D, DeliveredData)
With classic ECN, as soon as a CE mark is seen at the receiver side, it will feed this information back to the sender by setting the Echo Congestion Experienced (ECE) flag in the TCP header of subsequent ACKs. Once the sender receives the first ECE of a congestion notification, it sets the Congestion Window Reduced (CWR) flag in the TCP header once. When this packet with the CWR flag in the TCP header arrives at the receiver side acknowledging its first ECE feedback, the receiver stops setting the ECE flag.
従来のECNでは、CEマークが受信側で検出されるとすぐに、後続のACKのTCPヘッダーにEcho Congestion Experienced（ECE）フラグを設定して、この情報を送信側にフィードバックします。送信者は、輻輳通知の最初のECEを受信すると、TCPヘッダーにCongestion Window Reduced（CWR）フラグを1回設定します。 TCPヘッダーにCWRフラグが設定されたこのパケットが、最初のECEフィードバックを確認する受信側に到着すると、受信側はECEフラグの設定を停止します。
If the ConEx sender fully conforms to the semantics of ECN signaling as defined by [RFC3168], it will receive one full RTT of ACKs with the ECE flag set whenever at least one CE mark was received by the receiver. As the sender cannot estimate how many packets have actually been CE-marked during this RTT, the most conservative assumption MAY be taken, namely assuming that all packets were marked. This can be achieved by increasing the CEG by DeliveredData for each ACK with the ECE flag:
[RFC3168]で定義されているように、ConEx送信者がECNシグナリングのセマンティクスに完全に準拠している場合、受信者が少なくとも1つのCEマークを受信すると、ECEフラグが設定されたACKの完全なRTTを1つ受信します。送信者は、このRTTの間に実際にCEマークが付けられたパケットの数を推定できないため、最も保守的な仮定、つまり、すべてのパケットがマークされていると仮定することができます。これは、ECEフラグが設定された各ACKのDeliveredDataによってCEGを増やすことで実現できます。
CEG += DeliveredData
CEG + = DeliveredData
Optionally, a ConEx sender could implement the following technique (that does not conform to [RFC3168]), called "advanced compatibility mode", to considerably improve its estimate of the number of ECN-marked packets:
オプションで、ConEx送信者は、「高度な互換性モード」と呼ばれる次の手法（[RFC3168]に準拠しない）を実装して、ECNマーク付きパケット数の推定を大幅に改善できます。
To extract more than one ECE indication per RTT, a ConEx sender could set the CWR flag continuously to force the receiver to signal only one ECE per CE mark. Unfortunately, the use of delayed ACKs [RFC5681] (which is common) will prevent feedback of every CE mark; if a CWR confirmation is received before the ECE can be sent out on the next ACK, ECN feedback information could get lost (depending on the actual receiver implementation). Thus, a sender SHOULD set CWR only on those data segments that will presumably trigger a (delayed) ACK. The sender would need an additional control loop to estimate which data segments will trigger an ACK in order to extract more timely congestion notifications. Still, the CEG SHOULD be increased by DeliveredData, as one or more CE-marked packets could be acknowledged by one delayed ACK.
RTTごとに複数のECEインジケーションを抽出するために、ConEx送信者はCWRフラグを継続的に設定して、CEマークごとに1つのECEのみをシグナル通知するように強制できます。残念ながら、遅延ACK [RFC5681]（一般的）を使用すると、すべてのCEマークのフィードバックができなくなります。 ECEが次のACKで送信される前にCWR確認が受信されると、ECNフィードバック情報が失われる可能性があります（実際のレシーバーの実装によって異なります）。したがって、送信者は、おそらく（遅延した）ACKをトリガーするデータセグメントにのみCWRを設定する必要があります（SHOULD）。送信者は、よりタイムリーな輻輳通知を抽出するために、どのデータセグメントがACKをトリガーするかを推定するための追加の制御ループを必要とします。それでも、1つ以上のCEマークの付いたパケットが1つの遅延ACKで確認応答される可能性があるため、CEGはDeliveredDataによって増加する必要があります。
By setting the X flag, a packet is marked as ConEx-capable. All packets carrying payload MUST be marked with the X flag set, including retransmissions. Only if no congestion feedback information is (currently) available, SHOULD the X flag be zero (e.g., for control packets on a connection that has not sent any user data for some time and, therefore is sending only pure ACKs that are not carrying any payload).
Xフラグを設定すると、パケットはConEx対応としてマークされます。ペイロードを運ぶすべてのパケットは、再送信を含むXフラグセットでマークされている必要があります。 （現在）利用可能な輻輳フィードバック情報がない場合のみ、Xフラグをゼロにする必要があります（たとえば、しばらくユーザーデータを送信しておらず、したがって何も運んでいない純粋なACKのみを送信している接続の制御パケットの場合）ペイロード）。
As described in Section 3.1, the sender needs to maintain a CEG counter and might also maintain a LEG counter. If no LEG is used, all retransmission will be marked with the L flag.
セクション3.1で説明したように、送信者はCEGカウンターを維持する必要があり、LEGカウンターも維持する場合があります。 LEGを使用しない場合、すべての再送信にはLフラグが付けられます。
Further, as long as the LEG or CEG counter is positive, the sender marks each ConEx-capable packet with L or E respectively, and decreases the LEG or CEG counter by the TCP payload bytes carried in the marked packet (assuming headers are not being counted because packet sizes are regular). No matter how small the value of LEG or CEG, if the value is positive the sender MUST NOT defer packet marking; this ensures that ConEx Signals are timely. Therefore, the value of LEG and CEG will commonly be negative.
さらに、LEGまたはCEGカウンターが正である限り、送信者は各ConEx対応パケットをそれぞれLまたはEでマークし、マークされたパケットで運ばれるTCPペイロードバイトによってLEGまたはCEGカウンターを減らします（ヘッダーが存在しないと仮定）パケットサイズが定期的であるためカウントされます）。 LEGまたはCEGの値がどんなに小さくても、値が正の場合、送信者はパケットマーキングを延期してはなりません。これにより、ConExシグナルがタイムリーになります。したがって、LEGとCEGの値は通常負になります。
If both the LEG and CEG are positive, the sender MUST mark each ConEx-capable packet with both L and E. If a credit signal is also pending (see the next section), the C flag can be set as well.
LEGとCEGの両方が正の場合、送信者は各ConEx対応パケットをLとEの両方でマークする必要があります。クレジット信号も保留中の場合（次のセクションを参照）、Cフラグも設定できます。
The ConEx abstract mechanism [RFC7713] requires that sufficient credit MUST be signaled in advance to cover the expected congestion during the feedback delay of one RTT.
ConEx抽象メカニズム[RFC7713]では、1つのRTTのフィードバック遅延中に予想される輻輳をカバーするために、十分なクレジットを事前に通知する必要があります。
To monitor the credit state at the audit, a ConEx sender needs to maintain a Credit State Counter (CSC) in bytes. If congestion occurs, credits will be consumed and the CSC is reduced by the number of bytes that were lost or estimated to be ECN-marked. If the risk of congestion was estimated wrongly, and thus too few credits were sent, the CSC becomes zero but cannot go negative.
監査時に信用状態を監視するには、ConEx送信者は信用状態カウンター（CSC）をバイト単位で維持する必要があります。輻輳が発生すると、クレジットが消費され、CSCは失われた、またはECNマークが付けられたと推定されるバイト数だけ減少します。輻輳のリスクが誤って推定され、送信されたクレジットが少なすぎる場合、CSCはゼロになりますが、マイナスになることはできません。
To be sure that the credit state in the audit never reaches zero, the number of credits should always equal the number of bytes in flight as all packets could potentially get lost or congestion-marked. In this case, a ConEx sender also monitors the number of bytes in flight F. If F ever becomes larger than the CSC, the ConEx sender sets the C flag on each ConEx-capable packet and increases the CSC by the payload size of each marked packet until the CSC is no less than F again. However, a ConEx sender might also be less conservative and send fewer credits if it, e.g., assumes that the congestion will be low on a certain path based on previous experience.
すべてのパケットが失われたり、輻輳マークが付けられたりする可能性があるため、監査のクレジット状態がゼロにならないことを確認するために、クレジット数は常に飛行中のバイト数と等しくなければなりません。この場合、ConEx送信者はフライトFのバイト数も監視します。FがCSCよりも大きくなると、ConEx送信者は各ConEx対応パケットにCフラグを設定し、マークされた各パケットのペイロードサイズだけCSCを増やしますCSCが再びF以上になるまでパケット。ただし、ConEx送信者は、たとえば、以前の経験に基づいて特定のパスの輻輳が低いと想定している場合、保守性が低く、送信するクレジットが少なくなる場合もあります。
Recall that the CSC will be decreased whenever congestion occurs; therefore the CSC will need to be replenished as soon as the CSC drops below F. Also recall that the sender can set the C flag on a ConEx-capable packet whether or not the E or L flags are also set.
CSCは、輻輳が発生するたびに減少することを思い出してください。したがって、CSCがFを下回るとすぐにCSCを補充する必要があります。EまたはLフラグも設定されているかどうかに関係なく、送信者はConEx対応パケットにCフラグを設定できることを思い出してください。
In TCP Slow Start, the congestion window might grow much larger than during the rest of the transmission. Likely, a sender could consider sending fewer than F credits but risking being penalized by an audit function. However, the credits should at least cover the increase in sending rate. Given the exponential increase as implemented in the TCP Slow Start algorithm, which means that the sending rate doubles every RTT, a ConEx sender should at least cover half the number of packets in flight by credits.
TCPスロースタートでは、輻輳ウィンドウが残りの送信時よりもはるかに大きくなる可能性があります。おそらく、送信者はF未満のクレジットを送信することを検討できますが、監査機能によってペナルティが課せられる危険があります。ただし、クレジットは少なくとも送信レートの増加をカバーする必要があります。 TCPスロースタートアルゴリズムに実装されているように指数関数的に増加するため、送信レートはすべてのRTTが2倍になるため、ConEx送信者は、クレジットによって飛行中のパケット数の少なくとも半分をカバーする必要があります。
Note that the number of losses or markings within one RTT does not depend solely on the sender's actions. In general, the behavior of the cross traffic, whether Active Queue Management (AQM) is used and how it is parameterized influence how many packets might be dropped or marked. As long as any AQM encountered is not overly aggressive with ECN marking, sending half the flight size as credits should be sufficient whether congestion is signaled by loss or ECN.
1つのRTT内の損失またはマーキングの数は、送信者のアクションだけに依存しないことに注意してください。一般に、クロストラフィックの動作、アクティブキュー管理（AQM）が使用されるかどうか、およびパラメーター化の方法は、ドロップまたはマークされるパケットの数に影響します。遭遇したAQMがECNマーキングで過度に攻撃的でない限り、混雑が損失またはECNによって通知されているかどうかにかかわらず、クレジットとしてフライトサイズの半分を送信するだけで十分です。
To maintain half of the packets in flight as credits, half of the packet of the initial window must also be C-marked. In Slow Start marking, every fourth packet introduces the correct amount of credit as can be seen in Figure 1.
処理中のパケットの半分をクレジットとして維持するには、初期ウィンドウのパケットの半分にもCマークを付ける必要があります。スロースタートマーキングでは、図1に示すように、4番目のパケットごとに正しい量のクレジットが導入されます。
in_flight credits
RTT1 |------XC------>| 1 1
|------X------->| 2 1
|------XC------>| 3 2
| |
RTT2 |------X------->| 3 2
|------X------->| 4 2
|------X------->| 4 2
|------XC------>| 5 3
|------X------->| 5 3
|------X------->| 6 3
| |
RTT3 |------X------->| 6 3
|------XC------>| 7 4
|------X------->| 7 4
|------X------->| 8 4
|------X------->| 8 4
|------XC------>| 9 5
|------X------->| 9 5
|------X------->| 10 5
|------X------->| 10 5
|------XC------>| 11 6
|------X------->| 11 6
|------X------->| 12 6
| . |
| : |
Figure 1: Credits in Slow Start (with an initial window of 3)
図1：スロースタートのクレジット（初期ウィンドウは3）
It is possible that a TCP flow will encounter an audit function without relevant flow state due to, e.g., rerouting or memory limitations. Therefore, the sender needs to detect this case and resend credits. A ConEx sender might reset the credit counter CSC to zero if losses occur in subsequent RTTs (assuming that the sending rate was correctly reduced based on the received congestion signal and using a conservatively large RTT estimation).
再ルーティングやメモリの制限などが原因で、TCPフローが関連するフロー状態のない監査機能に遭遇する可能性があります。したがって、送信者はこのケースを検出してクレジットを再送信する必要があります。後続のRTTで損失が発生した場合、ConEx送信者はクレジットカウンターCSCをゼロにリセットする可能性があります（受信した輻輳信号に基づいて送信レートが正しく、かつ控えめに大きなRTT推定を使用した場合）。
This section proposes a concrete algorithm for determining how much credit to signal (with a separate approach used for Slow Start). However, experimentation in credit setting algorithms is expected and encouraged. The wider goal of ConEx is to reflect the "cost" of the risk of causing congestion on those that contribute most to it. Thus, experimentation is encouraged to improve or maintain performance while reducing the risk of causing congestion and, therefore potentially reducing the need to signal so much credit.
このセクションでは、シグナルのクレジット量を決定するための具体的なアルゴリズムを提案します（スロースタートには別のアプローチを使用します）。ただし、クレジット設定アルゴリズムの実験が期待され、推奨されています。 ConExのより広い目標は、輻輳の原因となるものに輻輳を引き起こすリスクの「コスト」を反映することです。したがって、輻輳を引き起こすリスクを低減しつつ、パフォーマンスを向上または維持するために実験を行うことをお勧めします。そのため、多くの信用を示す必要性を減らす可能性があります。
Packets carrying ConEx Signals could be discarded themselves. This will be a second order problem (e.g., if the loss probability is 0.1%, the probability of losing a ConEx L signal will be 0.1% of 0.1% = 0.01%). Further, the penalty an audit induces should be proportional to the mismatch of expected ConEx marks and observed congestion, therefore the audit might only slightly increase the loss level of this flow. Therefore, an implementer MAY choose to ignore this problem, accepting instead the risk that an audit function might wrongly penalize a flow.
ConEx信号を伝送するパケットは、それ自体が破棄される可能性があります。これは2次の問題になります（たとえば、損失確率が0.1％の場合、ConEx L信号を失う確率は0.1％の0.1％= 0.01％になります）。さらに、監査によって引き起こされるペナルティは、予想されるConExマークと観察された輻輳の不一致に比例する必要があるため、監査によってこのフローの損失レベルがわずかに増加するだけかもしれません。したがって、実装者はこの問題を無視して、監査機能が誤ってフローにペナルティを課す可能性があるリスクを受け入れてもよい（MAY）。
Nonetheless, a ConEx sender is responsible for always signaling sufficient congestion feedback, and therefore SHOULD remember which packet was marked with either the L, the E, or the C flag. If one of these packets is detected as lost, the sender SHOULD increase the respective gauge(s), LEG or CEG, by the number of lost payload bytes in addition to increasing LEG for the loss.
それにもかかわらず、ConEx送信者は常に十分な輻輳フィードバックをシグナリングする責任があるため、L、E、またはCフラグのいずれかでマークされたパケットを覚えておく必要があります。これらのパケットの1つが損失として検出された場合、送信者は、損失のLEGを増やすことに加えて、失われたペイロードバイトの数だけ、それぞれのゲージ、LEGまたはCEGを増やす必要があります。
ConEx Signals will only be useful to a network node within a time delay of about one RTT after the congestion occurred. To avoid further delays, a ConEx sender SHOULD send the ConEx signaling on the next available packet.
ConEx信号は、輻輳が発生してから約1 RTTの時間遅延内でのみネットワークノードに役立ちます。さらなる遅延を回避するために、ConEx送信者は次の利用可能なパケットでConExシグナリングを送信する必要があります（SHOULD）。
Any or all of the ConEx flags can be used in the same packet, which allows delays to be minimized when multiple signals are pending. The need to set multiple ConEx flags at the same time can occur if, e.g, an ACK is received by the sender that simultaneously indicates that at least one ECN mark was received, and that one or more segments were lost. This may happen during excessive congestion, if the queues overflow even though ECN was used and currently all forwarded packets are marked, while others have to be dropped. Another case when this might happen is when ACKs are lost, so that a subsequent ACK carries summary information not previously available to the sender.
ConExフラグの一部またはすべてを同じパケットで使用できるため、複数の信号が保留されている場合の遅延を最小限に抑えることができます。たとえば、少なくとも1つのECNマークが受信され、1つ以上のセグメントが失われたことを同時に示すACKが送信者によって受信された場合、同時に複数のConExフラグを設定する必要が生じる可能性があります。これは、ECNが使用され、現在転送されているすべてのパケットがマークされているにもかかわらずキューがオーバーフローし、他のパケットはドロップする必要がある場合、過度の輻輳中に発生する可能性があります。これが発生する可能性があるもう1つのケースは、ACKが失われる場合です。そのため、後続のACKには、以前は送信者が利用できなかった要約情報が含まれます。
If a flow becomes application-limited, there could be insufficient bytes to send to reduce the gauges to zero or below. In such cases, the sender cannot help but delay ConEx Signals. Nonetheless, as long as the sender is marking all outgoing packets, an audit function is unlikely to penalize ConEx-Marked packets. Therefore, no matter how long a gauge has been positive, a sender MUST NOT reduce the gauge by more than the ConEx-Marked bytes it has sent.
フローがアプリケーションによって制限された場合、ゲージをゼロ以下に減らすために送信するのに十分なバイトがない可能性があります。このような場合、送信者はConEx信号を遅らせるしかありません。それにもかかわらず、送信者がすべての発信パケットをマークしている限り、監査機能がConEx-Markedパケットにペナルティを課すことはほとんどありません。したがって、ゲージが正である期間に関係なく、送信者は、送信したConEx-Markedバイトを超えてゲージを削減してはなりません（MUST NOT）。
If the CEG or LEG counter is negative, the respective counter MAY be reset to zero within one RTT after it was decreased the last time, or one RTT after recovery if no further congestion occurred.
CEGまたはLEGカウンターが負の場合、それぞれのカウンターは、前回減少した後の1 RTT内でゼロにリセットされる場合があります。それ以上の輻輳が発生しなかった場合は、回復後1 RTTです。
All proposed mechanisms in this document are experimental, and therefore further large-scale experimentation on the Internet is required to evaluate if the signaling provided by these mechanisms is accurate and timely enough to produce value for ConEx-based (traffic management or other) mechanisms.
このドキュメントで提案されているメカニズムはすべて実験的なものであるため、これらのメカニズムによって提供されるシグナリングがConExベースの（トラフィック管理またはその他の）メカニズムの価値を生み出すのに十分正確かつタイムリーであるかどうかを評価するには、インターネットでのさらに大規模な実験が必要です。
The current ConEx specifications assume that congestion is counted in the number of bytes (including the IP header that directly encapsulates the CDO and everything that the IP header encapsulates) [RFC7837]. This decision was taken because most network devices today experience byte-congestion where the memory is filled exactly with the number of bytes a packet carries [RFC7141]. However, there are also devices that may allocate a certain amount of memory per packet, no matter how large a packet is. These devices get congested based on the number of packets in their memory and therefore, in this case, congestion is determined by the number of packets that have been lost or marked. Furthermore, a transport-layer endpoint such as a TCP sender or receiver, might not know the exact number of bytes that a lower layer was carrying. Therefore, a TCP endpoint may only be able to estimate the exact number of congested bytes (assuming that all lower-layer headers have the same length). If this estimation is sufficient to work with, the ConEx Signal needs to be further evaluated in tests on the Internet together with different auditor implementations.
現在のConEx仕様では、輻輳はバイト数（CDOを直接カプセル化するIPヘッダーとIPヘッダーがカプセル化するすべてのものを含む）でカウントされると想定しています[RFC7837]。この決定が行われたのは、今日のほとんどのネットワークデバイスで、パケットが運ぶバイト数でメモリが正確に満たされるバイト輻輳が発生するためです[RFC7141]。ただし、パケットの大きさに関係なく、パケットごとに特定の量のメモリを割り当てるデバイスもあります。これらのデバイスは、メモリ内のパケット数に基づいて輻輳します。したがって、この場合、輻輳は、失われたかマークされたパケットの数によって決まります。さらに、TCP送信側や受信側などのトランスポート層エンドポイントは、下位層が伝送していた正確なバイト数を知らない場合があります。したがって、TCPエンドポイントは、混雑したバイトの正確な数のみを推定できる場合があります（すべての下位層ヘッダーが同じ長さであると想定）。この推定で十分に機能する場合は、インターネット上のテストで、さまざまな監査者の実装とともに、ConExシグナルをさらに評価する必要があります。
Further, the proposed marking schemes in this document are designed under the assumption that all TCP packets of a ConEx-capable flow are of equal size or that flows have a constant mean packet size over a rather small time frame, like one RTT or less. In most implementations, this assumption might be taken as well and is probably true for most of the traffic flows. If this proposed scheme is used, it is necessary to evaluate how much accuracy degrades if this precondition is not met. Evaluating with real traffic from different applications is especially important in making the decision regarding whether the proposed schemes are sufficient or whether a more complex scheme is needed.
さらに、このドキュメントで提案されているマーキングスキームは、ConEx対応フローのすべてのTCPパケットが同じサイズであるか、フローが1つのRTT以下のようなかなり短い時間フレームにわたって一定の平均パケットサイズを持っているという前提の下で設計されています。ほとんどの実装では、この仮定も採用される可能性があり、おそらくほとんどのトラフィックフローに当てはまります。この提案された方式を使用する場合、この前提条件が満たされない場合にどれだけ精度が低下するかを評価する必要があります。さまざまなアプリケーションからの実際のトラフィックを評価することは、提案されたスキームが十分であるかどうか、またはより複雑なスキームが必要かどうかを決定する際に特に重要です。
In this context, the proposed scheme to set credit markings in Slow Start runs the risk of providing an insufficient number of markings, which can cause an audit function to penalize this flow. Both the proposed credit scheme for Slow Start as well as the scheme in Congestion Avoidance must be evaluated together with one or more specific implementations of a ConEx auditor to ensure that both algorithms, in the sender and in the auditor, work properly together with a low risk of false positives (which would lead to penalization of an honest sender). However, if a sender is wrongly assumed to cheat, the penalization of the audit should be adequate and should allow an honest sender using a congestion control scheme that is commonly used today to recover quickly.
このコンテキストでは、スロースタートでクレジットマーキングを設定するために提案されたスキームは、不十分な数のマーキングを提供するリスクがあり、監査機能がこのフローにペナルティを科す可能性があります。スロースタート用に提案されたクレジットスキームと輻輳回避のスキームの両方を、送信者と監査者の両方のアルゴリズムが低レベルで適切に機能するように、ConEx監査者の1つ以上の特定の実装と一緒に評価する必要があります誤検知のリスク（正直な送信者のペナルティにつながる）ただし、送信者が不正を行うと誤って想定されている場合、監査のペナルティは適切であり、正直な送信者が現在一般的に使用されている輻輳制御スキームを使用して迅速に回復できるようにする必要があります。
Another open issue is the accuracy of the ECN feedback signal. At the time of this document's publication, there is no AccECN mechanism specified yet, and further AccECN will also take some time to be widely deployed. This document proposes an advanced compatibility mode for classic ECN. The proposed mechanism can provide more accurate feedback by utilizing the way classic ECN is specified but has a higher risk of losing information. To figure out how high this risk is in a real deployment scenario, further experimental evaluation is needed. The following argument is intended to prove that suppressing repetitions of ECE, however, is still safe against possible congestion collapse due to lost congestion feedback and should be further proven in experimentation:
もう1つの未解決の問題は、ECNフィードバック信号の精度です。このドキュメントの公開時点では、まだAccECNメカニズムは指定されていません。また、AccECNが広く展開されるまでには、しばらく時間がかかります。このドキュメントでは、クラシックECNの高度な互換モードを提案します。提案されたメカニズムは、従来のECNが指定されている方法を利用することにより、より正確なフィードバックを提供できますが、情報を失うリスクが高くなります。実際の展開シナリオでこのリスクがどれほど高いかを把握するには、さらに実験的な評価が必要です。次の議論は、ECEの繰り返しを抑制しても、輻輳フィードバックが失われたために起こり得る輻輳崩壊に対して依然として安全であることを証明することを目的としており、実験でさらに証明する必要があります。
Repetition of ECE in classic ECN is intended to ensure reliable delivery of congestion feedback. However, with advanced compatibility mode, it is possible to miss congestion notifications. This can happen in some implementations if delayed acknowledgements are used. Further, an ACK containing ECE can simply get lost. If only a few CE marks are received within one congestion event (e.g., only one), the loss of one acknowledgement due to (heavy) congestion on the reverse path can prevent that any congestion notification is received by the sender.
従来のECNでのECEの繰り返しは、輻輳フィードバックを確実に配信することを目的としています。ただし、拡張互換モードでは、輻輳通知を見逃す可能性があります。これは、遅延確認が使用される場合、一部の実装で発生する可能性があります。さらに、ECEを含むACKは単純に失われる可能性があります。 1つの輻輳イベント内で少数のCEマークのみが受信される場合（1つのみなど）、リバースパスでの（重い）輻輳が原因で1つの確認応答が失われると、送信者が輻輳通知を受信できなくなります。
However, if loss of feedback exacerbates congestion on the forward path, more forward packets will be CE-marked, increasing the likelihood that feedback from at least one CE will get through per RTT. As long as one ECE reaches the sender per RTT, the sender's congestion response will be the same as if CWR were not continuous. The only way that heavy congestion on the forward path could be completely hidden would be if all ACKs on the reverse path were lost. If total ACK loss persisted, the sender would time out and do a congestion response anyway. Therefore, the problem seems confined to potential suppression of a congestion response during light congestion.
ただし、フィードバックが失われると、フォワードパスの輻輳が悪化すると、より多くのフォワードパケットにCEマークが付けられ、少なくとも1つのCEからのフィードバックがRTTごとに通過する可能性が高くなります。 RTTごとに1つのECEが送信者に到達する限り、送信者の輻輳応答は、CWRが連続的でない場合と同じになります。フォワードパス上の重い輻輳を完全に隠すことができる唯一の方法は、リバースパス上のすべてのACKが失われた場合です。完全なACK損失が持続した場合、送信者はタイムアウトし、とにかく輻輳応答を行います。したがって、問題は、軽い輻輳時の輻輳応答の潜在的な抑制に限定されているようです。
Furthermore, even if loss of all ECN feedback leads to no congestion response, the worst that could happen would be loss instead of ECN-signaled congestion on the forward path. Given that compatibility mode does not affect loss feedback, there would be no risk of congestion collapse.
さらに、すべてのECNフィードバックが失われたために輻輳応答が発生しなかったとしても、発生する可能性のある最悪の事態は、フォワードパスでのECN信号による輻輳ではなく損失です。互換性モードは損失フィードバックに影響を与えないので、輻輳が崩壊するリスクはありません。
General ConEx security considerations are covered extensively in the ConEx abstract mechanism [RFC7713]. This section covers TCP-specific concerns that may occur with the addition of ConEx to TCP (while not discussing generally well-known attacks against TCP). It is assumed that any altering of ConEx information can be detected by protection mechanisms in the IP layer and is, therefore, not discussed here but in [RFC7837]. Further, [RFC7837] describes how to use ConEx to mitigate flooding attacks by using preferential drop where the use of ConEx can even increase security.
一般的なConExセキュリティの考慮事項は、ConEx抽象メカニズム[RFC7713]で広くカバーされています。このセクションでは、TCPへのConExの追加で発生する可能性があるTCP固有の懸念について説明します（TCPに対する一般的によく知られている攻撃については説明しません）。 ConEx情報の変更はIP層の保護メカニズムによって検出できると想定されているため、ここでは説明していませんが[RFC7837]で説明しています。さらに、[RFC7837]では、ConExを使用してセキュリティを強化できる優先ドロップを使用して、ConExを使用してフラッディング攻撃を緩和する方法について説明しています。
The ConEx modifications to TCP provide no mechanism for a receiver to force a sender not to use ConEx. A receiver can degrade the accuracy of ConEx by claiming that it does not support SACK, AccECN, or ECN, but the sender will never have to turn ConEx off. Further, the receiver cannot force the sender to have to mark ConEx more conservatively, in order to cover the risk of any inaccuracy. Instead, it is always the sender's choice to either mark very conservatively, which ensures that the audit always sees enough markings to not penalize the flow, or estimate the needed number of markings more tightly. This second case can lead to inaccurate marking, and therefore increases the likelihood of loss at an audit function that will only harm the receiver itself.
TCPへのConExの変更は、受信者が送信者にConExを使用しないように強制するメカニズムを提供しません。受信者はSACK、AccECN、またはECNをサポートしていないと主張することでConExの精度を低下させる可能性がありますが、送信者はConExをオフにする必要はありません。さらに、不正確さのリスクをカバーするために、受信者は送信者にConExをより保守的にマークするように強制することはできません。代わりに、非常に控えめにマークすることは常に送信者の選択です。これにより、監査は常に、フローにペナルティを課さない十分なマーキングを確認するか、必要なマーキングの数をより厳密に推定します。この2番目のケースは、不正確なマーキングにつながる可能性があり、したがって、受信機自体に害を及ぼすだけの監査機能での損失の可能性が高くなります。
Assuming the sender is limited in some way by a congestion allowance or quota, a receiver could spoof more loss or ECN congestion feedback than it actually experiences, in an attempt to make the sender draw down its allowance faster than necessary. However, over-declaring congestion simply makes the sender slow down. If the receiver is interested in the content, it will not want to harm its own performance.
送信者が輻輳許容量または割り当てによって何らかの方法で制限されていると仮定すると、受信者は、実際よりも多くの損失またはECN輻輳フィードバックをスプーフィングして、送信者に許容量を必要以上に早く引き下げようとする可能性があります。ただし、輻輳を過度に宣言すると、送信者の速度が低下するだけです。受信者がコンテンツに関心を持っている場合、それ自体のパフォーマンスを損なうことは望まないでしょう。
However, if the receiver is solely interested in making the sender draw down its allowance, the net effect will depend on the sender's congestion control algorithm as permanently adding more and more additional congestion would cause the sender to more and more reduce its sending rate. Therefore, a receiver can only maintain a certain congestion level that is corresponding to a certain sending rate. With NewReno [RFC6582], doubling congestion feedback causes the sender to reduce its sending rate such that it would only consume sqrt(2) = 1.4 times more congestion allowance. However, to improve scaling, congestion control algorithms are tending towards less responsive algorithms like Cubic or Compound TCP, and ultimately to linear algorithms like Data Center TCP (DCTCP) [DCTCP] that aim to maintain the same congestion level independent of the current sending rate and always reduce its sending window if the signaled congestion feedback is higher. In each case, if the receiver doubles congestion feedback, it causes the sender to respectively consume more allowance by a factor of 1.2, 1.15, or 1, where 1 implies the attack has become completely ineffective as no further congestion allowance is consumed but the flow will decrease its sending rate to a minimum instead.
ただし、受信者が送信者に許容値を引き下げることのみに関心がある場合、最終的な輻輳を永続的に追加すると送信者は送信レートをますます低下させるため、正味の影響は送信者の輻輳制御アルゴリズムに依存します。したがって、受信者は、特定の送信レートに対応する特定の輻輳レベルのみを維持できます。 NewReno [RFC6582]では、輻輳フィードバックを2倍にすると、送信者は送信レートを下げ、sqrt（2）= 1.4倍の輻輳許容量しか消費しなくなります。ただし、スケーリングを改善するために、輻輳制御アルゴリズムは、キュービックまたはコンパウンドTCPなどの応答性の低いアルゴリズム、そして最終的には現在の送信レートに関係なく同じ輻輳レベルを維持することを目的とするデータセンターTCP（DCTCP）[DCTCP]などの線形アルゴリズムに向かう傾向があります。また、通知された輻輳フィードバックが高い場合は、常に送信ウィンドウを減らします。いずれの場合も、受信者が輻輳フィードバックを2倍にすると、送信者はそれぞれ1.2、1.15、または1の係数でより多くの許容量を消費します。1は、輻輳許容量がそれ以上消費されないため、攻撃が完全に無効になったことを意味します。代わりに、送信レートを最小に下げます。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, <http://www.rfc-editor.org/info/rfc2018>.
[RFC2018] Mathis、M.、Madhavi、J.、Floyd、S。、およびA. Romanow、「TCP選択的確認応答オプション」、RFC 2018、DOI 10.17487 / RFC2018、1996年10月、<http：//www.rfc- editor.org/info/rfc2018>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[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, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<http：// www。 rfc-editor.org/info/rfc3168>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<http://www.rfc-editor.org/info/ rfc5681>。
[RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements", RFC 7713, DOI 10.17487/RFC7713, December 2015, <http://www.rfc-editor.org/info/rfc7713>.
[RFC7713] Mathis、M。、およびB. Briscoe、「Congestion Exposure（ConEx）Concepts、Abstract Mechanism、and Requirements」、RFC 7713、DOI 10.17487 / RFC7713、December 2015、<http://www.rfc-editor.org / info / rfc7713>。
[RFC7837] Krishnan, S., Kuehlewind, M., Briscoe, B., and C. Ralli, "IPv6 Destination Option for Congestion Exposure (ConEx)", RFC 7837, DOI 10.17487/RFC7837, May 2016, <http://www.rfc-editor.org/info/rfc7837>.
[RFC7837]クリシュナン、S。、キュールウィンド、M。、ブリスコー、B。、およびC.ラリー、「輻輳露出のIPv6宛先オプション（ConEx）」、RFC 7837、DOI 10.17487 / RFC7837、2016年5月、<http：/ /www.rfc-editor.org/info/rfc7837>。
[ACCURATE] Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More Accurate ECN Feedback in TCP", Work in Progress, draft-ietf-tcpm-accurate-ecn-00, December 2015.
[正確] Briscoe、B.、Kuehlewwind、M。、およびR. Scheffenegger、「TCPでのより正確なECNフィードバック」、作業中、draft-ietf-tcpm-accurate-ecn-00、2015年12月。
[DCTCP] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data Center TCP (DCTCP)", ACM SIGCOMM Computer Communication Review, Volume 40, Issue 4, pages 63-74, DOI 10.1145/1851182.1851192, October 2010, <http://portal.acm.org/citation.cfm?id=1851192>.
[DCTCP] Alizadeh、M.、Greenberg、A.、Maltz、D.、Padhye、J.、Patel、P.、Prabhakar、B.、Sengupta、S。、およびM. Sridharan、「Data Center TCP（DCTCP） "、ACM SIGCOMM Computer Communication Review、Volume 40、Issue 4、pages 63-74、DOI 10.1145 / 1851182.1851192、October 2010、<http://portal.acm.org/citation.cfm?id=1851192>。
[ECNTCP] Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith, "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Work in Progress, draft-briscoe-conex-re-ecn-tcp-04, July 2014.
[ECNTCP] Briscoe、B.、Jacquet、A.、Moncaster、T。、およびA. Smith、「Re-ECN：Adding Accountability for Causing Congestion to TCP / IP」、Work in Progress、draft-briscoe-conex-re -ecn-tcp-04、2014年7月。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, DOI 10.17487/RFC3522, April 2003, <http://www.rfc-editor.org/info/rfc3522>.
[RFC3522] Ludwig、R.およびM. Meyer、「The Eifel Detection Algorithm for TCP」、RFC 3522、DOI 10.17487 / RFC3522、2003年4月、<http://www.rfc-editor.org/info/rfc3522>。
[RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions", RFC 3708, DOI 10.17487/RFC3708, February 2004, <http://www.rfc-editor.org/info/rfc3708>.
[RFC3708]ブラントン、E。およびM.オールマン、「TCP重複選択的確認応答（DSACK）およびストリーム制御伝送プロトコル（SCTP）重複伝送シーケンス番号（TSN）を使用して偽の再送を検出する」、RFC 3708、DOI 10.17487 / RFC3708、 2004年2月、<http://www.rfc-editor.org/info/rfc3708>。
[RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", RFC 4015, DOI 10.17487/RFC4015, February 2005, <http://www.rfc-editor.org/info/rfc4015>.
[RFC4015] Ludwig、R。およびA. Gurtov、「The Eifel Response Algorithm for TCP」、RFC 4015、DOI 10.17487 / RFC4015、2005年2月、<http://www.rfc-editor.org/info/rfc4015>。
[RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP", RFC 5682, DOI 10.17487/RFC5682, September 2009, <http://www.rfc-editor.org/info/rfc5682>.
[RFC5682] Sarolahti、P.、Kojo、M.、Yamamoto、K。、およびM. Hata、「Forward RTO-Recovery（F-RTO）：Detecting for Spurious Retransmission Timeouts with TCP」、RFC 5682、DOI 10.17487 / RFC5682、2009年9月、<http://www.rfc-editor.org/info/rfc5682>。
[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, DOI 10.17487/RFC6582, April 2012, <http://www.rfc-editor.org/info/rfc6582>.
[RFC6582] Henderson、T.、Floyd、S.、Gurtov、A。、およびY. Nishida、「The NewReno Modification to TCP's Fast Recovery Algorithm」、RFC 6582、DOI 10.17487 / RFC6582、2012年4月、<http：// www.rfc-editor.org/info/rfc6582>。
[RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed., "Congestion Exposure (ConEx) Concepts and Use Cases", RFC 6789, DOI 10.17487/RFC6789, December 2012, <http://www.rfc-editor.org/info/rfc6789>.
[RFC6789] Briscoe、B。、編、Woundy、R。、編、およびA. Cooper、編、「Congestion Exposure（ConEx）Concepts and Use Cases」、RFC 6789、DOI 10.17487 / RFC6789、2012年12月、 <http://www.rfc-editor.org/info/rfc6789>。
[RFC7141] Briscoe, B. and J. Manner, "Byte and Packet Congestion Notification", BCP 41, RFC 7141, DOI 10.17487/RFC7141, February 2014, <http://www.rfc-editor.org/info/rfc7141>.
[RFC7141] Briscoe、B。およびJ. Manner、「Byte and Packet Congestion Notification」、BCP 41、RFC 7141、DOI 10.17487 / RFC7141、2014年2月、<http://www.rfc-editor.org/info/rfc7141 >。
Acknowledgements
謝辞
The authors would like to thank Bob Briscoe who contributed with these initial ideas [ECNTCP] and valuable feedback. Moreover, thanks to Jana Iyengar who also provided valuable feedback.
著者は、これらの最初のアイデア[ECNTCP]と貴重なフィードバックを提供してくれたBob Briscoeに感謝します。さらに、貴重なフィードバックを提供してくれたJana Iyengarに感謝します。
Authors' Addresses
著者のアドレス
Mirja Kuehlewind (editor) ETH Zurich Switzerland
Mirja Kuehlewind（編集者）ETHチューリッヒスイス
Email: mirja.kuehlewind@tik.ee.ethz.ch
Richard Scheffenegger NetApp, Inc. Am Euro Platz 2 Vienna 1120 Austria
Richard Scheffenegger NetApp、Inc. Am Euro Platz 2 Vienna 1120 Austria
Email: rs.ietf@gmx.at