[要約] RFC 9265 は、FECコーディングと輻輳制御が共存する方法についての議論を提供し、通信システムにおけるFECコーディングの提案や比較において輻輳制御の側面も考慮することを研究コミュニティに奨励する目的を持つ。
Internet Research Task Force (IRTF) N. Kuhn
Request for Comments: 9265 CNES
Category: Informational E. Lochin
ISSN: 2070-1721 ENAC
F. Michel
UCLouvain
M. Welzl
University of Oslo
July 2022
Forward Erasure Correction (FEC) Coding and Congestion Control in Transport
輸送における前方消去補正（FEC）コーディングと混雑制御
Abstract
概要
Forward Erasure Correction (FEC) is a reliability mechanism that is distinct and separate from the retransmission logic in reliable transfer protocols such as TCP. FEC coding can help deal with losses at the end of transfers or with networks having non-congestion losses. However, FEC coding mechanisms should not hide congestion signals. This memo offers a discussion of how FEC coding and congestion control can coexist. Another objective is to encourage the research community to also consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems.
前方消去補正（FEC）は、TCPなどの信頼できる転送プロトコルの再送信ロジックとは異なる信頼性メカニズムです。FECコーディングは、転送の終了時の損失や、非合成損失のネットワークに対処するのに役立ちます。ただし、FECコーディングメカニズムはうっ血信号を隠してはなりません。このメモは、FECコーディングと輻輳制御がどのように共存できるかについての議論を提供します。もう1つの目的は、コミュニケーションシステムでFECコーディングソリューションを提案および比較する際に、研究コミュニティが混雑制御の側面を検討することを奨励することです。
This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG). The scope of the document is end-to-end communications; FEC coding for tunnels is out of the scope of the document.
このドキュメントは、効率的なネットワークコミュニケーション研究グループ（NWCRG）のコーディングの製品です。ドキュメントの範囲はエンドツーエンドの通信です。トンネルのFECコーディングは、ドキュメントの範囲外です。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Network Coding for Efficient Network Communications Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）の効率的なネットワークコミュニケーション研究グループをコーディングするネットワークのコンセンサスを表しています。IRSGによって公開されることが承認された文書は、インターネット標準のレベルの候補者ではありません。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/rfc9265.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9265で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction
2. Context
2.1. Fairness, Quantifying and Limiting Harm, and Policy
Concerns
2.2. Separate Channels, Separate Entities
2.3. Relation between Transport Layer and Application
Requirements
2.4. Scope of the Document Concerning Transport Multipath and
Multistream Applications
2.5. Types of Coding
3. FEC above the Transport
3.1. Fairness and Impact on Non-coded Flows
3.2. Congestion Control and Recovered Symbols
3.3. Interactions between Congestion Control and Coding Rates
3.4. On Useless Repair Symbols
3.5. On Partial Ordering at FEC Level
3.6. On Partial Reliability at FEC Level
3.7. On Multipath Transport and FEC Mechanism
4. FEC within the Transport
4.1. Fairness and Impact on Non-coded Flows
4.2. Interactions between Congestion Control and Coding Rates
4.3. On Useless Repair Symbols
4.4. On Partial Ordering at FEC and/or Transport Level
4.5. On Partial Reliability at FEC Level
4.6. On Transport Multipath and Subpath FEC Coding Rate
5. FEC below the Transport
5.1. Fairness and Impact on Non-coded Flows
5.2. Congestion Control and Recovered Symbols
5.3. Interactions between Congestion Control and Coding Rates
5.4. On Useless Repair Symbols
5.5. On Partial Ordering at FEC Level with In-Order Delivery
Transport
5.6. On Partial Reliability at FEC Level
5.7. FEC Not Aware of Transport Multipath
6. Research Recommendations and Questions
6.1. Activities Related to Congestion Control and Coding
6.2. Open Research Questions
6.2.1. Parameter Derivation
6.2.2. New Signaling Methods and Fairness
6.3. Recommendations and Advice for Evaluating Coding Mechanisms
7. IANA Considerations
8. Security Considerations
9. Informative References
Acknowledgements
Authors' Addresses
There are cases where deploying FEC coding improves the performance of a transmission. As an example, it may take time for a sender to detect transfer tail losses (losses that occur at the end of a transfer where, e.g., TCP obtains no more ACKs that would enable it to quickly repair the loss via retransmission). Allowing the receiver to recover such losses instead of having to rely on a retransmission could improve the experience of applications using short flows. Another example is a network where non-congestion losses are persistent and prevent a sender from exploiting the link capacity.
FECコーディングを展開すると、伝送のパフォーマンスが向上する場合があります。例として、送信者がトランスファーテール損失を検出するのに時間がかかる場合があります（たとえば、TCPが再送信を介して損失を迅速に修復できるようにするACKを取得できない移動の終了時に発生する損失）。再送信に依存する代わりに、受信者がそのような損失を回収できるようにすると、短いフローを使用してアプリケーションの経験を改善することができます。別の例は、非合成損失が持続的であり、送信者がリンク容量を悪用することを妨げるネットワークです。
Coding and the loss detection of congestion controls are two distinct and separate reliability mechanisms. Since FEC coding repairs losses, blindly applying FEC may easily lead to an implementation that also hides a congestion signal from the sender. It is important to ensure that such hiding of information does not occur, because loss may be the only congestion signal available to the sender (e.g., TCP [RFC5681]).
混雑制御のコーディングと損失検出は、2つの異なる信頼性メカニズムです。FECコーディングは損失を修復するため、盲目的にFECを適用すると、送信者からの混雑信号も隠す実装に簡単につながる可能性があります。損失が送信者が利用できる唯一の輻輳信号である可能性があるため、そのような情報の隠れが発生しないことを確認することが重要です（例：TCP [RFC5681]）。
FEC coding and congestion control can be seen as two separate channels. In practice, implementations may mix the signals that are exchanged on these channels. This memo offers a discussion of how FEC coding and congestion control coexist. Another objective is to encourage the research community to also consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems. This document does not aim to propose guidelines for characterizing FEC coding solutions.
FECコーディングと混雑制御は、2つの別々のチャネルと見なすことができます。実際には、実装では、これらのチャネルで交換される信号を組み合わせる場合があります。このメモは、FECコーディングと輻輳制御がどのように共存するかについての議論を提供します。もう1つの目的は、コミュニケーションシステムでFECコーディングソリューションを提案および比較する際に、研究コミュニティが混雑制御の側面を検討することを奨励することです。このドキュメントは、FECコーディングソリューションを特徴付けるためのガイドラインを提案することを目的としていません。
We consider three architectures for end-to-end unicast data transfer:
エンドツーエンドのユニキャストデータ転送のための3つのアーキテクチャを検討します。
* with FEC coding in the application (above the transport) (Section 3),
* アプリケーションのFECコーディング（輸送の上）（セクション3）、
* within the transport (Section 4), or
* 輸送内（セクション4）、または
* directly below the transport (Section 5).
* 輸送の真下（セクション5）。
A typical scenario for the considerations in this document is a client browsing the Web or watching a live video.
このドキュメントの考慮事項の典型的なシナリオは、Webを閲覧したり、ライブビデオを見たりするクライアントです。
This document represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product nor a standard. The document follows the terminology proposed in the taxonomy document [RFC8406].
このドキュメントは、効率的なネットワークコミュニケーション研究グループ（NWCRG）のコーディングの共同作業とコンセンサスを表しています。IETF製品でも標準でもありません。この文書は、分類文書[RFC8406]で提案されている用語に従います。
Traffic from or to different end users may share various types of bottlenecks. When such a shared bottleneck does not implement some form of flow protection, the share of the available capacity between single flows can help assess when one flow starves the other.
異なるエンドユーザーからのトラフィックは、さまざまな種類のボトルネックを共有する場合があります。そのような共有ボトルネックが何らかの形のフロー保護を実装しない場合、単一のフロー間の利用可能な容量のシェアは、一方の流れが他方の流れを飢えたときの評価に役立ちます。
As one example, for residential accesses, the data rate can be guaranteed for the customer premises equipment but not necessarily for the end user. The quality of service that guarantees fairness between the different clients can be seen as a policy concern [FLOW-RATE-FAIRNESS].
一例として、住宅へのアクセスの場合、顧客施設機器のデータレートは保証できますが、必ずしもエンドユーザーにはそうではありません。さまざまなクライアント間の公平性を保証するサービスの質は、政策上の懸念[フローレートフェアネス]と見なすことができます。
While past efforts have focused on achieving fairness, quantifying and limiting harm caused by new algorithms (or algorithms with coding) is more practical [BEYONDJAIN]. This document considers fairness as the impact of the addition of coded flows on non-coded flows when they share the same bottleneck. It is assumed that the non-coded flows respond to congestion signals from the network. This document does not contribute to the definition of fairness at a wider scale.
過去の努力は公平性を達成することに焦点を合わせてきましたが、新しいアルゴリズム（またはコーディングを伴うアルゴリズム）によって引き起こされる害の定量化と制限はより実用的です[BeyondJain]。このドキュメントは、同じボトルネックを共有したときに、コード化されたフローに対するコード化されたフローの追加の影響と見なされます。非コード化されたフローは、ネットワークからのうっ血信号に応答すると想定されています。このドキュメントは、より広い規模での公平性の定義に貢献していません。
Figures 1 and 2 present the notations that will be used in this document and introduce the Forward Erasure Correction (FEC) and Congestion Control (CC) channels. The FEC channel carries repair symbols (from the sender to the receiver) and information from the receiver to the sender (e.g., signaling which symbols have been recovered, loss rate prior and/or after decoding, etc.). The CC channel carries network packets from a sender to a receiver and packets signaling information about the network (number of packets received vs. lost, Explicit Congestion Notification (ECN) marks [RFC3168], etc.) from the receiver to the sender. The network packets that are sent by the CC channel may be composed of source packets and/or repair symbols.
図1と2は、このドキュメントで使用される表記を示し、前方消去補正（FEC）および混雑制御（CC）チャネルを導入します。FECチャネルには、修理シンボル（送信者から受信機へ）とレシーバーから送信者への情報（たとえば、どの記号が回収されたか、前および/またはデコード後の損失率など）を搭載しています。CCチャネルは、送信者からレシーバーへのネットワークパケットを搭載し、ネットワークに関する情報を通知するパケット（受信したパケットの数、失われた、明示的な混雑通知（ECN）マーク[RFC3168]など）を送信者に送信者に送信者に配置します。CCチャネルによって送信されるネットワークパケットは、ソースパケットおよび/または修理シンボルで構成されている場合があります。
SENDER RECEIVER
送信者レシーバー
+------+ +------+
| | ----- network packets ---->| |
| CC | | CC |
| | <--- network information ---| |
+------+ +------+
Figure 1: Congestion Control (CC) Channel
図1：混雑制御（CC）チャネル
SENDER RECEIVER
送信者レシーバー
+------+ +------+
| | source and/or | |
| | ----- repair symbols ---->| |
| FEC | | FEC |
| | signaling | |
| | <--- recovered symbols ----| |
+------+ +------+
Figure 2: Forward Erasure Correction (FEC) Channel
図2：前方消去補正（FEC）チャネル
Inside a host, the CC and FEC entities can be regarded as conceptually separate:
ホスト内では、CCおよびFECエンティティは概念的に分離していると見なすことができます。
| ^ | ^
| source | coding |packets | sending
| packets | rate |requirements | rate (or
v | v | window)
+---------------+source +-----------------+
| FEC |and/or | CC |
| |repair | |network
| |symbols | |packets
+---------------+==> +-----------------+==>
^ ^
| signaling | network
| recovered symbols | information
Figure 3: Separate Entities (Sender-Side)
図3：個別のエンティティ（送信者側）
| |
| source and/or | network
| repair symbols | packets
v v
+---------------+ +-----------------+
| FEC |signaling | CC |
| |recovered | |network
| |symbols | |information
+---------------+==> +-----------------+==>
Figure 4: Separate Entities (Receiver-Side)
図4：個別のエンティティ（受信者側）
Figures 3 and 4 provide more details than Figures 1 and 2. Some elements are introduced:
図3および4は、図1および2よりも詳細な詳細を示しています。いくつかの要素が紹介されています。
'network information' (input control plane for the transport including CC): refers not only to the network information that is explicitly signaled from the receiver but all the information a congestion control obtains from a network.
「ネットワーク情報」（CCを含むトランスポートの入力制御プレーン）：受信機から明示的に信号されるネットワーク情報だけでなく、混雑制御がネットワークから取得したすべての情報を参照します。
'requirements' (input control plane for the transport including CC): refers to application requirements such as upper/lower rate bounds, periods of quiescence, or a priority.
「要件」（CCを含む輸送の入力コントロールプレーン）：上/低いレートの境界線、静止期間、または優先度などのアプリケーション要件を指します。
'sending rate (or window)' (output control plane for the transport including CC): refers to the rate at which a congestion control decides to transmit packets based on 'network information'.
「送信レート（またはウィンドウ）」（CCを含む輸送の出力制御プレーン）：輻輳制御が「ネットワーク情報」に基づいてパケットを送信することを決定するレートを指します。
'signaling recovered symbols' (input control plane for the FEC): refers to the information a FEC sender can obtain from a FEC receiver about the performance of the FEC solution as seen by the receiver.
「シグナリング回収されたシンボル」（FECの入力コントロールプレーン）：FEC送信者がFECレシーバーから受信機から受信することができる情報を、受信機に見られるように、FECソリューションのパフォーマンスを指します。
'coding rate' (output control plane for the FEC): refers to the coding rate that is used by the FEC solution (i.e., proportion of transmitted symbols that carry useful data).
「コーディングレート」（FECの出力制御プレーン）：FECソリューション（つまり、有用なデータを運ぶ送信シンボルの割合）が使用するコーディングレートを指します。
'network packets' (output data plane for the CC): refers to the data that is transmitted by a CC sender to a CC receiver. The network packets may contain source and/or repair symbols.
「ネットワークパケット」（CCの出力データプレーン）：CC送信者によってCCレシーバーに送信されるデータを指します。ネットワークパケットには、ソースおよび/または修理シンボルが含まれる場合があります。
'source and/or repair symbols' (data plane for the FEC): refers to the data that is transmitted by a FEC sender to a FEC receiver. The sender can decide to send source symbols only (meaning that the coding rate is 0), repair symbols only (if the solution decides not to send the original source symbols), or a mix of both.
「ソースおよび/または修理シンボル」（FECのデータプレーン）：FEC送信者によってFECレシーバーに送信されるデータを指します。送信者は、ソースシンボルのみを送信することを決定できます（コードレートは0です）、修理シンボルのみ（ソリューションが元のソース記号を送信しないことを決定した場合）、または両方のミックス。
The inputs to FEC (incoming data packets without repair symbols and signaling from the receiver about losses and/or recovered symbols) are distinct from the inputs to CC. The latter calculates a sending rate or window from network information, and it takes the packet to send as input, sometimes along with application requirements such as upper/lower rate bounds, periods of quiescence, or a priority. It is not clear that the ACK signals feeding into a congestion control algorithm are useful to FEC in their raw form, and vice versa; information about recovered blocks may be quite irrelevant to a CC algorithm.
FECへの入力（修理記号なしの着信データパケットおよび損失および/または回収された記号についての受信機からの信号）は、CCへの入力とは異なります。後者は、ネットワーク情報からの送信レートまたはウィンドウを計算し、パケットを入力として送信するには、時には上/低いレートの境界、静止期間、または優先度などのアプリケーション要件とともに送信されます。輻輳制御アルゴリズムに供給するACK信号が、生の形でFECに役立つことは明らかではありません。回収されたブロックに関する情報は、CCアルゴリズムとはまったく関係がない場合があります。
The choice of the adequate transport layer may be related to application requirements and the services offered by a transport protocol [RFC8095]:
適切な輸送層の選択は、アプリケーション要件と輸送プロトコル[RFC8095]によって提供されるサービスに関連している可能性があります。
The transport layer may implement a retransmission mechanism to guarantee the reliability of a data transfer (e.g., TCP). Depending on how the FEC and CC functions are scheduled (FEC above CC (Section 3), FEC in CC (Section 4), and FEC below CC (Section 5)), the impact of reliable transport on the FEC reliability mechanisms is different.
輸送層は、データ転送の信頼性（TCPなど）を保証する再送信メカニズムを実装する場合があります。FECおよびCC関数のスケジュール（CC（セクション3）、CCのFEC（セクション4）、およびCC未満のFEC（セクション5））のスケジュール方法に応じて、FECの信頼性メカニズムに対する信頼できる輸送の影響は異なります。
The transport layer may provide an unreliable transport service (e.g., UDP or the Datagram Congestion Control Protocol (DCCP) [RFC4340]) or a partially reliable transport service (e.g., the Stream Control Transmission Protocol (SCTP) with the partial reliability extension [RFC3758] or QUIC with the unreliable datagram extension [RFC9221]). Depending on the amount of redundancy and network conditions, there could be cases where it becomes impossible to carry traffic. This is further discussed in Section 3 where a "FEC above CC" case is assessed and in Sections 4 and 5 where "FEC in CC" and "FEC below CC" are assessed, respectively.
輸送層は、信頼性の低い輸送サービス（UDPまたはDatagram混雑制御プロトコル（DCCP）[RFC4340]）または部分的に信頼できる輸送サービス（部分的な信頼性拡張[RFC37588を備えたストリーム制御透過プロトコル（SCTP））を提供する場合があります[RFC37588]または信頼性の低いデータグラム拡張[RFC9221]を使用したquic）。冗長性とネットワーク条件の量に応じて、トラフィックを運ぶことが不可能になる場合があります。これは、「CC上記のFEC」ケースが評価されるセクション3でさらに説明し、セクション4および5では、「CCのFEC」および「CC以下のFEC」がそれぞれ評価されます。
2.4. Scope of the Document Concerning Transport Multipath and Multistream Applications
2.4. トランスポートマルチパスおよびマルチストリームアプリケーションに関するドキュメントの範囲
The application layer can be composed of several streams above FEC and transport-layer instances. The transport layer can exploit a multipath mechanism. The different streams could exploit different paths between the sender and the receiver. Moreover, a single-stream application could also exploit a multipath transport mechanism. This section describes what is in the scope of this document with regard to multistream applications and multipath transport protocols.
アプリケーション層は、FECおよび輸送層インスタンスの上のいくつかのストリームで構成できます。輸送層は、マルチパスメカニズムを活用できます。異なるストリームは、送信者と受信機の間で異なるパスを悪用する可能性があります。さらに、シングルストリームアプリケーションは、マルチパス輸送メカニズムを活用することもできます。このセクションでは、マルチストリームアプリケーションとマルチパス輸送プロトコルに関するこのドキュメントの範囲にあるものについて説明します。
The different combinations between multistream applications and multipath transport are the following: (1) one application-layer stream as input packets above a combination of FEC and multipath (Mpath) transport layers (Figure 5) and (2) multiple application-layer streams as input packets above a combination of FEC and multipath (Mpath) or single path (Spath) transport layers (Figure 6). This document further details cases I (in Section 3.7), II (in Section 4.6), and III (in Section 5.7) as illustrated in Figure 5. Cases IV, V, and VI of Figure 6 are related to how multiple streams are managed by a single transport or FEC layer; this does not directly concern the interaction between FEC and the transport and is out of the scope of this document.
マルチストリームアプリケーションとマルチパストランスポートの間の異なる組み合わせは次のとおりです。（1）FECとマルチパス（MPATH）輸送層の組み合わせ（図5）と（2）複数のアプリケーション層ストリームの組み合わせの上に入力パケットとして1つのアプリケーション層パケットがあります。FECとマルチパス（MPATH）またはシングルパス（スパース）輸送層の組み合わせの上の入力パケット（図6）。このドキュメントでは、図5に示すように、このドキュメントI（セクション3.7の）、II（セクション4.6の）、III（セクション5.7の）、およびIII（セクション5.7の）を詳しく説明しています。図6のケースIV、V、およびVIは、複数のストリームの管理方法に関連しています。単一の輸送またはFEC層によって。これは、FECとトランスポート間の相互作用に直接関係するものではなく、このドキュメントの範囲外です。
CASE I CASE II CASE III
+---------------+ +---------------+ +---------------+
| Stream 1 | | Stream 2 | | Stream 3 |
+---------------+ +---------------+ +---------------+
+---------------+ +---------------+ +---------------+
| FEC | | FEC | |Mpath Transport|
+---------------+ | in | +---------------+
|Mpath Transport|
+---------------+ | | +-----+ +-----+
|Mpath Transport| | | |Flow1|...|FlowM|
+---------------+ +---------------+ +-----+ +-----+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|Flow1|...|FlowM| |Flow1|...|FlowM| | FEC |...| FEC |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 5: Transport Multipath and Single-Stream Applications - in the Scope of the Document
図5：ドキュメントの範囲内での輸送マルチパスおよびシングルストリームアプリケーション
CASE IV CASE V CASE VI
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
|Stream1|...|StreamM| |Stream1|...|StreamM| |Stream1|...|StreamM|
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
+-------------------+ +-------------------+ +-------------------+
| | | FEC | | Mpath Transport |
| FEC | +-------------------+ +-------------------+
| above/in/below |
| Spath Transport | +-------------------+ +-------------------+
| | | Mpath Transport | | FEC |
+-------------------+ +-------------------+ +-------------------+
+-------------------+ +-----+ +-----+ +-----+ +-----+
| Flow | |Flow1| ... |FlowM| |Flow1| ... |FlowM|
+-------------------+ +-----+ +-----+ +-----+ +-----+
Figure 6: Transport Single Path, Transport Multipath, and Multistream Applications - out of the Scope of the Document
図6：ドキュメントの範囲外の単一パス、輸送マルチパス、およびマルチストリームアプリケーションの輸送
[RFC8406] summarizes recommended terminology for Network Coding concepts and constructs. In particular, the document identifies the following coding types (among many others):
[RFC8406]は、ネットワークコーディングの概念とコンストラクトに推奨される用語をまとめます。特に、ドキュメントは次のコーディングタイプ（他の多くの中でも）を識別します。
Block Coding: Coding technique where the input Flow must first be segmented into a sequence of blocks; FEC encoding and decoding are performed independently on a per-block basis.
ブロックコーディング：入力フローを最初にブロックのシーケンスにセグメント化する必要があるコーディング手法。FECエンコードとデコードは、ブロックごとに独立して実行されます。
Sliding Window Coding: General class of coding techniques that rely on a sliding encoding window.
スライドウィンドウコーディング：スライドエンコードウィンドウに依存するコード技術の一般的なクラス。
The decoding scheme may not be able to decode all the symbols. The chance of decoding the erased packets depends on the size of the encoding window, the coding rate, and the distribution of erasure in the transmission channel. The FEC channel may let the client transmit information related to the need of supplementary symbols to adapt the level of reliability. Partial and full reliability could be envisioned.
デコードスキームは、すべてのシンボルをデコードできない場合があります。消去されたパケットをデコードする可能性は、エンコードウィンドウのサイズ、コーディングレート、および伝送チャネルの消去の分布に依存します。FECチャネルにより、クライアントは、信頼性のレベルを適応させるために補足記号の必要性に関連する情報を送信できる場合があります。部分的かつ完全な信頼性が想定される可能性があります。
Full reliability: The receiver may hold symbols until the decoding of source symbols is possible. In particular, if the codec does not enable a subset of the system to be inverted, the receiver would have to wait for a certain minimum amount of repair packets before it can recover all the source symbols.
完全な信頼性：レシーバーは、ソースシンボルのデコードが可能になるまでシンボルを保持する場合があります。特に、コーデックがシステムのサブセットを反転させない場合、受信機はすべてのソースシンボルを回復する前に、一定の最小量の修理パケットを待つ必要があります。
Partial reliability: The receiver cannot deliver source symbols that could not have been decoded to the upper layer. For a fixed size of encoding window (for Sliding Window Coding) or of blocks (for Block Coding) containing the source symbols, increasing the amount of repair symbols would increase the chances of recovering the erased symbols. However, this would have an impact on memory requirements, the cost of encoding and decoding processes, and the network overhead.
部分的な信頼性：レシーバーは、上層にデコードできなかったソース記号を配信できません。ソース記号を含むエンコードウィンドウ（スライディングウィンドウコーディング用）またはブロック（ブロックコーディング用）の固定サイズの場合、修理記号の量を増やすと、消去された記号を回復する可能性が高くなります。ただし、これはメモリ要件、エンコードとデコードプロセスのコスト、およびネットワークのオーバーヘッドに影響を与えます。
| source ^ source
| packets | packets
v |
+-------------+ +-------------+
|FEC | signaling|FEC |
| | recovered| |
| | symbols| |
| | <==| |
+-------------+ +-------------+
| source ^ ^ source
| and/or | sending | and/or
| repair | rate | repair
| symbols | (or window) | symbols
v | |
+-------------+ +-------------+
|Transport | network|Transport |
|(incl. CC) | information| |
| |network <==| |
| |packets | |
+-------------+==> +-------------+
SENDER RECEIVER
送信者レシーバー
Figure 7: FEC above the Transport
図7：輸送の上のFEC
Figure 7 presents an architecture where FEC operates on top of the transport.
図7は、FECが輸送の上で動作するアーキテクチャを示しています。
The advantage of this approach is that the FEC overhead does not contribute to congestion in the network when congestion control is implemented at the transport layer, because the repair symbols are sent following the congestion window or rate determined by the CC mechanism. This can result in an improved quality of experience for latency-sensitive applications such as Voice over IP (VoIP) or any not-fully reliable services.
このアプローチの利点は、CCメカニズムによって決定された混雑ウィンドウまたはレートに従って修復記号が送信されるため、輸送層に渋滞制御が実装されている場合、FECオーバーヘッドがネットワークの混雑に寄与しないことです。これにより、Voice over IP（VOIP）や信頼性の低いサービスなどの遅延に敏感なアプリケーションのエクスペリエンスの質が向上する可能性があります。
This approach requires that the transport protocol does not implement a fully reliable in-order data transfer service (e.g., like TCP). QUIC with the unreliable datagram extension [RFC9221] is an example of a protocol for which this is relevant. In cases where the partially reliable transport is blocked and a fallback to a reliable transport is proposed, there is a risk for bad interactions between reliability at the transport level and coding schemes. For reliable transfers, coding usage does not guarantee better performance; instead, it would mainly reduce goodput.
このアプローチでは、輸送プロトコルが完全に信頼性の高い順序内データ転送サービス（TCPなど）を実装しないことが必要です。信頼性の低いデータグラム拡張[RFC9221]のQUICは、これが関連するプロトコルの例です。部分的に信頼できる輸送がブロックされ、信頼できる輸送へのフォールバックが提案されている場合、輸送レベルでの信頼性とコーディングスキームの間に悪い相互作用のリスクがあります。信頼できる転送の場合、コーディングの使用はパフォーマンスの向上を保証するものではありません。代わりに、主にGoodputを減らします。
The addition of coding within the flow does not influence the interaction between coded and non-coded flows. This interaction would mainly depend on the congestion controls associated with each flow.
フロー内でコーディングを追加しても、コード化されたフローと非コード化されたフローの間の相互作用に影響しません。この相互作用は、主に各フローに関連する輻輳制御に依存します。
The congestion control mechanism receives network packets and may not be able to differentiate repair symbols from actual source ones. This differentiation requires a transport protocol to provide more than the services described in [RFC8095], such as specifically indicating what information has been repaired. The relevance of adding coding at the application layer is related to the needs of the application. For real-time applications using an unreliable or partially reliable transport, this approach may reduce the number of losses perceived by the application.
混雑制御メカニズムはネットワークパケットを受け取り、修理シンボルを実際のソースのシンボルと区別できない場合があります。この差別化には、[RFC8095]に記載されているサービス以上のものを提供するためのトランスポートプロトコルが必要です。たとえば、どの情報が修復されたかを具体的に示すなどです。アプリケーションレイヤーでコーディングを追加することの関連性は、アプリケーションのニーズに関連しています。信頼性の低いまたは部分的に信頼できる輸送を使用したリアルタイムアプリケーションの場合、このアプローチは、アプリケーションによって知覚される損失の数を減らす可能性があります。
The coding rate applied at the application layer mainly depends on the available rate or congestion window given by the congestion control underneath. The coding rate could be adapted to avoid adding overhead when the minimum required data rate of the application is not provided by the congestion control underneath. When the congestion control allows sending faster than the application needs, adding coding can reduce packet losses and improve the quality of experience (provided that an unreliable or partially reliable transport is used).
アプリケーションレイヤーに適用されるコーディングレートは、主に下の混雑制御によって与えられる利用可能なレートまたは輻輳ウィンドウに依存します。コーディングレートは、アプリケーションの最小必要なデータレートが下の混雑制御によって提供されない場合にオーバーヘッドを追加しないように適合させることができます。混雑制御がアプリケーションのニーズよりも速く送信できる場合、コーディングを追加するとパケットの損失を減らし、経験の質を向上させることができます（信頼性の低いまたは部分的に信頼できる輸送が使用されている場合）。
The only case where adding useless repair symbols does not obviously result in reduced goodput is when the application rate is limited (e.g., VoIP traffic). In this case, useless repair symbols would only impact the amount of data generated in the network. Extra data in the network can, however, increase the likelihood of increasing delay and/or packet loss, which could provoke a congestion control reaction that would degrade goodput.
役に立たない修理記号を追加すると、明らかにグッドプットが低下しない場合の唯一のケースは、アプリケーションレートが制限されている場合（VoIPトラフィックなど）。この場合、役に立たない修復記号は、ネットワークで生成されたデータの量のみに影響します。ただし、ネットワーク内の追加データは、遅延および/またはパケット損失の増加の可能性を高める可能性があります。
Irrespective of the transport protocol, a FEC mechanism does not require implementing a reordering mechanism if the application does not need it. However, if the application needs in-order delivery of packets, a reordering mechanism at the receiver is required.
輸送プロトコルに関係なく、FECメカニズムでは、アプリケーションが必要としない場合、再注文メカニズムを実装する必要はありません。ただし、アプリケーションがパケットの注文内配信を必要とする場合、受信機での並べ替えメカニズムが必要です。
The application may require partial reliability. In this case, the coding rate of a FEC mechanism could be adapted based on inputs from the application and the trade-off between latency and packet loss. Partial reliability impacts the type of FEC and type of codec that can be used, such as discussed in Section 2.5.
アプリケーションには部分的な信頼性が必要になる場合があります。この場合、FECメカニズムのコーディング速度は、アプリケーションからの入力とレイテンシとパケット損失の間のトレードオフに基づいて適応できます。部分的な信頼性は、セクション2.5で説明したように、使用できるFECのタイプと使用できるコーデックのタイプに影響を与えます。
Whether the transport protocol exploits multiple paths or not does not have an impact on the FEC mechanism.
輸送プロトコルが複数のパスを悪用するかどうかは、FECメカニズムに影響を与えません。
| source ^ source
| packets | packets
v |
+------------+ +------------+
| Transport | | Transport |
| | | |
| +---+ +--+ | signaling| +---+ +--+ |
| |FEC| |CC| | recovered| |FEC| |CC| |
| +---+ +--+ | symbols| +---+ +--+ |
| | <==| |
| |network network| |
| |packets information| |
+------------+ ==> <==+------------+
SENDER RECEIVER
送信者レシーバー
Figure 8: FEC in the Transport
図8：輸送中のFEC
Figure 8 presents an architecture where FEC operates within the transport. The repair symbols are sent within what the congestion window or calculated rate allows, such as in [CTCP].
図8は、FECが輸送内で動作するアーキテクチャを示しています。修理記号は、[CTCP]などの輻輳ウィンドウまたは計算レートが許すもの内で送信されます。
The advantage of this approach is that it allows a joint optimization of CC and FEC. Moreover, the transmission of repair symbols does not add congestion in potentially congested networks but helps repair lost packets (such as tail losses). This joint optimization is the key to prevent flows to consume the whole available capacity. The amount of repair traffic injected should not lead to congestion. As denoted in [FEC-CONGESTION-CONTROL], an increase of the repair ratio should be done conjointly with a decrease of the source sending rate.
このアプローチの利点は、CCとFECの共同最適化を可能にすることです。さらに、修理記号の送信は、潜在的に混雑したネットワークに混雑を追加するのではなく、失われたパケット（テール損失など）の修復に役立ちます。この共同最適化は、利用可能な容量全体を消費するフローを防ぐための鍵です。注入された修理トラフィックの量は、混雑につながるべきではありません。[FEC-Congestion-Control]で示されているように、修復率の増加は、ソース送信率の低下と結合して行う必要があります。
The drawback of this approach is that it may require specific signaling and transport services that may not be described in [RFC8095]. Therefore, development and maintenance may require specific efforts at both the transport and the coding levels, and the design of the solution may end up being complex to suit different deployment needs.
このアプローチの欠点は、[RFC8095]で説明されていない特定のシグナル伝達および輸送サービスが必要になる可能性があることです。したがって、開発とメンテナンスには、輸送レベルとコーディングレベルの両方で特定の努力が必要になる場合があり、ソリューションの設計は、さまざまな展開ニーズに合わせて複雑になる可能性があります。
For reliable transfers, including redundancy reduces goodput for long transfers, but the amount of repair symbols can be adapted, e.g., depending on the congestion window size. There is a trade-off between 1) the capacity that could have been exploited by application data instead of transmitting source packets and 2) the benefits derived from transmitting repair symbols (e.g., unlocking the receive buffer if it is limiting). The coding ratio needs to be carefully designed. For small files, sending repair symbols when there is no more data to transmit could help to reduce the transfer time. Sending repair symbols can avoid the silence period between the transmission of the last packet in the send buffer and 1) firing a retransmission of lost packets or 2) the transmission of new packets.
冗長性を含む信頼性の高い転送の場合、長い転送のためのグッドプットを削減しますが、修理記号の量は、たとえば、輻輳ウィンドウサイズに応じて適応できます。1）送信ソースパケットの代わりにアプリケーションデータによって悪用される可能性のある容量と2）送信修理シンボルから得られる利点の間にトレードオフがあります（たとえば、制限されている場合は受信バッファーのロックを解除します）。コーディング比は慎重に設計する必要があります。小さなファイルの場合、送信するデータがもうない場合に修理記号を送信すると、転送時間を短縮するのに役立ちます。修理記号を送信すると、送信バッファー内の最後のパケットの送信と1）紛失パケットの再送信または2）新しいパケットの送信の間の沈黙期間を回避できます。
Examples of the solution could be to add a given percentage of the congestion window or rate as supplementary symbols or to send a fixed amount of repair symbols at a fixed rate. The redundancy flow can be decorrelated from the congestion control that manages source packets; a separate congestion control entity could be introduced to manage the amount of recovered symbols to transmit on the FEC channel. The separate congestion control instances could be made to work together while adhering to priorities, as in coupled congestion control for RTP media [RFC8699] in case all traffic can be assumed to take the same path, or otherwise with a multipath congestion window coupling mechanism as in Multipath TCP [RFC6356]. Another possibility would be to exploit a lower-than-best-effort congestion control [RFC6297] for repair symbols.
解決策の例は、特定の割合の輻輳ウィンドウまたはレートを補足記号として追加するか、固定金額の修理記号を固定速度で送信することです。冗長性の流れは、ソースパケットを管理するうっ血制御から切り離すことができます。FECチャネルで送信する回収された記号の量を管理するために、別の混雑制御エンティティを導入できます。すべてのトラフィックが同じ経路をとることができると想定できる場合、またはマルチパス渋滞ウィンドウカップリングメカニズムの場合、RTPメディア[RFC8699]の結合された混雑制御のように、優先順位に付着している間、別々の混雑制御インスタンスを協力して作業することができます。マルチパスTCP [RFC6356]。別の可能性は、修復記号のために、ベストよりも低いエフォルトの混雑制御[RFC6297]を活用することです。
Specific interaction between congestion controls and coding schemes can be proposed (see Sections 4.2 and 4.3). If no specific interaction is introduced, the coding scheme may hide congestion losses from the congestion controller, and the description of Section 5 may apply.
混雑制御とコーディングスキームの間の特定の相互作用を提案できます（セクション4.2および4.3を参照）。特定の相互作用が導入されていない場合、コーディングスキームは混雑コントローラーからの輻輳損失を非表示にする可能性があり、セクション5の説明が適用される場合があります。
The receiver can differentiate between source packets and repair symbols. The receiver may indicate both the number of source packets received and the repair symbols that were actually useful in the recovery process of packets. The congestion control at the sender can then exploit this information to tune congestion control behavior.
受信機は、ソースパケットと修理シンボルを区別できます。受信機は、受信したソースパケットの数と、実際にパケットの回復プロセスに役立つ修理シンボルの両方を示している場合があります。送信者の混雑制御は、この情報を活用して、混雑制御動作を調整することができます。
There is an important flexibility in the trade-off, inherent to the use of coding, between (1) reducing goodput when useless repair symbols are transmitted and (2) helping to recover from losses earlier than with retransmissions. The receiver may indicate to the sender the number of packets that have been received or recovered. The sender may use this information to tune the coding ratio. For example, coupling an increased transmission rate with an increasing or decreasing coding rate could be envisioned. A server may use a decreasing coding rate as a probe of the channel capacity and adapt the congestion control transmission rate.
（1）役に立たない修復記号が送信された場合、（2）再送信よりも早い段階から回復するのに役立つ、コーディングの使用に固有のトレードオフには重要な柔軟性があります。受信者は、受信または回収されたパケットの数を送信者に示す場合があります。送信者は、この情報を使用してコーディング比を調整できます。たとえば、送信速度の増加とコーディング速度の増加を結合することは、想定される可能性があります。サーバーは、チャネル容量のプローブとしてコードレートの減少を使用し、輻輳制御伝送速度を適応させることができます。
The sender may exploit the information given by the receiver to reduce the number of useless repair symbols and improve goodput.
送信者は、受信者から与えられた情報を悪用して、役に立たない修理記号の数を減らし、Goodputを改善する場合があります。
The application may require in-order delivery of packets. In this case, both FEC and transport-layer mechanisms should guarantee that packets are delivered in order. If partial ordering is requested by the application, both the FEC and transport could relax the constraints related to in-order delivery; partial ordering impacts both the congestion control and the type of FEC and type of codec that can be used.
アプリケーションには、パケットの注文の配信が必要になる場合があります。この場合、FECと輸送層の両方のメカニズムは、パケットが順番に配信されることを保証する必要があります。アプリケーションによって部分的な順序付けが要求された場合、FECと輸送の両方が、注文の配信に関連する制約を緩和することができます。部分的な順序付けは、混雑制御と使用できるCodecのタイプとCodecのタイプの両方に影響します。
The application may require partial reliability. The reliability offered by FEC may be sufficient with no retransmission required. This depends on application needs and the trade-off between latency and loss. Partial reliability impacts the type of FEC and type of codec that can be used, such as discussed in Section 2.5.
アプリケーションには部分的な信頼性が必要になる場合があります。FECが提供する信頼性は、再送信が必要ない場合に十分である可能性があります。これは、アプリケーションのニーズと潜時と損失の間のトレードオフに依存します。部分的な信頼性は、セクション2.5で説明したように、使用できるFECのタイプと使用できるコーデックのタイプに影響を与えます。
The sender may adapt the coding rate of each of the single subpaths whether the congestion control is coupled or not. There is an important flexibility on how the coding rate is tuned depending on the characteristics of each subpath.
送信者は、混雑制御が結合されているかどうかにかかわらず、単一のサブパスのそれぞれのコーディングレートを適応させることができます。各サブパスの特性に応じて、コーディングレートの調整方法には重要な柔軟性があります。
| source ^ source
| packets | packets
v |
+--------------+ +--------------+
|Transport | network|Transport |
|(including CC)| information| |
| | <==| |
+--------------+ +--------------+
| network packets ^ network packets
v |
+--------------+ +--------------+
| FEC |source | FEC |
| |and/or signaling| |
| |repair recovered| |
| |symbols symbols| |
| |==> <==| |
+--------------+ +--------------+
SENDER RECEIVER
送信者レシーバー
Figure 9: FEC below the Transport
図9：輸送の下のFEC
Figure 9 presents an architecture where FEC is applied end to end below the transport layer but above the link layer. Note that it is common to apply FEC at the link layer on one or more of the links that make up the end-to-end path. The application of FEC at the link layer contributes to the total capacity that a link exposes to upper layers, but it may not be visible to either the end-to-end sender or the receiver, if the end-to-end sender and receiver are separated by more than one link; this is therefore out of scope for this document. This includes the use of FEC on top of a link layer in scenarios where the link is known by configuration. In the scenario considered here, the repair symbols are not visible to the end-to-end congestion controller and may be sent on top of what is allowed by the congestion control.
図9は、FECが輸送層の下ではなくリンク層の上に端から端まで端が適用されるアーキテクチャを示しています。エンドツーエンドパスを構成する1つ以上のリンクにリンクレイヤーにFECを適用することが一般的であることに注意してください。リンク層でのFECの適用は、リンクが上層層にさらされる総容量に寄与しますが、エンドツーエンドの送信者と受信機の場合、エンドツーエンドの送信者または受信機のいずれにも見えない場合があります複数のリンクで分離されています。したがって、これはこのドキュメントの範囲外です。これには、リンクが構成によって知られているシナリオのリンクレイヤーの上でのFECの使用が含まれます。ここで考慮されるシナリオでは、修復記号はエンドツーエンドの輻輳コントローラーには見えず、輻輳制御によって許可されているものの上に送信される場合があります。
Including redundancy adds traffic without reducing goodput but incurs potential fairness issues. The effective bit rate is higher than the CC's computed fair share due to the transmission of repair symbols, and losses are hidden from the transport. This may cause a problem for loss-based congestion detection, but it is not a problem for delay-based congestion detection.
冗長性を含めると、Goodputを減らすことなくトラフィックが追加されますが、潜在的な公平性の問題は発生します。有効ビットレートは、修理シンボルの送信により、CCの計算された公正シェアよりも高く、輸送から損失が隠されています。これは、損失ベースの混雑検出の問題を引き起こす可能性がありますが、遅延ベースの輻輳検出の問題ではありません。
The advantage of this approach is that it can result in performance gains when there are persistent transmission losses along the path.
このアプローチの利点は、パスに沿って永続的な伝送損失がある場合にパフォーマンスの向上をもたらす可能性があることです。
The drawback of this approach is that it can induce congestion in already congested networks. The coding ratio needs to be carefully designed.
このアプローチの欠点は、すでに混雑しているネットワークに混雑を引き起こす可能性があることです。コーディング比は慎重に設計する必要があります。
Examples of the solution could be to add a given percentage of the congestion window or rate as supplementary symbols or to send a fixed amount of repair symbols at a fixed rate. The redundancy flow can be decorrelated from the congestion control that manages source packets; a separate congestion control entity could be introduced to manage the amount of recovered symbols to transmit on the FEC channel. The separate congestion control instances could be made to work together while adhering to priorities, as in coupled congestion control for RTP media [RFC8699] in case all traffic can be assumed to take the same path, or otherwise with a multipath congestion window coupling mechanism as in Multipath TCP [RFC6356]. Another possibility would be to exploit a lower-than-best-effort congestion control [RFC6297] for repair symbols.
解決策の例は、特定の割合の輻輳ウィンドウまたはレートを補足記号として追加するか、固定金額の修理記号を固定速度で送信することです。冗長性の流れは、ソースパケットを管理するうっ血制御から切り離すことができます。FECチャネルで送信する回収された記号の量を管理するために、別の混雑制御エンティティを導入できます。すべてのトラフィックが同じ経路をとることができると想定できる場合、またはマルチパス渋滞ウィンドウカップリングメカニズムの場合、RTPメディア[RFC8699]の結合された混雑制御のように、優先順位に付着している間、別々の混雑制御インスタンスを協力して作業することができます。マルチパスTCP [RFC6356]。別の可能性は、修復記号のために、ベストよりも低いエフォルトの混雑制御[RFC6297]を活用することです。
The coding scheme may hide congestion losses from the congestion controller. There are cases where this can drastically reduce the goodput of non-coded flows. Depending on the congestion control, it may be possible to signal to the congestion control mechanism that there was congestion (loss) even when a packet has been recovered, e.g., using ECN, to reduce the impact on the non-coded flows (see Section 5.2 and [TENTET]).
コーディングスキームは、混雑コントローラーからの輻輳損失を非表示にする可能性があります。これにより、コード化されていないフローのグッドプットを大幅に減らすことができる場合があります。輻輳制御に応じて、混雑制御メカニズムに、たとえばECNを使用してパケットが回収された場合でも混雑制御メカニズム（損失）があったことを示すことが可能かもしれません。5.2および[テントセット]）。
The congestion control may not be aware of the existence of a coding scheme underneath it. The congestion control may behave as if no coding scheme had been introduced. The only way for a coding channel to indicate that symbols have been lost but recovered is to exploit existing signaling that is understood by the congestion control mechanism. An example would be to indicate to a TCP sender that a packet has been received, yet congestion has occurred, by using ECN signaling [TENTET].
混雑制御は、その下にコーディングスキームの存在を認識していない場合があります。混雑制御は、まるでコーディングスキームが導入されていないかのように動作する場合があります。コーディングチャネルがシンボルが失われたが回復されたことを示す唯一の方法は、混雑制御メカニズムによって理解される既存のシグナル伝達を活用することです。例は、ECNシグナル[テントセット]を使用して、パケットが受信されたが、混雑が発生したことをTCP送信者に示すことです。
The coding rate can be tuned depending on the number of recovered symbols and the rate at which the sender transmits data. If the coding scheme is not aware of the congestion control implementation, it is hard for the coding scheme to apply the relevant coding rate.
コーディングレートは、回収された記号の数と、送信者がデータを送信するレートに応じて調整できます。コーディングスキームが混雑制御の実装を認識していない場合、コーディングスキームが関連するコーディングレートを適用することは困難です。
Useless repair symbols only impact the load on the network without actual gain for the coded flow. Using feedback signaling, FEC mechanisms can measure the ratio between the number of symbols that were actually used and the number of symbols that were useless, and adjust the coding rate.
役に立たない修理シンボルは、コード化されたフローの実際のゲインなしにネットワーク上の負荷にのみ影響します。フィードバックシグナル伝達を使用すると、FECメカニズムは、実際に使用された記号の数と役に立たないシンボルの数の比率を測定し、コーディングレートを調整できます。
The transport above the FEC channel may support out-of-order delivery of packets; reordering mechanisms at the receiver may not be necessary. In cases where the transport requires in-order delivery, the FEC channel may need to implement a reordering mechanism. Otherwise, spurious retransmissions may occur at the transport level.
FECチャネルの上のトランスポートは、パケットの注文不足配信をサポートする場合があります。受信機でメカニズムを並べ替える必要がない場合があります。輸送に注文内配信が必要な場合、FECチャネルは再注文メカニズムを実装する必要がある場合があります。そうしないと、輸送レベルで偽の再送信が発生する可能性があります。
The transport or application layer above the FEC channel may require partial reliability only. FEC may provide an unnecessary service unless it is aware of the reliability requirements. Partial reliability impacts the type of FEC and codec that can be used, such as discussed in Section 2.5.
FECチャネルの上のトランスポートまたはアプリケーション層には、部分的な信頼性のみが必要になる場合があります。FECは、信頼性の要件を認識しない限り、不必要なサービスを提供する場合があります。部分的な信頼性は、セクション2.5で説明したように、使用できるFECとコーデックのタイプに影響を与えます。
The transport may exploit multiple paths without the FEC channel being aware of it. If FEC is aware that multiple paths are in use, FEC can be applied to all subflows as an aggregate, or to each of the subflows individually. If FEC is not aware that multiple paths are in use, FEC can only be applied to each subflow individually. When FEC is applied to all the flows as an aggregate, the varying characteristics of the individual paths may lead to a risk for the coding rate to be inadequate for the characteristics of the individual paths.
輸送は、FECチャネルがそれを認識せずに複数のパスを活用する場合があります。FECが複数のパスが使用されていることを認識している場合、FECはすべてのサブフローに集約として、または個別に各サブフローに適用できます。FECが複数のパスが使用されていることを認識していない場合、FECは各サブフローに個別にのみ適用できます。FECが集合体としてすべてのフローに適用されると、個々のパスのさまざまな特性が、個々のパスの特性に対してコードレートが不十分になるリスクにつながる可能性があります。
This section provides a short state-of-the art overview of activities related to congestion control and coding. The objective is to identify open research questions and contribute to advice when evaluating coding mechanisms.
このセクションでは、混雑制御とコーディングに関連するアクティビティの最先端の概要を説明します。目的は、オープンな研究の質問を特定し、コーディングメカニズムを評価する際にアドバイスに貢献することです。
We map activities related to congestion control and coding with the organization presented in this document:
このドキュメントに示されている組織との混雑制御とコーディングに関連するアクティビティをマッピングします。
For the FEC above transport case: [RFC8680]
上記のFECの場合：[RFC8680]
For the FEC within transport case: [CODING-FOR-QUIC], [QUIC-FEC], and [RFC5109]
輸送ケース内のFECの場合：[コーディングフォークイック]、[QUIC-FEC]、および[RFC5109]
For the FEC below transport case: [NCTCP] and [TETRYS]
以下のFECの輸送ケースの場合：[NCTCP]および[Tetrys]
There is a general trade-off, inherent to the use of coding, between (1) reducing goodput when useless repair symbols are transmitted and (2) helping to recover from transmission and congestion losses.
（1）役に立たない修復記号が送信された場合のグッドプットを減らすことと、（2）伝送および輻輳損失からの回復に役立つ間に、コーディングの使用に固有の一般的なトレードオフがあります。
There is a trade-off related to the amount of redundancy to add as a function of the transport-layer protocol and application requirements.
輸送層プロトコルとアプリケーション要件の関数として追加する冗長性の量に関連するトレードオフがあります。
[RFC8095] describes the mechanisms provided by existing IETF protocols such as TCP, SCTP, or RTP. [RFC8406] describes the variety of coding techniques. The number of combinations makes the determination of an optimum parameters derivation very complex. This depends on application requirements and deployment context.
[RFC8095]は、TCP、SCTP、RTPなどの既存のIETFプロトコルによって提供されるメカニズムを説明しています。[RFC8406]は、コーディング技術の多様性を説明しています。組み合わせの数により、最適なパラメーターの決定が非常に複雑になります。これは、アプリケーションの要件と展開コンテキストに依存します。
Appendix C of [RFC8681] describes how to tune the parameters for a target use case. However, this discussion does not integrate congestion-controlled end points.
[RFC8681]の付録Cでは、ターゲットユースケースのパラメーターを調整する方法について説明します。ただし、この議論では、混雑制御のエンドポイントを統合しません。
Research question 1: "Is there a way to dynamically adjust the codec characteristics depending on the transmission channel, the transport protocol, and application requirements?"
調査質問1：「送信チャネル、輸送プロトコル、およびアプリケーション要件に応じてコーデックの特性を動的に調整する方法はありますか？」
Research question 2: "Should we apply specific per-stream FEC mechanisms when multiple streams with different reliability needs are carried out?"
研究質問2：「異なる信頼性のニーズを持つ複数のストリームが実行された場合、特定のストリームごとのFECメカニズムを適用する必要がありますか？」
Recovering lost symbols may hide congestion losses from the congestion control. Disambiguating ACKed packets from rebuilt packets would help the sender adapt its sending rate accordingly. There are opportunities for introducing interaction between congestion control and coding schemes to improve the quality of experience while guaranteeing fairness with other flows.
失われたシンボルを回復すると、混雑制御から渋滞の損失を隠す場合があります。再構築されたパケットからAckedパケットを編成することは、送信者が送信率をそれに応じて適応させるのに役立ちます。他のフローとの公平性を保証しながら、経験の質を向上させるために、混雑制御とコーディングスキームの間に相互作用を導入する機会があります。
Some existing solutions already propose to disambiguate ACKed packets from rebuilt packets [QUIC-FEC]. New signaling methods and FEC-recovery-aware congestion controls could be proposed. This would allow the design of adaptive coding rates.
いくつかの既存のソリューションは、再構築されたパケット[QUIC-FEC]からAcked Packetを明確にすることをすでに提案しています。新しいシグナル伝達方法とFEC回復を意識する混雑コントロールを提案することができます。これにより、適応コーディングレートの設計が可能になります。
Research question 3: "Should we quantify the harm that a coded flow would induce on a non-coded flow? How can this be reduced while still benefiting from advantages brought by FEC?"
研究質問3：「コード化されたフローが非コードフローに誘発する害を定量化する必要がありますか？FECによってもたらされた利点の恩恵を受けながら、これをどのように減らすことができますか？」
Research question 4: "If transport and FEC senders are collocated and close to the client, and FEC is applied only on the last mile, e.g., to ignore losses on a noisy wireless link, would this raise fairness issues?"
研究質問4：「輸送およびFEC送信者がクライアントに協力してクライアントに近づき、FECが最後のマイルにのみ適用されている場合、たとえば、騒々しいワイヤレスリンクの損失を無視するために、これは公平性の問題を引き起こすでしょうか？」
Research question 5: "Should we propose a generic API to allow dynamic interactions between a transport protocol and a coding scheme? This should consider existing APIs between application and transport layers."
研究質問5：「輸送プロトコルとコーディングスキームの間の動的な相互作用を可能にするための一般的なAPIを提案する必要がありますか？これは、アプリケーション層と輸送層の間の既存のAPIを考慮する必要があります。」
Research Recommendation 1: "From a congestion control point of view, a recovered packet must be considered as a lost packet. This does not apply to the usage of FEC on a path that is known to be lossy."
研究の推奨事項1：「混雑制御の観点から、回収されたパケットは失われたパケットと見なされなければなりません。これは、損失があることが知られているパスでのFECの使用には適用されません。」
Research Recommendation 2: "New research contributions should be mapped following the organization of this document (above, below, and in the congestion control) and should consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems."
研究の推奨事項2：「このドキュメントの組織化（上記、下、および混雑制御）に従って、新しい研究貢献をマッピングする必要があり、通信システムでFECコーディングソリューションを提案および比較する際に混雑制御の側面を考慮する必要があります。」
Research Recommendation 3: "When a research work aims at improving throughput by hiding the packet loss signal from congestion control (e.g., because the path between the sender and receiver is known to consist of a noisy wireless link), the authors should 1) discuss the advantages of using the proposed FEC solution compared to replacing the congestion control by one that ignores a portion of the encountered losses and 2) critically discuss the impact of hiding packet loss from the congestion control mechanism."
研究の推奨事項3：「研究作業が混雑制御からパケット損失信号を隠すことによりスループットを改善することを目的としている場合（たとえば、送信者と受信機の間のパスが騒々しいワイヤレスリンクで構成されていることが知られているため）、著者は議論する必要があります）輻輳制御を遭遇した損失の一部を無視したものに置き換えることと比較して、提案されたFECソリューションを使用することの利点は、2）渋滞制御メカニズムからのパケット損失の隠蔽の影響について批判的に議論します。」
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
FEC and CC schemes can contribute to DoS attacks. Moreover, the transmission of signaling messages from the client to the server should be protected and reliable; otherwise, an attacker may compromise FEC rate adaptation. Indeed, an attacker could either modify the values indicated by the client or drop signaling messages.
FECおよびCCスキームは、DOS攻撃に寄与する可能性があります。さらに、クライアントからサーバーへのシグナリングメッセージの送信は、保護され、信頼できるものでなければなりません。それ以外の場合、攻撃者はFECレートの適応を妥協する場合があります。実際、攻撃者は、クライアントが示す値を変更するか、シグナルメッセージをドロップすることができます。
In case of FEC below the transport, the aggregate rate of source and repair packets may exceed the rate at which a congestion control mechanism allows an application to send. This could result in an application obtaining more than its fair share of the network capacity.
輸送以下のFECの場合、ソースおよび修理パケットの総速度は、輻輳制御メカニズムがアプリケーションを送信できるレートを超える可能性があります。これにより、ネットワーク容量の公正なシェア以上のアプリケーションが得られる可能性があります。
[BEYONDJAIN] Ware, R., Mukerjee, M. K., Seshan, S., and J. Sherry, "Beyond Jain's Fairness Index: Setting the Bar For The Deployment of Congestion Control Algorithms", HotNets '19: Proceedings of the 18th ACM Workshop on Hot Topics in Networks, DOI 10.1145/3365609.3365855, November 2019, <https://doi.org/10.1145/3365609.3365855>.
[BeyondJain] Ware、R.、Mukerjee、M。K.、Seshan、S。、およびJ. Sherry、「Jainの公平性インデックスを超えて：混雑制御アルゴリズムの展開のためのバーの設定」、Hotnets '19：18番目のACMワークショップの議事録ネットワークのホットトピックについては、DOI 10.1145/3365609.3365855、2019年11月、<https://doi.org/10.1145/3365609.336555>。
[CODING-FOR-QUIC] Swett, I., Montpetit, M., Roca, V., and F. Michel, "Coding for QUIC", Work in Progress, Internet-Draft, draft-swett-nwcrg-coding-for-quic-04, 9 March 2020, <https://datatracker.ietf.org/doc/html/draft-swett-nwcrg-coding-for-quic-04>.
[Coding-for-Quic] Swett、I.、Montpetit、M.、Roca、V。、およびF. Michel、「Quicのコーディング」、進行中の作業、インターネットドラフト、ドラフトSwett-Nwcrg-Coding-for-for-quic-04、2020年3月9日、<https://datatracker.ietf.org/doc/html/draft-swett-nwcrg-coding-for-quic-04>。
[CTCP] Kim, M., Cloud, J., ParandehGheibi, A., Urbina, L., Fouli, K., Leith, D., and M. Medard, "Network Coded TCP (CTCP)", arXiv: 1212.2291v3, DOI 10.48550/arXiv.1212.2291, April 2013, <https://doi.org/10.48550/arXiv.1212.2291>.
[CTCP] Kim、M.、Cloud、J.、Parandehgheibi、A.、Urbina、L.、Fouli、K.、Leith、D。、およびM. Medard、 "Network Coded TCP（CTCP）"、arxiv：1212.2291V3、DOI 10.48550/arxiv.1212.2291、2013年4月、<https://doi.org/10.48550/arxiv.1212.2291>。
[FEC-CONGESTION-CONTROL] Singh, V., Nagy, M., Ott, J., and L. Eggert, "Congestion Control Using FEC for Conversational Media", Work in Progress, Internet-Draft, draft-singh-rmcat-adaptive-fec-03, 20 March 2016, <https://datatracker.ietf.org/doc/html/ draft-singh-rmcat-adaptive-fec-03>.
[FEC-Congestion-Control] Singh、V.、Nagy、M.、Ott、J。、およびL. Eggert、「会話メディアにFECを使用した混雑制御」、進行中の作業、インターネットドラフト、ドラフト-Singh-RMCAT-Adaptive-Fec-03、2016年3月20日、<https://datatracker.ietf.org/doc/html/ draft-singh-rmcat-adaptive-fec-03>。
[FLOW-RATE-FAIRNESS] Briscoe, B., "Flow Rate Fairness: Dismantling a Religion", Work in Progress, Internet-Draft, draft-briscoe-tsvarea-fair-02, 11 July 2007, <https://datatracker.ietf.org/doc/html/draft-briscoe-tsvarea-fair-02>.
[フローレートフェアネス]ブリスコー、B。、「流量の公平性：宗教の解体」、進行中の作業、インターネットドラフト、ドラフト - ブリスコ-TSVAREA-FAIR-02、2007年7月11日、<https：// datatracker.ietf.org/doc/html/draft-briscoe-tsvarea-fair-02>。
[NCTCP] Sundararajan, J., Shah, D., Médard, M., Jakubczak, S., Mitzenmacher, M., and J. Barros, "Network Coding Meets TCP: Theory and Implementation", Proceedings of the IEEE (Volume: 99, Issue: 3), DOI 10.1109/JPROC.2010.2093850, March 2011, <https://doi.org/10.1109/JPROC.2010.2093850>.
[NCTCP] Sundararajan、J.、Shah、D.、Médard、M.、Jakubczak、S.、Mitzenmacher、M.、およびJ. Barros、「ネットワークコーディングはTCPを満たしています：理論と実装」、IEEEの議事録（ボリューム：99、問題：3）、doi 10.1109/jproc.2010.2093850、2011年3月、<https://doi.org/10.1109/jproc.2010.2093850>。
[QUIC-FEC] Michel, F., De Coninck, Q., and O. Bonaventure, "QUIC-FEC: Bringing the benefits of Forward Erasure Correction to QUIC", DOI 10.23919/IFIPNetworking.2019.8816838, May 2019, <https://doi.org/10.23919/IFIPNetworking.2019.8816838>.
[Quic-Fec] Michel、F.、de Coninck、Q.、およびO. Bonaventure、「Quic-Fec：Forward Erasure Correctionの利点をQUICにもたらす」、DOI 10.23919/ifipnetworking.2019.8816838、2019年5月、<https：//doi.org/10.23919/ifipnetworking.2019.8816838>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、DOI 10.17487/RFC3168、2001年9月、<https：// www。rfc-editor.org/info/rfc3168>。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, <https://www.rfc-editor.org/info/rfc3758>.
[RFC3758] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M.、およびP. Conrad、「Stream Control Transmission Protocol（SCTP）部分信頼性拡張」、RFC 3758、DOI 10.17487/RFC3758、5月2004、<https://www.rfc-editor.org/info/rfc3758>。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <https://www.rfc-editor.org/info/rfc4340>.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram混雑制御プロトコル（DCCP）」、RFC 4340、DOI 10.17487/RFC4340、2006年3月、<https：//www.rfc-editor。org/info/rfc4340>。
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <https://www.rfc-editor.org/info/rfc5109>.
[RFC5109] Li、A.、ed。、「一般的なフォワードエラー補正のRTPペイロード形式」、RFC 5109、DOI 10.17487/RFC5109、2007年12月、<https://www.rfc-editor.org/info/rfc5109>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V.、およびE. Blanton、「TCP混雑制御」、RFC 5681、DOI 10.17487/RFC5681、2009年9月、<https://www.rfc-editor.org/info/RFC5681>。
[RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 2011, <https://www.rfc-editor.org/info/rfc6297>.
[RFC6297] Welzl、M。およびD. Ros、「ベストより低い輸送プロトコルの調査」、RFC 6297、DOI 10.17487/RFC6297、2011年6月、<https://www.rfc-editor.org/info/rfc6297>。
[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, DOI 10.17487/RFC6356, October 2011, <https://www.rfc-editor.org/info/rfc6356>.
[RFC6356] Raiciu、C.、Handley、M。、およびD. Wischik、「マルチパス輸送プロトコルの混合コントロール」、RFC 6356、DOI 10.17487/RFC6356、2011年10月、<https：//www.rfc-editor。org/info/rfc6356>。
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017, <https://www.rfc-editor.org/info/rfc8095>.
[RFC8095] Fairhurst、G.、ed。、Trammell、B.、ed。、およびM. Kuehlewind、ed。、「IETF輸送プロトコルと混雑制御メカニズムが提供するサービス」、RFC 8095、DOI 10.17487/RFC8095、2017年3月、<https://www.rfc-editor.org/info/rfc8095>。
[RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and S. Sivakumar, "Taxonomy of Coding Techniques for Efficient Network Communications", RFC 8406, DOI 10.17487/RFC8406, June 2018, <https://www.rfc-editor.org/info/rfc8406>.
[RFC8406] Adamson、B.、Adjih、C.、Bilbao、J.、Firoiu、V.、Fitzek、F.、Ghanem、S.、Lochin、E.、Masucci、A.、Montpetit、M-J。、Pedersen、M.、Peralta、G.、Roca、V.、Ed。、Saxena、P。、およびS. Sivakumar、「効率的なネットワーク通信のためのコーディング技術の分類法」、RFC 8406、DOI 10.17487/RFC8406、2018年6月、<https：//www.rfc-editor.org/info/rfc8406>。
[RFC8680] Roca, V. and A. Begen, "Forward Error Correction (FEC) Framework Extension to Sliding Window Codes", RFC 8680, DOI 10.17487/RFC8680, January 2020, <https://www.rfc-editor.org/info/rfc8680>.
[RFC8680] Roca、V。およびA. Begen、「フォワードエラー補正（FEC）フレームワークのスライドウィンドウコードへの拡張」、RFC 8680、DOI 10.17487/RFC8680、2020年1月、<https://www.rfc-editor.orgg/info/rfc8680>。
[RFC8681] Roca, V. and B. Teibi, "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME", RFC 8681, DOI 10.17487/RFC8681, January 2020, <https://www.rfc-editor.org/info/rfc8681>.
[RFC8681] Roca、V.およびB. Teibi、「スライドウィンドウランダム線形コード（RLC）FecFrameの前方消去補正（FEC）スキーム」、RFC 8681、DOI 10.17487/RFC8681、2020年1月、<https：// www。rfc-editor.org/info/rfc8681>。
[RFC8699] Islam, S., Welzl, M., and S. Gjessing, "Coupled Congestion Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699, January 2020, <https://www.rfc-editor.org/info/rfc8699>.
[RFC8699] Islam、S.、Welzl、M。、およびS. Gjessing、「RTP Mediaの結合渋滞制御」、RFC 8699、DOI 10.17487/RFC8699、2020年1月、<https：//www.rfc-editor.org/info/rfc8699>。
[RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", RFC 9221, DOI 10.17487/RFC9221, March 2022, <https://www.rfc-editor.org/info/rfc9221>.
[RFC9221] Pauly、T.、Kinnear、E。、およびD. Schinazi、「QUICへの信頼できないデータグラム拡張」、RFC 9221、DOI 10.17487/RFC9221、2022年3月、<https：//www.rfc-ed.org/info/rfc9221>。
[TENTET] Lochin, E., "On the joint use of TCP and Network Coding", NWCRG Session, IETF 100, November 2017, <https://datatracker.ietf.org/meeting/100/materials/ slides-100-nwcrg-07-lochin-on-the-joint-use-of-tcp-and-network-coding-00>.
[Tentet] Lochin、E。、「TCPとネットワークコーディングの共同使用」、NWCRGセッション、IETF 100、2017年11月、<https://datatracker.ietf.org/meeting/100/materials/ slides-100-nwcrg-07-lochin-on-the-aint-of-of-tcp-and-network-coding-00>。
[TETRYS] Detchart, J., Lochin, E., Lacan, J., and V. Roca, "Tetrys, an On-the-Fly Network Coding protocol", Work in Progress, Internet-Draft, draft-detchart-nwcrg-tetrys-08, 17 October 2021, <https://datatracker.ietf.org/doc/html/draft-detchart-nwcrg-tetrys-08>.
[Tetrys] Detchart、J.、Lochin、E.、Lacan、J。、およびV. Roca、「Tetrys、on-Fly Network Coding Protocol」、Work in Progress、Internet-Draft、Draft-Detchart-NWCRG-tetrys-08、2021年10月17日、<https://datatracker.ietf.org/doc/html/draft-detchart-nwcrg-tetrys-08>。
Acknowledgements
謝辞
Many thanks to Spencer Dawkins, Dave Oran, Carsten Bormann, Vincent Roca, and Marie-Jose Montpetit for their useful comments that helped improve the document.
スペンサー・ドーキンス、デイブ・オラン、カルステン・ボーマン、ヴィンセント・ロカ、マリー・ジョセ・モンペティットに、文書の改善に役立った有用なコメントに感謝します。
Authors' Addresses
著者のアドレス
Nicolas Kuhn CNES Email: nicolas.kuhn.ietf@gmail.com
Nicolas Kuhn Cnesメール：nicolas.kuhn.ietf@gmail.com
Emmanuel Lochin ENAC Email: emmanuel.lochin@enac.fr
Emmanuel Lochin Enac Email：emmanuel.lochin@enac.fr
François Michel UCLouvain Email: francois.michel@uclouvain.be
FrançoisMichelUclouvainメール：francois.michel@uclouvain.be
Michael Welzl University of Oslo Email: michawe@ifi.uio.no
Michael Welzl Oslo University Email：Michawe@ifi.uio.no