[要約] RFC 5690は、TCPに確認応答混雑制御を追加するための提案です。その目的は、ネットワークの混雑を制御し、TCPのパフォーマンスを向上させることです。
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
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パケットを検出し、TCPデータ受信機にACK比rを指示し、データ受信者からデータ送信者への逆パスの輻輳に応答するために使用します。TCPデータレシーバーは、受信したRデータパケットごとに約1つのACKパケットを送信します。このメカニズムは、データグラムの混雑制御プロトコル（DCCP）の混雑制御識別子（CCID）の確認渋滞制御に基づいています。
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エディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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からTCPへの謝辞（ACK）の混雑制御メカニズムについて説明しています。このメカニズムは、Balakrishnan et al。[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の確認渋滞制御では、受信者は送信者が報告したACK比rを使用し、受信したRデータパケットごとに約1つのACKパケットを送信します。CCID 2送信者は、ACKパケットの紛失とマークされたACK比を監視し、それに応じてACK比を変更することにより、ACKPに適したTCPフレンドリーを維持します。ACK輻輳イベント（つまり、ACKパケットの紛失またはマークされたパケット）を含むすべての往復時間（RTT）について、送信者はACK比を2倍にすることで確認レートを半分にします。ACK混雑イベントを含むすべてのRTTについて、送信者は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のACK混雑制御がTCP接続のパフォーマンスに最小限の悪影響を与えることです。
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比を調整するメカニズム。TCP送信者は、[RFC4341]のセクション6.1.2で指定されている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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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：ecnなしの接続のための、接続イニシエーターとしての確認補充コントロール、ホストB、
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またはSyn/ACKパケットに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またはSyn/ACKパケットでACK輻輳制御許可オプションを送信します。TCPホストBのACK輻輳制御許可オプションの送信と、[RFC3168]で指定されているECNキャピールの交渉と組み合わせて、これによりTCPホストBはACKパケットをECNキャプテンとして送信できます。
The TCP receiver starts with an ACK Ratio of two, generally sending one ACK packet for every two data packets received.
TCPレシーバーは2つのACK比で始まり、通常、受信した2つのデータパケットごとに1つの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比オプションを受信機に送信します。TCPレシーバーは4つのACK比に変更され、最大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パケットの紛失なしで期間を検出し、3のACK比オプションをTCPレシーバーに送信します。TCPレシーバーは3つのACK比に戻り、最大3つのデータパケットに1つの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を参照）は、TCPレシーバーが純粋なアックを運ぶIPパケットのECT（0）またはECT（1）のコードポイントを設定することを禁止していますが、レシーバーがそうでない限り *のみ **あらゆる形態の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.
TCPエンドポイントは、TCPオプションであるACK輻輳制御許可オプションを使用して、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エンドポイントはBからAに送られた純粋な概念でACK混雑制御を使用する可能性があります。TCPエンドポイントBのACK比率をTCPエンドポイントBに送信して、純粋な確認パケットで使用します。同等に、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エンドポイントはAからBから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がTCPエンドポイントAからACK輻輳制御許可オプションを受信し、ACK輻輳制御許可オプションをTCPエンドポイントAに送信し、ECNキャピールが交渉された場合、TCPエンドポイントB純粋なACKパケットをECN対応として送信できます。
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比TCPオプションを使用して、送信者からレシーバーにACK比率を通知します。
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送信者はTCPレシーバーがACK比オプションを受け取ったかどうかを知ることができます。
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.
RのACK比を使用すると、レシーバーは、遅延したACKタイマーが最初に期限切れにならない限り、新しく受信したデータパケットごとに1つの純粋なACKを送信する必要があります。受信者は、受信した新しいデータパケットごとに1つずつ増分するカウンターを維持し、カウンターがRに到達したときにACKパケットを送信することができます。レシーバーは、純粋またはピギーバックされた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.
受信機にバッファーの制限がある場合、受信機は現在のACK比Rより少ないKの場合、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比の場合、セクション4.6は、オーダーアウトデータパケットのACKを送信するための受信機の動作を詳細に指定しています。
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パケットでサックオプションを使用すると、送信者が失われた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の到着の間に到着したデュパックの数を数え、この数とデュパックの数と比較することにより、Lost Dupackパケットを検出できる必要があります。それは到着するはずです（完全または部分的なACKによってAckedされているパケットの数に基づいて）。実際には、TCP送信者が損失イベント中に失われたACKパケットを評価し、最大2つのACK比を評価するために機能するかどうかを判断するために、シミュレーションおよび/または実験が必要になります。
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で指定されているように、オーダーアウト外データパケットごとにデュパックを送信しません。簡単にするために、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比を使用しているか、古いACK比を使用しているかどうかをどのように知りますか？次のセクションで指定されているように、送信者は、1回の往復時間内にACK比に2つの可能な変更のうち1つだけを作成できます。送信者は、RからR-1にACK比を1つずつ減らすことができます。または、送信者はACK比を2倍にしてRから2Rに増やすことができます。しかし、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比オプションのみを送信し、これらのデータパケットは受信機によって認められます。1つの可能性は、送信者が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比の最後の変更が増加または減少であるかどうかの情報を保存するだけで、送信者が十分に *十分かもしれません。このようにして、送信者が最近ACK比をRから2Rに増やした場合、送信者は失われたACKパケットの検出に慎重になる可能性があります。もう1つの可能性は、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.
TCP送信者は、[RFC4341]のセクション6.1.2で指定されている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比は、K = 2の最大値（2、CWND/（K*MSS））を超えません。その結果、TCPレシーバーは通常、少なくとも4つのフルサイズのセグメントのウィンドウに応じて、少なくとも2つの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.
(3) 輻輳ウィンドウが少なくとも4つのフルサイズのセグメントと同じ大きさの場合、ACK比は少なくとも2つです。つまり、1つのACK比は、輻輳ウィンドウが最大3つのフルサイズのセグメントである場合にのみ許可されます。
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比は1によって減少します（派生についてはRFC 4341の付録Aを参照してください。RFC 4341のaは、パケットでcwndを使用している間、パケットにcwndを使用します。）前のセクションで述べたように、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比のこれらの変更により、ACK送信率はほぼTCPに優しいものです。もちろん、CWNDは通常、時間とともに変化します。ダイナミクスはかなり複雑ですが、ほぼTCPフレンドリーです。ACK損失イベントの直後に、送信者がACK比を1つ（つまり、カウントするためにカウントする数を計算することにより）を1つずつ減らすかを決定することをお勧めします。
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回に1回、ACK比の再交渉率を格付けする場合があります。送信者は、往復時間ごとにACK比を1回以上変更しようとしないでください。特に、ACK比の新しい値を持つパケットを送信する前に、送信者は、ACK比の古い値のACK比オプションを含むデータパケットを受信者が認めていることを確認する必要があります。さらに、送信者は、2つの最小ACK比を実施するか、1つまたは2つのパケットの永続的な混雑ウィンドウを使用した半接続のためにACK比を1に設定することができます。
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パケットがドロップされ、送信者が指数関数的にバックオフタイムアウトに戻ることに注意してください。したがって、逆のパスで混雑が十分に重い場合、送信者はフォワードパスでの送信速度を低下させ、逆パスのレートも削減します。1つの可能性は、ACK比に一定の上限を追加して、より高い最小ACKセンディングレートを使用することです。つまり、ACK比がCWNDとは無関係にJの上限を持っていた場合、レシーバーは、逆パスの輻輳のレベルに関係なく、常にすべてのJデータパケットに少なくとも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送信者はスロースタートし、輻輳ウィンドウを初期ウィンドウに減らし、ACK比を最大2つに設定します。
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レシーバーは、並べ替えイベントに到着した最初の3つのオーダーアウトオブオーダーセグメントのそれぞれに即時の複製ACKを送信する必要があります。（順序外セグメントが到着したときにレシーバーでの並べ替えイベントを定義し、受信者がこれ以上のオーダーアウトオブセグメントを保持していないときに終了します。）ただし、ACK比が2を超える場合、後にACK比が大きい場合最初の3つの重複ACKが送信されました。TCP受信機は、現在の順序付けイベント中に送信される残りのACKでACK輻輳制御を実行する必要があります。つまり、最初の3つの重複ACKが送信された後、TCPレシーバーは、その再注文イベントのすべてのオーダーアウトセグメントに対してACKを送信する代わりに、すべてのRセグメントの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データパケットのすべてのセットが反転した順序で到着する）では、上記のガイドラインにより、レシーバーがデータパケットごとにACKを送信する可能性があることに注意してください。ACK比に関係なく。永続的な並べ替えのあるこのような環境では、受信者は、並べ替えイベントに到着した最初の3つのオーダーアウトオブオーダーセグメントのそれぞれに即時の複製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で指定されているように、スロースタートでは、TCP送信者が受信した新しいACKごとに1つのフルサイズのセグメントによってCWNDを増加させます（このコンテキストでは、「新しいACK」は新しいデータを認めるACKです）。RFC 5681はまた、うっ血回避において、TCP送信者が受信するごとに約1/CWNDフルサイズのセグメントをCWND増加させ、ラウンドトリップ時間ごとに約1つのフルサイズのセグメントの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.
RFC 5681は、混雑回避中に、新しいACKによって認められたバイト数を数え、受け取った新しいACKの数ではなく、認められたバイト数に基づいてCWNDを増やすことも許容できることに注意してください。したがって、送信者は、確認補充コントロールを確認することで、この形式のバイトカウントを確認して、送信者から送信されたデータトラフィックのウィンドウの増加を遅らせないようにする必要があります。このセクションで前述したように、レートベースのペーシングは確認渋滞制御で使用する必要があるため、TCP送信者は、ACKごとに輻輳ウィンドウを2回以上増加させる可能性があります。
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.
[RFC3465]で指定されている適切なバイトカウント（ABC）の場合、スロースタート中に、送信者はACKごとに最大2つのMSSで混雑ウィンドウを増やすことが許可されていることに注意してください。承認渋滞制御により、TCP送信者がスロースタート中にABCを使用できるかどうかはまだ決定されていません。ABCが確認渋滞制御で使用されている場合、TCP送信者がスロースタートで、ACK比が2を超えると、TCP送信者は単一のACKに応じて2つのMSSよりも多くの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の1つ以上が逆パスで失われる可能性があり、受信機が受信されるまで待機する可能性があります。r次の重複ACKを送信する前に、より多くの秩序外セグメント。これはすべて、迅速な回復を遅くし、速い再送信をかなり遅くする可能性があります。袋の使用は、失われたパケットの検出の潜在的な遅延を減らすのに役立ちます。SACKを使用すると、TCP送信者はSACKオプションの情報を使用して、レシーバーが少なくとも3つのオーダーデータパケットを受信したときに検出し、TCP送信者がいなくても、この場合に高速な再送信と迅速な回復を開始できます。まだ3つの重複したAcksを受け取りました。
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レシーバーは、構成または過去の経験から、リターンパスの帯域幅が制限されていることを知っている可能性があり、ACK比Lに下限（2を超える）を設定したい場合があります。TCPレシーバーからTCP送信者へのTCPオプションが必要であり、ACK比の下限を報告します。ACK比の下限が有効になるように、TCP送信者の混雑ウィンドウが十分に高い場合にのみ注意が必要です。
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 Newパケット以上のことを認めている場合に純粋な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.
ただし、遅延承認は誤ったネガを引き起こす可能性があり、TCP送信者は遅延承認として送信されるACKパケットの損失を検出できません。偽のネガは受け入れられるようです。これにより、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レシーバーは代わりにセクション4.6のガイドラインを使用して、重複ACKの送信を規定します。より多くの作業は、高速再送信のトリガーの潜在的な遅延の観点から、このアプローチの利点と欠点を評価し、別の可能性を調査するために役立ちます。
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が必要な場合、または確認する新しいデータパケットがある場合にのみ純粋な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を認めるリバースパスフローのために新しく生成されたデータパケットを送信できます。そして、送信者はこのドロップを検出できません。
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送信者は、DUPACKのしきい値に並列メカニズムを使用して、TCPのようにACKパケットが失われた時期を推測するか、より堅牢に、TCP送信者はACKパケットがACKパケットが持っていると推測する前に、往復時間全体を待つことができます。失われた[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混雑制御の使用は、パスの凝集渋滞の削減に寄与しません。この場合、1つの目標は、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
図2. JフォワードとKのリバースTCP接続を備えたシナリオ
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トラフィックの相対的な寄与を調査するには、J TCP接続（フォワードTCP接続）からのデータトラフィックを運ぶ混雑した単方向リンクLを使用して、K TCP接続からのACKトラフィック（逆TCP接続からのACKトラフィックを備えた単純なシナリオを検討することが有用です。）。すべてのTCP接続には、同じ往復時間rと同じデータパケットサイズsが1500バイトであると想定しています。さらに、すべてのフォワードTCP接続には同じデータパケットドロップレートPと同じ輻輳ウィンドウWがあり、逆TCP接続のすべてが同じ輻輳ウィンドウW1と同じACKパケットドロップレートP1を持っていると想定しています。（データパケットのパケットドロップレートは、ドロップされる到着データパケットの割合として定義されます。同様に、ACKパケットのパケットドロップレートは、ドロップされた到着ACKパケットの割合です。）J TCP接続はそれぞれ帯域幅を使用します。1500*w/rバイトあたり1500*w/rバイトのリンクLと、k TCP接続は、ACK輻輳制御なしで、それぞれ40*（w1/2）/rバイトのリンクlの帯域幅を使用します。これにより、TCPデータ帯域幅に対する75*（j/k）*（w/w1）がリンクLのTCP ACK帯域幅の比率が得られます。比率j/kは、link lの順方向TCP接続の数の比率です。、そして幅広い値を持つことができます（たとえば、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.
可能性を調査するために、混雑したリンクの輻輳制御メカニズムの範囲の一部を検討します。まず、混雑した経路の制限が1秒あたりのバイトのリンク帯域幅にあるシナリオを検討します。
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）は、ACK渋滞制御の最良のシナリオを表しています。TCPACKパケットのパケットドロップの割合は、TCP ACKパケットの寄与とほぼ一致します。混雑。（これらのケースのいくつかでは、これはせいぜい、データパケットが帯域幅とキューの制限の要因であるため、大まかな一致ですが、TCP ACKパケットはキューの制限の要因にすぎません。）ケース（4）（8）以下は、TCP ACKパケットのパケットドロップの割合がTCP ACKパケットの混雑に対する寄与よりもはるかに高い問題のシナリオを表しています（混雑したルーターでの希少なCPUサイクルを使用して、混雑したキューで空間をとるという点で、または乏しい帯域幅を使用しています）。以下のケース（6）は、ACKの混雑制御が呼び出されないため有効ではないシナリオを表しています。ケース（6）のシナリオでは、TCP ACKパケットのパケットドロップの割合は、TCP ACKパケットの混雑に対する寄与よりもはるかに小さくなります。
(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のドロップテールキューは、パケットで測定されます。この場合、混雑したキューはNパケット（パケットサイズに関係なく）に対応できます。また、1秒あたりのバイトでの帯域幅とパケットのキュースペースの両方の制限があり、大規模なデータパケットと小さなTCP ACKパケットが同様のパケットを表示するはずです。ドロップレート。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パケットは帯域幅の制限またはキュースペースの制限に大きく貢献しません。また、このシナリオでは、たとえ渋滞が大きい場合でも、TCP ACKパケットのパケットドロップレートは小さい必要があります（小さな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) 赤いキューはパケットモードで、パケットで測定されます。これは、上記のケース（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) 赤いキューはパケットモードですが、バイトで測定されます。キューはバイトで測定されるため、小さな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) 赤いキューはバイトモードで、バイトで測定されます。これは、上記のケース（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) 赤いキューはバイトモードですが、パケットで測定されます。キューはパケットで測定されるため、小さな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.
次に、混雑したリンクの制限が、1秒あたりの帯域幅ではなく、パケットのルーターの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データパケットなど）によって課される負荷に似ています。このシナリオ、特にTCP ACKパケットがTCPデータパケットと同じパケットドロップレートを見た場合、ACKの混雑制御が役立ちます。
(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.
IETF会議では、現在のTCP実装がTCP仕様で要求されるように、少なくとも他のすべてのデータパケットを常に認めているわけではないことが報告されています。特に、TCPレシーバーが承認を送信する前に多くのデータパケットをバーストで受信した場合、パケットのバーストに対して単一の確認を送信する可能性があることが報告されています。このような動作は、ACK混雑制御を使用したTCP接続の合併症を引き起こすことに注意してください。送信者は、ACKパケットがネットワークで削除された時期やパケットがレシーバーによってスキップされたときを判断できないためです。データパケットの到着のバーストを処理していました。
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.
この問題に対処する可能性の1つは、ACK輻輳制御を使用してTCPレシーバーを使用して、ACK比Rの場合、各Rパケットの確認を送信する必要があることです。この場合、受信機が戻っているデータパケットの大きなバーストを受け取った場合戻って、レシーバーは、Rデータパケットのセットごとに1つずつ、ACKパケットの応答バーストを送信する必要があります。
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.
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.
考えられる合併症の1つは、ACKの混雑制御と、逆パスに沿ったACKフィルタリング（[BPK97]、[WWCM99]、[BA03]、[KLS07]）などのルーターベースまたはミドルボックスベースの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比を調整するメカニズムは、少なくとも4つのフルサイズのデータパケットの各ウィンドウに応答して、TCPレシーバーに少なくとも2つのAckを送信させることを目的として設計されています。ただし、ACK輻輳制御とデータ制限送信者と組み合わせて、送信者は往復時間に少なくとも4つのフルサイズのデータパケットを送信することができ、レシーバーは2つ未満の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).
ACK混雑制御の評価には、2つのコンポーネントがあります。（1）個々のTCP接続に対するACK輻輳制御の影響を評価し、（2）ACK渋滞制御が総トラフィックに対する影響を評価します（ACK輻輳制御が凝集に及ぼす影響を含むパスの混雑）。
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.
2番目の部分は、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混雑制御の可能性のある利点の1つは、ワイヤレスリンク、共有イーサネット、または前方パスと逆パストラフィックの間の競合を持つ他の環境での競合を減らすことができることです（[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.
一部のTCPホストは、長期間にわたってデータまたはACKパケットが受信されていない場合、Keep-Aliveパケットを送信します[Keep-Alive]。このキープアライブメカニズムは、TCP仕様では対処されていません。ただし、そのようなキープアライブパケットは、使用する場合は、ACK輻輳制御と何らかの方法で相互作用しないでください。ACK輻輳制御の場合、ACK比は、通常、データのウィンドウに少なくとも2つの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パケットの確認番号とサックオプションが新しい場合でも、受信ウィンドウの新しい値を発表するウィンドウ更新パケットとして純粋な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つのデータパケットごとに1つのパケットが増加します。、ACK比の最大値/2パケット/2パケットごとに、これはTCPの現在の標準（バイトカウントは含まれない）と一致する適切なバイトカウント[RFC3465]の修正形式ですが、CCID 2は攻撃的に増加することができますCCID 2のACK比が2のデフォルト値よりも大きいTCPとして。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輻輳制御をcheTeするインセンティブはほとんどありません。TCPホストがACKパケットの削除に応じて混雑制御を使用する必要があることは何もありません。
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パケットを使用することにより、不正行為の道は開かれますか？ENDノードがECNを使用してACKパケットをドロップするのではなくマークすることができ、ENDノードがACKパケットでのECNの使用に伴うACKうっ血コントロールの使用を回避できる場合、エンドノードにインセンティブがある可能性がありますカンニングする。送信者は、より高いACK比を使用するように受信機に指示しないことでチートできます。受信者は、この不正行為を検出するのに苦労します。受信者は、使用するように指示されたACK比を使用しないことでチートできますが、送信者はこの不正行為を簡単に検出できます。ただし、受信者はACK混雑制御を使用せず、ACKパケットをECN対応として送信することで不正行為をすることもできます。そのため、ACKの混雑制御は、受信者がECN対応のACKパケットを送信することについてチートするために必要なコンポーネントではありません。疑問の1つは、受信者がECN対応のACKパケットを送信することについて不正行為を行う方法があるかどうか、およびこの不正行為が送信者によって簡単に検出されることなく、適切な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.
ACKパケットをECN対応として不適切に送信することでチートするTCPレシーバーを検出するルーターまたはミドルボックスの能力はどうですか？ルーターは、Routerがフォワードパスとリバースパスの両方でトラフィックを確認し、Syn/ACKパケットの両方を監視できる場合、RouterがECN対応としてACKパケットをECN対応として送信することを許可されているかどうかのみを把握します（およびTCPオプションを読み取ることができましたパケットヘッダー）。ACK混雑制御が交渉されている場合、ルーターは、送信者から受信機に送信されたACK比オプションを監視できる場合、ACK輻輳制御が受信機によって正しく使用されているかどうかのみを知ります。ACK輻輳制御が使用されている場合、ACKパケットがルーターを離れた後にACKパケットのドロップが発生する可能性があるため、Routerは必ずしも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行がTCPオプション番号レジストリに追加されます（IANA -http://www.iana.orgによって維持）：
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オプション番号は、幅広または一般的な展開ではなく、実験とテストを目的としています。これらのオプション番号は、他の目的のために他の実験者によって使用される可能性があります。
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.
Mark Allman、Armando Caro、Alfred Hoenes、Ilpoo Jarvinen、Sara Landstrom、Anantha Ramaiah、Michael Welzlからのフィードバック、およびMichael Welzlからの貢献したテキストに感謝します。
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がECNに依存していることについて説明した実験的なACK輻輳制御メカニズムは、ECNマークされたパケットからACKパスの輻輳を検出します。RFC 3449は、ダイナミックACK比を使用するために、2つの受信機ベースのメカニズム、ウィンドウ予測メカニズム（WPM）[CLP98]とCWND推定（ACE）[MJW00]に基づく承認についても説明しています。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研究」は、Balakrishnan et al。[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、et al。[LL07]では、適切なバイトカウントを使用して送信者とともに、受信者がデータのウィンドウごとに4つの謝辞のみを送信するメカニズムを調査します。さらに、レシーバーは、タイムアウト後に低い確認頻度に戻り、不必要な再送信タイムアウトを避けます。論文の結論の1つは、送信者でのペーシングが追加の遅延を導入し、必要ではない可能性があるということです。この論文の重要な結果は、送信者で何らかの形のバイトカウントを使用すると、TCPが遅延承認の頻度よりも低い確認頻度を使用することが可能であることです。
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.
Balakrishnan、et al。[BPK97]では、ACKの送信速度を下げるために、戻りパスでの混雑を検出するためのECNの使用を説明してください。逆パスで赤いキューを使用すると、ACKパケットのマーキングが可能になります。送信者は、ecnの混雑マークをレシーバーに戻します。受信機は、ACK比d（「遅延act係数」と呼ばれる）を保持し、受信者が新しいACKを送信する前に受信する必要があるデータセグメントの数を指定します。ACK比dは、乗法増加、添加剤デクレアを使用して管理されます。混雑マークを受信すると、受信機はDの値を2倍にします（したがって、ACK送信率を2で割っています）。ACK比は、ECNマークされたACKが受信されないRTTごとに直線的に減少します。RTTで受け取った複数の混雑マークは、単一の混雑イベントとして扱われます。つまり、DはRTTごとにせいぜい1回倍増できます。TCPタイムスタンプオプションは、RTT値を追跡するために使用されます。
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]では、Tam Ming-Chit、et al。逆パスでの混雑を緩和するために、データの輻輳ウィンドウ（CWND）ごとの「適切な」数のAck数を計算するためのレシーバーベースの方法を提案します。送信者のCWNDは、RTTあたりの受信パケットの数をカウントすることにより、受信機で推定されます（これも受信機によって推定する必要があります）。この推定から、単純なアルゴリズムを使用して、CWNDごとに送信されるACKの数を計算します。アルゴリズムは、CWNDあたりのACKの数の下限を強制し、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は頻繁に送信され（受信セグメントごとに最大1つの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]）。
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.
Balakrishnan et al。からのACKフィルタリング（AF）[BPK97]混雑したリターンリンクで送信されるACKの数を減らすことを試みるルーターベースの手法です。AFを使用すると、到着するACKは、ボトルネックキューにある前の古いACKを置き換える場合があります。積極的な交換ポリシーは、最大で接続ごとに1つのACKがキューで待機していることを保証する場合があり、混雑を軽減します。ただし、他の提案と同様に、フィルタリングに起因する（少なすぎる）ACKが失われた場合に備えて、送信者のタイムアウトを避けるために注意する必要があります。ACKのフィルタリングのアイデアは、[YMH03]に拡張されており、Sack情報を処理しています。
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、et al。[AOM02]は、データパケットバーストを緩和し、Uplink ACKの混雑を制御するためのミドルボックスベースのアプローチを提示します。主なアイデアは、送信者のACK到着率を制御するために、送信者に近いエッジデバイスでACKセグメントでペーシングを実行することです。
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輻輳制御メカニズムでは、送信者はTCP ACK比オプションを使用して、使用するACK比を受信者に指示します。TCP ACK比の代替アプローチオプションは、送信者がデータパケットのTCPヘッダーで確認ビットを使用して、受信機にこのデータパケットを確認するよう指示することです。以下の議論では、これら2つのアプローチをTCP ACK比オプションアプローチと謝辞アプローチと呼びます。
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.
確認アプローチの利点は、受信者からの状態が少ないことです。受信者は、現在の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.
ただし、確認アプローチの欠点は、送信者がパケットがいつ順序付け、遅延、またはレシーバーへのパスでドロップされるかを知らないことです。特に、送信者は、COUND BIT SETを備えたデータパケットがネットワーク内で並べ替え、遅延、またはドロップされているかどうかを制御していません。このため、送信者が受信者にどのデータパケットを確認するかを正確に伝えるのではなく、使用する必要がある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.
確認アプローチの追加の欠点は、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.
これらの理由により、送信者が選択したデータパケットのTCPヘッダーに確認ビットを設定するのではなく、送信者が使用するACK比を決定し、通知することを指定しました。
Normative References
引用文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, February 2003.
[RFC3465] Allman、M。、「適切なバイトカウント（ABC）によるTCP混雑制御」、RFC 3465、2003年2月。
[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] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram混雑制御プロトコル（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] Floyd、S。およびE. Kohler、「データグラムの混雑制御プロトコルのプロファイル（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] Fenner、B。、「IPv4、IPv6、ICMPV4、ICMPV6、UDP、およびTCPヘッダーの実験値」、RFC 4727、2006年11月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「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] Allman、M.、Ed。、Dawkins、S.、Glover、D.、Griner、J.、Tran、D.、Henderson、T.、Heidemann、J.、Touch、J.、Kruse、H。、Ostermann、S.、Scott、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] Border、J.、J.、Kojo、M.、Griner、J.、Montenegro、G。、およびZ. Shelby、「リンク関連の劣化を緩和することを目的としたプロキシを向上させるパフォーマンス」、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.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、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] Balakrishnan、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.、Reddy、A.、Allman、M。、およびE. Blanton、「非合成イベントに対する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] Aggarwal、A.、Savage、S。、およびT. Anderson、「TCPペーシングのパフォーマンスの理解」、Infocom（3）、pp。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] Allman、M。、およびE. Blanton、「輸送プロトコルのバースト緩和に関するメモ」、Sigcomm、Computer Communications Review、35（2）：5360、2005。
[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] Altman、E。、およびT. Jimenez、「マルチホップワイヤレスネットワークのTCPパフォーマンスを改善するための新しい遅延ACK技術」、Proc。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）ペーシングスキーム」、International Journal of Network Management、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] Barakat、C。、およびE. Altman、「スローリバースチャネルでのACKフィルタリングについて」、International Journal of Satellite Communications and Networking、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] Balakrishnan、H.、Padmanabhan、V。、およびKatz、R。、「TCPパフォーマンスに対する非対称性の影響」、3回目のACM/IEEE Mobicom Conference、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] Blandford、D.K.、Goldman、S.A.、Gorinsky、S.、Zhou、Y。、およびD.R.DOOLY、「スマートパッキング：受信側からのTCPパフォーマンスの改善」、Journal of Internet Engineering、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.、Linares、J。、およびJ. Paradells、「ワイヤレス非対称リンクでTCPを改善するためのウィンドウ予測メカニズム」。Proc。IEEE Global Communications Conference（Globecom）、Sydney Australia、pp。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.、Inan、I。、およびE. Ayanoglu、「IEEE 802.11インフラストラクチャベーシックサービスセットのアップリンクにおける公平性の提供のためのTCP ACK混雑制御とフィルタリング」、Proc。IEEE ICC 2007、2007年6月。
[KEEP-ALIVE] Busatto, F., "TCP Keepalive HOWTO", May 2007, http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/index.html.
[Keep-Alive] Busatto、F。、「TCP Keepalive 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] Kim、H.、Lee、H。、およびS. Shin、「IEEE 802.11ワイヤレスMacダイナミクスに対するTCP ACK薄化の架橋への影響」、IEICE Transactions on Communications、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、Computer Communications Review、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] Ming-Chit、I.T.、Jinsong、D。、およびW. Wang、「非対称ネットワーク上のTCPパフォーマンスの改善」、Sigcomm、Computer Communications Review（CCR）、Vol.30、No.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] Wu、H.、Wu、J.、Cheng、S。、およびJ. Ma、「帯域幅の非対称ネットワークのACKフィルタリング」、IEEE Communications、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] Yu、L.、Minhua、Y.、およびZ. Huimin、「帯域幅の非対称ネットワークにおける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
サリーフロイドICSIセンターフォーインターネットリサーチ1947センターストリート、スイート600バークレー、カリフォルニア州94704 USA
EMail: 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
EMail: ae.arcia@telecom-bretagne.eu EMail: amoret@ula.ve
URI: http://www.ula.ve
David Ros Networking, Security & Multimedia (RSM) Dpt. TELECOM Bretagne Rue de la Chataigneraie, CS 17607 35576 Cesson Sevigne Cedex France
David Ros Networking、Security＆Multimedia（RSM）DPT。Telecom Bretagne Rue De La Chataigneraie、CS 17607 35576 CESSON SEVIGNE CEDEX FRANCE
EMail: 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. Iyengar Math and Computer Science Franklin＆Marshall College P. O. Box 3003 Lancaster、PA 17604-3003 USA
EMail: jiyengar@fandm.edu