[要約] RFC 8699は、RTPメディアのためのカップルされた輻輳制御に関する規格であり、複数のメディアストリーム間での公平な輻輳制御を提供することを目的としています。
Internet Engineering Task Force (IETF) S. Islam
Request for Comments: 8699 M. Welzl
Category: Experimental S. Gjessing
ISSN: 2070-1721 University of Oslo
January 2020
Coupled Congestion Control for RTP Media
RTPメディアの結合輻輳制御
Abstract
概要
When multiple congestion-controlled Real-time Transport Protocol (RTP) sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss, and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the number of changes needed to existing RTP applications. This document also specifies how to apply the method for the Network-Assisted Dynamic Adaptation (NADA) congestion control algorithm and provides suggestions on how to apply it to other congestion control algorithms.
複数の輻輳制御Real-time Transport Protocol（RTP）セッションが同じネットワークボトルネックを通過する場合、それらの制御を組み合わせると、遅延、損失、および公平性の観点から、ネットワーク上の動作全体を改善できます。このドキュメントでは、既存のRTPアプリケーションに必要な変更の数を最小限に抑えながら、可能な限り柔軟でシンプルな方法で、同じ送信者を持つフローのそのような方法について説明します。このドキュメントでは、Network-Assisted Dynamic Adaptation（NADA）輻輳制御アルゴリズムの方法を適用する方法も指定し、それを他の輻輳制御アルゴリズムに適用する方法に関する提案を提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8699.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8699で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2020 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Definitions
3. Limitations
4. Architectural Overview
5. Roles
5.1. SBD
5.2. FSE
5.3. Flows
5.3.1. Example Algorithm 1 - Active FSE
5.3.2. Example Algorithm 2 - Conservative Active FSE
6. Application
6.1. NADA
6.2. General Recommendations
7. Expected Feedback from Experiments
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Application to GCC
Appendix B. Scheduling
Appendix C. Example Algorithm - Passive FSE
C.1. Example Operation (Passive)
Acknowledgements
Authors' Addresses
When there is enough data to send, a congestion controller attempts to increase its sending rate until the path's capacity has been reached. Some controllers detect path capacity by increasing the sending rate further, until packets are ECN-marked [RFC8087] or dropped, and then decreasing the sending rate until that stops happening. This process inevitably creates undesirable queuing delay when multiple congestion-controlled connections traverse the same network bottleneck, and each connection overshoots the path capacity as it determines its sending rate.
送信するのに十分なデータがある場合、輻輳コントローラは、パスの容量に達するまで送信レートを上げようとします。一部のコントローラーは、パケットにECNマークが付けられるか[RFC8087]になるまで送信レートをさらに上げ、それが発生しなくなるまで送信レートを下げて、パス容量を検出します。このプロセスは、複数の輻輳制御接続が同じネットワークボトルネックを通過し、送信レートを決定するときに各接続がパス容量をオーバーシュートすると、必然的に望ましくないキューイング遅延を作成します。
The Congestion Manager (CM) [RFC3124] couples flows by providing a single congestion controller. It is hard to implement because it requires an additional congestion controller and removes all per-connection congestion control functionality, which is quite a significant change to existing RTP-based applications. This document presents a method to combine the behavior of congestion control mechanisms that is easier to implement than the Congestion Manager [RFC3124] and also requires fewer significant changes to existing RTP-based applications. It attempts to roughly approximate the CM behavior by sharing information between existing congestion controllers. It is able to honor user-specified priorities, which is required by WebRTC [RTCWEB-OVERVIEW] [RFC7478].
Congestion Manager（CM）[RFC3124]は、単一の輻輳コントローラーを提供することにより、フローを結合します。追加の輻輳コントローラーが必要であり、すべての接続ごとの輻輳制御機能が削除されるため、実装は困難です。これは、既存のRTPベースのアプリケーションに対する非常に大きな変更です。このドキュメントでは、Congestion Manager [RFC3124]よりも実装が容易で、既存のRTPベースのアプリケーションに大幅な変更を加える必要がない、輻輳制御メカニズムの動作を組み合わせる方法を示します。既存の輻輳コントローラー間で情報を共有することにより、CMの動作を大まかに近似しようとします。 WebRTC [RTCWEB-OVERVIEW] [RFC7478]で必要とされるユーザー指定の優先度を尊重することができます。
The described mechanisms are believed safe to use, but they are experimental and are presented for wider review and operational evaluation.
説明されたメカニズムは安全に使用できると考えられていますが、それらは実験的であり、より広範なレビューと運用評価のために提示されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Available Bandwidth: The available bandwidth is the nominal link capacity minus the amount of traffic that traversed the link during a certain time interval, divided by that time interval.
利用可能な帯域幅：利用可能な帯域幅は、公称リンク容量から特定の時間間隔中にリンクを通過したトラフィックの量を差し引いたものを、その時間間隔で割った値です。
Bottleneck: The first link with the smallest available bandwidth along the path between a sender and receiver.
ボトルネック：送信者と受信者の間のパスに沿って利用可能な最小の帯域幅を持つ最初のリンク。
Flow: A flow is the entity that congestion control is operating on. It could, for example, be a transport-layer connection or an RTP stream [RFC7656], regardless of whether or not this RTP stream is multiplexed onto an RTP session with other RTP streams.
フロー：フローは、輻輳制御が動作しているエンティティです。たとえば、このRTPストリームが他のRTPストリームとのRTPセッションに多重化されているかどうかに関係なく、トランスポート層接続またはRTPストリーム[RFC7656]である可能性があります。
Flow Group Identifier (FGI): A unique identifier for each subset of flows that is limited by a common bottleneck.
フローグループ識別子（FGI）：共通のボトルネックによって制限されるフローの各サブセットの一意の識別子。
Flow State Exchange (FSE): The entity that maintains information that is exchanged between flows.
Flow State Exchange（FSE）：フロー間で交換される情報を維持するエンティティ。
Flow Group (FG): A group of flows having the same FGI.
フローグループ（FG）：同じFGIを持つフローのグループ。
Shared Bottleneck Detection (SBD): The entity that determines which flows traverse the same bottleneck in the network or the process of doing so.
共有ボトルネック検出（SBD）：どのフローがネットワーク内の同じボトルネックを通過するかを決定するエンティティまたはそのプロセス。
Sender-side only: Shared bottlenecks can exist when multiple flows originate from the same sender or when flows from different senders reach the same receiver (see Section 3 of [RFC8382]). Coupled congestion control, as described here, only supports the former case, not the latter, as it operates inside a single host on the sender side.
送信者側のみ：複数のフローが同じ送信者から発信された場合、または異なる送信者からのフローが同じ受信者に到達した場合、共有ボトルネックが存在する可能性があります（[RFC8382]のセクション3を参照）。ここで説明する結合輻輳制御は、送信側の単一ホスト内で動作するため、前者のケースのみをサポートし、後者はサポートしません。
Shared bottlenecks do not change quickly: As per the definition above, a bottleneck depends on cross traffic, and since such traffic can heavily fluctuate, bottlenecks can change at a high frequency (e.g., there can be oscillation between two or more links). This means that, when flows are partially routed along different paths, they may quickly change between sharing and not sharing a bottleneck. For simplicity, here it is assumed that a shared bottleneck is valid for a time interval that is significantly longer than the interval at which congestion controllers operate. Note that, for the only SBD mechanism defined in this document (multiplexing on the same five-tuple), the notion of a shared bottleneck stays correct even in the presence of fast traffic fluctuations; since all flows that are assumed to share a bottleneck are routed in the same way, if the bottleneck changes, it will still be shared.
共有ボトルネックはすぐには変化しません。上記の定義に従って、ボトルネックはクロストラフィックに依存します。このようなトラフィックは大きく変動する可能性があるため、ボトルネックは高頻度で変化する可能性があります（たとえば、2つ以上のリンク間に振動がある可能性があります）。これは、フローが異なるパスに沿って部分的にルーティングされている場合、ボトルネックを共有することと共有しないこととの間ですぐに変わる可能性があることを意味します。簡単にするために、ここでは、共有ボトルネックが、輻輳コントローラーが動作する間隔よりも大幅に長い時間間隔で有効であると想定しています。このドキュメントで定義されている唯一のSBDメカニズム（同じ5タプルでの多重化）の場合、共有トラフィックのボトルネックの概念は、トラフィックの変動が速い場合でも正しいままです。ボトルネックを共有すると想定されているすべてのフローは同じ方法でルーティングされるため、ボトルネックが変化しても、共有されます。
Figure 1 shows the elements of the architecture for coupled congestion control: the Flow State Exchange (FSE), Shared Bottleneck Detection (SBD), and Flows. The FSE is a storage element that can be implemented in two ways: active and passive. In the active version, it initiates communication with flows and SBD. However, in the passive version, it does not actively initiate communication with flows and SBD; its only active role is internal state maintenance (e.g., an implementation could use soft state to remove a flow's data after long periods of inactivity). Every time a flow's congestion control mechanism would normally update its sending rate, the flow instead updates information in the FSE and performs a query on the FSE, leading to a sending rate that can be different from what the congestion controller originally determined. Using information about/from the currently active flows, SBD updates the FSE with the correct Flow Group Identifiers (FGIs).
図1は、結合された輻輳制御のアーキテクチャーの要素、フロー状態交換（FSE）、共有ボトルネック検出（SBD）、およびフローを示しています。 FSEは、アクティブとパッシブの2つの方法で実装できるストレージ要素です。アクティブバージョンでは、フローおよびSBDとの通信を開始します。ただし、パッシブバージョンでは、フローおよびSBDとの通信をアクティブに開始しません。その唯一のアクティブな役割は、内部状態のメンテナンスです（たとえば、実装では、ソフトステートを使用して、長期間非アクティブになった後にフローのデータを削除できます）。フローの輻輳制御メカニズムが通常はその送信レートを更新するたびに、フローは代わりにFSEの情報を更新し、FSEに対してクエリを実行するため、輻輳コントローラーが最初に決定したものとは異なる送信レートになる可能性があります。 SBDは、現在アクティブなフローに関する情報を使用して、FSEを正しいフローグループ識別子（FGI）で更新します。
This document describes both active and passive versions. While the passive algorithm works better for congestion controls with RTT-independent convergence, it can still produce oscillations on short time scales. The passive algorithm, described in Appendix C, is therefore considered highly experimental and not safe to deploy outside of testbed environments. Figure 2 shows the interaction between flows and the FSE using the variable names defined in Section 5.2.
このドキュメントでは、アクティブバージョンとパッシブバージョンの両方について説明します。パッシブアルゴリズムは、RTTに依存しない収束による輻輳制御に適していますが、短い時間スケールで振動を生成する可能性があります。したがって、付録Cで説明されているパッシブアルゴリズムは非常に実験的であり、テストベッド環境の外に展開するのは安全ではありません。図2は、セクション5.2で定義された変数名を使用したフローとFSE間の相互作用を示しています。
------- <--- Flow 1
| FSE | <--- Flow 2 ..
------- <--- .. Flow N
^
| |
------- |
| SBD | <-------|
-------
Figure 1: Coupled congestion control architecture
図1：結合された輻輳制御アーキテクチャ
Flow#1(cc) FSE Flow#2(cc)
---------- --- ----------
#1 JOIN ----register--> REGISTER
REGISTER <--register-- JOIN #1
登録<-register-- JOIN＃1
#2 CC_R(1) ----UPDATE----> UPDATE (in)
#3 NEW RATE <---FSE_R(1)-- UPDATE (out) --FSE_R(2)-> #3 NEW RATE
Figure 2: Flow-FSE interactions
図2：Flow-FSEの相互作用
Since everything shown in Figure 1 is assumed to operate on a single host (the sender) only, this document only describes aspects that have an influence on the resulting on-the-wire behavior. It does not, for instance, define how many bits must be used to represent FGIs or in which way the entities communicate.
図1に示されているものはすべて、単一のホスト（送信側）でのみ動作することを前提としているため、このドキュメントでは、結果として生じるネットワーク上の動作に影響を与える側面のみを説明します。たとえば、FGIを表すために使用する必要があるビット数や、エンティティがどのように通信するかは定義しません。
Implementations can take various forms; for instance, all the elements in the figure could be implemented within a single application, thereby operating on flows generated by that application only. Another alternative could be to implement both the FSE and SBD together in a separate process that different applications communicate with via some form of Inter-Process Communication (IPC). Such an implementation would extend the scope to flows generated by multiple applications. The FSE and SBD could also be included in the Operating System kernel. However, only one type of coupling algorithm should be used for all flows. Combinations of multiple algorithms at different aggregation levels (e.g., the Operating System coupling application aggregates with one algorithm, and applications coupling their flows with another) have not been tested and are therefore not recommended.
実装にはさまざまな形式があります。たとえば、図のすべての要素を単一のアプリケーション内に実装して、そのアプリケーションのみで生成されたフローを操作できます。別の方法としては、FSEとSBDの両方を、異なるアプリケーションが何らかの形式のプロセス間通信（IPC）を介して通信する個別のプロセスに一緒に実装することもできます。そのような実装は、複数のアプリケーションによって生成されるフローに範囲を拡張します。 FSEとSBDは、オペレーティングシステムカーネルに含めることもできます。ただし、すべてのフローに使用する結合アルゴリズムのタイプは1つだけにする必要があります。異なる集約レベルでの複数のアルゴリズムの組み合わせ（たとえば、オペレーティングシステムカップリングアプリケーションが1つのアルゴリズムと集約し、アプリケーションがフローを別のアルゴリズムとカップリングする）はテストされていないため、推奨されません。
This section gives an overview of the roles of the elements of coupled congestion control and provides an example of how coupled congestion control can operate.
このセクションでは、結合された輻輳制御の要素の役割の概要を示し、結合された輻輳制御がどのように動作するかの例を示します。
SBD uses knowledge about the flows to determine which flows belong in the same Flow Group (FG) and assigns FGIs accordingly. This knowledge can be derived in three basic ways:
SBDは、フローに関する知識を使用して、どのフローが同じフローグループ（FG）に属しているかを判断し、それに応じてFGIを割り当てます。この知識は、3つの基本的な方法で導き出すことができます。
1. From multiplexing: It can be based on the simple assumption that packets sharing the same five-tuple (IP source and destination address, protocol, and transport-layer port number pair) and having the same values for the Differentiated Services Code Point (DSCP) and the ECN field in the IP header are typically treated in the same way along the path. This method is the only one specified in this document; SBD MAY consider all flows that use the same five-tuple, DSCP, and ECN field value to belong to the same FG. This classification applies to certain tunnels or RTP flows that are multiplexed over one transport (cf. [TRANSPORT-MULTIPLEX]). Such multiplexing is also a recommended usage of RTP in WebRTC [RTCWEB-RTP-USAGE].
1. 多重化から：同じ5タプル（IP送信元と宛先のアドレス、プロトコル、トランスポート層のポート番号のペア）を共有し、Differentiated Services Code Point（DSCP）に同じ値を持つパケットという単純な仮定に基づくことができます。 IPヘッダーのECNフィールドは、通常、パスに沿って同じ方法で処理されます。このメソッドは、このドキュメントで指定されている唯一のメソッドです。 SBDは、同じ5タプル、DSCP、およびECNフィールド値を使用するすべてのフローが同じFGに属すると見なす場合があります。この分類は、1つのトランスポートを介して多重化される特定のトンネルまたはRTPフローに適用されます（[TRANSPORT-MULTIPLEX]を参照）。このような多重化は、WebRTC [RTCWEB-RTP-USAGE]でのRTPの推奨される使用法でもあります。
2. Via configuration: e.g., by assuming that a common wireless uplink is also a shared bottleneck.
2. 構成経由：たとえば、一般的なワイヤレスアップリンクも共有ボトルネックであると想定します。
3. From measurements: e.g., by considering correlations among measured delay and loss as an indication of a shared bottleneck.
3. 測定から：たとえば、測定された遅延と損失の間の相関を、共有ボトルネックの指標として検討することによって。
The methods above have some essential trade-offs. For example, multiplexing is a completely reliable measure, but it is limited in scope to two endpoints (i.e., it cannot be applied to couple congestion controllers of one sender talking to multiple receivers). A measurement-based SBD mechanism is described in [RFC8382]. Measurements can never be 100% reliable, in particular because they are based on the past, but applying coupled congestion control involves making an assumption about the future; it is therefore recommended to implement cautionary measures, e.g., by disabling coupled congestion control if enabling it causes a significant increase in delay and/or packet loss. Measurements also take time, which entails a certain delay for turning on coupling (refer to [RFC8382] for details). When this is possible, it can be more efficient to statically configure shared bottlenecks (e.g., via a system configuration or user input) based on assumptions about the network environment.
上記の方法にはいくつかの本質的なトレードオフがあります。たとえば、多重化は完全に信頼できる手段ですが、範囲は2つのエンドポイントに限定されます（つまり、1つの送信者の輻輳コントローラーを複数の受信者と通信するために適用することはできません）。測定ベースのSBDメカニズムは、[RFC8382]で説明されています。特に過去に基づいているため、測定が100％信頼できるとは限りませんが、結合された輻輳制御を適用すると、将来についての仮定が必要になります。したがって、遅延やパケット損失の大幅な増加を引き起こす可能性がある場合は、結合された輻輳制御を無効にするなど、注意事項を実装することをお勧めします。測定にも時間がかかるため、カップリングをオンにするために一定の遅延が生じます（詳細については、[RFC8382]を参照してください）。これが可能な場合は、ネットワーク環境に関する想定に基づいて、共有のボトルネックを静的に構成すること（システム構成やユーザー入力など）の方が効率的です。
The FSE contains a list of all flows that have registered with it. For each flow, the FSE stores the following:
FSEには、FSEに登録されているすべてのフローのリストが含まれています。 FSEは、フローごとに次のものを格納します。
* a unique flow number f to identify the flow.
* フローを識別する一意のフロー番号f。
* the FGI of the FG that it belongs to (based on the definitions in this document, a flow has only one bottleneck and can therefore be in only one FG).
* 所属するFGのFGI（このドキュメントの定義に基づいて、フローにはボトルネックが1つしかないため、1つのFGにしか存在できません）。
* a priority P(f), which is a number greater than zero.
* 優先度P（f）。これはゼロより大きい数値です。
* The rate used by the flow in bits per second, FSE_R(f).
* フローが使用するレート（ビット/秒）、FSE_R（f）。
* The desired rate DR(f) of flow f. This can be smaller than FSE_R(f) if the application feeding into the flow has less data to send than FSE_R(f) would allow or if a maximum value is imposed on the rate. In the absence of such limits, DR(f) must be set to the sending rate provided by the congestion control module of flow f.
* フローfの望ましいレートDR（f）。フローにフィードするアプリケーションがFSE_R（f）が許可するよりも送信するデータが少ない場合、または最大値がレートに課せられている場合、これはFSE_R（f）よりも小さくなる可能性があります。そのような制限がない場合、DR（f）はフローfの輻輳制御モジュールによって提供される送信レートに設定する必要があります。
Note that the absolute range of priorities does not matter; the algorithm works with a flow's priority portion of the sum of all priority values. For example, if there are two flows, flow 1 with priority 1 and flow 2 with priority 2, the sum of the priorities is 3. Then, flow 1 will be assigned 1/3 of the aggregate sending rate, and flow 2 will be assigned 2/3 of the aggregate sending rate. Priorities can be mapped to the "very-low", "low", "medium", or "high" priority levels described in [WEBRTC-TRANS] by simply using the values 1, 2, 4, and 8, respectively.
優先順位の絶対的な範囲は重要ではないことに注意してください。アルゴリズムは、すべての優先順位値の合計のフローの優先順位部分で機能します。たとえば、フロー1に優先度1のフロー1と優先度2のフロー2がある場合、優先度の合計は3になります。次に、フロー1には集約送信レートの1/3が割り当てられ、フロー2は総送信レートの2/3が割り当てられます。優先度は、[WEBRTC-TRANS]で説明されている「非常に低い」、「低い」、「中」、または「高い」優先度レベルにそれぞれ1、2、4、および8の値を使用するだけでマッピングできます。
In the FSE, each FG contains one static variable, S_CR, which is the sum of the calculated rates of all flows in the same FG. This value is used to calculate the sending rate.
FSEでは、各FGに1つの静的変数S_CRが含まれています。これは、同じFG内のすべてのフローの計算されたレートの合計です。この値は、送信速度の計算に使用されます。
The information listed here is enough to implement the sample flow algorithm given below. FSE implementations could easily be extended to store, e.g., a flow's current sending rate for statistics gathering or future potential optimizations.
ここにリストされている情報は、以下に示すサンプルフローアルゴリズムを実装するのに十分です。 FSEの実装は、統計収集や将来の潜在的な最適化のためのフローの現在の送信レートなどを格納するように簡単に拡張できます。
Flows register themselves with SBD and FSE when they start, deregister from the FSE when they stop, and carry out an UPDATE function call every time their congestion controller calculates a new sending rate. Via UPDATE, they provide the newly calculated rate and, optionally (if the algorithm supports it), the desired rate. The desired rate is less than the calculated rate in case of application-limited flows; otherwise, it is the same as the calculated rate.
フローは、開始時にSBDおよびFSEに自分自身を登録し、フローが停止するとFSEから登録解除し、輻輳コントローラーが新しい送信レートを計算するたびにUPDATE関数呼び出しを実行します。 UPDATEを介して、それらは新しく計算されたレートを提供し、オプションで（アルゴリズムがサポートしている場合は）望ましいレートを提供します。アプリケーションで制限されたフローの場合、望ましいレートは計算されたレートよりも低くなります。それ以外の場合は、計算されたレートと同じです。
Below, two example algorithms are described. While other algorithms could be used instead, the same algorithm must be applied to all flows. Names of variables used in the algorithms are explained below.
以下に、2つのアルゴリズムの例を示します。他のアルゴリズムを代わりに使用できますが、同じアルゴリズムをすべてのフローに適用する必要があります。アルゴリズムで使用される変数の名前を以下に説明します。
CC_R(f) The rate received from the congestion controller of flow f when it calls UPDATE.
CC_R（f）UPDATEを呼び出したときに、フローfの輻輳コントローラーから受信したレート。
FSE_R(f) The rate calculated by the FSE for flow f.
FSE_R（f）フローfのFSEによって計算されたレート。
DR(f) The desired rate of flow f.
DR（f）望ましい流量f。
S_CR The sum of the calculated rates of all flows in the same FG; this value is used to calculate the sending rate.
S_CR同じFG内のすべてのフローの計算されたレートの合計。この値は、送信速度の計算に使用されます。
FG A group of flows having the same FGI and hence, sharing the same bottleneck.
FG同じFGIを持ち、したがって同じボトルネックを共有するフローのグループ。
P(f) The priority of flow f, which is received from the flow's congestion controller; the FSE uses this variable for calculating FSE_R(f).
P（f）フローの輻輳コントローラから受信したフローfの優先度。 FSEはこの変数を使用してFSE_R（f）を計算します。
S_P The sum of all the priorities.
S_Pすべての優先度の合計。
TLO The total leftover rate; the sum of rates that could not be assigned to flows that were limited by their desired rate.
TLO残りの合計レート。望ましいレートによって制限されたフローに割り当てることができなかったレートの合計。
AR The aggregate rate that is assigned to flows that are not limited by their desired rate.
AR必要なレートによって制限されないフローに割り当てられる総レート。
This algorithm was designed to be the simplest possible method to assign rates according to the priorities of flows. Simulation results in [FSE] indicate that it does not, however, significantly reduce queuing delay and packet loss.
このアルゴリズムは、フローの優先順位に従ってレートを割り当てる最も簡単な方法になるように設計されました。 [FSE]のシミュレーション結果は、キューイング遅延とパケット損失を大幅に削減しないことを示しています。
(1) When a flow f starts, it registers itself with SBD and the FSE. FSE_R(f) is initialized with the congestion controller's initial rate. SBD will assign the correct FGI. When a flow is assigned an FGI, it adds its FSE_R(f) to S_CR.
（1）フローfが開始されると、フロー自体がSBDおよびFSEに登録されます。 FSE_R（f）は、輻輳コントローラーの初期レートで初期化されます。 SBDは正しいFGIを割り当てます。フローにFGIが割り当てられると、フローはそのFSE_R（f）をS_CRに追加します。
(2) When a flow f stops or pauses, its entry is removed from the list.
（2）フローfが停止または一時停止すると、そのエントリはリストから削除されます。
(3) Every time the congestion controller of the flow f determines a new sending rate CC_R(f), the flow calls UPDATE, which carries out the tasks listed below to derive the new sending rates for all the flows in the FG. A flow's UPDATE function uses three local (i.e., per-flow) temporary variables: S_P, TLO, and AR.
（3）フローfの輻輳コントローラーが新しい送信レートCC_R（f）を決定するたびに、フローはUPDATEを呼び出します。UPDATEは、以下のタスクを実行して、FG内のすべてのフローの新しい送信レートを導き出します。フローのUPDATE関数は、S_P、TLO、ARの3つのローカル（フローごと）一時変数を使用します。
(a) It updates S_CR.
（a）S_CRを更新します。
S_CR = S_CR + CC_R(f) - FSE_R(f)
(b) It calculates the sum of all the priorities, S_P, and initializes FSE_R.
（b）すべての優先度の合計S_Pを計算し、FSE_Rを初期化します。
S_P = 0 for all flows i in FG do S_P = S_P + P(i) FSE_R(i) = 0 end for
FG内のすべてのフローiに対してS_P = 0 do S_P = S_P + P（i）FSE_R（i）= 0終了
(c) It distributes S_CR among all flows, ensuring that each flow's desired rate is not exceeded.
（c）すべてのフロー間でS_CRを分散し、各フローの希望レートを超えないようにします。
TLO = S_CR
while(TLO-AR>0 and S_P>0)
AR = 0
for all flows i in FG do
if FSE_R[i] < DR[i] then
if TLO * P[i] / S_P >= DR[i] then
TLO = TLO - DR[i]
FSE_R[i] = DR[i]
S_P = S_P - P[i]
else
FSE_R[i] = TLO * P[i] / S_P
AR = AR + TLO * P[i] / S_P
end if
end if
end for
end while
(d) It distributes FSE_R to all the flows.
（d）FSE_Rをすべてのフローに分散します。
for all flows i in FG do send FSE_R(i) to the flow i end for
FG内のすべてのフローについて、FSE_R（i）をフローiに送信します。
This algorithm changes algorithm 1 to conservatively emulate the behavior of a single flow by proportionally reducing the aggregate rate on congestion. Simulation results in [FSE] indicate that it can significantly reduce queuing delay and packet loss.
このアルゴリズムは、アルゴリズム1を変更して、輻輳時の総レートを比例的に低下させることにより、単一のフローの動作を控えめにエミュレートします。 [FSE]のシミュレーション結果は、キューイング遅延とパケット損失を大幅に削減できることを示しています。
Step (a) of the UPDATE function is changed as described below. This also introduces a local variable DELTA, which is used to calculate the difference between CC_R(f) and the previously stored FSE_R(f). To prevent flows from either ignoring congestion or overreacting, a timer keeps them from changing their rates immediately after the common rate reduction that follows a congestion event. This timer is set to two RTTs of the flow that experienced congestion because it is assumed that a congestion event can persist for up to one RTT of that flow, with another RTT added to compensate for fluctuations in the measured RTT value.
UPDATE関数のステップ（a）は、次のように変更されます。これは、CC_R（f）と以前に保存されたFSE_R（f）の間の差を計算するために使用されるローカル変数DELTAも導入します。フローが輻輳を無視したり過剰に反応したりするのを防ぐために、タイマーは、輻輳イベントに続く一般的なレート削減の直後にフローがレートを変更しないようにします。このタイマーは、輻輳が発生したフローの2つのRTTに設定されます。これは、測定されたRTT値の変動を補正するために別のRTTが追加されて、そのフローの最大1つのRTTまで輻輳イベントが持続することが想定されるためです。
(a) It updates S_CR based on DELTA.
（a）DELTAに基づいてS_CRを更新します。
if Timer has expired or was not set then
DELTA = CC_R(f) - FSE_R(f)
if DELTA < 0 then // Reduce S_CR proportionally
S_CR = S_CR * CC_R(f) / FSE_R(f)
Set Timer for 2 RTTs
else
S_CR = S_CR + DELTA
end if
end if
This section specifies how the FSE can be applied to specific congestion control mechanisms and makes general recommendations that facilitate applying the FSE to future congestion controls.
このセクションでは、FSEを特定の輻輳制御メカニズムに適用する方法を指定し、FSEを将来の輻輳制御に適用することを容易にする一般的な推奨事項を作成します。
Network-Assisted Dynamic Adaptation (NADA) [RFC8698] is a congestion control scheme for WebRTC. It calculates a reference rate r_ref upon receiving an acknowledgment and then, based on the reference rate, calculates a video target rate r_vin and a sending rate for the flows, r_send.
Network-Assisted Dynamic Adaptation（NADA）[RFC8698]は、WebRTCの輻輳制御方式です。確認応答の受信時に参照レートr_refを計算し、参照レートに基づいて、ビデオのターゲットレートr_vinとフローの送信レートr_sendを計算します。
When applying the FSE to NADA, the UPDATE function call described in Section 5.3 gives the FSE NADA's reference rate r_ref. The recommended algorithm for NADA is the Active FSE in Section 5.3.1. In step 3 (d), when the FSE_R(i) is "sent" to the flow i, r_ref (r_vin and r_send) of flow i is updated with the value of FSE_R(i).
FSEをNADAに適用する場合、セクション5.3で説明されているUPDATE関数呼び出しは、FSE NADAの参照レートr_refを提供します。 NADAの推奨アルゴリズムは、セクション5.3.1のアクティブFSEです。ステップ3（d）では、FSE_R（i）がフローiに「送信」されると、フローiのr_ref（r_vinおよびr_send）がFSE_R（i）の値で更新されます。
This section provides general advice for applying the FSE to congestion control mechanisms.
このセクションでは、FSEを輻輳制御メカニズムに適用するための一般的なアドバイスを提供します。
Receiver-side calculations: When receiver-side calculations make assumptions about the rate of the sender, the calculations need to be synchronized, or the receiver needs to be updated accordingly. This applies to TCP Friendly Rate Control (TFRC) [RFC5348], for example, where simulations showed somewhat less favorable results when using the FSE without a receiver-side change [FSE].
受信者側の計算：受信者側の計算で送信者のレートを想定する場合、計算を同期させるか、受信者をそれに応じて更新する必要があります。これは、TCPフレンドリーレートコントロール（TFRC）[RFC5348]に適用されます。たとえば、受信者側の変更なしでFSEを使用すると、シミュレーションがやや不利な結果を示した[FSE]。
Stateful algorithms: When a congestion control algorithm is stateful (e.g., during the TCP slow start, congestion avoidance, or fast recovery phase), these states should be carefully considered such that the overall state of the aggregate flow is correct. This may require sharing more information in the UPDATE call.
ステートフルアルゴリズム：輻輳制御アルゴリズムがステートフルである場合（TCPスロースタート、輻輳回避、高速リカバリフェーズなど）、これらの状態は、集約フローの全体的な状態が正しくなるように慎重に検討する必要があります。これには、UPDATE呼び出しでより多くの情報を共有する必要がある場合があります。
Rate jumps: The FSE-based coupling algorithms can let a flow quickly increase its rate to its fair share, e.g., when a new flow joins or after a quiescent period. In case of window-based congestion controls, this may produce a burst that should be mitigated in some way. An example of how this could be done without using a timer is presented in [ANRW2016], using TCP as an example.
レートジャンプ：FSEベースのカップリングアルゴリズムを使用すると、フローは、たとえば新しいフローが加わったときや休止期間の後で、そのレートをフェアシェアにすばやく上げることができます。ウィンドウベースの輻輳制御の場合、これはバーストを生成する可能性があり、何らかの方法で軽減する必要があります。タイマーを使用せずにこれを行う方法の例は、TCPを例にして[ANRW2016]に示されています。
The algorithm described in this memo has so far been evaluated using simulations covering all the tests for more than one flow from [RMCAT-PROPOSALS] (see [IETF-93] and [IETF-94]). Experiments should confirm these results using at least the NADA congestion control algorithm with real-life code (e.g., browsers communicating over an emulated network covering the conditions in [RMCAT-PROPOSALS]). The tests with real-life code should be repeated afterwards in real network environments and monitored. Experiments should investigate cases where the media coder's output rate is below the rate that is calculated by the coupling algorithm (FSE_R(i) in algorithms 1 (Section 5.3.1) and 2 (Section 5.3.2)). Implementers and testers are invited to document their findings in an Internet-Draft.
このメモで説明されているアルゴリズムは、これまでのところ[RMCAT-PROPOSALS]（[IETF-93]および[IETF-94]を参照）からの複数のフローに対するすべてのテストをカバーするシミュレーションを使用して評価されています。実験では、少なくとも実際のコードを使用したNADA輻輳制御アルゴリズムを使用してこれらの結果を確認する必要があります（たとえば、[RMCAT-PROPOSALS]の条件をカバーするエミュレートされたネットワークを介して通信するブラウザ）。その後、実際のコードを使用したテストを実際のネットワーク環境で繰り返し、監視する必要があります。実験では、メディアコーダーの出力レートが、結合アルゴリズム（アルゴリズム1（セクション5.3.1）および2（セクション5.3.2）のFSE_R（i））によって計算されたレートを下回るケースを調査する必要があります。実装者とテスターは、発見したことをインターネットドラフトに文書化することができます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
In scenarios where the architecture described in this document is applied across applications, various cheating possibilities arise, e.g., supporting wrong values for the calculated rate, desired rate, or priority of a flow. In the worst case, such cheating could either prevent other flows from sending or make them send at a rate that is unreasonably large. The end result would be unfair behavior at the network bottleneck, akin to what could be achieved with any UDP-based application. Hence, since this is no worse than UDP in general, there seems to be no significant harm in using this in the absence of UDP rate limiters.
このドキュメントで説明されているアーキテクチャがアプリケーション全体に適用されるシナリオでは、たとえば、フローの計算されたレート、望ましいレート、または優先度の誤った値をサポートするなど、さまざまな不正の可能性が発生します。最悪の場合、このような不正行為は、他のフローが送信できないようにするか、不当に大きいレートで送信する可能性があります。最終結果は、UDPベースのアプリケーションで実現できるものと同様に、ネットワークボトルネックでの不公平な動作になります。したがって、これは一般的にUDPよりも悪くないため、UDPレートリミッターがない場合にこれを使用しても、重大な害はないようです。
In the case of a single-user system, it should also be in the interest of any application programmer to give the user the best possible experience by using reasonable flow priorities or even letting the user choose them. In a multi-user system, this interest may not be given, and one could imagine the worst case of an "arms race" situation where applications end up setting their priorities to the maximum value. If all applications do this, the end result is a fair allocation in which the priority mechanism is implicitly eliminated and no major harm is done.
シングルユーザーシステムの場合、適切なフローの優先順位を使用するか、ユーザーに選択させることで、ユーザーに最高のエクスペリエンスを提供することも、アプリケーションプログラマの利益になるはずです。マルチユーザーシステムでは、この関心は与えられない可能性があり、アプリケーションが優先度を最大値に設定してしまう「軍拡競争」状況の最悪のケースを想像できます。すべてのアプリケーションがこれを行う場合、最終的な結果は、優先メカニズムが暗黙的に排除され、大きな害が行われない公正な割り当てになります。
Implementers should also be aware of the Security Considerations sections of [RFC3124], [RFC5348], and [RFC7478].
実装者は、[RFC3124]、[RFC5348]、および[RFC7478]のセキュリティに関する考慮事項のセクションにも注意する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, DOI 10.17487/RFC3124, June 2001, <https://www.rfc-editor.org/info/rfc3124>.
[RFC3124] Balakrishnan、H。およびS. Seshan、「The Congestion Manager」、RFC 3124、DOI 10.17487 / RFC3124、2001年6月、<https://www.rfc-editor.org/info/rfc3124>。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, <https://www.rfc-editor.org/info/rfc5348>.
[RFC5348] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：Protocol Specification」、RFC 5348、DOI 10.17487 / RFC5348、2008年9月、<https： //www.rfc-editor.org/info/rfc5348>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8698] Zhu, X., Pan, R., Ramalho, M., and S. Mena, "Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media", RFC 8698, DOI 10.17487/RFC8698, January 2020, <https://www.rfc-editor.org/info/rfc8698>.
[RFC8698] Zhu、X.、Pan、R.、Ramalho、M。、およびS. Mena、「Network-Assisted Dynamic Adaptation（NADA）：A Unified Congestion Control Scheme for Real-Time Media」、RFC 8698、DOI 10.17487 / RFC8698、2020年1月、<https://www.rfc-editor.org/info/rfc8698>。
[ANRW2016] Islam, S. and M. Welzl, "Start Me Up: Determining and Sharing TCP's Initial Congestion Window", ACM, IRTF, ISOC Applied Networking Research Workshop 2016 (ANRW 2016), DOI 10.1145/2959424.2959440, Proceedings of the 2016 Applied Networking Research Workshop Pages 52-54, July 2016, <https://doi.org/10.1145/2959424.2959440>.
[ANRW2016] Islam、S. and M. Welzl、 "Start Me Up：Determining and Sharing TCP's Initial Congestion Window"、ACM、IRTF、ISOC Applied Networking Research Workshop 2016（ANRW 2016）、DOI 10.1145 / 2959424.2959440、Proceedings of the 2016 Applied Networking Research Workshop Pages 52-54、July 2016、<https://doi.org/10.1145/2959424.2959440>。
[FSE] Islam, S., Welzl, M., Gjessing, S., and N. Khademi, "Coupled Congestion Control for RTP Media", ACM SIGCOMM Capacity Sharing Workshop (CSWS 2014) and ACM SIGCOMM CCR 44(4) 2014, March 2014, <http://safiquli.at.ifi.uio.no/paper/fse-tech-report.pdf>.
[FSE] Islam、S.、Welzl、M.、Gjessing、S.、and N. Khademi、 "Coupled Congestion Control for RTP Media"、ACM SIGCOMM Capacity Sharing Workshop（CSWS 2014）and ACM SIGCOMM CCR 44（4）2014 、2014年3月、<http://safiquli.at.ifi.uio.no/paper/fse-tech-report.pdf>。
[FSE-NOMS] Islam, S., Welzl, M., Hayes, D., and S. Gjessing, "Managing real-time media flows through a flow state exchange", IEEE NOMS 2016, DOI 10.1109/NOMS.2016.7502803, <https://doi.org/10.1109/NOMS.2016.7502803>.
[FSE-NOMS] Islam、S.、Welzl、M.、Hayes、D.、and S. Gjessing、 "Managing real-time media flow through a flow state exchange"、IEEE NOMS 2016、DOI 10.1109 / NOMS.2016.7502803、 <https://doi.org/10.1109/NOMS.2016.7502803>。
[GCC-RTCWEB] Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. Mascolo, "A Google Congestion Control Algorithm for Real-Time Communication", Work in Progress, Internet-Draft, draft-ietf-rmcat-gcc-02, 8 July 2016, <https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02>.
[GCC-RTCWEB] Holmer、S.、Lundin、H.、Carlucci、G.、Cicco、L.、and S. Mascolo、 "A Google Congestion Control Algorithm for Real-Time Communication"、Work in Progress、Internet-Draft 、draft-ietf-rmcat-gcc-02、2016年7月8日、<https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02>。
[IETF-93] Islam, S., Welzl, M., and S. Gjessing, "Updates on 'Coupled Congestion Control for RTP Media'", RTP Media Congestion Avoidance Techniques (rmcat) Working Group, IETF 93, July 2015, <https://www.ietf.org/proceedings/93/rmcat.html>.
[IETF-93] Islam、S.、Welzl、M.、and S. Gjessing、 "Updates on 'Coupled Congestion Control for RTP Media'、RTP Media Congestion Improvement Techniques（rmcat）Working Group、IETF 93、July 2015、 <https://www.ietf.org/proceedings/93/rmcat.html>。
[IETF-94] Islam, S., Welzl, M., and S. Gjessing, "Updates on 'Coupled Congestion Control for RTP Media'", RTP Media Congestion Avoidance Techniques (rmcat) Working Group, IETF 94, November 2015, <https://www.ietf.org/proceedings/94/rmcat.html>.
[IETF-94] Islam、S.、Welzl、M.、and S. Gjessing、 "Updates on 'Coupled Congestion Control for RTP Media'、RTP Media Congestion Improvement Techniques（rmcat）Working Group、IETF 94、November 2015、 <https://www.ietf.org/proceedings/94/rmcat.html>。
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, <https://www.rfc-editor.org/info/rfc7478>.
[RFC7478] Holmberg、C.、Hakansson、S。、およびG. Eriksson、「Web Real-Time Communication Use Cases and Requirements」、RFC 7478、DOI 10.17487 / RFC7478、2015年3月、<https：//www.rfc- editor.org/info/rfc7478>。
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <https://www.rfc-editor.org/info/rfc7656>.
[RFC7656] Lennox、J.、Gross、K.、Nandakumar、S.、Salgueiro、G。、およびB. Burman、編、「リアルタイムの転送プロトコル（RTP）ソースのセマンティクスとメカニズムの分類法」、 RFC 7656、DOI 10.17487 / RFC7656、2015年11月、<https://www.rfc-editor.org/info/rfc7656>。
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using Explicit Congestion Notification (ECN)", RFC 8087, DOI 10.17487/RFC8087, March 2017, <https://www.rfc-editor.org/info/rfc8087>.
[RFC8087] Fairhurst、G。、およびM. Welzl、「明示的な輻輳通知（ECN）を使用する利点」、RFC 8087、DOI 10.17487 / RFC8087、2017年3月、<https://www.rfc-editor.org/info / rfc8087>。
[RFC8382] Hayes, D., Ed., Ferlin, S., Welzl, M., and K. Hiorth, "Shared Bottleneck Detection for Coupled Congestion Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382, June 2018, <https://www.rfc-editor.org/info/rfc8382>.
[RFC8382] Hayes、D。、編、Ferlin、S.、Welzl、M。、およびK. Hiorth、「RTPメディアの結合輻輳制御のための共有ボトルネック検出」、RFC 8382、DOI 10.17487 / RFC8382、2018年6月、 <https://www.rfc-editor.org/info/rfc8382>。
[RMCAT-PROPOSALS] Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test Cases for Evaluating RMCAT Proposals", Work in Progress, Internet-Draft, draft-ietf-rmcat-eval-test-10, 23 May 2019, <https://tools.ietf.org/html/draft-ietf-rmcat-eval-test-10>.
[RMCAT-PROPOSALS] Sarker、Z.、Singh、V.、Zhu、X。、およびM. Ramalho、「RMCATプロポーザルを評価するためのテストケース」、進行中の作業、インターネットドラフト、draft-ietf-rmcat-eval- test-10、2019年5月23日、<https://tools.ietf.org/html/draft-ietf-rmcat-eval-test-10>。
[RTCWEB-OVERVIEW] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, Internet-Draft, draft-ietf-rtcweb-overview-19, 11 November 2017, <https://tools.ietf.org/html/draft-ietf-rtcweb-overview-19>.
[RTCWEB-OVERVIEW] Alvestrand、H。、「Overview：Real Time Protocols for Browser-based Applications」、Work in Progress、Internet-Draft、draft-ietf-rtcweb-overview-19、11 November 2017、<https：// tools.ietf.org/html/draft-ietf-rtcweb-overview-19>。
[RTCWEB-RTP-USAGE] Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", Work in Progress, Internet-Draft, draft-ietf-rtcweb-rtp-usage-26, 17 March 2016, <https://tools.ietf.org/html/ draft-ietf-rtcweb-rtp-usage-26>.
[RTCWEB-RTP-USAGE] Perkins、C.、Westerlund、M.、J。Ott、「Web Real-Time Communication（WebRTC）：Media Transport and Use of RTP」、Work in Progress、Internet-Draft、draft- ietf-rtcweb-rtp-usage-26、2016年3月17日、<https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-26>。
[TRANSPORT-MULTIPLEX] Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a Single Lower-Layer Transport", Work in Progress, Internet-Draft, draft-westerlund-avtcore-transport-multiplexing-07, October 2013, <https://tools.ietf.org/html/draft-westerlund-avtcore-transport-multiplexing-07>.
[TRANSPORT-MULTIPLEX] Westerlund、M。およびC. Perkins、「単一の下位層トランスポートでの複数のRTPセッション」、作業中、Internet-Draft、draft-westerlund-avtcore-transport-multiplexing-07、2013年10月、 <https://tools.ietf.org/html/draft-westerlund-avtcore-transport-multiplexing-07>。
[WEBRTC-TRANS] Alvestrand, H., "Transports for WebRTC", Work in Progress, Internet-Draft, draft-ietf-rtcweb-transports-17, 26 October 2016, <https://tools.ietf.org/html/draft-ietf-rtcweb-transports-17>.
[WEBRTC-TRANS] Alvestrand、H。、「Transports for WebRTC」、Work in Progress、Internet-Draft、draft-ietf-rtcweb-transports-17、2016年10月26日、<https://tools.ietf.org/html / draft-ietf-rtcweb-transports-17>。
Google Congestion Control (GCC) [GCC-RTCWEB] is another congestion control scheme for RTP flows that is under development. GCC is not yet finalized, but at the time of this writing, the rate control of GCC employs two parts: controlling the bandwidth estimate based on delay and controlling the bandwidth estimate based on loss. Both are designed to estimate the available bandwidth, A_hat.
Google輻輳制御（GCC）[GCC-RTCWEB]は、開発中のRTPフローのもう1つの輻輳制御方式です。 GCCはまだ確定されていませんが、この記事の執筆時点では、GCCのレート制御は、遅延に基づく帯域幅推定の制御と損失に基づく帯域幅推定の制御の2つの部分を採用しています。どちらも使用可能な帯域幅A_hatを推定するように設計されています。
When applying the FSE to GCC, the UPDATE function call described in Section 5.3 gives the FSE GCC's estimate of available bandwidth A_hat. The recommended algorithm for GCC is the Active FSE in Section 5.3.1. In step 3 (d) of this algorithm, when the FSE_R(i) is "sent" to the flow i, A_hat of flow i is updated with the value of FSE_R(i).
FSEをGCCに適用する場合、セクション5.3で説明されているUPDATE関数呼び出しは、FSE GCCの使用可能な帯域幅の推定値A_hatを提供します。 GCCの推奨アルゴリズムは、セクション5.3.1のアクティブFSEです。このアルゴリズムのステップ3（d）では、FSE_R（i）がフローiに「送信」されると、フローiのA_hatがFSE_R（i）の値で更新されます。
When flows originate from the same host, it would be possible to use only one sender-side congestion controller that determines the overall allowed sending rate and then use a local scheduler to assign a proportion of this rate to each RTP session. This way, priorities could also be implemented as a function of the scheduler. The Congestion Manager (CM) [RFC3124] also uses such a scheduling function.
フローが同じホストから発信された場合、許可される送信レート全体を決定する送信側の輻輳コントローラーを1つだけ使用し、ローカルスケジューラを使用してこのレートの比率を各RTPセッションに割り当てることができます。このように、優先度はスケジューラの機能として実装することもできます。 Congestion Manager（CM）[RFC3124]もこのようなスケジューリング機能を使用しています。
Active algorithms calculate the rates for all the flows in the FG and actively distribute them. In a passive algorithm, UPDATE returns a rate that should be used instead of the rate that the congestion controller has determined. This can make a passive algorithm easier to implement; however, when round-trip times of flows are unequal, flows with shorter RTTs may (depending on the congestion control algorithm) update and react to the overall FSE state more often than flows with longer RTTs, which can produce unwanted side effects. This problem is more significant when the congestion control convergence depends on the RTT. While the passive algorithm works better for congestion controls with RTT-independent convergence, it can still produce oscillations on short time scales. The algorithm described below is therefore considered highly experimental and not safe to deploy outside of testbed environments. Results of a simplified passive FSE algorithm with both NADA and GCC can be found in [FSE-NOMS].
アクティブアルゴリズムは、FG内のすべてのフローのレートを計算し、それらをアクティブに分散します。パッシブアルゴリズムでは、UPDATEは、輻輳コントローラーが決定したレートの代わりに使用する必要があるレートを返します。これにより、パッシブアルゴリズムの実装が容易になります。ただし、フローのラウンドトリップ時間が等しくない場合、RTTが短いフローは（輻輳制御アルゴリズムに応じて）、RTTが長いフローよりも頻繁に更新され、全体的なFSE状態に反応する可能性があります。これにより、不要な副作用が発生する可能性があります。この問題は、輻輳制御の収束がRTTに依存している場合により重要になります。パッシブアルゴリズムは、RTTに依存しない収束による輻輳制御に適していますが、短い時間スケールで振動を生成することもできます。したがって、以下で説明するアルゴリズムは非常に実験的であり、テストベッド環境の外に展開するのは安全ではないと見なされています。 NADAとGCCの両方を使用した単純化されたパッシブFSEアルゴリズムの結果は、[FSE-NOMS]にあります。
In the passive version of the FSE, TLO (Total Leftover Rate) is a static variable per FG that is initialized to 0. Additionally, S_CR is limited to increase or decrease as conservatively as a flow's congestion controller decides in order to prohibit sudden rate jumps.
FSEのパッシブバージョンでは、TLO（Total Leftover Rate）はFGごとの静的変数であり、0に初期化されます。さらに、S_CRは、フローの輻輳コントローラーが突然のレートジャンプを禁止するために決定するのと同じくらい控えめに増減するように制限されています。
(1) When a flow f starts, it registers itself with SBD and the FSE. FSE_R(f) and DR(f) are initialized with the congestion controller's initial rate. SBD will assign the correct FGI. When a flow is assigned an FGI, it adds its FSE_R(f) to S_CR.
（1）フローfが開始されると、フロー自体がSBDおよびFSEに登録されます。 FSE_R（f）とDR（f）は、輻輳コントローラーの初期レートで初期化されます。 SBDは正しいFGIを割り当てます。フローにFGIが割り当てられると、フローはそのFSE_R（f）をS_CRに追加します。
(2) When a flow f stops or pauses, it sets its DR(f) to 0 and sets P(f) to -1.
（2）フローfは、停止または一時停止すると、そのDR（f）を0に設定し、P（f）を-1に設定します。
(3) Every time the congestion controller of the flow f determines a new sending rate CC_R(f), assuming the flow's new desired rate new_DR(f) to be "infinity" in case of a bulk data transfer with an unknown maximum rate, the flow calls UPDATE, which carries out the tasks listed below to derive the flow's new sending rate, Rate(f). A flow's UPDATE function uses a few local (i.e., per-flow) temporary variables, which are all initialized to 0: DELTA, new_S_CR, and S_P.
（3）フローfの輻輳コントローラーが新しい送信レートCC_R（f）を決定するたびに、最大レートが不明なバルクデータ転送の場合にフローの新しい希望レートnew_DR（f）が「無限大」であると想定し、フローはUPDATEを呼び出します。UPDATEは以下にリストされているタスクを実行して、フローの新しい送信レートであるRate（f）を導出します。フローのUPDATE関数は、いくつかのローカル（フローごと）一時変数を使用します。これらはすべて0に初期化されます：DELTA、new_S_CR、およびS_P。
(a) For all the flows in its FG (including itself), it calculates the sum of all the calculated rates, new_S_CR. Then, it calculates DELTA: the difference between FSE_R(f) and CC_R(f).
（a）FG内のすべてのフロー（自身を含む）について、計算されたすべてのレートの合計new_S_CRを計算します。次に、FSE_R（f）とCC_R（f）の差であるDELTAを計算します。
for all flows i in FG do
new_S_CR = new_S_CR + FSE_R(i)
end for
DELTA = CC_R(f) - FSE_R(f)
(b) It updates S_CR, FSE_R(f), and DR(f).
（b）S_CR、FSE_R（f）、およびDR（f）を更新します。
FSE_R(f) = CC_R(f)
if DELTA > 0 then // the flow's rate has increased
S_CR = S_CR + DELTA
else if DELTA < 0 then
S_CR = new_S_CR + DELTA
end if
DR(f) = min(new_DR(f),FSE_R(f))
(c) It calculates the leftover rate TLO, removes the terminated flows from the FSE, and calculates the sum of all the priorities, S_P.
（c）残存率TLOを計算し、終了したフローをFSEから削除し、すべての優先度の合計S_Pを計算します。
for all flows i in FG do
if P(i)<0 then
delete flow
else
S_P = S_P + P(i)
end if
end for
if DR(f) < FSE_R(f) then
TLO = TLO + (P(f)/S_P) * S_CR - DR(f))
end if
(d) It calculates the sending rate, Rate(f).
（d）送信レート、Rate（f）を計算します。
Rate(f) = min(new_DR(f), (P(f)*S_CR)/S_P + TLO)
if Rate(f) != new_DR(f) and TLO > 0 then
TLO = 0 // f has 'taken' TLO
end if
(e) It updates DR(f) and FSE_R(f) with Rate(f).
（e）DR（f）およびFSE_R（f）をRate（f）で更新します。
if Rate(f) > DR(f) then
DR(f) = Rate(f)
end if
FSE_R(f) = Rate(f)
The goals of the flow algorithm are to achieve prioritization, improve network utilization in the face of application-limited flows, and impose limits on the increase behavior such that the negative impact of multiple flows trying to increase their rate together is minimized. It does that by assigning a flow a sending rate that may not be what the flow's congestion controller expected. It therefore builds on the assumption that no significant inefficiencies arise from temporary application-limited behavior or from quickly jumping to a rate that is higher than the congestion controller intended. How problematic these issues really are depends on the controllers in use and requires careful per-controller experimentation. The coupled congestion control mechanism described here also does not require all controllers to be equal; effects of heterogeneous controllers, or homogeneous controllers being in different states, are also subject to experimentation.
フローアルゴリズムの目的は、優先順位付けを実現し、アプリケーションが制限されたフローに直面してネットワーク使用率を改善し、増加動作に制限を課して、複数のフローが一緒にレートを増加させようとする悪影響を最小限に抑えることです。これは、フローの輻輳コントローラが期待したものとは異なる送信レートをフローに割り当てることによって行われます。したがって、一時的なアプリケーション制限の動作から、または輻輳コントローラーが意図したよりも高いレートに素早くジャンプすることによって、重大な非効率が発生しないという仮定に基づいています。これらの問題の実際の問題の程度は、使用しているコントローラーによって異なり、コントローラーごとに注意深く実験する必要があります。ここで説明する結合された輻輳制御メカニズムでも、すべてのコントローラーが同じである必要はありません。異種コントローラ、または異なる状態にある同種コントローラの影響も実験の対象となります。
This algorithm gives the leftover rate of application-limited flows to the first flow that updates its sending rate, provided that this flow needs it all (otherwise, its own leftover rate can be taken by the next flow that updates its rate). Other policies could be applied, e.g., to divide the leftover rate of a flow equally among all other flows in the FGI.
このアルゴリズムは、アプリケーションが制限するフローの残りのレートを、送信レートを更新する最初のフローに提供します。ただし、このフローがすべてを必要とする場合（そうでない場合、独自の残りのレートは、レートを更新する次のフローで使用できます）。他のポリシーを適用して、たとえば、フローの残りのレートをFGI内の他のすべてのフロー間で均等に分割することができます。
In order to illustrate the operation of the passive coupled congestion control algorithm, this section presents a toy example of two flows that use it. Let us assume that both flows traverse a common 10 Mbit/s bottleneck and use a simplistic congestion controller that starts out with 1 Mbit/s, increases its rate by 1 Mbit/s in the absence of congestion, and decreases it by 2 Mbit/s in the presence of congestion. For simplicity, flows are assumed to always operate in a round-robin fashion. Rate numbers below without units are assumed to be in Mbit/s. For illustration purposes, the actual sending rate is also shown for every flow in FSE diagrams even though it is not really stored in the FSE.
パッシブ結合輻輳制御アルゴリズムの動作を説明するために、このセクションでは、それを使用する2つのフローのおもちゃの例を示します。両方のフローが共通の10メガビット/秒のボトルネックを通過し、1メガビット/秒で開始し、輻輳がない場合はレートを1メガビット/秒増加させ、2メガビット/秒減少させる単純な輻輳コントローラーを使用するとします。 s混雑が存在する場合。簡単にするために、フローは常にラウンドロビン方式で動作すると想定されています。単位のない以下のレート番号はMbit / sであると想定されています。説明のために、実際の送信レートは実際にはFSEに格納されていなくても、FSE図のすべてのフローについても示されています。
Flow #1 begins. It is a bulk data transfer and considers itself to have top priority. This is the FSE after the flow algorithm's step 1:
フロー＃1が始まります。これはバルクデータ転送であり、自分自身を最優先と見なします。これは、フローアルゴリズムのステップ1の後のFSEです。
----------------------------------------
| # | FGI | P | FSE_R | DR | Rate |
| | | | | | |
| 1 | 1 | 1 | 1 | 1 | 1 |
----------------------------------------
S_CR = 1, TLO = 0
Its congestion controller gradually increases its rate. Eventually, at some point, the FSE should look like this:
その輻輳コントローラーは徐々に速度を上げます。最終的に、ある時点で、FSEは次のようになります。
-----------------------------------------
| # | FGI | P | FSE_R | DR | Rate |
| | | | | | |
| 1 | 1 | 1 | 10 | 10 | 10 |
-----------------------------------------
S_CR = 10, TLO = 0
Now, another flow joins. It is also a bulk data transfer and has a lower priority (0.5):
これで、別のフローが参加します。これはバルクデータ転送でもあり、優先度は低くなります（0.5）。
------------------------------------------
| # | FGI | P | FSE_R | DR | Rate |
| | | | | | |
| 1 | 1 | 1 | 10 | 10 | 10 |
| 2 | 1 | 0.5 | 1 | 1 | 1 |
------------------------------------------
S_CR = 11, TLO = 0
Now, assume that the first flow updates its rate to 8, because the total sending rate of 11 exceeds the total capacity. Let us take a closer look at what happens in step 3 of the flow algorithm.
ここで、11の合計送信レートが合計容量を超えるため、最初のフローがレートを8に更新するとします。フローアルゴリズムのステップ3で何が起こるかを詳しく見てみましょう。
CC_R(1) = 8. new_DR(1) = infinity.
CC_R（1）=8。new_DR（1）=無限。
(3a) new_S_CR = 11; DELTA = 8 - 10 = -2.
（3a）new_S_CR = 11; DELTA = 8-10 = -2。
(3b) FSE_R(1) = 8. DELTA is negative, hence S_CR = 9; DR(1) = 8
(3c) S_P = 1.5.
（3c）S_P = 1.5。
(3d) new sending rate Rate(1) = min(infinity, 1/1.5 * 9 + 0) = 6.
（3d）新しい送信レートRate（1）= min（infinity、1 / 1.5 * 9 + 0）= 6。
(3e) FSE_R(1) = 6.
（3e）FSE_R（1）= 6。
The resulting FSE looks as follows:
結果のFSEは次のようになります。
-------------------------------------------
| # | FGI | P | FSE_R | DR | Rate |
| | | | | | |
| 1 | 1 | 1 | 6 | 8 | 6 |
| 2 | 1 | 0.5 | 1 | 1 | 1 |
-------------------------------------------
S_CR = 9, TLO = 0
The effect is that flow #1 is sending with 6 Mbit/s instead of the 8 Mbit/s that the congestion controller derived. Let us now assume that flow #2 updates its rate. Its congestion controller detects that the network is not fully saturated (the actual total sending rate is 6+1=7) and increases its rate.
その結果、フロー＃1は、輻輳コントローラーが導出した8 Mbit / sではなく、6 Mbit / sで送信しています。フロー＃2がレートを更新すると仮定します。その輻輳コントローラーは、ネットワークが完全に飽和していないことを検出し（実際の総送信速度は6 + 1 = 7）、その速度を上げます。
CC_R(2) = 2. new_DR(2) = infinity.
CC_R（2）=2。new_DR（2）=無限。
(3a) new_S_CR = 7; DELTA = 2 - 1 = 1.
（3a）new_S_CR = 7; DELTA = 2-1 = 1。
(3b) FSE_R(2) = 2. DELTA is positive, hence S_CR = 9 + 1 = 10; DR(2) = 2.
（3b）FSE_R（2）= 2. DELTAは正なので、S_CR = 9 + 1 = 10; DR（2）= 2。
(3c) S_P = 1.5.
（3c）S_P = 1.5。
(3d) Rate(2) = min(infinity, 0.5/1.5 * 10 + 0) = 3.33.
（3d）レート（2）=最小（無限大、0.5 / 1.5 * 10 + 0）= 3.33。
(3e) DR(2) = FSE_R(2) = 3.33.
（3e）DR（2）= FSE_R（2）= 3.33。
The resulting FSE looks as follows:
結果のFSEは次のようになります。
-------------------------------------------
| # | FGI | P | FSE_R | DR | Rate |
| | | | | | |
| 1 | 1 | 1 | 6 | 8 | 6 |
| 2 | 1 | 0.5 | 3.33 | 3.33 | 3.33 |
-------------------------------------------
S_CR = 10, TLO = 0
The effect is that flow #2 is now sending with 3.33 Mbit/s, which is close to half of the rate of flow #1 and leads to a total utilization of 6(#1) + 3.33(#2) = 9.33 Mbit/s. Flow #2's congestion controller has increased its rate faster than the controller actually expected. Now, flow #1 updates its rate. Its congestion controller detects that the network is not fully saturated and increases its rate. Additionally, the application feeding into flow #1 limits the flow's sending rate to at most 2 Mbit/s.
効果は、フロー＃2が3.33 Mbit / sで送信していることです。これは、フロー＃1のレートの半分に近く、合計使用率は6（＃1）+ 3.33（＃2）= 9.33 Mbit /になります。 s。フロー＃2の輻輳コントローラーは、コントローラーが実際に予想したよりも速く速度を上げました。これで、フロー＃1がレートを更新します。その輻輳コントローラーは、ネットワークが完全に飽和していないことを検出し、その速度を上げます。さらに、フロー＃1にフィードするアプリケーションは、フローの送信速度を最大2 Mbit / sに制限します。
CC_R(1) = 7. new_DR(1) = 2.
CC_R（1）= 7. new_DR（1）= 2。
(3a) new_S_CR = 9.33; DELTA = 1.
（3a）new_S_CR = 9.33; DELTA = 1。
(3b) FSE_R(1) = 7, DELTA is positive, hence S_CR = 10 + 1 = 11; DR(1) = min(2, 7) = 2.
（3b）FSE_R（1）= 7、DELTAは正であるため、S_CR = 10 + 1 = 11; DR（1）= min（2、7）= 2。
(3c) S_P = 1.5; DR(1) < FSE_R(1), hence TLO = 1/1.5 * 11 - 2 = 5.33.
（3c）S_P = 1.5; DR（1）<FSE_R（1）、したがってTLO = 1 / 1.5 * 11-2 = 5.33。
(3d) Rate(1) = min(2, 1/1.5 * 11 + 5.33) = 2.
（3d）レート（1）= min（2、1 / 1.5 * 11 + 5.33）= 2。
(3e) FSE_R(1) = 2.
（3e）FSE_R（1）= 2。
The resulting FSE looks as follows:
結果のFSEは次のようになります。
-------------------------------------------
| # | FGI | P | FSE_R | DR | Rate |
| | | | | | |
| 1 | 1 | 1 | 2 | 2 | 2 |
| 2 | 1 | 0.5 | 3.33 | 3.33 | 3.33 |
-------------------------------------------
S_CR = 11, TLO = 5.33
Now, the total rate of the two flows is 2 + 3.33 = 5.33 Mbit/s, i.e., the network is significantly underutilized due to the limitation of flow #1. Flow #2 updates its rate. Its congestion controller detects that the network is not fully saturated and increases its rate.
現在、2つのフローの合計レートは2 + 3.33 = 5.33 Mbit / sです。つまり、フロー＃1の制限により、ネットワークは十分に活用されていません。フロー＃2はレートを更新します。その輻輳コントローラーは、ネットワークが完全に飽和していないことを検出し、その速度を上げます。
CC_R(2) = 4.33. new_DR(2) = infinity.
CC_R（2）= 4.33。 new_DR（2）=無限大。
(3a) new_S_CR = 5.33; DELTA = 1.
（3a）new_S_CR = 5.33; DELTA = 1。
(3b) FSE_R(2) = 4.33. DELTA is positive, hence S_CR = 12; DR(2) = 4.33.
（3b）FSE_R（2）= 4.33。 DELTAは正なので、S_CR = 12です。 DR（2）= 4.33。
(3c) S_P = 1.5.
（3c）S_P = 1.5。
(3d) Rate(2) = min(infinity, 0.5/1.5 * 12 + 5.33 ) = 9.33.
（3d）Rate（2）= min（infinity、0.5 / 1.5 * 12 + 5.33）= 9.33。
(3e) FSE_R(2) = 9.33, DR(2) = 9.33.
（3e）FSE_R（2）= 9.33、DR（2）= 9.33。
The resulting FSE looks as follows:
結果のFSEは次のようになります。
-------------------------------------------
| # | FGI | P | FSE_R | DR | Rate |
| | | | | | |
| 1 | 1 | 1 | 2 | 2 | 2 |
| 2 | 1 | 0.5 | 9.33 | 9.33 | 9.33 |
-------------------------------------------
S_CR = 12, TLO = 0
Now, the total rate of the two flows is 2 + 9.33 = 11.33 Mbit/s. Finally, flow #1 terminates. It sets P(1) to -1 and DR(1) to 0. Let us assume that it terminated late enough for flow #2 to still experience the network in a congested state, i.e., flow #2 decreases its rate in the next iteration.
現在、2つのフローの合計レートは2 + 9.33 = 11.33 Mbit / sです。最後に、フロー＃1が終了します。 P（1）を-1に設定し、DR（1）を0に設定します。フロー＃2がネットワークを引き続き輻輳状態にするのに十分なほど遅く終了したと仮定します。反復。
CC_R(2) = 7.33. new_DR(2) = infinity.
CC_R（2）= 7.33。 new_DR（2）=無限大。
(3a) new_S_CR = 11.33; DELTA = -2.
（3a）new_S_CR = 11.33; DELTA = -2。
(3b) FSE_R(2) = 7.33. DELTA is negative, hence S_CR = 9.33; DR(2) = 7.33.
（3b）FSE_R（2）= 7.33。 DELTAは負なので、S_CR = 9.33; DR（2）= 7.33。
(3c) Flow 1 has P(1) = -1, hence it is deleted from the FSE. S_P = 0.5.
（3c）フロー1にはP（1）= -1があるため、FSEから削除されます。 S_P = 0.5。
(3d) Rate(2) = min(infinity, 0.5/0.5*9.33 + 0) = 9.33.
（3d）レート（2）=最小（無限大、0.5 / 0.5 * 9.33 + 0）= 9.33。
(3e) FSE_R(2) = DR(2) = 9.33.
（3e）FSE_R（2）= DR（2）= 9.33。
The resulting FSE looks as follows:
結果のFSEは次のようになります。
-------------------------------------------
| # | FGI | P | FSE_R | DR | Rate |
| | | | | | |
| 2 | 1 | 0.5 | 9.33 | 9.33 | 9.33 |
-------------------------------------------
S_CR = 9.33, TLO = 0
Acknowledgements
謝辞
This document benefited from discussions with and feedback from Andreas Petlund, Anna Brunstrom, Colin Perkins, David Hayes, David Ros (who also gave the FSE its name), Ingemar Johansson, Karen Nielsen, Kristian Hiorth, Martin Stiemerling, Mirja Kühlewind, Spencer Dawkins, Varun Singh, Xiaoqing Zhu, and Zaheduzzaman Sarker. The authors would like to especially thank Xiaoqing Zhu and Stefan Holmer for helping with NADA and GCC, and Anna Brunstrom as well as Julius Flohr for helping us correct the active algorithm for the case of application-limited flows.
このドキュメントは、Andreas Petlund、Anna Brunstrom、Colin Perkins、David Hayes、David Ros（FSEにもその名前を付けた）、Ingemar Johansson、Karen Nielsen、Kristian Hiorth、Martin Stiemerling、MirjaKühlewind、Spencer Dawkinsとのディスカッションとフィードバックから利益を得ました、Varun Singh、Xiaoqing Zhu、Zaheduzzaman Sarker。著者は、NADAとGCCを支援してくれたXiaoqing ZhuとStefan Holmer、アプリケーションが限定されたフローの場合のアクティブアルゴリズムを修正してくれたAnna BrunstromとJulius Flohrに特に感謝します。
This work was partially funded by the European Community under its Seventh Framework Program through the Reducing Internet Transport Latency (RITE) project (ICT-317700).
この作業は、第7フレームワークプログラムに基づいて、インターネットトランスポートレイテンシの削減（RITE）プロジェクト（ICT-317700）を通じて、欧州共同体によって部分的に資金提供されました。
Authors' Addresses
著者のアドレス
Safiqul Islam University of Oslo PO Box 1080 Blindern N-0316 Oslo Norway
Safiqul Islam University of Oslo PO Box 1080 Blindern N-0316オスロノルウェー
Phone: +47 22 84 08 37
Email: safiquli@ifi.uio.no
Michael Welzl University of Oslo PO Box 1080 Blindern N-0316 Oslo Norway
マイケルウェルズル大学オスロ私書箱1080ブリンデンN-0316オスロノルウェー
Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no
Stein Gjessing University of Oslo PO Box 1080 Blindern N-0316 Oslo Norway
スタインジェシン大学オスロ私書箱1080 Blindern N-0316オスロノルウェー
Phone: +47 22 85 24 44
Email: steing@ifi.uio.no