Independent Submission S. Floyd
Request for Comments: 5690 ICIR
Category: Informational A. Arcia
ISSN: 2070-1721 D. Ros
TELECOM Bretagne
J. Iyengar
Franklin & Marshall College
February 2010
Adding Acknowledgement Congestion Control to TCP
Abstract
抽象
This document describes a possible congestion control mechanism for acknowledgement (ACKs) traffic in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts: the TCP data sender and the TCP data receiver. The TCP data sender detects lost or Explicit Congestion Notification (ECN)-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in the Datagram Congestion Control Protocol's (DCCP's) Congestion Control Identifier (CCID) 2. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community.
このドキュメントでは、TCPでの応答（ACKの）トラフィックのための可能な輻輳制御機構を説明します。 TCPデータ送信側とTCPデータ受信：文書は、両方のTCPホストからの参加を使用するTCPのエンドツーエンドの肯定応答の輻輳制御機構を指定します。 TCPデータの送信者が紛失したり、明示的輻輳通知（ECN）を検出ACKパケットを-marked、およびTCPデータは、データ送信側にデータ受信機からリバースパス上の混雑に対応するために使用するためのACK比Rを受信機に伝えます。 TCPデータ受信機は、データパケットが受信されたすべてのRのための約1 ACKパケットを送信します。このメカニズムは、この確認応答輻輳制御メカニズムは、ネットワークコミュニティによるさらなる評価のために指定されているデータグラム輻輳制御プロトコルの（DCCPの）輻輳制御識別子（CCID）2の確認応答輻輳制御に基づいています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 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/rfc5690.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5690で取得することができます。
IESG Note
IESG注意
The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work.
このRFCの内容は、IETFによって考慮一度だったので、それが進行または公開されたIETF仕事で現在IETFの作業に似ていてもよいです。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions and Terminology .....................................4
3. Overview ........................................................4
4. Acknowledgement Congestion Control ..............................6
4.1. The ACK Congestion Control Permitted Option ................6
4.2. The TCP ACK Ratio Option ...................................7
4.3. The Receiver: Implementing the ACK Ratio ...................7
4.4. The Sender: Determining Lost or Marked ACK Packets .........8
4.4.1. The Sender: Detecting Lost ACK Packets
after a Congestion Event ...........................10
4.5. The Sender: Adjusting the ACK Ratio .......................10
4.5.1. Possible Addition: Decreasing the ACK Ratio
after a Congestion Window Decrease .................12
4.6. The Receiver: Sending ACKs for Out-of-Order Data
Segments ..................................................12
4.7. The Sender: Response to ACK Packets .......................13
4.8. Possible Addition: Receiver Bounds on the ACK Ratio .......15
5. Possible Complications .........................................15
5.1. Possible Complication: Delayed Acknowledgements ...........15
5.2. Possible Complication: Duplicate Acknowledgements .........15
5.3. Possible Complication: Two-Way Traffic ....................16
5.4. Possible Complication: Reordering of ACK Packets ..........16
5.5. Possible Complication: Abrupt Changes in the ACK Path .....17
5.6. Possible Complication: Corruption .........................17
5.7. Possible Complication: ACKs That Don't Contribute
to Congestion .............................................17
5.8. Possible Complication: TCP Implementations that
Skip ACK Packets ..........................................20
5.9. Possible Complication: Router or Middlebox-Based
ACK Mechanisms ............................................21
5.10. Possible Complication: Data-Limited Senders ..............21
5.11. Other Issues .............................................22
6. Evaluating ACK Congestion Control ..............................22
6.1. Contention in Wireless Links or in Non-Switched Ethernet ..22
6.2. Keep-Alive and Other Special ACK Packets ..................22
7. Measurements of ACK Traffic and Congestion .....................23
8. Acknowledgement Congestion Control in DCCP's CCID 2 ............23
9. Security Considerations ........................................24
10. IANA Considerations ...........................................25
11. Conclusions ...................................................26
12. Acknowledgements ..............................................26
Appendix A. Related Work ..........................................27
A.1. ECN-Only Mechanisms .......................................28
A.2. Receiver-Only Mechanisms ..................................28
A.3. Middlebox-Based Mechanisms ................................29
Appendix B. Design Considerations .................................29
B.1. The TCP ACK Ratio Option, or an AckNow Bit in
Data Packets? .............................................29
Normative References ..............................................30
Informative References ............................................30
This document describes a congestion control mechanism for acknowledgements (ACKs) to TCP. This mechanism is based on the acknowledgement congestion control in DCCP's CCID 2 ([RFC4340], [RFC4341]), which is a successor to the TCP acknowledgement congestion control mechanism proposed by Balakrishnan, et al. in [BPK97].
このドキュメントでは、TCPの確認応答（ACKの）のための輻輳制御機構を説明します。この機構は、バラクリシュナンによって提案されたTCP確認応答輻輳制御機構らの後継であるDCCPのCCID 2（[RFC4340]、[RFC4341]）で確認応答輻輳制御に基づいています。 [BPK97]インチ
In this document we use the terminology of senders and receivers, with the sender sending data traffic and the receiver sending acknowledgement traffic in response. In CCID 2's acknowledgement congestion control, specified in Section 6.1 of [RFC4341], the receiver uses an ACK Ratio R reported to it by the sender, sending roughly one ACK packet for every R data packets received. The CCID 2 sender keeps the acknowledgement rate roughly TCP-friendly by monitoring the acknowledgement stream for lost and marked ACK packets and modifying the ACK Ratio accordingly. For every round-trip time (RTT) containing an ACK congestion event (that is, a lost or marked ACK packet), the sender halves the acknowledgement rate by doubling the ACK Ratio; for every RTT containing no ACK congestion event, the sender additively increases the acknowledgement rate through gradual decreases in the ACK Ratio.
この文書では、送信者がデータトラフィックと応答で確認応答トラフィックを送信する受信機を送信すると、送信側と受信側の用語を使用します。 [RFC4341]のセクション6.1で指定されたCCID 2の確認応答輻輳制御において、受信機は、データパケットを受信し、すべてのRのために約1 ACKパケットを送信する、送信者によってそれに報告されたACK比Rを使用します。 CCID 2送信者は、失われたとマークされたACKパケットの確認応答ストリームを監視し、それに応じてACK比を変更することで、ほぼTCPフレンドリー承認率を維持します。 ACK輻輳イベントを含むすべてのラウンドトリップ時間（RTT）（つまり、紛失またはマークACKパケットである）の場合、送信側はACK比を2倍にすることにより、確認応答率を半減します。すべてのRTTが全くACK輻輳イベントを含まないため、送信者は、付加的にACK率が緩やかに減少して確認応答速度を増加させます。
The goal of this document is to explore a similar congestion control mechanism for acknowledgement traffic for TCP. The assumption is that in some environments with congestion on the reverse path, reducing the sending rate for ACK traffic traversing the congested path can help to reduce the congestion itself. For those environments where the reverse path is congested but where TCP ACK traffic does not appreciably contribute to that aggregate congestion, the goal is for TCP's ACK congestion control to have a minimal negative effect on the performance of the TCP connection.
このドキュメントの目標は、TCPに対する肯定応答トラフィックに対して同様の輻輳制御機構を探ることです。仮定は逆の経路上の渋滞といくつかの環境では、混雑した道を横断ACKトラフィックの送信レートを低減することが輻輳自体を減らすのに役立つことができるということです。逆の経路が輻輳しているが、TCP ACKトラフィックはかなりその集計輻輳に寄与しない場合には、目標は、TCP接続のパフォーマンスに最小限の負の効果を持っているTCPのACKの輻輳制御のためにあるような環境のために。
Adding acknowledgement congestion control as an option in TCP would require the following:
TCPのオプションとして承認輻輳制御を追加すると、以下が必要になります。
* An agreement from the TCP hosts on the use of ACK congestion control. For the mechanism specified in this document, the TCP hosts would use a new TCP option, the ACK Congestion Control Permitted option.
ACKの輻輳制御の使用上のTCPホストから*合意。この文書で指定されたメカニズムのために、TCPホストは新しいTCPオプション、オプションを許可ACK輻輳制御を使用します。
* A mechanism for the TCP sender to detect lost and ECN-marked pure acknowledgement packets.
* TCP送信者のためのメカニズムが失われたとECN-マークされ、純粋な確認応答パケットを検出します。
* A mechanism for adjusting the ACK Ratio. The TCP sender would adjust the ACK Ratio as specified in Section 6.1.2 of [RFC4341].
* ACK比率を調整する機構。 [RFC4341]のセクション6.1.2で指定されたTCP送信側はACK比率を調整します。
* A method for the TCP sender to inform the TCP receiver of a new value for the ACK Ratio. For the mechanism specified in this document, the TCP sender would use a new TCP option, the ACK Ratio option.
* TCP送信者のための方法は、ACK比率の新しい値のTCP受信機に通知します。この文書で指定されたメカニズムのために、TCPの送信者は、新たなTCPオプション、ACK比率オプションを使用します。
MSS refers to the Maximum Segment Size.
MSSは最大セグメントサイズを指します。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This section gives an overview of acknowledgement congestion control for TCP.
このセクションでは、TCPのための確認応答輻輳制御の概要を説明します。
---------------------------------------------------------------
TCP Host A Router TCP Host B
(data sender) (data receiver)
---------- ------ ----------
<--- SYN with AckCC Permitted.
SYN/ACK with AckCC Permitted --->
. . .
Data packets --->
<--- one ACK packet
for every two data packets
. . .
Sender detects a lost ACK packet.
Data packet with an ACK Ratio option of 4 --->
<--- one ACK packet
for at most every four data packets
. . .
Sender detects a period with no lost ACK packets.
Data packet with an ACK Ratio option of 3 --->
<--- one ACK packet
for at most every three data packets
---------------------------------------------------------------
Figure 1: Acknowledgement Congestion Control, Host B as the Connection Initiator, for a Connection without ECN
図1：接続イニシエータとして受け付け輻輳制御、ホストB、ECNなしで接続するための
Figure 1 gives an example of acknowledgement congestion control (AckCC) with TCP Host B as the connection initiator.
図1は、接続開始剤としてTCPホストBとの確認応答輻輳制御（AckCC）の例を示します。
During connection initiation, TCP host B sends an ACK Congestion Control Permitted option on its SYN or SYN/ACK packet. This allows TCP host A (now called the sender) to send instructions to TCP host B (now called the receiver) about the ACK Ratio to use in responding to data packets.
接続開始時には、TCPホストBは、そのSYNにACK輻輳制御許可オプションまたはSYN / ACKパケットを送信します。これは、（今、送信者と呼ばれる）TCPホストAは、データパケットへの応答に使用するためにACK比率について（現在の受信機と呼ばれる）TCPホストBに指示を送信することができます。
Also during connection initiation, TCP host A sends an ACK Congestion Control Permitted option on its SYN or SYN/ACK packet. In combination with TCP host B's sending of an ACK Congestion Control Permitted option, and with the negotiation of ECN-Capability as specified in [RFC3168], this would allow TCP host B to send its ACK packets as ECN-Capable.
また、接続開始時に、TCPホストAは、そのSYNにACK輻輳制御許可オプションまたはSYN / ACKパケットを送信します。 TCPホストBのACK輻輳制御許可オプションの送信、および[RFC3168]で指定されたECN-能力の交渉を持つとの組み合わせで、これは、TCPホストBがECN対応としてそのACKパケットを送信することができるようになります。
The TCP receiver starts with an ACK Ratio of two, generally sending one ACK packet for every two data packets received.
TCP受信機は、すべての2つのデータパケットを受信するために、一般的に、1つのACKパケットを送信し、2のACK比で始まります。
The TCP sender detects a lost or ECN-marked ACK packet from the TCP receiver and sends an ACK Ratio option of four to the receiver. The TCP receiver changes to an ACK Ratio of four, sending one ACK packet for at most four data packets. The TCP sender uses Appropriate Byte Counting and rate-based pacing in responding to these ACK packets.
TCPの送信者は、TCP受信機からの紛失やECN-マークACKパケットを検出し、受信機に4のACK比率オプションを送信します。 4のACK比にTCP受信機の変更、最大4つのデータパケットのための1つのACKパケットを送信します。 TCPの送信者は、これらのACKパケットに応答して適切なバイトカウントとレートベースペーシングを使用しています。
The TCP sender detects a period with no lost ACK packets and sends an ACK Ratio option of three to the TCP receiver. The TCP receiver changes back to an ACK Ratio of three, sending one ACK packet for at most three data packets.
TCPの送信者はいない、失われたACKパケットとの期間を検出し、TCP受信機に3のACK比率オプションを送信します。 TCP受信機は最大3つのデータパケットのための1つのACKパケットを送信し、バック3のACK比に変更します。
The goal of the mechanism proposed in this document is to control pure ACK traffic on the path from the TCP data receiver to the TCP data sender. Note that the approach outlined here is an end-to-end one (as is the approach followed by DCCP's CCID 2 [RFC4341]), but it may also take advantage of explicit congestion information from the network, conveyed by ECN [RFC3168], if available. The ECN specification ([RFC3168], see Section 6.1.4) prohibits a TCP receiver from setting the ECT(0) or ECT(1) codepoints in IP packets carrying pure ACKs, but *only* as long as the receiver does *not* implement any form of ACK congestion control. Unlike some of the related work cited in the appendix, in this document we are proposing an end-to-end ACK congestion control mechanism that controls congestion on the reverse path (the path followed by the ACK traffic) by detecting and responding to either marked or dropped ACK packets.
この文書で提案された機構の目標は、TCPデータ送信者へのTCPデータ受信機からのパスに純粋なACKトラフィックを制御することです。ここで概説したアプローチは、エンドツーエンドの一つであることに留意されたい（続くアプローチであるようにDCCPのCCID 2 [RFC4341]）、それはまた、ECN [RFC3168]によって搬送ネットワークからの明示的輻輳情報を利用することができます、可能な場合は。 ECN仕様（[RFC3168]、セクション6.1.4を参照）は、*のみ*であれば、受信機がそうであるようではない純粋なACKを運ぶIPパケットにECT（0）かECT（1）コードポイントを設定することからTCP受信を禁止したが、 * ACK輻輳制御のいずれかの形式を実装します。付録に引用され、関連する作業の一部とは違って、このドキュメントでは、我々はマークのいずれかに検出し、応答することによって逆経路（ACKトラフィックがたどる経路）上の輻輳を制御し、エンドツーエンドACKの輻輳制御機構を提案していますまたはACKパケットを落としました。
The TCP end-points would negotiate the use of ACK congestion control (AckCC) with a TCP option: the ACK Congestion Control Permitted option. The option number would be allocated by IANA.
ACK輻輳制御許可オプション：TCPエンドポイントは、TCPオプションでACK輻輳制御（AckCC）の使用を交渉するでしょう。オプション番号は、IANAによって割り当てられます。
The ACK Congestion Control Permitted option can only be sent on packets that have the SYN bit set. If TCP end-point A receives an ACK Congestion Control Permitted option from TCP end-point B, then the TCP end-points may use ACK congestion control on the pure acknowledgements sent from B to A. This means that TCP end-point A may send ACK Ratio values to TCP end-point B, for TCP end-point B to use on pure acknowledgement packets. Equivalently, if TCP end-point A *does not* receive an ACK Congestion Control Permitted option from TCP end-point B, then TCP end-point A knows not to waste its time detecting lost ACK packets and adjusting and sending the ACK Ratio values.
オプションを許可ACK輻輳制御はSYNビットがセットされているパケットで送信することができます。 TCPエンドポイントAは、TCPエンドポイントBからACK輻輳制御許可オプションを受信した場合、TCPエンドポイントは、AにBから送信された純粋な肯定応答にACK輻輳制御を使用することができるこれは、TCPエンドポイントA 5月を意味します純粋な確認応答パケットで使用するTCPエンドポイントBのために、TCPエンドポイントBにACK比の値を送信します。 TCPエンドポイントA *は、* TCPエンドポイントBからのACK輻輳制御許可オプションを受信しない場合、等価的に、そして、TCPエンドポイントAは、その時間失われたACKパケットを検出し、ACK比率値を調整し、送信を無駄にしない知っています。
If TCP end-point B receives an ACK Congestion Control Permitted option from TCP end-point A, then the TCP end-points may use ACK congestion control on the pure acknowledgements sent from A to B.
TCPエンドポイントBは、TCPエンドポイントAからACK輻輳制御許可オプションを受信した場合、TCPエンドポイントからBに送信された純粋な肯定応答にACK輻輳制御を使用することができます
If TCP end-point B receives an ACK Congestion Control Permitted option from TCP end-point A and also sent an ACK Congestion Control Permitted option to TCP end-point A, and if ECN-Capability has been negotiated, then TCP end-point B can send its pure ACK packets as ECN-Capable.
TCPエンドポイントBがACK輻輳制御を受信した場合、TCPエンドポイントAからオプションを許可し、また、TCPエンドポイントAへACK輻輳制御許可オプションを送信し、ECN-Capabilityがネゴシエートされている場合、TCPエンドポイントB ECN対応として、その純粋なACKパケットを送信することができます。
TCP ACK Congestion Control Permitted Option:
TCP ACK輻輳制御は、オプションを許可します：
Kind: TBD1
子供：TbD1
+-----------+-----------+
| Kind=TBD1 | Length=2 |
+-----------+-----------+
When ACK congestion control is used, the default initial ACK Ratio is two, with the receiver acknowledging at least every other data packet.
ACKの輻輳制御を使用する場合、デフォルトの初期ACK比率は、受信機は、少なくとも他のすべてのデータパケットを認めると、2です。
The sender uses an ACK Ratio TCP option to communicate the ACK Ratio value from the sender to the receiver.
送信者は送信側から受信側にACK比値を通信するために、ACK比率TCPオプションを使用しています。
TCP ACK Ratio Option:
TCP ACK比率オプション：
Kind: TBD2
種類：TBD2
+-----------+-----------+-----------+
| Kind=TBD2 | Length=3 | ACK Ratio |
+-----------+-----------+-----------+
The ACK Ratio option is only sent on data packets. Because TCP uses reliable delivery for data packets, the TCP sender can tell if the TCP receiver has received an ACK Ratio option.
ACK比率オプションは、データ・パケットのみに送信されます。 TCPはデータパケットのための信頼性の高い配信を使用しているため、TCP受信機がACK比率オプションを受信した場合、TCPの送信者が伝えることができます。
With an ACK Ratio of R, the receiver should send one pure ACK for every R newly received data packets unless the delayed ACK timer expires first. A receiver could simply maintain a counter that increments by one for each new data packet received, and send an ACK packet when the counter reaches R. The receiver would reset the counter to zero whenever a pure or piggybacked ACK is sent.
遅延ACKタイマが満了しない限り、最初のRのACK比で、受信機は、すべてのR、新たに受信したデータパケットのための1つの純粋なACKを送信する必要があります。受信機は、単に、各新たなデータパケットのための1つによってインクリメントが受信したカウンタを維持し、カウンタが純粋又はACKをピギーバックが送信されたとき、受信機は、カウンタをゼロにリセットするであろうR.に達したときにACKパケットを送信することができます。
If the receiver has buffer limitations, the receiver might have to acknowledge K packets, for some K less than the current ACK Ratio R. In this case, the sender could observe from the acknowledgements that the receiver is acknowledging less than R packets.
受信機は、バッファの制限を持っている場合、受信機は、K個のパケットを認識する必要がある場合があります。この場合、現在のACK比Rよりも少ない一部のKのために、送信側は受信側がRパケット未満を認めていることの確認応答から観察することができました。
It is possible for there to be lost or marked ACK packets when there haven't yet been any lost or marked data packets. Thus, the sender could increase the ACK Ratio R even during the initial slow-start.
まだ紛失またはマークされたデータパケットが存在していない場合があるが、ACKパケットを紛失したり、マークされることが可能です。このように、送信側でも、最初のスロースタート時のACK比Rを増加させる可能性があります。
[RFC5681] recommends that the receiver SHOULD acknowledge out-of-order data packets immediately, sending an immediate duplicate ACK when it receives a data segment above a gap in the sequence space, and sending an immediate ACK when it receives a data segment that fills in all or part of a gap in the sequence space.
[RFC5681]は、それがいっぱいにデータセグメントを受信した場合、受信機は、それが配列空間におけるギャップ上記のデータセグメントを受信し、即時重複ACKを送信し、即時ACKを送信し、すぐにアウト・オブ・オーダーデータパケットを認めるべきであることをお勧めしますシーケンス空間のギャップの全部または一部インチ
When ACK congestion control is being used and the ACK Ratio is at most two, the TCP receiver acknowledges each out-of-order data packet immediately. For an ACK Ratio greater than two, Section 4.6 specifies in detail the receiver's behavior for sending ACKs for out-of-order data packets.
ACK輻輳制御が使用されているとACK比は、せいぜい2である場合には、TCP受信機はすぐに各アウトオブオーダーデータパケットを認めています。 2より大きいACK比、セクションアウトオブオーダーデータパケットのためのACKを送信するための受信機の動作を詳細に4.6を指定するために。
The TCP data sender uses its knowledge of the ACK Ratio in use by the receiver to infer when an ACK packet has been lost.
TCPデータ送信側はACKパケットが失われた時に推論するために受信機によって使用されているACK比率のその知識を使用しています。
Because the TCP sender knows the ACK Ratio R in use by the receiver, the TCP sender knows that in the absence of dropped or reordered acknowledgement packets, each new acknowledgement received will acknowledge at most R additional data packets. Thus, if the sender receives an acknowledgement acknowledging more than R data packets, and does not receive a subsequent acknowledgement acknowledging a strict subset (with a smaller cumulative acknowledgement, or with the same cumulative acknowledgement but a strict subset of data acknowledged in selective acknowledgement (SACK) blocks), then the sender can infer that an ACK packet has been dropped. The use of SACK options in ACK packets would help the sender in detecting lost ACK packets.
TCPの送信側が受信側で使用されているACK比Rを知っているので、TCPの送信者は落としたり、並べ替え、確認応答パケットが存在しない場合に、それぞれの新しい承認は、ほとんどのRの追加のデータパケットに認めるだろう受け取ったことを知っています。したがって、送信者はRデータパケットよりも認める肯定応答を受信し、および（または同じ累積確認応答が、選択的確認応答で確認応答データの厳密なサブセットに小さい累積確認応答に厳密サブセットを（認める後続の確認応答を受信しない場合SACK）ブロック）、その後、送信側はACKパケットが廃棄されたことを推測することができます。 ACKパケットでSACKオプションを使用すると、失われたACKパケットを検出する際に、送信者に役立つだろう。
Similarly, the TCP sender knows that in the absence of dropped or delayed data packets from the sender, and in the absence of delayed acknowledgements due to a timer expiring at the receiver, each new pure acknowledgement received will acknowledge at least R additional data packets. In terms of ACK congestion control, the TCP sender does not have to take any actions when it receives an acknowledgement acknowledging less than R additional packets.
同様に、TCPの送信者は送信者からの、および遅延確認応答の不在下での落下または遅延のデータパケットが存在しない場合に起因する受信機でタイマーが切れるまで、受信した各新しい純粋な確認は、少なくともRの追加のデータパケットを認めることを知っています。 ACKの輻輳制御の観点では、TCPの送信者は、それがR追加パケット未満を認め確認応答を受信したときに任意のアクションを実行する必要はありません。
Out-of-order data packets:
アウトオブオーダデータパケット：
If the ACK Ratio is at most two, then the TCP receiver sends a duplicate acknowledgement (DupACK) for every out-of-order data packet. In this case, the TCP sender should be able to detect lost DupACK packets by counting the number of DupACKs that arrive between the beginning of the loss event and the arrival of the first full or partial ACK, and comparing this number with the number of DupACKs that should have arrived (based on the number of packets being ACKed by the full or partial ACK). Simulations and/or experiments will be needed to determine whether, in practice, it works for the TCP sender to assess lost ACK packets during loss events, for an ACK Ratio of at most two.
ACK比が2以下である場合には、TCP受信機はすべてのアウトオブオーダーデータパケットの重複確認応答（のdupack）を送信します。この場合、TCP送信者は、損失事象の開始と最初の完全なまたは部分的なACKの到着との間の到着DupACKsの数をカウントし、DupACKsの数とこの数を比較することにより失われたのdupackパケットを検出することができなければなりませんそれは、（完全または部分的ACKでACKされるパケットの数に基づいて）到着しているはずです。シミュレーションおよび/または実験は、実際に、それはせいぜい2のACK比率のために、損失事象の間に失われたACKパケットを評価するために、TCP送信のために働く、かどうかを判断するために必要とされるであろう。
If the ACK Ratio is greater than two, the TCP receiver does not send a DupACK for every out-of-order data packet, as specified in Section 4.6. For simplicity, the TCP sender does not attempt to detect lost ACK packets during loss events involving forward-path data traffic. That is, as soon as the sender infers a packet loss for a forward-path data packet, it stops detection of ACK loss on the reverse path. The sender waits until a new cumulative acknowledgement is received that covers the retransmitted data, and then restarts detection of ACK loss for reverse-path traffic.
ACK比が2以上である場合には、TCP受信機は4.6節で指定されているように、すべてのアウトオブオーダーデータパケットのためのdupackを送信しません。簡単にするために、TCPの送信者は、往路のデータトラフィックを伴う損失イベント中に失われたACKパケットを検出しようとしません。それはすぐに送信者が往路のデータパケットのパケット損失を推論として、それは逆の経路上でACK損失の検出を停止し、です。送信元待機新たな累積肯定応答は再送データを覆う受信し、次いで逆パストラフィックのACK損失の検出を再開するまで。
Detecting lost ACK packets after changes in the ACK Ratio:
ACK比率の変更後に失われたACKパケットを検出します：
In detecting lost ACK packets, the sender relies on its knowledge of the ACK Ratio used by the receiver. But when the sender makes a change in the ACK Ratio and then receives ACK packets, how does the sender know whether the receiver was using the new or the old ACK Ratio when it sent those ACK packets? As specified in the next section, the sender can make only one of two possible changes to the ACK Ratio within one round-trip time. The sender can decrease the ACK Ratio by one, from R to R-1, or the sender can double the ACK Ratio, increasing it from R to 2R. But, in detecting lost ACK packets after an increase in the ACK Ratio, the sender needs to know whether the receiver was using the old ACK Ratio R or the new ACK Ratio 2R.
失われたACKパケットを検出するには、送信側は受信側で使用されるACK比率の知識に依存しています。しかし、送信者がACK比の変化を行い、その後、ACKパケットを受信したとき、どのように送信者は、それは、これらのACKパケットを送信したとき、受信機が新しいか古いACK比を使用していたかどうかを知っていますか？次のセクションで指定されているように、送信者が1往復時間内にACK比にのみ、1〜2の可能な変更を行うことができます。送信者は、RからR-1に、いずれかによってACK率を減少させることができ、又は送信者が2RにRからそれを増加させる、ACK率を倍増することができます。しかし、ACK比で増加した後、失われたACKパケットを検出する際に、送信者は受信機が古いACK比Rまたは新しいACK比2Rを使用していたかどうかを知る必要があります。
The sender sends ACK Ratio options only on data packets, and these data packets are acknowledged by the receiver. One possibility would be for the sender to save the sequence number of the last data packet that contained an ACK Ratio option and to remember whether that ACK Ratio option was for an increase or a decrease in the ACK Ratio. Then, if the sender receives an ACK packet acknowledging the saved sequence number, the sender knows that the receiver has begun using the new ACK Ratio.
送信者は、データ・パケットのみにACK比のオプションを送信し、これらのデータパケットは、受信機によって確認されます。一つの可能性は、ACK比率オプションが含まれている最後のデータパケットのシーケンス番号を保存すると、そのACK比率オプションが増加またはACK率の低下のためだったかどうか覚えている送信者のためになります。送信者は、保存されたシーケンス番号を認めACKパケットを受信した場合次に、送信者は受信機が新しいACK比を使用し始めていることを知っています。
It *might* be sufficient for the sender just to save the information of whether the last change in the ACK Ratio was an increase or a decrease, without saving the sequence number associated with the last ACK Ratio option. In this way, if the sender recently increased the ACK Ratio from R to 2R, the sender could be more cautious in detecting lost ACK packets. Another possibility would be that, after sending an ACK Ratio option, the sender waits until that data has been ACKed, with the new ACK Ratio in use by the receiver, before resuming the detection of lost ACK packets. However, we do not explore either of these approaches in more detail in this document.
送信者は、単に最後のACK比率オプションに関連付けられたシーケンス番号を保存せずに、ACK率の最後の変更が増減したかどうかの情報を保存することは* *十分かもしれません。送信者が最近、Rから2RにACK比率を増加する場合は、この方法では、送信者は、失われたACKパケットを検出し、より慎重である可能性があります。別の可能性は、データが失われたACKパケットの検出を再開する前に、受信機で使用されている新しいACK比で、ACKされるまで、送信者が待機をACK比率オプションを送信した後、ということでしょう。しかし、私たちは、この文書でより詳細にこれらのアプローチのいずれかを探求していません。
After a sender's retransmit timeout or fast retransmit, the sender might retransmit a number of data packets dropped from a single window of data. In particular, during a loss recovery period (from the sender's detection of the congestion event up until the sender receives an acknowledgement of all data packets transmitted before the loss recovery period began), retransmitted data packets can fill holes in the receiver's sequence space, resulting in irregular jumps in the cumulative acknowledgement field in ACK packets from the receiver. These jumps in the cumulative acknowledgement field make it difficult for the sender to reliably detect lost ACK packets during a loss recovery period.
送信者の再送タイムアウトや高速再送後、送信側はデータパケットの数は、データの単一の窓から落とさ再送するかもしれません。 （送信者が損失の回復期間が始まる前に送信されるすべてのデータパケットの確認応答を受信するまで渋滞イベントまでの送信者の検知からの）損失の回復期間中、特に、再送データパケットは、その結果、受信側のシーケンススペースの穴を埋めることができます受信機からのACKパケットの累積確認応答フィールドが不規則ジャンプします。累積確認応答フィールド内のこれらのジャンプはそれが困難な送信者が確実に損失回復期間中に失われたACKパケットを検出するために作ります。
Because of this uneven progress of the cumulative acknowledgement field during a loss recovery period, the sender should not attempt to detect lost ACK packets during a loss recovery period. As a consequence, the sender will not increase the ACK Ratio in response to ACK packets that are lost during a loss recovery period.
そのため、損失回復期間中の累積承認フィールドのこの不均一な進行のため、送信者は損失の回復期間中に失われたACKパケットを検出するために、試みるべきではありません。結果として、送信者が損失の回復期間中に失われたパケットをACKに応じて、ACK率を高めることはありません。
The TCP sender will adjust the ACK Ratio as specified in Section 6.1.2 of [RFC4341], as follows.
[RFC4341]のセクション6.1.2で指定されるように、以下のようにTCPの送信側は、ACK比率を調整します。
The ACK Ratio always meets the following three constraints.
ACK比率は常に次の3つの制約を満たしています。
(1) The ACK Ratio is an integer.
（1）ACK比は整数です。
(2) The minimum ACK sending rate: The ACK Ratio does not exceed max(2, cwnd/(K*MSS)), rounded up, for K=2. As a result, the TCP receiver generally sends at least two ACKs in response to a window of at least four full-sized segments.
（2）レート送信最小ACK：ACK比が最大（2、CWND /（K * MSS））を超えないことは、= 2 Kため、切り上げ。結果として、TCP受信機は、一般に、少なくとも4つのフルサイズのセグメントのウィンドウに応答して少なくとも二つのACKを送信します。
(3) If the congestion window is at least as large as four full-sized segments, then the ACK Ratio is at least two. In other words, an ACK Ratio of one is only allowed when the congestion window is at most three full-sized segments.
輻輳ウィンドウは、4つのフルサイズのセグメントと少なくとも同じ大きさである場合（3）、次いで、ACK比が少なくとも2です。輻輳ウィンドウは、せいぜい3、フルサイズのセグメントであるとき、つまり、1のACK比のみが許可されます。
The sender changes the ACK Ratio within those constraints as follows.
次のように送信者は、これらの制約の中でACK比を変更します。
For each congestion window of data with lost or marked ACK packets, the ACK Ratio R is doubled; for each cwnd/(MSS*(R^2 - R)) consecutive congestion windows of data with no lost or marked ACK packets, the ACK Ratio is decreased by 1. (See Appendix A of RFC 4341 for the derivation. Note that Appendix A of RFC 4341 assumes a congestion window W in packets, while we use cwnd in bytes.) As stated in the previous section, when the ACK Ratio is greater than two, the sender does not attempt to detect lost ACK packets during loss events for forward-path traffic.
紛失またはマークされたACKパケットを有するデータの各輻輳ウィンドウのために、ACK比率Rが2倍になります。それぞれのcwnd /（MSS *（R ^ 2 - R））には、失われたか、マークされたACKパケットとのデータの連続した輻輳ウィンドウ、ACK比率は、導出のためにRFC 4341の付録Aを参照してください（1減少している付録に注意してください。私たちはバイト単位でのcwndを使用しながら、RFC 4341の、パケット内の輻輳ウィンドウWを前提としています。）ACK比が2以上である前項で述べたように、送信者がのために損失イベントの際に失われたACKパケットを検出しようとしません。往路トラフィック。
For a constant congestion window, these modifications to the ACK Ratio give an ACK sending rate that is roughly TCP-friendly. Of course, cwnd usually varies over time; the dynamics will be rather complex, but roughly TCP friendly. We recommend that the sender determines when to decrease the ACK Ratio by one (i.e., by calculating the number of in-order data packets to count) right after an ACK loss event.
一定の輻輳ウィンドウの場合は、ACK比にこれらの変更は、おおよそTCPフレンドリーであるACK送信レートを与えます。もちろん、cwndのは、通常、時間とともに変化します。ダイナミクスはかなり複雑であるが、おおよそTCPフレンドリーになります。我々は右のACK損失イベント後の1（すなわち、インオーダーのデータパケットの数を計算することでカウントする）ことにより、ACK比率を低下させる際に、送信者が決定することをお勧めします。
The frequency of ACK Ratio negotiations:
ACK比率交渉の頻度：
The sender need not keep the ACK Ratio completely up to date. For instance, it may rate-limit ACK Ratio renegotiations to once every four or five round-trip times, or to once every second or two. The sender should not attempt to change the ACK Ratio more than once per round-trip time. In particular, before sending a packet with a new value for the ACK Ratio, the sender should verify that the receiver has acknowledged a data packet containing an ACK Ratio option for the old value of the ACK Ratio. Additionally, the sender may enforce a minimum ACK Ratio of two, or it may set the ACK Ratio to one for half-connections with persistent congestion windows of 1 or 2 packets.
送信者は、完全に最新のACK比率を維持する必要はありません。例えば、それは一回ごとに4または5往復時間に、または1秒に1回または2にACK比再交渉制限速度があります。送信者は複数回往復時間あたりよりACK比を変更しようとするべきではありません。具体的には、ACK比率の新しい値を持つパケットを送信する前に、送信側は受信側がACK比の古い値のためのACK比率オプションを含むデータパケットを認めていることを確認する必要があります。また、送信側は、二つの最小ACK比率を適用することができる、又はそれは1つの又は2のパケットの持続的な輻輳ウィンドウと半接続のための1つにACK比を設定してもよいです。
The minimum ACK sending rate:
最小ACK送信レート：
From rule (2) above, the TCP receiver always sends at least K=2 ACKs for a window of data, even in the face of very heavy congestion on the reverse path. We would note, however, that if congestion is sufficiently heavy, all the ACK packets are dropped, and then the sender falls back on an exponentially backed-off timeout. Thus, if congestion is sufficiently heavy on the reverse path, then the sender reduces its sending rate on the forward path, which reduces the rate on the reverse path as well. One possibility would be to use a higher minimum ACK-sending rate, adding a constant upper bound on the ACK Ratio. That is, if the ACK Ratio also had an upper bound of J, independent of cwnd, then the receiver would always send at least one ACK for every J data packets, regardless of the level of congestion on the reverse path.
ルール（2）から上記、TCP受信機は常にも逆の経路上の非常に重い輻輳に直面して、データのウィンドウに対して少なくともK = 2つのACKを送信します。私たちは、輻輳が十分に重い場合、すべてのACKパケットが廃棄されていること、しかし、注意してなり、その後、送信者は、指数関数的バックオフタイムアウトにフォールバックします。輻輳が逆の経路上に十分に重い場合したがって、送信者は、同様に、逆方向経路上の速度を減少させる順方向経路上の送信速度を低下させます。一つの可能性は、ACK比率に一定の上限を追加し、より高い最小ACK-送信レートを使用することです。 ACK比ものcwndとは無関係に、Jの上限を持っていた場合には、受信機は、常に逆の経路上の渋滞のレベルにかかわらず、すべてのJ・データ・パケットのための少なくとも一つのACKを送信しています。
4.5.1. Possible Addition: Decreasing the ACK Ratio after a Congestion Window Decrease
4.5.1. 可能性のある追加：輻輳ウィンドウの減少後のACKの割合を下げ
After a lost or ECN-marked data packet, the data sender halves the congestion window, thus halving the sending rate for data packets, while making no change to the ACK Ratio R. As a result, after a congestion event involving a data packet, the sending rate for ACK packets on the return path is also halved. If the congestion event was a lost or ECN-marked data packet, this was due to congestion on the forward path, which may have been unrelated to conditions on the reverse path. Thus, it has been suggested that the sender could decrease the ACK Ratio R when it halves the congestion window; in this case, the halving of the sending rate for data packets would not be accompanied by a halving of the sending rate for ACK packets also.
紛失またはECN-マークされたデータパケットの後、データ送信側はデータパケットを伴う輻輳イベントの後、結果としてACK比Rへの変更を行っていないしつつ、データパケットの送信レートを半減、輻輳ウィンドウを半分に、復路のACKパケットの送信レートも半分になります。輻輳イベントが紛失またはECN-マークされたデータパケットであった場合、これは逆の経路上の条件に無関係であったかもしれない、往路、上の混雑によるものでした。したがって、輻輳ウィンドウを半分にする場合、送信者がACK比Rを減少させることができたことが示唆されています。この場合には、データパケットの送信レートの半分にもACKパケットの送信レートの半分を伴うことはないでしょう。
However, there are a few cases where a congestion event involving data packets could in fact have been caused by congestion on the reverse path. As one example, the path could include a congested multiaccess link where forward-path and reverse-path traffic can interfere with each other. Thus, in this case it might be desirable if a congestion event resulted in a reduction in the sending rate of ACK packets as well as of data packets.
しかし、データパケットを伴う輻輳イベントは実際には逆の経路上の混雑によって引き起こされた可能性があり、いくつかの例があります。一例として、パスはフォワードパス及び逆パストラフィックが互いに干渉することができる混雑マルチアクセスリンクを含むことができます。輻輳イベントは、データパケットの送信ACKパケットのレートなどの減少が生じた場合はこのように、この場合にはそれが望ましいかもしれません。
As a second example of a congestion event involving congestion of the reverse path, a congestion event could be caused not by a dropped or ECN-marked data packet, but by a window of dropped ACK packets, resulting in a retransmit timeout at the data sender. After a retransmit timeout, the TCP sender will slow-start, reducing the congestion window to the initial window and setting the ACK Ratio to at most two.
リバースパスの輻輳を伴う輻輳イベントの第2の例として、輻輳イベントは、データ送信側に再送タイムアウトが生じるなく、ドロップまたはECNマーク付きデータ・パケットによって、しかしドロップACKパケットのウィンドウによって引き起こされる可能性が。再送タイムアウトの後、TCPの送信側はスロースタートをし、初期画面に輻輳ウィンドウを縮小し、高々2にACK比率を設定します。
Until further investigation, the sender will not decrease the ACK Ratio as a result of a congestion event involving a data packet.
さらに調査までは、送信側はデータパケットを伴う輻輳イベントの結果としてACK比率を低下させないであろう。
RFC 5681 says that "a TCP receiver SHOULD send an immediate duplicate ACK when an out-of-order segment arrives". After three duplicate ACKs are received, the TCP sender infers a packet loss and implements fast retransmit and fast recovery, retransmitting the missing packet. When the ACK Ratio is at most two, the TCP receiver should still send an immediate duplicate ACK when an out-of-order segment arrives.
RFC 5681は、「アウト・オブ・オーダーセグメントが到着したときにTCP受信機はすぐに重複ACKを送信すべきである」と述べています。 3つの重複ACKが受信された後、TCPの送信者は、パケットロスを推測し、欠落パケットを再送、高速再送と高速リカバリを実現しています。 ACK比が2以下であれば、アウトオブオーダーセグメントが到着したときに、TCP受信機はまだ即時重複ACKを送信する必要があります。
In general, when the ACK Ratio is greater than two, the TCP receiver still should send an immediate duplicate ACK for each of the first three out-of-order segments that arrive in a reordering event. (We define a reordering event at the receiver as beginning when an out-of-order segment arrives, and ending when the receiver holds no more out-of-order segments.) However, when the ACK Ratio is greater than two, after the first three duplicate ACKs have been sent, the TCP receiver should perform ACK congestion control on the remaining ACKs to be sent during the current reordering event. That is, after the first three duplicate ACKs have been sent, the TCP receiver should return to sending an ACK for every R segments, instead of sending an ACK for every out-of-order segment in that reordering event. (We note that the fast recovery procedure of the TCP sender might have to be modified to take this change into account.) In addition, a receiver must not withhold an ACK for more than 500 ms.
ACK比率が2より大きい場合、一般的に、TCP受信機は依然として並べ替えイベントに到着する最初の三つのアウト・オブ・オーダのセグメントの各々に対する即時重複ACKを送信しなければなりません。 （受信機がもはやアウト・オブ・オーダのセグメントを保持している場合我々は、アウト・オブ・オーダのセグメントが到着開始、および終了などの受信機で並べ替えイベントを定義する。）しかしながら、ACKの比率が2より大きい場合には、後最初の3つの重複ACKが送信された、TCP受信機は現在の並べ替えイベント中に送信する残りのACKのACK輻輳制御を実行する必要があります。最初の三つの重複ACKが送信された後、それは、TCP受信機は、すべてのRセグメントに対するACKを送信する代わりに、その並べ替えイベント内のすべてのアウト・オブ・オーダのセグメントに対するACKを送信し返すべきされます。 （私たちは、TCPの送信側の高速回復手順は、アカウントにこの変更を取るように変更することが必要になる場合がありますので注意してください。）また、受信機は500以上のミリ秒のためのACKを保留してはなりません。
We note that in an environment with systematic reordering in the data path (e.g., every set of K data packets arrives in inverted order, for some value of K), the guideline above could result in the receiver sending an ACK for every data packet, regardless of the ACK Ratio. In such an environment with persistent reordering, the receiver may decide not to send an immediate duplicate ACK for each of the first three out-of-order segments that arrive in a reordering event. We leave the investigation of mechanisms for effective ACK congestion control in environments with systematic reordering for future work.
当社は、データパスの系統的並べ替えと環境の中で（例えば、KデータパケットのすべてのセットはKのいくつかの値に対して、逆の順序で到着する）、上記のガイドラインは、すべてのデータパケットのためのACKを送信する受信機が生じる可能性があることに注意してくださいかかわらず、ACK比率の。永続的な並べ替えこのような環境では、受信機は、並べ替えイベントに到着する最初の三つのアウト・オブ・オーダのセグメントの各々に対する即時重複ACKを送信しないことを決定することができます。私たちは、今後の作業のための体系的な並べ替えがある環境での効果的なACKの輻輳制御のためのメカニズムの調査を残します。
The use of a large ACK Ratio can generate line-rate data bursts at a TCP sender. When the ACK Ratio is greater than two, the TCP sender should use some form of burst mitigation or rate-based pacing for sending data packets in response to a single acknowledgement. The use of rate-based pacing will be limited by the timer granularity at the TCP sender.
大ACK比の使用は、TCPの送信側でラインレートのデータバーストを生成することができます。 ACK比率が2より大きい場合、TCP送信者は、単一の肯定応答に応答してデータパケットを送信するためのバースト緩和またはレートに基づくペーシングのいくつかのフォームを使用する必要があります。レートベースペーシングの使用はTCP送信側でのタイマーの粒度によって制限されます。
We note that the interaction of ACK congestion control and burst mitigation schemes needs further study.
私たちは、ACK輻輳制御とバースト緩和スキームの相互作用は、さらなる研究が必要であることに注意してください。
Byte counting at the sender:
送信側でカウントバイト：
In addition to the impact of a large ACK Ratio on the burstiness of the TCP sender's sending rate, a large ACK Ratio can also affect the data-sending rate by slowing down the increase of the congestion window cwnd. As specified in RFC 5681, in slow-start the TCP sender increases cwnd by one full-sized segment for each new ACK received (in this context, a "new ACK" is an ACK that acknowledges new data). RFC 5681 also specifies that in congestion avoidance, the TCP sender increases cwnd by roughly 1/cwnd full-sized segments for each ACK received, resulting in an increase in cwnd of roughly one full-sized segment per round-trip time. In this case, the use of a large ACK Ratio would slow down the increase of the sender's congestion window.
TCPの送信者の送信レートのバースト性に大きなACK比の影響に加えて、大規模なACK比も輻輳ウィンドウのcwndの増加を遅くすることにより、データ送信速度に影響を与えることができます。 RFC 5681で指定されるように受信されたそれぞれの新しいACKための一つのフルサイズのセグメントによってcwndをTCP送信者が増加するスロースタート（この文脈では、「新たなACK」は新しいデータを肯定応答ACKです）。 RFC 5681は、各ACKが往復時間当たり約1フルサイズセグメントのCWNDが増加し、その結果、受信のために輻輳回避に、TCP送信者増加はおおよそ1 / CWNDフルサイズのセグメントによってcwndをことを指定します。この場合、大ACK比の使用は、送信側の輻輳ウィンドウの増加を遅くするでしょう。
RFC 5681 notes that during congestion avoidance, it is also acceptable to count the number of bytes acknowledged by new ACKs and to increase cwnd based on the number of bytes acknowledged, rather than on the number of new ACKs received. Thus, the sender should use this form of byte counting with acknowledgement congestion control, so that the acknowledgement congestion control doesn't slow down the window increases for the data traffic sent by the sender. Because rate-based pacing should be used with acknowledgement congestion control, as recommended earlier in this section, the TCP sender may increase the congestion window by more than two MSS for each ACK.
輻輳回避の間に、新しいのACKによって確認したバイト数をカウントすると、バイト数に基づいてにcwndを増加させることも許容されることをRFC 5681のノートではなく、受信した新たなACKの数に比べて、認めました。確認輻輳制御は、送信側によって送信されるデータトラフィックのためのウィンドウが増加を遅くしないようにこのように、送信者は、受信確認輻輳制御とバイトカウントのこのフォームを使用する必要があります。以前、このセクションで推奨されているようにレートベースペーシングが、確認応答輻輳制御に使用する必要がありますので、TCPの送信者は、各ACKのために二つ以上のMSSによって輻輳ウィンドウを増大させることができます。
We note that for Appropriate Byte Counting (ABC) as specified in [RFC3465], during slow-start the sender is allowed to increase the congestion window by at most two MSS for each ACK. It has not yet been determined whether, with acknowledgement congestion control, the TCP sender could use ABC during slow-start. If ABC is used with acknowledgement congestion control, then when the TCP sender is in slow-start and the ACK Ratio is greater than two, the TCP sender may increase the congestion window by more that two MSS in response to a single ACK. Section 4.2 of [LL07] explores some of the issues with the use of ABC for TCP connections with a fixed ACK Ratio greater than two.
私たちは、送信者が各ACKのために最も2 MSSによって輻輳ウィンドウを上昇させているスロースタート時に、適切なバイトカウント（ABC）のために[RFC3465]で指定されていることに注意してください。まだ確認輻輳制御と、TCPの送信側はスロースタート時のABCを使用することができ、かどうか決定されていません。 ABCが確認輻輳制御で使用されている場合は、送信者がスロースタートとACKの比率であるTCPが2以上であるとき、そして、TCPの送信者は、単一のACKに応じて3つ以上のMSSによって輻輳ウィンドウを増大させることができます。 [LL07]のセクション4.2は、2よりも大きい固定ACK比とのTCP接続のためのABCを使用した問題のいくつかを探ります。
Inferring lost data packets:
失われたデータパケットを推測します：
As cited earlier, RFC 5681 infers that a packet has been lost after it receives three duplicate acknowledgements. Because ACK congestion control is only used when there is congestion on the reverse path, after a packet loss, one or more of the three duplicate ACKs sent by the receiver could be lost on the reverse path, and the receiver might wait until it has received R more out-of-order segments before sending the next duplicate ACK. All this could slow down fast recovery and fast retransmit quite a bit. The use of SACK can help reduce the potential delay in detecting a lost packet. With SACK, a TCP sender can use the information in the SACK option to detect when the receiver has received at least three out-of-order data packets and to initiate fast retransmit and fast recovery in this case, even if the TCP sender has not yet received three duplicate ACKs.
先に引用したように、RFC 5681は、それが3つの重複確認応答を受信した後、パケットが失われたことを推測します。リバースパス上の輻輳があるときACK輻輳制御にのみ使用されるため、パケットロスの後に、受信機によって送信された3個の重複ACKの一つ以上は逆の経路で失われる可能性があり、それが受信されるまで受信機が待つかもしれませんより多くのアウト・オブ・オーダーセグメントの次の重複ACKを送信する前にR。このすべては、高速回復および高速再送かなり遅くなる可能性があります。 SACKの使用は、失われたパケットを検出する際の潜在的な遅延を減らすことができます。 SACKでは、TCPの送信者は、受信機は、少なくとも3アウトオブオーダーのデータパケットを受信したときを検出すると、TCPの送信者がいない場合でも、この場合には高速再送と高速リカバリを開始するためにSACKオプションで情報を使用することができますまだ3つの重複ACKを受け取りました。
It has been suggested that in some environments, the TCP receiver might want to set lower bounds on the ACK Ratio. For example, the TCP receiver might know from configuration or from past experience that the bandwidth on the return path is limited, and might want to set a lower bound (greater than two) on the ACK Ratio R. If this is included, this would require a TCP option from the TCP receiver to the TCP sender, reporting the lower bound on the ACK Ratio. Care would also be needed so that the lower bound on the ACK Ratio was only in effect when the TCP sender's congestion window was sufficiently high.
いくつかの環境では、TCP受信機はACK比率に下限を設定したいかもしれないことが示唆されています。たとえば、TCP受信機は設定からか、リターンパス上の帯域幅が制限されていることを過去の経験から知っているかもしれない、と下限を設定することをお勧めします（2より大きい）これが含まれている場合、これは希望ACK比RにACK率に下限を報告し、TCPの送信側へのTCP受信機からのTCPオプションが必要です。 TCPの送信側の輻輳ウィンドウが十分に高い場合ACK比の下限のみ有効であったように注意も必要であろう。
The receiver could send a delayed acknowledgement acknowledging a single packet, even when the ACK Ratio is two or more.
ACK比が2以上である場合でも受信機は、単一のパケットを認める遅延確認応答を送信することができます。
This should not cause false positives (when the TCP sender infers a loss when no loss happened). The TCP sender only infers that a pure ACK packet has been lost when no data packet has been lost and an ACK packet arrives acknowledging more than R new packets.
（TCPの送信者が何の損失が起こっていない損失を推論する場合）これは偽陽性が発生することはありません。 TCP送信側は何のデータパケットが失われていないとACKパケットがRの新しいパケットよりも多くを認める到着したときに、純粋なACKパケットが失われていることを推測します。
Delayed acknowledgements could, however, cause false negatives, with the TCP sender unable to detect the loss of an ACK packet sent as a delayed acknowledgement. False negatives seem acceptable; this would result in approximate ACK congestion control, which would be better than no ACK congestion control at all. In particular, when this form of false negative occurs, it is because the receiver is sending acknowledgements at such a low rate that it is sending delayed acknowledgements, rather than acknowledging at least R data packets with each acknowledgement.
遅延確認応答は、しかし、遅延確認応答として送信されたACKパケットの損失を検出することができませんでしTCPの送信者と、偽陰性を引き起こす可能性があります。偽陰性は、許容可能なようです。これはまったくのACK輻輳制御よりも良いだろうおおよそのACK輻輳制御をもたらすでしょう。偽陰性のこの形態が発生した場合、受信機は、それが遅延確認応答を送信するのではなく、それぞれの確認応答と少なくともRデータパケットを承認されているような低速度で肯定応答を送信しているので、特に、それがあります。
As discussed in Section 4.3, RFC 5681 states that "a TCP receiver SHOULD send an immediate duplicate ACK when an out-of-order segment arrives", and that "a TCP receiver SHOULD send an immediate ACK when the incoming segment fills in all or part of a gap in the sequence space" [RFC5681]. When ACK congestion control is used, the TCP receiver instead uses the guidelines from Section 4.6 to govern the sending of duplicate ACKs. More work would be useful to evaluate the advantages and disadvantages of this approach in terms of the potential delay in triggering fast retransmit, and to explore alternate possibilities.
4.3節で述べたように、RFC 5681は、着信セグメントが全てを埋めるとき、または「TCP受信機は即時ACKを送信する必要があることが、「アウト・オブ・オーダーセグメントが到着したときにTCP受信機はすぐに重複ACKを送信すべきである」と述べています配列空間におけるギャップの一部」[RFC5681]。 ACKの輻輳制御を使用する場合、TCP受信機ではなく、重複ACKの送信を管理するために、セクション4.6からのガイドラインを使用しています。より多くの仕事は、高速再送をトリガにおける潜在的な遅延の観点から、このアプローチの長所と短所を評価することは有用であろう、と代替可能性を探求します。
In a TCP connection with two-way traffic, the receiver could send some pure ACK packets and some acknowledgements piggybacked on data packets. The receiver would still follow the rule of only sending a pure ACK packet when there is a need for a delayed ACK or when there are R new data packets to acknowledge.
双方向のトラフィックとのTCP接続では、受信機は、いくつかの純粋なACKパケットとデータパケットに便乗いくつかの肯定応答を送信することができます。遅延ACKまたは承認するあるR、新たなデータパケットのために必要がある場合、受信機は、まだ純粋なACKパケットを送信するルールに従います。
In a connection with two-way traffic, the TCP sender would not always be able to infer when a pure ACK packet had been lost. For example, the receiver could send a pure ACK packet acknowledging packet K and, soon afterwards, the receiver could send a newly generated data packet for the reverse-path flow also acknowledging packet K. The pure ACK packet could be dropped in the network, and the sender would not be able to detect this drop.
双方向のトラフィックに関連して、TCPの送信者は、常に純粋なACKパケットが失われていた時に推測することはできません。例えば、受信機は、受信機は、純粋なACKパケットがネットワークにドロップすることができ、パケットK.を認めるリバースパスフローの新たに生成されたデータ・パケットを送信することができ、すぐにその後、パケットKを認める純粋なACKパケットを送信し、可能性送信者は、この低下を検出することができません。
Fortunately, there are limitations to the potential problems caused by undetected ACK losses in two-way traffic. The sender will only fail to detect the loss of a pure ACK packet if the ACK packet was followed by a data packet with the same acknowledgement number. If the reverse-path traffic for the connection is dominated by data traffic, then the congestion control for the data traffic is more important than the congestion control for the pure ACK traffic. If the reverse-path traffic is dominated by pure ACK traffic, then the sender would detect any losses of pure ACK packets followed by other pure ACK packets, and this would include most of the pure ACK packets for that connection. Thus, the sender's failure to detect the loss of a pure ACK packet followed by a data packet with the same acknowledgement number would not disable acknowledgement congestion control for a TCP connection with two-way traffic.
幸いなことに、双方向のトラフィックで検出されないACKの損失に起因する潜在的な問題には限界があります。送信者は、唯一のACKパケットが同じ確認応答番号を持つデータパケットが続いた場合には、純粋なACKパケットの損失を検出するために失敗します。接続のためのリバースパストラフィックは、データトラフィックによって支配されている場合は、データトラフィックの輻輳制御は、純粋なACKトラフィックの輻輳制御よりも重要です。リバースパストラフィックは、純粋なACKトラフィックによって支配されている場合、送信者は、他の純粋なACKパケットに続く純粋なACKパケットの任意の損失を検出するであろう、そしてこれは、その接続のための純粋なACKパケットのほとんどが含まれるであろう。このように、同じ確認応答番号のデータパケットに続く純粋なACKパケットの損失を検出するために、送信者の失敗は、双方向のトラフィックとTCP接続の確認輻輳制御を無効にしないでしょう。
It is possible for ACK packets to be reordered on the reverse path. The TCP sender could either use a parallel mechanism to the DupACK threshold to infer when an ACK packet has been lost, as with TCP, or, more robustly, the TCP sender could wait an entire round-trip time before inferring that an ACK packet has been lost [RFC4653].
ACKパケットが逆の経路上で並べ替えられることが可能です。 TCPの送信者は、または、より堅牢、TCPの送信側がACKパケットを持っていることを推論する前に、全体のラウンドトリップ時間を待つことができ、TCPと同様に、ACKパケットが失われた時に推論するのdupackしきい値にパラレルメカニズムを使用することができますいずれか[RFC4653]を失われました。
What happens when there are abrupt changes in the reverse path, such as from vertical handovers? Can there be any problems that would be worse than those experienced by a TCP connection that is not using ACK congestion control?
そのような垂直ハンドオーバなどからリバースパスの急激な変化は、あるときはどうなりますか？ ACKの輻輳制御を使用していないTCPコネクションが経験したものより悪化するだろう何か問題があることはできますか？
As with data packets, it is possible for ACK packets to be dropped in the network due to corruption rather than congestion. The current assumption of ACK congestion control is that all losses should be taken as indications of congestion. If there is ever some better mechanism for identifying and responding to corrupted TCP data packets, the same solution hopefully would apply to corrupted ACK packets as well.
ACKパケットが破損なく混雑に起因するネットワーク内でドロップするためのデータパケットと同様に、それが可能です。 ACK輻輳制御の現在の仮定は、すべての損失が輻輳の兆候として取られるべきであるということです。これまでに特定し、破損したTCPデータパケットに応答するいくつかの優れたメカニズムがある場合は、同じソリューションは、うまくいけば、同様破損したACKパケットに適用されます。
One problem with the interaction of packet corruption and congestion control, for both data and ACK packets, is that it is not always obvious when the packet corruption is related to congestion and when the packet corruption is independent of the level of congestion on the corrupting link. In environments where packet corruption exists and is independent of the level of congestion on the corrupting link, applying ACK congestion control would only make the connection more sensitive to ACK packet corruption by reducing the number of ACKs that are sent.
両方のデータおよびACKパケットのパケット破損や輻輳制御、との相互作用の1つの問題は、パケットの破損が混雑に関係しているとき、それは必ずしも明確ではないということであるパケットの破損が破損リンクの輻輳のレベルは独立しているとき。パケットの破損が存在し、破損リンクの輻輳のレベルとは無関係である環境では、ACK輻輳制御を適用することのみ送信されるACKの数を減らすことによって、ACKパケットの破損への接続がより敏感になるだろう。
It is possible for the ACK packets in a TCP connection to traverse a congested path where ACK packets are dropped but where the ACK packets themselves don't significantly contribute to the congestion on the path. In scenarios where ACK packets are dropped but where ACK traffic doesn't make a significant contribution of the congestion on the path, the use of ACK congestion control would not contribute to reducing the aggregate congestion on the path. In this case, one goal is to minimize the negative impact of ACK congestion control on the overall performance of the TCP connection.
TCPコネクションでのACKパケットが輻輳ACKパケットがドロップされるパスが、どこACKパケット自体が大幅にパス上の混雑に寄与しないを通過することが可能です。 ACKパケットがドロップされるシナリオではなくACKトラフィックがパス上の混雑の重要な貢献をしていない場合は、ACKの輻輳制御の使用は、パス上の集約混雑削減に貢献しないでしょう。この場合、一つの目標は、TCP接続の全体的なパフォーマンス上のACK輻輳制御のマイナスの影響を最小限に抑えることです。
J TCP conns. link L -> J TCP conns.
data -> |---| |---| <- ACKs
<-------------> | | | | <------------->
| | <-------------> | |
<-------------> | | | | <------------->
K TCP conns. |---| |---| K TCP conns.
ACKs -> <- link L1 <- data
Figure 2. A Scenario with J Forward and K Reverse TCP Connections
JフォワードおよびKリバースTCP接続を有する図2のシナリオ
To explore the relative contribution of ACK traffic on congestion, it is useful to consider a simple scenario with a congested unidirectional link L carrying data traffic from J TCP connections (the forward TCP connections) and ACK traffic from K TCP connections (the reverse TCP connections). We assume that all TCP connections have the same round-trip time R and the same data packet size S of 1500 bytes. We further assume that all of the forward TCP connections have the same data packet drop rate p and the same congestion window W, and that all of the reverse TCP connections have the same congestion window W1 and the same ACK packet drop rate p1. (The packet drop rate for data packets is defined as the fraction of arriving data packets that are dropped; similarly, the packet drop rate for ACK packets is the fraction of arriving ACK packets that are dropped.) The J TCP connections each use a bandwidth on link L of 1500*W/R bytes per second, and the K TCP connections, without ACK congestion control, each use a bandwidth on link L of 40*(W1/2)/R bytes per second. This gives a ratio of 75*(J/K)*(W/W1) for TCP data bandwidth to TCP ACK bandwidth on link L. The ratio J/K is the ratio between the number of forward and reverse TCP connections on link L, and could have a wide range of values (e.g., large for an access link from a web server, and small for an access link to a web server). For this scenario, the ratio W/W1 is largely a function of the different levels of congestion on the forward and reverse paths.
混雑のACKトラフィックの相対的な寄与を調べるために、K TCPコネクションからJのTCPコネクション（前方TCPコネクション）とACKトラフィック（リバースTCP接続からのデータトラフィックを運ぶ混雑単方向リンクLとの単純なシナリオを考慮することが有用です）。我々は、すべてのTCP接続が同じラウンドトリップ時間Rと1500バイトの同じデータパケットサイズSを持っていることを前提としています。私たちは、さらに前方のTCP接続のすべてが同じデータパケットのドロップ率pと同じ輻輳ウィンドウWを持っていることを前提とし、逆TCP接続のすべてが同じ輻輳ウィンドウW1と同じACKパケットのドロップ率P1を持っていること。 （データパケットのパケットドロップ率が廃棄されたデータパケットを到着の割合として定義される;同様に、ACKパケットのパケットドロップ率がドロップされるACKパケットの到着の一部である）はそれぞれ帯域幅を使用J TCP接続を1500のリンクL上* W / Rは、秒あたりのバイト数、およびK TCP接続、ACK輻輳制御することなく、それぞれが40 *のリンクL（W1 / 2）の帯域幅を使用する/ Rは、秒あたりのバイト数。これは、比J / Kが前方の数との比であるリンクL上のTCP接続を逆方向リンクL上にTCP ACK帯域幅にTCPデータ帯域幅のために75 *の比（J / K）*（W / W1）を与えます、および（例えば、Webサーバからのアクセスリンクのための大規模、およびWebサーバへのアクセスリンクのための小さな）値の広い範囲を持つことができます。このシナリオでは、比W / W1は、主に、前方に渋滞の異なるレベルの関数であり、経路を逆。
To explore the possibilities, we will consider some of the range of congestion control mechanisms for the congested link. First, we consider scenarios where the limitation on the congested path is in the link bandwidth in bytes per second.
可能性を探るために、我々は混雑リンクの輻輳制御機構の範囲のいくつかを検討します。まず、私たちは混雑し、パス上の制限はバイト毎秒リンクの帯域幅であるシナリオを検討してください。
Cases (1), (2), (3), (5), and (7) below represent the best scenarios for ACK congestion control, where the fraction of packet drops for TCP ACK packets roughly matches the TCP ACK packets' contribution to congestion. (In several of these cases this is, at best, a rough match because the data packets are a factor in the bandwidth and in the queue limitations, while the TCP ACK packets are only a factor in the queue limitations.) Cases (4) and (8) below represent problematic scenarios where the fraction of packet drops for TCP ACK packets is much higher than the TCP ACK packets' contribution to congestion (in terms of taking space in a congested queue, using scarce CPU cycles at the congested router, or using scarce bandwidth). Case (6) below represents scenarios where ACK congestion control would not be effective because it would not be invoked. In the scenarios in case (6), the fraction of packet drops for TCP ACK packets would be much smaller than the TCP ACK packets' contribution to congestion.
ケース（1）、（2）、（3）、（5）、（7）以下のTCP ACKが略へのTCP ACKパケットの寄与と一致するパケットのためのパケットの割合が低下する場合、ACK輻輳制御のための最良のシナリオを表します混雑。 （TCP ACKパケットがキューの制限で唯一の要因である一方、データパケットは、帯域幅およびキュー制限する要因であるため、これらの例のいくつかでは、これは、最高の状態で、ラフな試合である。）ケース（4） （8）以下、輻輳ルータに乏しいCPUサイクルを使用して、輻輳キューにスペースを取るという点で混雑（へのTCP ACKパケットの寄与よりはるかに高いパケットの割合がTCP ACKパケットのドロップ問題のシナリオを表しますまたは）希少な帯域幅を使用します。ケースは、下記（6）が起動されないので、ACK輻輳制御が有効でないシナリオを表します。 TCP ACKパケットが輻輳のTCP ACKパケットの寄与よりはるかに小さいであろうための場合のシナリオでは（6）、パケットの割合が低下します。
(1) The Drop-Tail queue for link L is measured in packets. In this case, the congested queue can accommodate N packets (regardless of packet size), there is a limitation of both bandwidth in bytes per second and also in queue space in packets, and large data packets and small TCP ACK packets should see similar packet drop rates. Although TCP ACK packets most likely aren't a major factor in the bandwidth limitation, they can be a significant contribution to the limitation of queue space. So, while the packet drop rate for ACK packets could be high in times of congestion, the ACK packets are contributing to that congestion somewhat by using scarce buffer space.
（1）リンクLのドロップテールキューがパケットで測定されます。この場合、輻輳キューが秒あたりのバイト数の両方の帯域幅の制限があり、またパケット内のキュー・スペースに、大きなデータパケットと小さなTCPのACKパケットが同様のパケットを参照しなければならない、（かかわらず、パケットサイズの）N個のパケットを収容することができます速度を落とします。 TCP ACKパケットが最も可能性の高い帯域幅の制限の主要な要因ではないですが、彼らは、キュースペースの制限に大きく貢献することができます。 ACKパケットのパケットドロップ率が混雑の時代に高い可能性がありながら、そう、ACKパケットが乏しいバッファ・スペースを使用することにより、多少その混雑に貢献しています。
(2) The Drop-Tail queue is measured in bytes. In this case, the congested queue can accommodate M bytes of packets, and TCP ACK packets don't make a significant contribution to either the bandwidth limitation or to the limitation in queue space. It is also the case that, in this scenario, even if there is heavy congestion, the packet drop rate for TCP ACK packets should be small (because small ACK packets can often find space on the congested queue when large data packets can't find space). In this case, ACK congestion control should not present any problems; the TCP ACK packets aren't contributing significantly to congestion and aren't experiencing significant packet drop rates.
（2）ドロップテールキューはバイト単位で測定されます。この場合、混雑したキューは、パケットのMバイトを収容することができ、およびTCP ACKパケットは、帯域幅の制限のいずれかまたはキュースペースの制限に重要な貢献をすることはありません。大きなデータパケットを見つけることができないとき、小さなACKパケットがしばしば混雑キュー上のスペースを見つけることができるので、それは（また、このシナリオでは、混雑があっても、TCP ACKパケットのパケットドロップ率が小さいはずである、そうですスペース）。この場合、ACK輻輳制御は、任意の問題を提示してはなりません。 TCP ACKパケットが輻輳に大きく貢献されておらず、重要なパケットのドロップ率を経験していません。
(3) The RED queue is in packet mode and is measured in packets. This is similar to case (1) above. Because the queue is measured in packets, small TCP ACK packets contribute to the limitation in queue space but not to the limitation in link bandwidth. Because the queue is in packet mode, large data packets and small TCP ACK packets should see similar packet drop rates.
（3）REDキューがパケット・モードにあり、パケットに測定されます。これは、（1）上記の場合と同様です。キューがパケットで測定されているので、小さなTCPのACKパケットがキュー・スペースに制限のために貢献ではなく、リンク帯域幅の制限に。キューがパケットモードになっているので、大きなデータパケットと小さなTCPのACKパケットは、同様のパケットドロップ率が表示されるはずです。
(4) The RED queue is in packet mode but is measured in bytes. Because the queue is measured in bytes, small TCP ACK packets don't contribute significantly to either the limitation in queue space or to the limitation in link bandwidth. Because the queue is in packet mode, large data packets and small TCP ACK packets should see similar packet drop rates. If it existed, this case would be problematic, because the TCP ACK packets would not be contributing significantly to the congestion but they would see a similar packet drop rate as the large data packets that are contributing to congestion.
（4）REDキューがパケット・モードであるが、バイト単位で測定されます。キューがバイト単位で測定されているので、小さなTCPのACKパケットがキュースペース内またはリンク帯域幅の制限に制限のどちらかに大きく寄与していません。キューがパケットモードになっているので、大きなデータパケットと小さなTCPのACKパケットは、同様のパケットドロップ率が表示されるはずです。それは存在していた場合は、TCP ACKパケットが輻輳に大きく貢献されないので、この場合は、問題となるが、彼らは混雑に貢献している大規模なデータパケットと同様のパケット廃棄率を見るであろう。
(5) The RED queue is in byte mode and is measured in bytes. This is similar to case (2) above. Because the queue is measured in bytes, small TCP ACK packets don't contribute significantly to either the limitation in queue space or to the limitation in link bandwidth. At the same time, because the queue is in byte mode, small TCP ACK packets see much smaller packet drop rates than those of large data packets.
（5）REDキューは、バイトモードであり、バイト単位で測定されます。これは、上記（2）の場合と同様です。キューがバイト単位で測定されているので、小さなTCPのACKパケットがキュースペース内またはリンク帯域幅の制限に制限のどちらかに大きく寄与していません。キューがバイトモードであるため、同時に、小さなTCPのACKパケットが大きなデータパケットのものよりはるかに小さいパケットドロップ率を参照してください。
(6) The RED queue is in byte mode but is measured in packets. Because the queue is measured in packets, small TCP ACK packets contribute to the limitation in queue space but not to the limitation in link bandwidth. Because the queue is in byte mode, small TCP ACK packets see much smaller packet drop rates than those of large data packets. If this case existed, TCP ACK packets would contribute somewhat to congestion but would see a much smaller packet drop rate than that of large data packets.
（6）REDキューはバイトモードであるが、パケットで測定されます。キューがパケットで測定されているので、小さなTCPのACKパケットがキュー・スペースに制限のために貢献ではなく、リンク帯域幅の制限に。キューがバイトモードになっているので、小さなTCPのACKパケットが大きなデータパケットのものよりはるかに小さいパケットドロップ率を参照してください。この場合には存在していた場合は、TCPのACKパケットが輻輳に多少貢献するだろうが、大きなデータパケットのそれよりもはるかに小さいパケットドロップ率を見るであろう。
Next, we consider scenarios where the limitation on the congested link is in CPU cycles at the router in packets per second, not in bandwidth in bytes per second.
次に、私たちは混雑したリンク上の制限は、秒あたりのパケットではなく、秒あたりのバイト数で、帯域幅のルータでCPUサイクルであるシナリオを検討してください。
(7) The CPU load imposed by TCP ACK packets is similar to the load imposed by other packets (e.g., TCP data packets). ACK congestion control would be useful in this scenario, particularly if TCP ACK packets saw the same packet drop rates as TCP data packets.
（7）TCP ACKパケットによって課さCPU負荷は、他のパケット（例えば、TCPデータパケット）によって課される負荷と同様です。 ACKの輻輳制御は、TCP ACKパケットがTCPデータパケットと同一のパケットドロップ率を見た場合は特に、このシナリオで有用であろう。
(8) The CPU load imposed by TCP ACK packets is much less than the load imposed by other packets (e.g., TCP data packets). If TCP ACK packets saw a smaller packet drop rate than TCP data packets, then the TCP ACK packet drop rate would roughly match the TCP ACK packets' contribution to congestion, and this would be good. If TCP ACK packets saw the same packet drop rate as TCP data packets, this case would be problematic, because the TCP ACK packets would not be contributing significantly to the congestion, but they would see a similar packet drop rate as the large data packets that are contributing to congestion.
（8）TCP ACKパケットによって課さCPU負荷は、他のパケット（例えば、TCPデータパケット）によって課される負荷よりもはるかに小さいです。 TCP ACKパケットがTCPデータパケットよりも小さいパケットドロップ率を見た場合、TCP ACKパケットのドロップ率は大体混雑へのTCP ACKパケットの貢献に一致し、これが良いでしょう。 TCP ACKパケットがTCPデータパケットと同一のパケット廃棄率を見た場合、TCP ACKパケットが輻輳に大きく貢献することがないので、この場合は、問題となるが、彼らは大きなデータパケットと同様のパケット廃棄率を見るであろうこと混雑に貢献しています。
It has been reported in IETF meetings that current TCP implementations do not always acknowledge at least every other data packet, as required by the TCP specifications. In particular, it has been reported that if a TCP receiver receives many data packets in a burst, before it is able to send an acknowledgement, then it might send a single acknowledgement for the burst of packets. We note that such a behavior would cause complications for a TCP connection that used ACK congestion control, as the sender would not be able to determine when an ACK packet had been dropped in the network or when the packet had been skipped by the receiver because it was processing a burst of data packet arrivals.
これは、TCPの仕様で要求される現在のTCP実装は常に、少なくとも他のすべてのデータパケットを承認していないIETF会議で報告されています。特に、確認応答を送信することが可能である前に、TCP受信機が、バーストで多くのデータパケットを受信した場合、それはパケットのバーストのための単一の確認応答を送信するかもしれないと報告されています。私たちは、送信者が決定することができないとして、ACKパケットがネットワークで落とされていた場合、またはパケットがそのために受信機によってスキップされていたとき、このような行動は、ACKの輻輳制御を使用し、TCP接続のための合併症を引き起こすことに注意してくださいデータパケット到着のバーストを処理しました。
One possibility for addressing this problem would be for TCP receivers using ACK congestion control to be required to send an acknowledgement for each R packets, for ACK Ratio R. In this case, if the receiver received a large burst of data packets back-to-back, the receiver would be required to send a responding burst of ACK packets, one for each set of R data packets.
受信機は、バック・ツー・データ・パケットの大バーストを受信した場合は、この問題に対処するための一つの可能性は、この場合、ACK比Rのため、各Rパケットに対する肯定応答を送信するために必要であることがACK輻輳制御を使用して、TCP受信機のためになりますバック、受信機は、ACKパケットの応答バースト、Rデータパケットの各セットのための1つを送信するために必要とされるであろう。
A second possibility for addressing this problem would be to define a TCP option or flag that the TCP receiver could use when sending an ACK packet to inform the sender that the TCP receiver `skipped' some ACK packets, so that the sender should not infer ACK loss if some previous ACK packets seem to be missing.
この問題に対処するための第2の可能性は、送信側がACKを推測しないように、TCP受信機は `」いくつかのACKパケットをスキップし、送信者に通知するACKパケットを送信するときにTCP受信機が使用できるTCPオプションまたはフラグを定義することです損失いくつかの以前のACKパケットが欠落しているように見える場合。
Future work will explore the costs and benefits of these two approaches.
今後の課題は、これら2つのアプローチの費用と便益を探求します。
One possible complication would be the interaction of ACK congestion control with router-based or middlebox-based ACK mechanisms, such as ACK filtering along the reverse path ([BPK97], [WWCM99], [BA03], [KLS07]). We are not aware of the deployment of ACK filtering in the Internet, but any testing of ACK congestion control would have to look for interactions with any middlebox-based mechanisms regarding ACK packets. In particular, we would consider interactions of ACK congestion control with the possible deployment of ACK filtering on satellite links, cable modems, or the like.
一つの可能性のある合併症は、逆パス（[BPK97]、[WWCM99]、[BA03]、[KLS07]）に沿ってACKフィルタリングなどのルータベースまたはミドルベースのACKメカニズムを有するACK輻輳制御の相互作用であろう。私たちは、インターネットでのACKフィルタリングの展開を認識していないですが、ACK輻輳制御のいずれかのテストでは、ACKパケットに関するいかなるミドルベースのメカニズムとの相互作用を探す必要があります。特に、我々は衛星リンク、ケーブルモデム等のACKフィルタリングの有効な配置とACKの輻輳制御の相互作用を検討します。
The mechanism for adjusting the ACK Ratio is designed with the goal of having the TCP receiver send at least two ACKs in response to each window of at least four full-sized data packets. However, with ACK congestion control in combination with a data-limited sender, it is possible for the sender to send at least four full-sized data packets in a round-trip time, with the receiver sending less than two ACKs in response.
ACKの比率を調整するための機構は、TCP受信機が少なくとも4つのフルサイズのデータ・パケットの各ウィンドウに対応して少なくとも二つのACKを送信することの目的で設計されています。送信側は受信側が応答して2つの未満のACKを送信すると、往復時間に少なくとも4つのフルサイズのデータパケットを送信するためしかし、データが制限された送信者と組み合わせてACK輻輳制御と、それが可能です。
As an example, consider a connection where the sender's congestion window W is greater than four and the ACK Ratio R is at its maximum value of W/2. If the sender becomes data-limited and sends less than W data packets in a round-trip time, then the receiver can send less than two ACK packets in response. This behavior makes the connection more sensitive to the loss of an occasional ACK packet.
一例として、送信側の輻輳ウィンドウWが4より大きく、ACK比率RがW / 2の最大値にある接続を考えます。送信者は、データ制限になり、ラウンドトリップ時間でWデータパケット未満を送信する場合、受信機は対応して2つ未満のACKパケットを送信することができます。この動作は、時折ACKパケットの損失への接続がより敏感になります。
Of course, there is still the safety mechanism of the receiver sending an ACK packet when the delayed ACK timer expires. However, more work would be useful to explore the conflicting goals of a congestion-controlled ACK flow and a timely ACK response to the sender for the specific case of a connection with a data-limited sender and a congested ACK path.
もちろん、遅延ACKタイマが満了したときにACKパケットを送信し、受信機の安全機構が依然として存在します。しかし、より多くの仕事は、輻輳制御のACKフローとデータが制限された送信者と混雑ACKパスとの接続の特定の場合のために、送信者へのタイムリーなACK応答の相反する目標を探求することは有用であろう。
Are there any problems caused by the combination of two-way traffic and reordering? Or other issues that have not yet been addressed?
双方向のトラフィックと並べ替えの組み合わせによって引き起こされる問題はありますか？それとも、まだ対処されていない他の問題？
Evaluating ACK congestion control will have two components: (1) evaluating the effects of ACK congestion control on an individual TCP connection, and (2) evaluating the effects of ACK congestion control on aggregate traffic (including the effects of ACK congestion control on the aggregate congestion of the path).
（1）個々のTCP接続上でACK輻輳制御の効果を評価する、及び（2）（骨材上のACK輻輳制御の影響を含む集約トラフィックにACK輻輳制御の影響を評価：評価ACK輻輳制御は、2つの成分を有することになりますパスの輻輳）。
The first part, evaluating ACK congestion control on the performance of an individual TCP connection, will have to examine those scenarios where ACK congestion control might help the performance of a TCP connection and those scenarios where the use of ACK congestion control might cause problems.
最初の部分は、個々のTCP接続のパフォーマンスにACK輻輳制御を評価し、ACKの輻輳制御はTCP接続とACKの輻輳制御の使用は問題を引き起こす可能性があり、これらのシナリオのパフォーマンスを助けるかもしれない、これらのシナリオを検討する必要があります。
The second part, evaluating the effects of ACK congestion control on aggregate traffic, should consider scenarios where the use of ACK congestion control helps all of the connections sharing a path by reducing the aggregate congestion on the path. This part should also see if there are scenarios where ACK congestion control causes problems by increasing the burstiness of aggregate traffic or by otherwise changing traffic dynamics.
第二部では、集約トラフィック上のACK輻輳制御の効果を評価し、ACKの輻輳制御の使用は、パス上の集約混雑を減らすことによって、パスを共有するすべての接続を助けシナリオを検討すべきです。 ACKの輻輳制御が集約トラフィックのバースト性を増加させることにより、またはその他のトラフィックのダイナミクスを変更することで問題が発生したシナリオがある場合は、この部分にも表示されるはずです。
One possible benefit of ACK congestion control is that it could reduce contention in wireless links, shared Ethernet, or other environments with contention between forward-path and reverse-path traffic ([AJ03], [KIA07]). At the same time, contention on the shared medium won't necessarily result in dropped ACK packets, and therefore wouldn't necessarily be detected by ACK congestion control.
ACK輻輳制御の一つの可能な利点は、無線リンクでの競合を減少させることができることで、往路と逆パストラフィック（[AJ03]、[KIA07]）間の競合とイーサネット（登録商標）、または他の環境を共有しました。同時に、共有媒体上の競合が必ずしもドロップACKパケットをもたらさないであろう、従って必ずしもACK輻輳制御によって検出されません。
Some TCP hosts send keep-alive packets when no data or ACK packets have been received over a long period of time [KEEP-ALIVE]. This keep-alive mechanism is not addressed in TCP specifications. However, such keep-alive packets, if used, should not interact with ACK congestion control one way or another. For ACK congestion control, the ACK Ratio is set small enough to allow the receiver to generally send at least two ACKs for a window of data. In addition, the receiver uses a delayed ACK timer with the ACK Ratio, always sending an acknowledgement if the delayed ACK timer expires. Thus, ACK congestion control will never cause the receiver to delay indefinitely in sending an acknowledgement for a received data packet.
何のデータやACKパケットが、時間の長い期間にわたって受信されていない場合、一部のTCPホストが[キープアライブ]キープアライブパケットを送信します。このキープアライブメカニズムは、TCPの仕様で対処されていません。しかし、そのようなキープアライブパケットは、使用している場合、ACK輻輳制御一つの方法または別と相互作用しないはずです。 ACK輻輳制御のために、ACK率が受信機は、一般に、データのウィンドウに対して少なくとも二つのACKを送信することを可能にするために十分に小さく設定されています。また、受信機は、遅延ACKタイマが満了した場合、常に確認応答を送信し、ACK比で遅延ACKタイマを使用しています。このように、ACKの輻輳制御は、受信機が受信したデータパケットに対する肯定応答を送信するに無期限に延期する原因は決してありません。
Some TCP implementations send pure ACK packets as window probes, to solicit an ACK packet from the other end with current window information. Such ACK packets will generally be orthogonal to the ACK congestion control specified in this document.
いくつかのTCP実装は、現在のウィンドウ情報ともう一方の端からACKパケットを勧誘するために、ウィンドウプローブとして、純粋なACKパケットを送信します。そのようなACKパケットは、一般的に、この文書で指定されたACK輻輳制御に直交するであろう。
TCP receivers also can send pure ACK packets as window update packets announcing a new value for the receive window, even when the acknowledgement number and SACK options in the ACK packet are not new. The receiver may send window update packets even if the ACK congestion control mechanism would say that it is not time yet to send a pure ACK. The sender will not necessarily be able to detect the loss of a window update ACK packet.
TCP受信機はまた、ACKパケットで確認応答番号とSACKオプションは新しいものではない場合でも、受信ウィンドウの新しい値を発表するウィンドウ更新パケットとして純粋なACKパケットを送信することができます。 ACK輻輳制御機構は、それが純粋なACKを送信するためにはまだ時間がないことを言う場合でも、受信機は、ウィンドウ更新パケットを送信することができます。送信者は必ずしもウィンドウアップデートACKパケットの損失を検出することができません。
There are a number of studies about the traffic composition on various links in the Internet, reporting the fraction of bandwidth used by TCP data and by TCP ACK traffic [Studies].
[研究] TCPデータによっておよびTCP ACKのトラフィックが使用する帯域幅の割合を報告し、インターネットでさまざまなリンク上のトラフィックの組成について多くの研究があります。
Are there any studies that show the relative packet drop rates for TCP data and ACK traffic, for particular links or for particular TCP connections?
特定のリンクまたは特定のTCP接続のために、TCPデータとACKトラフィックの相対的なパケット廃棄率を示し、いずれの研究はありますか？
Are there any studies of congested links that show the fraction of traffic on the congested link, or in the congested queue, that consist of TCP ACK packets?
TCP ACKパケットで構成されて混雑したリンク上のトラフィックの割合を示し、または混雑キューで混雑したリンク、のいずれかの研究がありますか？
In the transport protocol DCCP [RFC4340], the congestion control mechanism for the CCID 2 profile is based on that of TCP. This section briefly discusses some of the issues that have been addressed in the acknowledgement congestion control already standardized in CCID 2 [RFC4341].
トランスポート・プロトコルDCCP [RFC4340]において、CCID 2プロファイルの輻輳制御機構は、TCPのものに基づいています。このセクションでは、簡単に、すでにCCID 2 [RFC4341]で標準化承認輻輳制御で対処されている問題のいくつかを説明します。
Rate-based pacing:
レートベースペーシング：
For CCID 2, RFC 4341 says that "senders MAY use a form of rate-based pacing when sending multiple data packets liberated by a single ACK packet, rather than sending all liberated data packets in a single burst." However, rate-based pacing is not required in CCID 2.
CCID 2については、RFC 4341「は、単一のACKパケットによって遊離複数のデータパケットを送信するときの送信者ではなく、単一のバースト内の全て解放されたデータパケットを送信するよりも、レートベースペーシングのフォームを使用するかもしれません。」と述べていますしかし、レートベースペーシングがCCID 2で必要とされていません。
Increasing the congestion window:
輻輳ウィンドウの増加：
For CCID 2, RFC 4341 says that "when cwnd < ssthresh, meaning that the sender is in slow-start, the congestion window is increased by one packet for every two newly acknowledged data packets with ACK Vector State 0 (not ECN-marked), up to a maximum of ACK Ratio/2 packets per acknowledgement. This is a modified form of Appropriate Byte Counting [RFC3465] that is consistent with TCP's current standard (which does not include byte counting), but allows CCID 2 to increase as aggressively as TCP when CCID 2's ACK Ratio is greater than the default value of two. When cwnd >= ssthresh, the congestion window is increased by one packet for every window of data acknowledged without lost or marked packets."
CCID 2については、RFC 4341には、ときにcwnd <ssthreshを、送信側はスロースタートであることを意味し、輻輳ウィンドウはACKベクトル状態0（ECN-マークされていない）との2つのずつ、新たに承認されたデータパケットのための一つのパケットによって増加する」と述べています、肯定応答あたりACK比/ 2パケットの最大まで。これは、適切なバイトカウント（バイトカウントを含まない）TCPの現在の標準と一致している[RFC3465]の改変された形態であるが、CCID 2のように積極的に増加することができTCPとしてCCID 2のACK比率は、2のデフォルト値よりも大きいとき。にcwnd> = SSTHRESH、輻輳ウィンドウは、データのすべてのウィンドウのために1つのパケット増加失われたり、マークされたパケットなしで承認された場合。」
What are the sender's incentives to cheat on ACK congestion control? What are the receiver's incentives to cheat? What are the avenues open for cheating?
ACKの輻輳制御でカンニングをするために、送信者のインセンティブは何ですか？カンニングする受信機のインセンティブは何ですか？不正行為のためのオープンな道は何ですか？
As long as ACK congestion control is optional, neither host can be forced to use ACK congestion control if it doesn't want to. So ACK congestion control will only be used if the sender or receiver have some chance of receiving some benefit.
限りACK輻輳制御がオプションであるとして、どちらのホストはそれはしたくない場合はACK輻輳制御を使用するように強制することができます。送信側または受信側が何らかの利益を受けるのいくつかのチャンスを持っているのであればACK輻輳制御にのみ使用されます。
As long as ACK congestion control is optional for TCP, there is little incentive for the TCP end nodes to cheat on non-ECN-based ACK congestion control. There is nothing now that requires TCP hosts to use congestion control in response to dropped ACK packets.
限りACK輻輳制御はTCPのためのオプションであるとして、TCPのエンドノードが非ECNベースのACK輻輳制御でカンニングをするために少し動機が存在します。今では、ドロップされたACKパケットに応じて輻輳制御を使用するTCPホストを必要とするものは何もありません。
What avenues for cheating are opened by the use of ECN-Capable ACK packets? If the end nodes can use ECN to have ACK packets marked rather than dropped, and if the end nodes can then avoid the use of ACK congestion control that goes along with the use of ECN on ACK packets, then the end nodes could have an incentive to cheat. Senders could cheat by not instructing the receiver to use a higher ACK Ratio; the receiver would have a hard time detecting this cheating. Receivers could cheat by not using the ACK Ratio they were instructed to use, but senders could easily detect this cheating. However, receivers could also cheat by not using ACK congestion control and still sending ACK packets as ECN-Capable, so ACK congestion control is not a necessary component for receivers to cheat about sending ECN-Capable ACK packets. One question would be whether there is any way for receivers to cheat about sending ECN-Capable ACK packets and not using appropriate ACK congestion control without this cheating being easily detected by the sender.
不正行為のためにどのような道は、ECN対応のACKパケットを使用して開かれていますか？エンド・ノードは、ACKパケットがドロップされたのではなく、マーク、およびエンド・ノードは、その後ACKパケットのECNの使用と一緒に行くACK輻輳制御の使用を避けることができれば、その後、エンド・ノードは、インセンティブを持つことができる持っているECNを使用できる場合カンニングする。送信者は、より高いACK比率を使用するための受信機を指示していないことでカンニングでした。受信機は、この不正行為を検出する苦労を持っているでしょう。レシーバは、彼らが使用するように指示されたACKの比率を使用していないことでカンニングこともできますが、送信者が簡単にこの不正行為を検出することができました。しかしながら、受信機はまた、ACK輻輳制御を使用して、まだECN-できるようにACKパケットを送信しないことによってごまかすことができ、そうACK輻輳制御は、受信機がECN-可能なACKパケットを送信についてカンニングするために必要な構成要素ではありません。一つの疑問は、受信機は、この不正行為を簡単に送信者によって検出されることなく、適切なACK輻輳制御を使用してECN対応のACKパケットを送信していない約カンニングするためにどのような方法があるかどうかだろう。
What about the ability of routers or middleboxes to detect TCP receivers that cheat by inappropriately sending ACK packets as ECN-Capable? The router will only know if the receiver is authorized to send ACK packets as ECN-Capable if the router can see traffic on both the forward and reverse paths and monitored both the SYN and SYN/ACK packets (and was able to read the TCP options in the packet headers). If ACK congestion control has been negotiated, the router will only know if ACK congestion control is being used correctly by the receiver if it can monitor the ACK Ratio options sent from the sender to the receiver. If ACK congestion control is being used, the router will not necessarily be able to tell if ACK congestion control is being used correctly by the sender, because drops of ACK packets might be occurring after the ACK packets have left the router. However, if the router sees the ACK Ratio options sent from the sender, the router will be able to tell if the sender is correctly accounting for those ACK packets that are dropped or ECN-marked on the path from the receiver to the router.
どのような不適切ECN対応としてACKパケットを送信することにより、カンニングTCP受信機を検出するために、ルータやミドルボックスの能力についてはどうですか？ルータは、受信機が、ルータが両方の前方上のトラフィックを参照してパスを逆にすることができた場合にECN対応としてACKパケットを送信することを許可し、両方のSYNおよびSYN / ACKパケットを監視されているかどうかを知る（およびTCPオプションを読むことができただろうパケットヘッダ中）。 ACKの輻輳制御が交渉された場合は、受信機に送信者から送られたACK比のオプションを監視することができた場合にACK輻輳制御は、受信機によって正しく使用されている場合、ルータは知っているだろう。 ACK輻輳制御が使用されている場合、ルータは必ずしもACKパケットがルータを去った後、ACKパケットのドロップが発生する可能性があるため、ACKの輻輳制御は、送信者が正しく使用されている場合伝えることができなくなります。ルータは、送信者から送られたACK比のオプションを見ている場合は、ルータは、送信者が正しくルータへの受信機からのパスにドロップまたはECN-マークされ、それらのACKパケットを占めている場合伝えることができるようになります。
No IANA action is needed at this time. If this document was advanced as Experimental or Proposed Standard, then IANA would allocate the option numbers for the two TCP options, the ACK Congestion Control Permitted option, and the ACK Ratio option. In such a case, the following two lines would be added to the TCP Option Numbers registry (maintained by IANA -- http://www.iana.org):
IANAのアクションは、この時点では必要ありませんありません。この文書は、実験や標準化提案として進められた場合には、IANAは、2つのTCPオプション、ACK輻輳制御許可オプション、およびACK比率オプションのオプション番号を割り当てます。このような場合には、次の2行は（IANAによって維持 - http://www.iana.org）TCPオプション番号のレジストリに追加されるであろう。
Kind Length Meaning Reference
---- ------ --------------------------------- -----------
TBD1 2 ACK Congestion Control Permitted [RFCXXXX]
TBD2 3 ACK Ratio [RFCXXXX]
In the absence of TCP option numbers allocated by IANA, experimenters may use the TCP Option Numbers set aside for Experimentation in RFC 4727 [RFC4727]. As stressed in Section 1 of RFC 3692 [RFC3692], the TCP Option Numbers in the experimental range are intended for experimentation and testing and not for wide or general deployments; these option numbers could be in use by other experimentors for other purposes.
IANAによって割り当てられたTCPオプション番号がない場合、実験者は、RFC 4727 [RFC4727]に実験のために確保されたTCPオプション番号を使用してもよいです。 RFC 3692 [RFC3692]のセクション1で強調したように、実験範囲内のTCPオプション番号は、実験とテストのためではなく、広い又は一般的な展開のために意図されています。これらのオプション番号は、他の目的のために他のexperimentorsによって使用中である可能性があります。
This document specifies a congestion control mechanism for acknowledgement (ACKs) traffic for TCP and discusses the possible complications. We are deferring a recommendation on the use of this mechanism for TCP until it has been evaluated more fully.
このドキュメントは、TCPに対する肯定応答（ACKの）トラフィックのための輻輳制御メカニズムを指定し、可能な合併症について説明します。それは、より完全に評価されるまで私たちは、TCPのために、このメカニズムの使用に関する勧告を延期しています。
Many thanks for feedback from Mark Allman, Armando Caro, Alfred Hoenes, Ilpoo Jarvinen, Sara Landstrom, Anantha Ramaiah, and Michael Welzl, and for contributed text from Michael Welzl.
マーク・オールマン、アルマンドカロ、アルフレッドHoenes、Ilpoo Jarvinen、サラLandstrom、Anantha Ramaiah、そしてマイケル・Welzlからのフィードバックのために、そしてマイケル・Welzlから貢献したテキストのための多くのおかげで。
Appendix A. Related Work
付録A.関連作品
There exist several papers dealing with controlling congestion in the reverse path of a TCP connection, especially in the context of networks with bandwidth asymmetry. Some of these proposals require explicit support from routers or middleboxes, whereas others are "pure" end-to-end schemes.
特に帯域幅の非対称性を持つネットワークの文脈では、TCPコネクションの逆の経路で輻輳制御を扱ういくつかの論文が存在します。他の人が「純粋な」エンド・ツー・エンドのスキームあるのに対し、これらの提案のいくつかは、ルーターやミドルボックスからの明示的なサポートを必要とします。
RFC 3449 [RFC3449] discusses TCP performance problems that arise in TCP connections over asymmetric paths. Section 3 of RFC 3449 describes in detail how congestion on the ACK path can affect overall TCP performance. RFC 3449 also outlines a number of proposed mitigations, including ACK congestion control. The experimental ACK congestion control mechanism discussed in that RFC relies on ECN, with the TCP sender detecting congestion on the ACK path from ECN-marked packets. RFC 3449 also discusses two receiver-based mechanisms, the Window Prediction Mechanism (WPM) [CLP98] and Acknowledgement based on Cwnd Estimation (ACE) [MJW00], for using a dynamic ACK Ratio. RFC 3449 also considers link- and network-layer techniques that address congestion on the upstream path. These include header compression as well as bandwidth management techniques for the upstream link, including ACK filtering and ACK reconstruction.
RFC 3449 [RFC3449]は、非対称経路を介してTCP接続で発生するTCPのパフォーマンスの問題について説明します。 RFC 3449のセクション3は、ACKパス上の輻輳が、全体的なTCPのパフォーマンスに影響を与えることができる方法を詳細に説明しています。 RFC 3449はまた、ACK輻輳制御を含む提案された緩和策の数を概説します。そのRFCで議論した実験ACKの輻輳制御機構は、TCPの送信側がECN-マークされたパケットからACKパス上の輻輳を検出すると、ECNに依存しています。 RFC 3449は、動的ACK比を使用するため、[MJW00] CWND推定（ACE）に基づいて、2つの受信機ベースのメカニズム、ウィンドウ予測機構（WPM）[CLP98]を説明し、確認応答。 RFC 3449はまた、アップストリームパスの輻輳に対処リンク - およびネットワーク層技術を考慮する。これらは、ヘッダ圧縮、並びにACKフィルタリング及びACKの再構成を含む上流のリンクの帯域幅管理技術を含みます。
RFC 3135 [RFC3135], "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", surveys a range of Performance Enhancing Proxies used to improve TCP behavior, including proxies for ACK filtering and reconstruction. RFC 2760 [RFC2760], "Ongoing TCP Research Related to Satellites", discusses both ACK congestion control and ACK filtering and reconstruction, with detailed descriptions of the mechanisms proposed by Balakrishnan, et al. in [BPK97].
RFC 3135 [RFC3135]は、「リンク関連の劣化を軽減することを目的とプロキシのパフォーマンスの向上」には、ACKフィルタリングと再構築のための委任状を含め、TCPの動作を改善するために使用される性能向上プロキシの範囲を調査し。 RFC 2760 [RFC2760]、「衛星への継続的なTCPリサーチ関連」、らバラクリシュナン、によって提案されたメカニズムの詳細な説明と、ACK輻輳制御とACKフィルタリング及び再構成の両方を論じています。 [BPK97]インチ
Landstrom, et al. in [LL07] explore a mechanism where the receiver sends only four acknowledgements per window of data, along with the sender using a form of Appropriate Byte Counting. In addition, the receiver reverts to a lower acknowledgement frequency after a timeout, to avoid unnecessary retransmit timeouts. One conclusion of the paper is that pacing at the sender introduces an additional delay and might not be necessary. A key result of the paper is that, with the use of some form of byte counting at the sender, it is possible for TCP to use a lower acknowledgement frequency than that of delayed acknowledgements.
Landstromら。 [LL07]に受信機が適切なバイトカウントの形式を使用して送信者と一緒に、データのウィンドウごとに4つだけ肯定応答を送信するメカニズムを探ります。また、受信機は、不要な再送タイムアウトを回避するために、タイムアウト後に低い肯定応答周波数に戻ります。紙の一つの結論は、送信側でペーシングすると、追加の遅延を導入し、必要ではないかもしれないということです。紙の主要な結果は、TCPが遅延確認応答のより低い確認応答周波数を使用するため、送信側のバイトカウントのいくつかのフォームを使用して、それが可能である、ということです。
A.1. ECN-Only Mechanisms
A.1。 ECN-メカニズムのみ
Balakrishnan, et al. in [BPK97] describe the use of ECN to detect congestion in the return path, in order to reduce the sending rate of ACKs. The use of a RED queue in the reverse path allows for marking of ACK packets. The sender echoes back ECN congestion marks to the receiver. The receiver keeps an ACK Ratio d (called the "delayed-ACK factor"), specifying the number of data segments that have to be received before the receiver sends a new ACK. The ACK Ratio d is managed using multiplicative-increase, additive-decrease; upon reception of a congestion mark, the receiver doubles the value of d (hence dividing the ACK sending rate by two). The ACK Ratio decreases linearly for each RTT in which no ECN-marked ACKs are received. Multiple congestion marks received in an RTT are treated as a single congestion event, i.e., d can be doubled at most once per RTT. The TCP timestamp option is used to keep track of the RTT values.
バラクリシュナン、ら。 【BPK97]にすると、ACKの送信速度を低減するために、リターンパスの輻輳を検出するためのECNの使用を記載しています。逆の経路におけるREDキューの使用は、ACKパケットのマーキングを可能にします。送信側は受信機にECNの輻輳マークをエコーバック。受信機は、受信機が新しいACKを送信する前に受信されなければならないデータセグメントの数を指定し、（「遅延ACK因子」と呼ばれる）ACK比Dを保持します。 ACK比Dは、乗法-増加、添加剤の減少を使用して管理されます。輻輳マークを受信すると、受信機は、Dの値（したがって2でACK送信レートを割る）を倍増します。 ACK比率にはECN-マークされたACKを受信していないされている各RTTのために直線的に減少します。複数輻輳マークがRTTで受信即ち、dはRTTごとに最大1回倍増することができ、単一の輻輳イベントとして扱われます。 TCPタイムスタンプオプションは、RTT値を追跡するために使用されます。
A.2. Receiver-Only Mechanisms
A.2。レシーバのみのメカニズム
In [MJW00], Tam Ming-Chit, et al. propose a receiver-based method for calculating an "appropriate" number of ACKs per congestion window (cwnd) of data, in order to alleviate congestion on the reverse path. The sender's cwnd is estimated at the receiver by counting the number of received packets per RTT (which also has to be estimated by the receiver). From this estimate, a simple algorithm is used to compute the number of ACKs to be sent per cwnd. The algorithm enforces a lower bound on the number of ACKs per cwnd, aiming at minimizing the probability of timeout at the sender due to ACK loss. Similarly, the ACK Ratio is upper-bounded so as to avoid excessive ACK delay.
【MJW00]において、タム明チット、ら。リバースパスの輻輳を緩和するために、データの輻輳ウィンドウ（CWND）当たりのACKの「適切な」数を計算するための受信機ベースの方法を提案します。送信者のCWNDは（また、受信機によって推定されなければならない）RTT当たりの受信パケット数をカウントすることにより、受信機において推定されます。この推定から、単純なアルゴリズムはcwndのあたりに送信するACKの数を計算するために使用されます。アルゴリズムが原因ACK損失に送信側でタイムアウトの可能性を最小限に抑えることを目指して、CWNDあたりのACKの数に下限を強制します。過度のACK遅延を回避するように同様に、ACK率が上位境界です。
Blandford, et al. [BGG+07] propose an end-to-end, receiver-oriented scheme called "smartacking". The algorithm is based upon the receiver's monitoring the inter-segment arrival time for data packets and adapting the ACK sending rate in response. When the bottleneck link is underutilized, ACKs are sent frequently (up to one ACK per received segment) to promote fast growth of the congestion window. On the other hand, when the bottleneck is close to full utilization, the algorithm tries to reduce control traffic overhead and slow congestion window growth by generating ACKs at the minimum rate needed to keep the data pipe full.
ブランドフォードら。 [BGG + 07]「smartacking」と呼ばれるエンドツーエンド、受信指向の方式を提案します。アルゴリズムは、受信機のデータパケットのセグメント間到達時間を監視し、それに応答してACK送信レートを適応に基づいています。ボトルネックリンクが十分に活用されている場合、ACKは輻輳ウィンドウの急速な成長を促進する（受信したセグメントごとにACKまで）頻繁に送信されます。ボトルネックがフル稼働に近い一方、アルゴリズムは、完全なデータパイプを維持するために必要な最低限の速度でACKを生成することにより、制御トラフィックのオーバーヘッドと遅い輻輳ウィンドウの成長を削減しようとします。
Reducing the number of ACKs (or, equivalently, increasing the amount of bytes acknowledged by each ACK) can increase the burstiness of the TCP sender. Hence, any mechanism as those cited above should be coupled with a burst mitigation technique, such as rate-based pacing, that paces the sending of data segments ([AB05], [ASA00], [BPK97]).
（同等又は、各ACKによって承認バイトの量を増加させる）ACKの数を減らすことTCP送信者のバースト性を高めることができます。したがって、上記に引用したもののような任意の機構は、データセグメントの送信をペーシングレートに基づくペーシングとして、バースト緩和技術と結合されるべきである（[AB05]、[ASA00]、[BPK97]）。
A.3. Middlebox-Based Mechanisms
A.3。ミドルベースのメカニズム
ACK filtering (AF) [BPK97] from Balakrishnan, et al. is a router-based technique that tries to reduce the number of ACKs sent over the congested return link. With AF, an arriving ACK may replace preceding, older ACKs at the bottleneck queue. An aggressive replacement policy might guarantee that at most one ACK per connection is waiting in the queue, alleviating congestion. However, as in other proposals, care must be taken to avoid sender timeouts in case the (too few) ACKs resulting from the filtering get lost. The idea of filtering ACKs has been extended in [YMH03] to deal with SACK information.
らバラクリシュナン、からACKフィルタリング（AF）[BPK97]。混雑リターンリンクを介して送信されるACKの数を減らそうとルータベースの手法です。 AFでは、到着ACKがボトルネックキューで、古いACKを直前置き換えることができます。積極的な置換ポリシーは、接続ごとに最大で1つのACKが、混雑を緩和する、キュー内で待機していることを保証することがあります。しかし、他の提案のように、注意がフィルタリングの結果（少なすぎる）ACKが迷子になる場合には、送信者のタイムアウトを避けるようにしなければなりません。フィルタリングACKのアイデアは、SACK情報に対処する[YMH03]に拡張されています。
Aweya, et al. [AOM02] present a middlebox-based approach for mitigating data packet bursts and for controlling the uplink ACK congestion. The main idea is to perform pacing on ACK segments on an edge device close to the sender, so as to control the ACK arrival rate at the sender.
Aweyaら。 【AOM02】データパケットバーストを緩和するためのアップリンクACK輻輳を制御するためのミドルベースのアプローチを提示します。主なアイデアは、送信側にACKの到着率を制御するように、送信者に近いエッジデバイスにACKセグメントにペーシングを行うことです。
Appendix B. Design Considerations
付録B.設計上の考慮事項
B.1. The TCP ACK Ratio Option or an AckNow Bit in Data Packets?
B.1。データパケットにおけるTCP ACK比率オプションまたはAckNowビット？
In the ACK congestion control mechanism specified in this document, the sender uses the TCP ACK Ratio option to tell the receiver the ACK Ratio to use. An alternate approach to the TCP ACK Ratio option could be for the sender to use an AckNow bit in the TCP header of data packets, telling the receiver to acknowledge this data packet. In the discussion below, we call these two approaches the TCP ACK Ratio option approach and the AckNow approach.
この文書で指定されたACKの輻輳制御機構では、送信側はACK比は、使用する受信機を伝えるためにTCP ACK比率オプションを使用しています。送信者は、このデータパケットを確認するために受信機に伝える、データパケットのTCPヘッダにAckNowビットを使用するTCP ACKの比率オプションへの代替アプローチがあり得ます。以下の議論では、我々はこれらの二つのアプローチTCP ACK比率オプション・アプローチとAckNowアプローチを呼び出します。
An advantage of an AckNow approach is that it would require less state from the receiver; the receiver would not need to maintain a variable for the current ACK Ratio and would not need to keep track of the number of data packets un-ACKed to date.
AckNowアプローチの利点は、受信機からのより少ない状態を必要とするであろうということです。受信機は、現在のACK比率のための変数を維持する必要はありませんし、現在までに非ACKされたデータパケットの数を追跡する必要はありません。
However, a disadvantage of the AckNow approach is that the sender does not know when packets will be reordered, delayed, or dropped on the path to the receiver. In particular, the sender does not have control over whether a data packet with the AckNow bit set is reordered, delayed, or dropped in the network. For this reason, we have chosen the approach of the sender determining the ACK Ratio that should be used and sending the ACK Ratio to the receiver, rather than the sender telling the receiver exactly which data packets to acknowledge.
しかし、AckNowアプローチの欠点は、パケットが、並べ替え遅れ、または受信機へのパス上にドロップされるとき、送信者が知らないことです。具体的には、送信者がAckNowビットがセットされたデータパケットは、並べ替え遅延、またはネットワークにドロップされたか否かを制御する必要はありません。このような理由から、私たちはむしろ、パケットが承認する正確にデータ受信を知らせる送信者よりも、送信者のアプローチが使用されるべきACKの比率を決定し、受信機にACK比率を送ることを選択しました。
An additional disadvantage of the AckNow approach is that it would add complications and difficulties for the default cases of the receiver using an ACK Ratio of one or two, as is done in the absence of ACK congestion control.
AckNowアプローチのさらなる欠点は、ACKの輻輳制御の不存在下で行われているように、それは、1または2のACK比を使用した受信機のデフォルトケースの合併症や困難を追加するだろうということです。
For these reasons, we have specified that the sender determines the ACK Ratio to use and tells the receiver, rather than the sender setting an AckNow bit in the TCP Header of selected data packets.
これらの理由から、我々は、送信者が使用するACK比率を決定し、受信機ではなく、選択したデータ・パケットのTCPヘッダーにAckNowビットをセットし、送信者に指示することを指定しています。
Normative References
引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, February 2003.
[RFC3465]オールマン、M.、RFC 3465、2003年2月 "適切なバイトカウント（ABC）とTCP輻輳制御"。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten氏、T.、 "役に立つと考えられ割り当て実験とテスト番号"、BCP 82、RFC 3692、2004年1月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006.
[RFC4341]フロイド、S.、およびE.コーラー、 "データグラム輻輳制御プロトコル（DCCP）輻輳制御ID 2用のプロフィール：TCPのような輻輳制御"、RFC 4341、2006年3月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727]フェナー、B.、RFC 4727、2006年11月 "のIPv4、IPv6の、ICMPv4の、ICMPv6の、UDP、およびTCPヘッダには実験値"。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681]オールマン、M.、パクソン、V.、およびE.ブラントン、 "TCP輻輳制御"、RFC 5681、2009年9月。
Informative References
参考文献
[RFC2760] Allman, M., Ed., Dawkins, S., Glover, D., Griner, J., Tran, D., Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann, S., Scott, K., and J. Semke, "Ongoing TCP Research Related to Satellites", RFC 2760, February 2000.
[RFC2760]オールマン、M.、編、ドーキンス、S.、グローバー、D.、Griner、J.、トラン、D.、ヘンダーソン、T.、Heidemann、J.、タッチ、J.、クルーズ、H. 、Ostermann、S.、スコット、K.、およびJ. Semke、 "継続的なTCPの研究衛星に関連する"、RFC 2760、2000年2月。
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
[RFC3135]ボーダー、J.、古城、M.、Griner、J.、モンテネグロ、G.、およびZ.シェルビー、 "プロキシのパフォーマンスの向上は、リンク関連の劣化を軽減することを目的"、RFC 3135、2001年6月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", BCP 69, RFC 3449, December 2002.
[RFC3449]バラクリシュナン、H.、Padmanabhan、V.、Fairhurst、G.、およびM. Sooriyabandara、 "ネットワークパス非対称のTCPパフォーマンスへの影響"、BCP 69、RFC 3449、2002年12月。
[RFC4653] Bhandarkar, S., Reddy, A., Allman, M., and E. Blanton, "Improving the Robustness of TCP to Non-Congestion Events", RFC 4653, August 2006.
[RFC4653] Bhandarkarの、S.、レディ、A.、オールマン、M.、およびE.ブラントン、 "非輻輳イベントへのTCPの頑健性を向上させる"、RFC 4653、2006年8月。
[ASA00] Aggarwal, A., Savage, S., and T. Anderson, "Understanding the Performance of TCP Pacing", INFOCOM (3), pp. 1157-1165, 2000.
【ASA00]アガルワル、A.、サベージ、S.、およびT.アンダーソン、 "TCPペーシングのパフォーマンスの理解"、INFOCOM（3）、頁1157年から1165年、2000年。
[AB05] Allman, M., and E. Blanton, "Notes on Burst Mitigation for Transport Protocols", SIGCOMM, Computer Communications Review, 35(2):5360, 2005.
[AB05]オールマン、M.、およびE.ブラントンは、 "トランスポートプロトコルのためのバースト緩和上の注意"、SIGCOMM、コンピュータコミュニケーションレビュー、35（2）：2005 5360。
[AJ03] Altman, E., and T. Jimenez, "Novel Delayed ACK Techniques for Improving TCP Performance in Multihop Wireless Networks", Proc. of the Personal Wireless Communications, 2003.
[AJ03]アルトマン、E.、およびT.ヒメネス、PROC「小説はマルチホップ無線ネットワークにおけるTCPのパフォーマンスを向上させるためのACK技術を遅延します」。パーソナル無線通信、2003年。
[AOM02] Aweya, J., Ouellette, M., and D. Y. Montuno, "A Self-regulating TCP Acknowledgement (ack) Pacing Scheme", International Journal of Network Management, 12(3):145163, 2002.
[AOM02] Aweya、J.、Ouellette、M.、およびD. Y. Montuno、 "自己規制TCP確認（ACK）ペーシングスキーム"、ネットワーク管理の国際ジャーナル、12（3）：145163、2002。
[BA03] Barakat, C., and E. Altman, "On ACK Filtering on a Slow Reverse Channel", International Journal of Satellite Communications and Networking, V.21 N.3, 2003.
[BA03]バラカット、C.、およびE.アルトマン、「スロー逆方向チャネル上のACKフィルタリングに」、衛星通信およびネットワーキングの国際ジャーナル、V.21 N.3、2003。
[BPK97] Balakrishnan, H., Padmanabhan, V., and Katz, R., "The Effects of Asymmetry on TCP Performance", Third ACM/IEEE Mobicom Conference, September 1997.
[BPK97]バラクリシュナン、H.、Padmanabhan、V.、およびカッツ、R.、 "TCPパフォーマンス上の非対称性の影響"、第三ACM / IEEEモビコム会議、1997年9月。
[BGG+07] Blandford, D.K., Goldman, S.A., Gorinsky, S., Zhou, Y., and D.R. Dooly, "Smartacking: Improving TCP Performance from the Receiving End", Journal of Internet Engineering, 1(1), 2007.
[BGG + 07]ブランドフォード、D.K.、ゴールドマン、S.A.、Gorinsky、S.、周、Y.、およびD.R. Dooly、 "Smartacking：受信側からのTCPのパフォーマンスの向上"、インターネット・エンジニアリング誌、1（1）、2007。
[CLP98] Calveras, A., Linares, J., and J. Paradells, "Window Prediction Mechanism for Improving TCP in Wireless Asymmetric Links". Proc. IEEE Global Communications Conference (GLOBECOM), Sydney Australia, pp. 533-538, November 1998.
[CLP98] Calveras、A.、リナレス、J.、およびJ. Paradells、 "無線非対称リンクでTCPを改善するためのウィンドウ予測機構"。 PROC。 IEEEグローバルコミュニケーション会議（GLOBECOM）、オーストラリアのシドニー、頁533-538、1998年11月。
[KIA07] Keceli, F., Inan, I., and E. Ayanoglu, "TCP ACK Congestion Control and Filtering for Fairness Provision in the Uplink of IEEE 802.11 Infrastructure Basic Service Set", Proc. IEEE ICC 2007, June 2007.
[KIA07] Keceli、F.、イナン、I.、およびE. Ayanoglu、PROC、 "IEEE 802.11インフラストラクチャ基本サービスセットのアップリンクでの公平性の提供のためのTCP ACK輻輳制御とフィルタリング"。 IEEE ICC 2007、2007年6月。
[KEEP-ALIVE] Busatto, F., "TCP Keepalive HOWTO", May 2007, http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/index.html.
[キープアライブ] Busatto、F.、 "TCPキープアライブHOWTO"、2007年5月、http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/index.html。
[KLS07] Kim, H., Lee, H., and S. Shin, "On the Cross-Layer Impact of TCP ACK Thinning on IEEE 802.11 Wireless MAC Dynamics", IEICE Transactions on Communications, 2007.
[KLS07]キム、H.、リー、H.、およびS.新、 "IEEE 802.11無線MAC力学上のTCP ACK間伐のクロスレイヤへの影響について"、コミュニケーションズ、2007年電子情報通信学会論文誌。
[LL07] Landstrom, S., and Larzon, L.A., "Reducing the TCP Acknowledgement Frequency", SIGCOMM, Computer Communications Review, July 2007.
[LL07] Landstrom、S.、およびLarzon、L.A.、 "TCP確認応答周波数を下げる"、SIGCOMMコンピュータコミュニケーションレビュー、2007年7月。
[MJW00] Ming-Chit, I.T., Jinsong, D., and W. Wang, "Improving TCP Performance Over Asymmetric Networks", SIGCOMM, Computer Communications Review (CCR), Vol.30, No.3, 2000.
[MJW00]明チット、髄腔内、Jinsong、D.、およびW.ワング、 "非対称ネットワークにおけるTCPのパフォーマンスの向上"、SIGCOMMコンピュータコミュニケーションレビュー（CCR）、Vol.30、第3号、2000年。
[Studies] Floyd, S., "Measurement Studies of End-to-End Congestion Control in the Internet", http://www.icir.org/floyd/ccmeasure.html.
[研究]フロイド、S.、「インターネットにおけるエンドツーエンドの輻輳制御の測定学」、http://www.icir.org/floyd/ccmeasure.html。
[WWCM99] Wu, H., Wu, J., Cheng, S., and J. Ma, "ACK Filtering on Bandwidth Asymmetry Networks", IEEE Communications, 1999.
【WWCM99]呉、H.、ウー、J.、チェン、S.、およびJ.馬、 "帯域幅非対称ネットワーク上のACKフィルタリング"、IEEEコミュニケーションズ、1999。
[YMH03] Yu, L., Minhua, Y., and Z. Huimin, "The Improvement of TCP Performance in Bandwidth Asymmetric Network", IEEE PIMRC, 1:482-486, September 2003.
[YMH03]ゆう、L.、Minhua、Y.、およびZ.ホイミン、 "帯域幅非対称ネットワークにおけるTCPの性能の向上"、IEEE PIMRC、1：482-486、2003年9月。
Authors' Addresses
著者のアドレス
Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
インターネットリサーチ1947センターストリートのためのサリーフロイドICSIセンター、スイート600バークレー、CA 94704 USA
EMail: floyd@icir.org
メールアドレス：floyd@icir.org
Andres Arcia Networking, Security & Multimedia (RSM) Universidad de Los Andes TELECOM Bretagne Facultad de Ingenieria Rue de la Chataigneraie, CS 17607 Nucleo La Hechicera 35576 Cesson Sevigne Cedex Merida, Merida 5101 France Venezuela
アンドレスArciaネットワーキング、セキュリティ＆マルチメディア（RSM）エンジニアリングルー・デ・ラ・Chataigneraieのロス・アンデスTELECOMブルターニュ学部の大学、CS 17607 35576ヌクレオソーサレスセッソンセヴィニエCedexのメリダ、メリダ5101ベネズエラフランス
EMail: ae.arcia@telecom-bretagne.eu EMail: amoret@ula.ve URI: http://www.ula.ve
電子メール：ae.arcia@telecom-bretagne.eu Eメール：URI amoret@ula.ve：http://www.ula.ve
David Ros Networking, Security & Multimedia (RSM) Dpt. TELECOM Bretagne Rue de la Chataigneraie, CS 17607 35576 Cesson Sevigne Cedex France
デビッド・ロスネットワーキング、セキュリティ＆マルチメディア（RSM）のDpt。 TELECOM Bretagneのルー・デ・ラ・Chataigneraie、CS 17607 35576セッソンセヴィニエセデックスフランス
EMail: David.Ros@telecom-bretagne.eu
メールアドレス：David.Ros@telecom-bretagne.eu
Janardhan R. Iyengar Math and Computer Science Franklin & Marshall College P. O. Box 3003 Lancaster, PA 17604-3003 USA
Janardhan R.アイアンガー数学とコンピュータサイエンスフランクリン＆マーシャル大学のP. O.ボックス3003ランカスター、PA 17604から3003 USA
EMail: jiyengar@fandm.edu
メールアドレス：jiyengar@fandm.edu