[要約] RFC 9407 は、Tetrysというリアルタイムネットワークコーディングプロトコルに関する経験をまとめたものであり、遅延やパケット損失に対応することを目的としています。NWCRGによって開発され、RFC 8406のタクソノミーに準拠しています。
Internet Research Task Force (IRTF) J. Detchart
Request for Comments: 9407 ISAE-SUPAERO
Category: Experimental E. Lochin
ISSN: 2070-1721 ENAC
J. Lacan
ISAE-SUPAERO
V. Roca
INRIA
June 2023
This document describes Tetrys, which is an on-the-fly network coding protocol that can be used to transport delay-sensitive and loss-sensitive data over a lossy network. Tetrys may recover from erasures within an RTT-independent delay thanks to the transmission of coded packets. This document is a record of the experience gained by the authors while developing and testing the Tetrys protocol in real conditions.
このドキュメントでは、損失のあるネットワークを介して遅延に敏感で損失に敏感なデータを輸送するために使用できるフライオンネットワークコーディングプロトコルであるTetryについて説明します。コード化されたパケットの送信により、テトリーはRTTに依存しない遅延内の消去から回復する場合があります。このドキュメントは、実際の条件でTetrysプロトコルを開発およびテストしながら、著者が得た経験の記録です。
This document is a product of the Coding for Efficient NetWork Communications Research Group (NWCRG). It conforms to the NWCRG taxonomy described in RFC 8406.
このドキュメントは、効率的なネットワークコミュニケーション研究グループ（NWCRG）のコーディングの製品です。RFC 8406に記載されているNWCRG分類法に準拠しています。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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 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/rfc9407.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9407で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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の法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
1.1. Requirements Notation
2. Definitions, Notations, and Abbreviations
3. Architecture
3.1. Use Cases
3.2. Overview
4. Tetrys Basic Functions
4.1. Encoding
4.2. The Elastic Encoding Window
4.3. Decoding
5. Packet Format
5.1. Common Header Format
5.1.1. Header Extensions
5.2. Source Packet Format
5.3. Coded Packet Format
5.3.1. The Encoding Vector
5.4. Window Update Packet Format
6. Research Issues
6.1. Interaction with Congestion Control
6.2. Adaptive Coding Rate
6.3. Using Tetrys below the IP Layer for Tunneling
7. Security Considerations
7.1. Problem Statement
7.2. Attacks against the Data Flow
7.3. Attacks against Signaling
7.4. Attacks against the Network
7.5. Baseline Security Operation
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Authors' Addresses
This document is a product of and represents the collaborative work and consensus of the Coding for Efficient NetWork Communications Research Group (NWCRG). It is not an IETF product or an IETF standard.
このドキュメントは、効率的なネットワークコミュニケーション研究グループ（NWCRG）のコーディングの共同作業とコンセンサスの製品であり、表しています。IETF製品やIETF標準ではありません。
This document describes Tetrys, which is an on-the-fly network coding protocol that can be used to transport delay-sensitive and loss-sensitive data over a lossy network. Network codes were introduced in the early 2000s [AHL-00] to address the limitations of transmission over the Internet (delay, capacity, and packet loss). While network codes have seen some deployment fairly recently in the Internet community, the use of application-layer erasure codes in the IETF has already been standardized in the RMT [RFC5052] [RFC5445] and FECFRAME [RFC8680] Working Groups. The protocol presented here may be seen as a network-coding extension to standard unicast transport protocols (or even multicast or anycast with a few modifications). The current proposal may be considered a combination of network erasure coding and feedback mechanisms [Tetrys] [Tetrys-RT].
このドキュメントでは、損失のあるネットワークを介して遅延に敏感で損失に敏感なデータを輸送するために使用できるフライオンネットワークコーディングプロトコルであるTetryについて説明します。ネットワークコードは、インターネット経由の送信の制限（遅延、容量、およびパケット損失）に対処するために、2000年代初頭[AHL-00]に導入されました。ネットワークコードは最近インターネットコミュニティでかなり展開されていますが、IETFでのアプリケーションレイヤー消去コードの使用は、RMT [RFC5052] [RFC5445]およびFECFRAME [RFC8680]ワーキンググループですでに標準化されています。ここで提示されているプロトコルは、標準のユニキャスト輸送プロトコル（またはいくつかの変更を伴うマルチキャストまたはAnycast）のネットワークコーディング拡張と見なされる場合があります。現在の提案は、ネットワーク消去コーディングとフィードバックメカニズム[Tetrys] [Tetrys-Rt]の組み合わせと見なされる場合があります。
The main innovation of the Tetrys protocol is in the generation of coded packets from an elastic encoding window. This window is filled by any source packets coming from an input flow and is periodically updated with the receiver feedback. These feedback messages provide to the sender information about the highest sequence number received or rebuilt, which can enable the flushing the corresponding source packets stored in the encoding window. The size of this window may be fixed or dynamically updated. If the window is full, incoming source packets replace older source packets that are dropped. As a matter of fact, its limit should be correctly sized. Finally, Tetrys allows dealing with losses on both the forward and return paths and is particularly resilient to acknowledgment losses. All these operations are further detailed in Section 4.
Tetrysプロトコルの主な革新は、弾性エンコードウィンドウからのコード化されたパケットの生成にあります。このウィンドウは、入力フローから来るソースパケットで埋められ、レシーバーフィードバックで定期的に更新されます。これらのフィードバックメッセージは、受信または再構築された最高のシーケンス番号に関する情報を送信者に提供します。これにより、エンコードウィンドウに保存されている対応するソースパケットをフラッシュできます。このウィンドウのサイズは固定または動的に更新される場合があります。ウィンドウがいっぱいの場合、着信ソースパケットは、ドロップされた古いソースパケットを置き換えます。実際のところ、その制限は正しくサイズにする必要があります。最後に、Tetrysは、フォワードパスとリターンパスの両方で損失に対処することを許可し、特に承認損失に対して回復力があります。これらすべての操作については、セクション4でさらに詳しく説明しています。
With Tetrys, a coded packet is a linear combination over a finite field of the data source packets belonging to the coding window. The choice of coefficients, as finite fields elements, is a trade-off between the best erasure recovery performance (finite fields of 256 elements) and the system constraints (finite fields of 16 elements are preferred) and is driven by the application.
テトリーを使用すると、コード化されたパケットは、コーディングウィンドウに属するデータソースパケットの有限フィールド上の線形の組み合わせです。有限のフィールド要素としての係数の選択は、最良の消去回復パフォーマンス（256要素の有限フィールド）とシステム制約（16の要素の有限フィールドが推奨）のトレードオフであり、アプリケーションによって駆動されます。
Thanks to the elastic encoding window, the coded packets are built on-the-fly by using a predefined method to choose the coefficients. The redundancy ratio may be dynamically adjusted and the coefficients may be generated in different ways during the transmission. Compared to Forward Error Correction (FEC) block codes, this reduces the bandwidth use and the decoding delay.
弾性エンコードウィンドウのおかげで、コード化されたパケットは、事前定義された方法を使用して係数を選択することにより、フライで構築されます。冗長比は動的に調整され、伝送中に係数が異なる方法で生成される場合があります。フォワードエラー補正（FEC）ブロックコードと比較して、これにより帯域幅の使用とデコード遅延が減少します。
The design description of the Tetrys protocol in this document is complemented by a record of the experience gained by the authors while developing and testing the Tetrys protocol in realistic conditions. In particular, several research issues are discussed in Section 6 following our own experience and observations.
このドキュメントのTetrysプロトコルの設計記述は、現実的な条件でTetrysプロトコルを開発およびテストしながら、著者が得た経験の記録によって補完されます。特に、私たち自身の経験と観察に続いて、セクション6でいくつかの研究問題について説明します。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The notation used in this document is based on the NWCRG taxonomy [RFC8406].
このドキュメントで使用されている表記は、NWCRG分類法[RFC8406]に基づいています。
Source Symbol:
ソースシンボル：
A symbol that is transmitted between the ingress and egress of the network.
ネットワークの侵入と出口の間に送信されるシンボル。
Coded Symbol:
コード化されたシンボル：
A linear combination over a finite field of a set of source symbols.
ソースシンボルのセットの有限フィールド上の線形結合。
Source Symbol ID:
ソースシンボルID：
A sequence number to identify the source symbols.
ソースシンボルを識別するシーケンス番号。
Coded Symbol ID:
コード化されたシンボルID：
A sequence number to identify the coded symbols.
コード化されたシンボルを識別するシーケンス番号。
Encoding Coefficients:
エンコード係数：
Elements of the finite field characterizing the linear combination used to generate coded symbols.
コード化されたシンボルを生成するために使用される線形結合を特徴付ける有限フィールドの要素。
Encoding Vector:
ベクトルのエンコード：
A set of the coding coefficients and input source symbol IDs.
コーディング係数のセットと入力ソースシンボルID。
Source Packet:
ソースパケット：
A source packet contains a source symbol with its associated IDs.
ソースパケットには、関連するIDを持つソース記号が含まれています。
Coded Packet:
コード化されたパケット：
A coded packet contains a coded symbol, the coded symbol's ID, and encoding vector.
コード化されたパケットには、コード化されたシンボル、コード化されたシンボルのID、およびエンコードベクトルが含まれています。
Input Symbol:
入力記号：
A symbol at the input of the Tetrys encoder.
Tetrysエンコーダーの入力のシンボル。
Output Symbol:
出力シンボル：
A symbol generated by the Tetrys encoder. For a non-systematic mode, all output symbols are coded symbols. For a systematic mode, output symbols MAY be the input symbols and a number of coded symbols that are linear combinations of the input symbols plus the encoding vectors.
Tetrysエンコーダーによって生成されたシンボル。非システムモードの場合、すべての出力シンボルはコード化されたシンボルです。系統的モードの場合、出力シンボルは、入力記号と、入力記号とエンコーディングベクトルの線形結合である多くのコード化されたシンボルである場合があります。
Feedback Packet:
フィードバックパケット：
A feedback packet is a packet containing information about the decoded or received source symbols. It MAY also contain additional information about the Packet Error Rate or the number of various packets in the receiver decoding window.
フィードバックパケットは、デコードされたソースシンボルに関する情報を含むパケットです。また、パケットエラー率または受信機デコードウィンドウ内のさまざまなパケットの数に関する追加情報も含まれている場合があります。
Elastic Encoding Window:
弾性エンコーディングウィンドウ：
An encoder-side buffer that stores all the unacknowledged source packets of the input flow involved in the coding process.
コーディングプロセスに含まれる入力フローのすべての未把持されたソースパケットを保存するエンコーダーサイドバッファー。
Coding Coefficient Generator Identifier (CCGI):
コーディング係数発電機識別子（CCGI）：
A unique identifier that defines a function or an algorithm allowing the generation of the encoding vector.
エンコーディングベクトルの生成を可能にする関数またはアルゴリズムを定義する一意の識別子。
Code Rate:
コードレート：
Defines the rate between the number of input symbols and the number of output symbols.
入力記号の数と出力シンボルの数との間のレートを定義します。
Tetrys is well suited, but not limited, to the use case where there is a single flow originated by a single source with intra-stream coding at a single encoding node. Note that the input stream MAY be a multiplex of several upper-layer streams. Transmission MAY be over a single path or multiple paths. This is the simplest use case that is quite aligned with currently proposed scenarios for end-to-end streaming.
テトリーは、単一のエンコーディングノードでストリーム内コーディングを備えた単一のソースから発生する単一のフローがあるユースケースがある場合には、適していますが、これらに限定されません。入力ストリームは、いくつかの上層層ストリームの多重になる可能性があることに注意してください。トランスミッションは、単一のパスまたは複数のパスを超えている場合があります。これは、エンドツーエンドのストリーミングのために現在提案されているシナリオと非常に整合している最も単純なユースケースです。
+----------+ +----------+
| | | |
| App | | App |
| | | |
+----------+ +----------+
| ^
| Source Source |
| Symbols Symbols |
| |
v |
+----------+ +----------+
| | Output Packets | |
| Tetrys |--------------->| Tetrys |
| Encoder |Feedback Packets| Decoder |
| |<---------------| |
+----------+ +----------+
Figure 1: Tetrys Architecture
図1：Tetrysアーキテクチャ
The Tetrys protocol features several key functionalities. The mandatory features include:
Tetrysプロトコルは、いくつかの重要な機能を備えています。必須の機能には次のものがあります。
* on-the-fly encoding;
* オンザフライエンコーディング;
* decoding;
* デコード;
* signaling, to carry in particular the symbol IDs in the encoding window and the associated coding coefficients when meaningful;
* シグナリング、特にエンコードウィンドウ内のシンボルIDと、意味のある場合の関連するコーディング係数を運ぶ。
* feedback management;
* フィードバック管理。
* elastic window management; and
* 弾性ウィンドウ管理;そして
* Tetrys packet header creation and processing.
* Tetrysパケットヘッダーの作成と処理。
The optional features include:
オプションの機能には以下が含まれます。
* channel estimation;
* チャネル推定;
* dynamic adjustment of the code rate and flow control; and
* コードレートとフロー制御の動的調整。そして
* congestion control management (if appropriate). See Section 6.1 for further details.
* 混雑制御管理（必要に応じて）。詳細については、セクション6.1を参照してください。
Several building blocks provide the following functionalities:
いくつかのビルディングブロックは、次の機能を提供します。
The Tetrys Building Block:
Tetrys Building Block：
This building block embeds both the Tetrys decoder and Tetrys encoder; thus, it is used during encoding and decoding processes. It must be noted that Tetrys does not mandate a specific building block. Instead, any building block compatible with the elastic encoding window feature of Tetrys may be used.
このビルディングブロックは、Tetrys DecoderとTetrysエンコーダーの両方を埋め込みます。したがって、エンコードおよびデコードプロセス中に使用されます。Tetrysは特定のビルディングブロックを義務付けていないことに注意する必要があります。代わりに、テトリーの弾性エンコードウィンドウ機能と互換性のあるビルディングブロックを使用できます。
The Window Management Building Block:
ウィンドウ管理ビルディングブロック：
This building block is in charge of managing the encoding window at a Tetrys sender.
このビルディングブロックは、Tetrys Senderでエンコードウィンドウの管理を担当しています。
To ease the addition of future components and services, Tetrys adds a header extension mechanism that is compatible with that of Layered Coding Transport (LCT) [RFC5651], NACK-Oriented Reliable Multicast (NORM) [RFC5740], and FEC Framework (FECFRAME) [RFC8680].
将来のコンポーネントとサービスの追加を容易にするために、Tetryは、レイヤードコーディングトランスポート（LCT）[RFC5651]、NACK指向の信頼できるマルチキャスト（NORM）[RFC5740]、およびFECフレームワーク（FECFRAME）と互換性のあるヘッダー拡張メカニズムを追加します。[RFC8680]。
At the beginning of a transmission, a Tetrys encoder MUST choose an initial code rate that adds redundancy as it doesn't know the packet loss rate of the channel. In the steady state, the Tetrys encoder MAY generate coded symbols when it receives a source symbol from the application or some feedback from the decoding blocks depending on the code rate.
トランスミッションの開始時に、Tetrysエンコーダーは、チャネルのパケット損失率がわからないため、冗長性を追加する初期コードレートを選択する必要があります。定常状態では、Tetrysエンコーダーは、コードレートに応じて、アプリケーションからソース記号またはデコードブロックからフィードバックを受信すると、コード化されたシンボルを生成する場合があります。
When a Tetrys encoder needs to generate a coded symbol, it considers the set of source symbols stored in the elastic encoding window and generates an encoding vector with the coded symbol. These source symbols are the set of source symbols that are not yet acknowledged by the receiver. For each source symbol, a finite field coefficient is determined using a Coding Coefficient Generator. This generator MAY take the source symbol IDs and the coded symbol ID as an input and MAY determine a coefficient in a deterministic way as presented in Section 5.3. Finally, the coded symbol is the sum of the source symbols multiplied by their corresponding coefficients.
Tetrysエンコーダーがコード化されたシンボルを生成する必要がある場合、弾性エンコードウィンドウに保存されたソースシンボルのセットを考慮し、コード化されたシンボルを持つエンコーディングベクトルを生成します。これらのソースシンボルは、レシーバーによってまだ認められていないソースシンボルのセットです。各ソースシンボルについて、有限フィールド係数は、コーディング係数発電機を使用して決定されます。このジェネレーターは、ソースシンボルIDとコード化されたシンボルIDを入力として取得し、セクション5.3で示されているように決定論的な方法で係数を決定する場合があります。最後に、コード化されたシンボルは、ソース記号の合計に対応する係数を掛けたものです。
A Tetrys encoder MUST set a limit to the elastic encoding window maximum size. This controls the algorithmic complexity at the encoder and decoder by limiting the size of linear combinations. It is also needed in situations where all window update packets are lost or absent.
Tetrysエンコーダーは、弾性エンコードウィンドウの最大サイズに制限を設定する必要があります。これにより、線形結合のサイズを制限することにより、エンコーダーとデコーダーのアルゴリズムの複雑さを制御します。また、すべてのウィンドウ更新パケットが失われたり存在しない状況でも必要です。
When an input source symbol is passed to a Tetrys encoder, it is added to the elastic encoding window. This window MUST have a limit set by the encoding building block. If the elastic encoding window has reached its limit, the window slides over the symbols. The first (oldest) symbol is removed, and the newest symbol is added. As an element of the coding window, this symbol is included in the next linear combinations created to generate the coded symbols.
入力ソースシンボルがテトリーエンコーダーに渡されると、弾性エンコードウィンドウに追加されます。このウィンドウには、エンコードビルディングブロックによって制限が設定されている必要があります。弾性エンコーディングウィンドウが限界に達した場合、ウィンドウはシンボルの上にスライドします。最初の（最古の）シンボルが削除され、最新のシンボルが追加されます。コーディングウィンドウの要素として、このシンボルは、コード化されたシンボルを生成するために作成された次の線形結合に含まれています。
As explained below, the Tetrys decoder sends periodic feedback indicating the received or decoded source symbols. When the sender receives the information that a source symbol was received or decoded by the receiver, it removes this symbol from the coding window.
以下で説明するように、Tetrys Decoderは、受信またはデコードされたソースシンボルを示す定期的なフィードバックを送信します。送信者がソースシンボルが受信またはレシーバーによってデコードされたという情報を受信すると、このシンボルがコーディングウィンドウから削除されます。
A standard Gaussian elimination is sufficient to recover the erased source symbols when the matrix rank enables it.
マトリックスランクが有効になったときに、消去されたソース記号を回復するには、標準のガウス除去で十分です。
All types of Tetrys packets share the same common header format (see Figure 2).
すべてのタイプのTetryパケットは、同じ共通ヘッダー形式を共有しています（図2を参照）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | C |S| Reserved | HDR_LEN | PKT_TYPE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32*C bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32*S bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Common Header Format
図2：一般的なヘッダー形式
As noted above, this format is inspired by, and inherits from, the LCT header format [RFC5651] with slight modifications.
上記のように、この形式は、LCTヘッダー形式[RFC5651]に触発され、継承されています。
Tetrys version number (V):
Tetrysバージョン番号（v）：
4 bits. Indicates the Tetrys version number. The Tetrys version number for this specification is 1.
4ビット。Tetrysバージョン番号を示します。この仕様のテトリーバージョン番号は1です。
Congestion control flag (C):
混雑制御フラグ（c）：
2 bits. C set to 0b00 indicates the Congestion Control Information (CCI) field is 0 bits in length. C set to 0b01 indicates the CCI field is 32 bits in length. C set to 0b10 indicates the CCI field is 64 bits in length. C set to 0b11 indicates the CCI field is 96 bits in length.
2ビット。cセット0b00は、輻輳制御情報（CCI）フィールドの長さが0ビットのことを示します。cセット0B01は、CCIフィールドの長さが32ビットのことを示します。cセット0B10は、CCIフィールドの長さが64ビットのことを示します。Cセット0B11に設定されているCCIフィールドの長さは96ビットです。
Transport Session Identifier flag (S):
トランスポートセッション識別子フラグ：
1 bit. This is the number of full 32-bit words in the TSI field. The TSI field is 32*S bits in length; i.e., the length is either 0 bits or 32 bits.
1ビット。これは、TSIフィールドの完全な32ビット語の数です。TSIフィールドの長さは32*sビットです。つまり、長さは0ビットまたは32ビットのいずれかです。
Reserved (Resv):
予約済み（RESV）：
9 bits. These bits are reserved. In this version of the specification, they MUST be set to zero by senders and MUST be ignored by receivers.
9ビット。これらのビットは予約されています。仕様のこのバージョンでは、送信者がゼロに設定する必要があり、受信機は無視する必要があります。
Header length (HDR_LEN):
ヘッダー長（HDR_LEN）：
8 bits. The total length of the Tetrys header in units of 32-bit words. The length of the Tetrys header MUST be a multiple of 32 bits. This field may be used to directly access the portion of the packet beyond the Tetrys header, i.e., to the first next header if it exists, to the packet payload if it exists and there is no other header, or to the end of the packet if there are no other headers or packet payload.
8ビット。32ビット単語の単位でのTetrysヘッダーの全長。テトリーヘッダーの長さは、32ビットの倍数でなければなりません。このフィールドを使用して、Tetrysヘッダーを超えてパケットの部分に直接アクセスすることができます。つまり、存在する場合は、最初の次のヘッダーが存在し、他のヘッダーがない場合、またはパケットの端までにパケットペイロードにアクセスできます。他のヘッダーやパケットペイロードがない場合。
Tetrys packet type (PKT_TYPE):
Tetrysパケットタイプ（PKT_TYPE）：
8 bits. There are three types of packets: the PKT_TYPE_SOURCE (0b00) defined in Section 5.2, the PKT_TYPE_CODED (0b01) defined in Section 5.3 and the PKT_TYPE_WND_UPT (0b11) for window update packets defined in Section 5.4.
8ビット。パケットには、セクション5.2で定義されているPKT_TYPE_SOURCE（0B00）、セクション5.3で定義されているPKT_TYPE_CODED（0B01）、セクション5.4で定義されたウィンドウ更新パケットのPKT_TYPE_WND_UPT（0B11）が定義されている3つのタイプがあります。
Congestion Control Information (CCI):
混雑制御情報（CCI）：
0, 32, 64, or 96 bits. Used to carry congestion control information. For example, the congestion control information could include layer numbers, logical channel numbers, and sequence numbers. This field is opaque for this specification. This field MUST be 0 bits (absent) if C is set to 0b00. This field MUST be 32 bits if C is set to 0b01. This field MUST be 64 bits if C is set to 0b10. This field MUST be 96 bits if C is set to 0b11.
0、32、64、または96ビット。混雑制御情報を運ぶために使用されます。たとえば、輻輳制御情報には、レイヤー番号、論理チャネル番号、シーケンス番号が含まれる場合があります。このフィールドは、この仕様には不透明です。Cが0B00に設定されている場合、このフィールドは0ビット（不在）でなければなりません。Cが0B01に設定されている場合、このフィールドは32ビットでなければなりません。Cが0B10に設定されている場合、このフィールドは64ビットでなければなりません。Cが0B11に設定されている場合、このフィールドは96ビットでなければなりません。
Transport Session Identifier (TSI):
トランスポートセッション識別子（TSI）：
0 or 32 bits. The TSI uniquely identifies a session among all sessions from a particular Tetrys encoder. The TSI is scoped by the IP address of the sender; thus, the IP address of the sender and the TSI together uniquely identify the session. Although a TSI always uniquely identifies a session conjointly with the IP address of the sender, whether the TSI is included in the Tetrys header depends on what is used as the TSI value. If the underlying transport is UDP, then the 16-bit UDP source port number MAY serve as the TSI for the session. If there is no underlying TSI provided by the network, transport, or any other layer, then the TSI MUST be included in the Tetrys header.
0または32ビット。TSIは、特定のテトリーエンコーダーからのすべてのセッション間のセッションを一意に識別します。TSIは、送信者のIPアドレスによってスコープされます。したがって、送信者のIPアドレスとTSIは一緒にセッションを一意に識別します。TSIは常にセッションを送信者のIPアドレスと一意に識別しますが、TSIがTetryヘッダーに含まれているかどうかは、TSI値として使用されるものに依存します。基礎となる輸送がUDPの場合、16ビットのUDPソースポート番号がセッションのTSIとして機能する可能性があります。ネットワーク、トランスポート、またはその他のレイヤーによって提供される基礎となるTSIがない場合は、TSIをTetrysヘッダーに含める必要があります。
Header extensions are used in Tetrys to accommodate optional header fields that are not always used or have variable sizes. The presence of header extensions MAY be inferred by the Tetrys header length (HDR_LEN). If HDR_LEN is larger than the length of the standard header, then the remaining header space is taken by header extensions.
ヘッダー拡張機能は、常に使用されていない、またはさまざまなサイズを持つオプションのヘッダーフィールドに対応するために、テトリーで使用されます。ヘッダー拡張の存在は、Tetrysヘッダー長（HDR_LEN）によって推測される場合があります。HDR_LENが標準ヘッダーの長さよりも大きい場合、残りのヘッダースペースはヘッダー拡張機能によって取得されます。
If present, header extensions MUST be processed to ensure that they are recognized before performing any congestion control procedure or otherwise accepting a packet. The default action for unrecognized header extensions is to ignore them. This allows for the future introduction of backward-compatible enhancements to Tetrys without changing the Tetrys version number. Header extensions that are not backward-compatible MUST NOT be introduced without changing the Tetrys version number.
存在する場合は、ヘッダー拡張機能を処理して、輻輳制御手順を実行するか、パケットを受け入れる前に認識されることを確認する必要があります。認識されていないヘッダー拡張機能のデフォルトのアクションは、それらを無視することです。これにより、Tetryのバージョン数を変更せずに、Tetryの後方互換拡張機能を将来導入できます。後方互換性のないヘッダー拡張機能は、Tetrysバージョン数を変更せずに導入してはなりません。
There are two formats for header extensions as depicted in Figure 3:
図3に示すように、ヘッダー拡張機能には2つの形式があります。
* The first format is used for variable-length extensions with header extension type (HET) values between 0 and 127.
* 最初の形式は、0〜127の間のヘッダー拡張タイプ（HET）値を持つ可変長拡張機能に使用されます。
* The second format is used for fixed-length (one 32-bit word) extensions using HET values from 128 to 255.
* 2番目の形式は、128〜255のHET値を使用して、固定長（1つの32ビットワード）拡張機能に使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (>=128) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Header Extension Format
図3：ヘッダー拡張形式
Header Extension Type (HET):
ヘッダー拡張タイプ（HET）：
8 bits. The type of the header extension. This document defines several possible types. Additional types may be defined in future versions of this specification. HET values from 0 to 127 are used for variable-length header extensions. HET values from 128 to 255 are used for fixed-length, 32-bit header extensions.
8ビット。ヘッダー拡張機能のタイプ。このドキュメントでは、いくつかの可能なタイプを定義します。追加のタイプは、この仕様の将来のバージョンで定義できます。0〜127のHET値は、可変長ヘッダー拡張に使用されます。128〜255のHET値は、固定長の32ビットヘッダー拡張機能に使用されます。
Header Extension Length (HEL):
ヘッダー拡張長（HEL）：
8 bits. The length of the whole header extension field expressed in multiples of 32-bit words. This field MUST be present for variable-length extensions (HETs between 0 and 127) and MUST NOT be present for fixed-length extensions (HETs between 128 and 255).
8ビット。ヘッダー拡張フィールド全体の長さは、32ビット単語の倍数で表されます。このフィールドは、可変長拡張機能（0〜127の間のHET）に存在する必要があり、固定長拡張（128〜255のHETS）には存在しないでください。
Header Extension Content (HEC):
ヘッダー拡張コンテンツ（HEC）：
Length of the variable. The content of the header extension. The format of this subfield depends on the header extension type. For fixed-length header extensions, the HEC is 24 bits. For variable-length header extensions, the HEC field has a variable size as specified by the HEL field. Note that the length of each header extension MUST be a multiple of 32 bits. Additionally, the total size of the Tetrys header, including all header extensions and optional header fields, cannot exceed 255 32-bit words.
変数の長さ。ヘッダー拡張機能の内容。このサブフィールドの形式は、ヘッダー拡張タイプに依存します。固定長ヘッダー拡張機能の場合、HECは24ビットです。可変長ヘッダー拡張機能の場合、HECフィールドは、HELフィールドで指定されている可変サイズを持っています。各ヘッダー拡張の長さは32ビットの倍数でなければならないことに注意してください。さらに、すべてのヘッダー拡張機能とオプションのヘッダーフィールドを含むTetrysヘッダーの合計サイズは、255 32ビット単語を超えることはできません。
A source packet is a common packet header encapsulation, a source symbol ID, and a source symbol (payload). The source symbols MAY have variable sizes.
ソースパケットは、一般的なパケットヘッダーカプセル化、ソースシンボルID、ソースシンボル（ペイロード）です。ソースシンボルには、さまざまなサイズがある場合があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Common Packet Header /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Payload /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Source Packet Format
図4：ソースパケット形式
Common Packet Header:
一般的なパケットヘッダー：
A common packet header (as common header format) where packet type is set to 0b00.
パケットタイプが0B00に設定されている一般的なパケットヘッダー（一般的なヘッダー形式として）。
Source Symbol ID:
ソースシンボルID：
The sequence number to identify a source symbol.
ソースシンボルを識別するシーケンス番号。
Payload:
ペイロード：
The payload (source symbol).
ペイロード（ソースシンボル）。
A coded packet is the encapsulation of a common packet header, a coded symbol ID, the associated encoding vector, and a coded symbol (payload). As the source symbols MAY have variable sizes, all the source symbol sizes need to be encoded. To generate this encoded payload size as a 16-bit unsigned value, the linear combination uses the same coefficients as the coded payload. The result MUST be stored in the coded packet as the encoded payload size (16 bits). As it is an optional field, the encoding vector MUST signal the use of variable source symbol sizes with the field V (see Section 5.3.1).
コード化されたパケットは、共通のパケットヘッダー、コード化されたシンボルID、関連するエンコードベクトル、およびコード化されたシンボル（ペイロード）のカプセル化です。ソースシンボルにはさまざまなサイズがある可能性があるため、すべてのソースシンボルサイズをエンコードする必要があります。このエンコードされたペイロードサイズを16ビットの署名値として生成するために、線形結合はコード化されたペイロードと同じ係数を使用します。結果は、エンコードされたペイロードサイズ（16ビット）としてコード化されたパケットに保存する必要があります。オプションのフィールドであるため、エンコーディングベクトルは、フィールドVで可変ソースシンボルサイズの使用を通知する必要があります（セクション5.3.1を参照）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Common Packet Header /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Coded Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Encoding Vector /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded Payload Size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ Payload /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Coded Packet Format
図5：コード化されたパケット形式
Common Packet Header:
一般的なパケットヘッダー：
A common packet header (as common header format) where packet type is set to 0b01.
パケットタイプが0B01に設定されている一般的なパケットヘッダー（一般的なヘッダー形式として）。
Coded Symbol ID:
コード化されたシンボルID：
The sequence number to identify a coded symbol.
コード化されたシンボルを識別するシーケンス番号。
Encoding Vector:
ベクトルのエンコード：
An encoding vector to define the linear combination used (coefficients and source symbols).
使用される線形結合（係数とソース記号）を定義するエンコードベクトル。
Encoded Payload Size:
エンコードされたペイロードサイズ：
The coded payload size used if the source symbols have a variable size (optional, Section 5.3.1).
ソース記号の可変サイズがある場合に使用されるコード化されたペイロードサイズ（オプション、セクション5.3.1）。
Payload:
ペイロード：
The coded symbol.
コード化されたシンボル。
An encoding vector contains all the information about the linear combination used to generate a coded symbol. The information includes the source identifiers and the coefficients used for each source symbol. It MAY be stored in different ways depending on the situation.
エンコードベクトルには、コード化されたシンボルを生成するために使用される線形結合に関するすべての情報が含まれています。情報には、各ソースシンボルに使用されるソース識別子と係数が含まれます。状況に応じて、さまざまな方法で保管される場合があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EV_LEN | CCGI | I |C|V| NB_IDS | NB_COEFS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FIRST_SOURCE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| b_id | |
+-+-+-+-+-+-+-+-+ id_bit_vector +-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ coef_bit_vector +-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Encoding Vector Format
図6：ベクトル形式のエンコード
Encoding Vector Length (EV_LEN):
ベクトルの長さのエンコード（EV_LEN）：
8 bits. The size in units of 32-bit words.
8ビット。32ビット語の単位のサイズ。
Coding Coefficient Generator Identifier (CCGI):
コーディング係数発電機識別子（CCGI）：
4-bit ID to identify the algorithm or function used to generate the coefficients. As a CCGI is included in each encoded vector, it MAY dynamically change between the generation of two coded symbols. The CCGI builds the coding coefficients used to generate the coded symbols. They MUST be known by all the Tetrys encoders or decoders. The two RLC FEC schemes specified in this document reuse the finite fields defined in [RFC5510], Section 8.1. More specifically, the elements of the field GF(2^(m)) are represented by polynomials with binary coefficients (i.e., over GF(2)) and with degree lower or equal to m-1. The addition between two elements is defined as the addition of binary polynomials in GF(2), which is equivalent to a bitwise XOR operation on the binary representation of these elements. With GF(2^(8)), multiplication between two elements is the multiplication modulo a given irreducible polynomial of degree 8. The following irreducible polynomial is used for GF(2^(8)):
4ビットID係数を生成するために使用されるアルゴリズムまたは関数を識別する。CCGIは各エンコードされたベクトルに含まれているため、2つのコード化されたシンボルの生成間で動的に変化する場合があります。CCGIは、コード化されたシンボルを生成するために使用されるコーディング係数を構築します。それらは、すべてのテトリーエンコーダーまたはデコーダーによって知られている必要があります。このドキュメントで指定された2つのRLC FECスキームは、[RFC5510]で定義されている有限フィールド、セクション8.1を再利用します。より具体的には、フィールドGF（2^（m））の要素は、バイナリ係数（すなわち、GF（2）を超えて）を備えた多項式で表され、程度はm-1以下の程度で表されます。2つの要素間の添加は、GF（2）のバイナリ多項式の添加として定義されます。これは、これらの要素のバイナリ表現のビットワイズXOR操作に相当します。GF（2^（8））では、2つの要素間の乗算は、程度8の既約多項式Aの乗算モジュロです。次の既約多項式がGF（2^（8））に使用されます。
x^(8) + x^(4) + x^(3) + x^(2) + 1
x^（8）x^（4）x^（3）x^（2）1
With GF(2^(4)), multiplication between two elements is the multiplication modulo a given irreducible polynomial of degree 4. The following irreducible polynomial is used for GF(2^(4)):
GF（2^（4））では、2つの要素間の乗算は、程度4の還元可能な多項式Aの乗算モジュロです。次の既約多項式がGF（2^（4））に使用されます。
x^(4) + x + 1
x^（4）x 1
* 0b00: Vandermonde-based coefficients over the finite field GF(2^(4)) as defined below. Each coefficient is built as alpha^( (source_symbol_id*coded-symbol_id) % 16), with alpha the root of the primitive polynomial.
* 0B00：以下に定義するように、有限フィールドGF（2^（4））上のVandermondeベースの係数。各係数は、alpha^（（source_symbol_id*coded-symbol_id）％16）として構築され、アルファは原始多項式のルートです。
* 0b01: Vandermonde-based coefficients over the finite field GF(2^(8)) as defined below. Each coefficient is built as alpha^( (source_symbol_id*coded-symbol_id) % 256), with alpha the root of the primitive polynomial.
* 0B01：以下に定義するように、有限フィールドGF（2^（8））上のVandermondeベースの係数。各係数は、alpha^（（source_symbol_id*coded-symbol_id）％256）として構築され、アルファは原始的多項式のルートです。
* Suppose we want to generate the coded symbol 2 as a linear combination of the source symbols 1, 2, and 4 using CCGI set to 0b01. The coefficients will be alpha^( (1 * 1) % 256), alpha^( (1 * 2) % 256), and alpha^( (1 * 4) % 256).
* 0B01に設定されたCCGIを使用して、ソースシンボル1、2、および4の線形結合としてコード化されたシンボル2を生成する必要があるとします。係数は、alpha^（（1 * 1）％256）、alpha^（（1 * 2）％256）、およびalpha^（（1 * 4）％256）です。
Store the Source Symbol ID Format (I) (2 bits):
ソースシンボルID形式（i）（2ビット）を保存します。
* 0b00 means there is no source symbol ID information.
* 0B00は、ソースシンボルID情報がないことを意味します。
* 0b01 means the encoding vector contains the edge blocks of the source symbol IDs without compression.
* 0B01は、エンコードベクトルに、圧縮なしでソースシンボルIDのエッジブロックが含まれることを意味します。
* 0b10 means the encoding vector contains the compressed list of the source symbol IDs.
* 0B10は、エンコードベクトルにソースシンボルIDの圧縮リストが含まれることを意味します。
* 0b11 means the encoding vector contains the compressed edge blocks of the source symbol IDs.
* 0B11は、エンコードベクトルにソースシンボルIDの圧縮エッジブロックが含まれることを意味します。
Store the Encoding Coefficients (C):
エンコーディング係数（c）を保存します。
1 bit to indicate if an encoding vector contains information about the coefficients used.
エンコーディングベクトルに使用される係数に関する情報が含まれているかどうかを示す1ビット。
Having Source Symbols with Variable Size Encoding (V):
可変サイズエンコーディング（v）を持つソースシンボルを持つ：
Set V to 0b01 if the combination that refers to the encoding vector is a combination of source symbols with variable sizes. In this case, the coded packets MUST have the 'Encoded Payload Size' field.
エンコードベクトルを指す組み合わせがソースシンボルの組み合わせと可変サイズの組み合わせである場合、vを0B01に設定します。この場合、コード化されたパケットには「エンコードされたペイロードサイズ」フィールドが必要です。
NB_IDS:
nb_ids：
The number of source IDs stored in the encoding vector (depending on I).
エンコードベクトルに保存されているソースIDの数（iに依存）。
Number of Coefficients (NB_COEFS):
係数の数（NB_COEFS）：
The number of the coefficients used to generate the associated coded symbol.
関連するコード化されたシンボルを生成するために使用される係数の数。
The First Source Identifier (FIRST_SOURCE_ID):
最初のソース識別子（first_source_id）：
The first source symbol ID used in the combination.
最初のソースシンボルは、組み合わせで使用されます。
Number of Bits for Each Edge Block (b_id):
各エッジブロックのビット数（B_ID）：
The number of bits needed to store the edge.
エッジを保存するために必要なビットの数。
Information about the Source Symbol IDs (id_bit_vector):
ソースシンボルID（ID_BIT_VECTOR）に関する情報：
If I is set to 0b01, store the edge blocks as b_id * (NB_IDS * 2 - 1). If I is set to 0b10, store the edge blocks in a compressed way.
私が0B01に設定されている場合、エッジブロックをB_ID *（NB_IDS * 2-1）として保存します。0B10に設定されている場合は、エッジブロックを圧縮方法で保存します。
The Coefficients (coef_bit_vector):
係数（COEF_BIT_VECTOR）：
The coefficients stored depending on the CCGI (4 or 8 bits for each coefficient).
CCGIに応じて保存された係数（各係数の4または8ビット）。
Padding:
パディング：
Padding to have an encoding vector size that is a multiple of 32 bits (for the ID and coefficient part).
32ビットの倍数（IDおよび係数パーツの場合）のエンコードベクトルサイズを持つパディング。
The source symbol IDs are organized as a sorted list of 32-bit unsigned integers. Depending on the feedback, the source symbol IDs in the list MAY be successive or not. If they are successive, the boundaries are stored in the encoding vector; it just needs 2*32 bits of information. If not, the full list or the edge blocks MAY be stored and a differential transform to reduce the number of bits needed to represent an identifier MAY be used.
ソースシンボルIDは、32ビットの署名されていない整数のソート付きリストとして編成されています。フィードバックに応じて、リスト内のソースシンボルIDは連続しているかどうかです。それらが連続している場合、境界はエンコードベクトルに保存されます。2*32ビットの情報が必要です。そうでない場合、完全なリストまたはエッジブロックを保存し、識別子を表すために必要なビット数を減らすために差動変換を使用することができます。
For the following subsections, let's take as an example the generation of an encoding vector for a coded symbol that is a linear combination of the source symbols with IDs 1, 2, 3, 5, 6, 8, 9, and 10 (or as edge blocks: [1..3], [5..6], [8..10]).
以下のサブセクションについては、ソース記号の線形結合とIDS 1、2、3、5、6、8、9、および10（または10）のコード化されたシンボルのエンコードベクトルの生成の例を例にしてみましょう。エッジブロック：[1..3]、[5..6]、[8..10]）。
There are several ways to store the source symbol IDs into the encoding vector:
ソースシンボルIDをエンコードベクトルに保存する方法はいくつかあります。
* If no information about the source symbol IDs is needed, the field I MUST be set to 0b00: no b_id and no id_bit_vector field.
* ソースシンボルIDに関する情報が不要な場合、フィールドIは0B00に設定する必要があります。
* If the edge blocks are stored without compression, the field I MUST be set to 0b01. In this case, set b_id to 32 (as a Symbol ID is 32 bits), and store the list of 32-bit unsigned integers (1, 3, 4, 5, 6, 10) into id_bit_vectors.
* エッジブロックが圧縮なしで保存されている場合、フィールドIは0B01に設定する必要があります。この場合、B_IDを32に設定し（シンボルIDが32ビット）、32ビットの符号なし整数（1、3、4、5、6、10）のリストをID_Bit_Vectorsに保存します。
* If the source symbol IDs are stored as a list with compression, the field I MUST be set to 0b10. In this case, see Section 5.3.1.1, but rather than compressing the edge blocks, we compress the full list of the source symbol IDs.
* ソースシンボルIDが圧縮のあるリストとして保存されている場合、フィールドIは0B10に設定する必要があります。この場合、セクション5.3.1.1を参照しますが、エッジブロックを圧縮するのではなく、ソースシンボルIDの完全なリストを圧縮します。
* If the edge blocks are stored with compression, the field I MUST be set to 0b11. In this case, see Section 5.3.1.1.
* エッジブロックが圧縮で保存されている場合、フィールドIは0B11に設定する必要があります。この場合、セクション5.3.1.1を参照してください。
Let's continue with our coded symbol defined in the previous section. The source symbol IDs used in the linear combination are: [1..3], [5..6], [8..10].
前のセクションで定義されているコード化されたシンボルを続けましょう。線形の組み合わせで使用されるソースシンボルIDは、[1..3]、[5..6]、[8..10]です。
If we want to compress and store this list into the encoding vector, we MUST follow this procedure:
このリストをエンコードベクトルに圧縮して保存する場合は、次の手順に従う必要があります。
1. Keep the first element in the packet as the first_source_id: 1.
1. first_source_id：1としてパケットの最初の要素を保持します。
2. Apply a differential transform to the other elements ([3, 5, 6, 8, 10]) that removes the element i-1 to the element i, starting with the first_source_id as i0, and get the list L = [2, 2, 1, 2, 2].
2. 他の要素（[3、5、6、8、10]）に微分変換を適用します。これは、要素I-1を要素Iに削除し、I0としてfirst_source_idで始まり、リストl = [2、2を取得します。、1、2、2]。
3. Compute b, the number of bits needed to store all the elements, which is ceil(log2(max(L))), where max(L) represents the maximum of the elements of the list L; here, it is 2 bits.
3. b、すべての要素を保存するために必要なビット数を計算します。これは、ceil（log2（max（l）））です。ここで、max（l）はリストlの要素の最大値を表します。ここでは、2ビットです。
4. Write b in the corresponding field, and write all the b * [(2 * NB blocks) - 1] elements in a bit vector here: 10, 10, 01, 10, 10.
4. 対応するフィールドにBを書き込み、すべてのb * [（2 * nbブロック）-1]要素をここで少しベクトルに書き込みます：10、10、01、10、10。
When a Tetrys decoding block wants to reverse the operations, this algorithm is used:
テトリーデコードブロックが操作を逆にする必要がある場合、このアルゴリズムが使用されます。
1. Rebuild the list of the transmitted elements by reading the bit vector and b: [10, 10, 01, 10, 10] => [2, 2, 1, 2, 2].
1. ビットベクトルとbを読み取ることにより、送信された要素のリストを再構築します：[10、10、01、10、10] => [2、2、1、2、2]。
2. Apply the reverse transform by adding successively the elements, starting with first_source_id: [1, 1 + 2, (1 + 2) + 2, (1 + 2 + 2) + 1, ...] => [1, 3, 5, 6, 8, 10].
2. first_source_idで始まる要素を連続的に追加して、逆変換を適用します：[1、1 2）2、（1 2 2）1、...] => [1、3、5、6、8、10]。
3. Rebuild the blocks using the list and first_source_id: [1..3], [5..6], [8..10].
3. リストとfirst_source_id：[1..3]、[5..6]、[8..10]を使用してブロックを再構築します。
A Tetrys decoder MAY send window update packets back to another building block. They contain information about what the packets received, decoded, or dropped, and other information such as a packet loss rate or the size of the decoding buffers. They are used to optimize the content of the encoding window. The window update packets are OPTIONAL; hence, they could be omitted or lost in transmission without impacting the protocol behavior.
Tetrysデコーダーは、ウィンドウ更新パケットを別のビルディングブロックに戻す場合があります。パケットが受信、デコード、またはドロップされたもの、およびパケットの損失率やデコードバッファーのサイズなどのその他の情報に関する情報が含まれています。それらは、エンコードウィンドウのコンテンツを最適化するために使用されます。ウィンドウ更新パケットはオプションです。したがって、プロトコルの動作に影響を与えることなく、伝送で省略または失われる可能性があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Common Packet Header /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nb_missing_src |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nb_not_used_coded_symb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| first_src_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| plr | sack_size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ SACK Vector /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Window Update Packet Format
図7：ウィンドウ更新パケット形式
Common Packet Header:
一般的なパケットヘッダー：
A common packet header (as common header format) where packet type is set to 0b10.
パケットタイプが0B10に設定されている一般的なパケットヘッダー（一般的なヘッダー形式として）。
nb_missing_src:
nb_missing_src：
The number of missing source symbols in the receiver since the beginning of the session.
セッションの開始以来、レシーバーの不足しているソース記号の数。
nb_not_used_coded_symb:
nb_not_used_coded_symb：
The number of coded symbols at the receiver that have not already been used for decoding (e.g., the linear combinations contain at least two unknown source symbols).
デコードにまだ使用されていないレシーバーのコード化された記号の数（例えば、線形の組み合わせには、少なくとも2つの未知のソース記号が含まれています）。
first_src_id:
first_src_id：
ID of the first source symbol to consider in the selective acknowledgment (SACK) vector.
選択的承認（sack）ベクトルで考慮する最初のソースシンボルのID。
plr:
plr：
Packet loss ratio expressed as a percentage normalized to an 8-bit unsigned integer. For example, 2.5% will be stored as floor(2.5 * 256/100) = 6. Conversely, if 6 is the stored value, the corresponding packet loss ratio expressed as a percentage is 6*100/256 = 2.34%. This value is used in the case of dynamic code rate or for a statistical purpose. The choice of calculation is left to the Tetrys decoder, depending on a window observation, but should be the PLR seen before decoding.
パケット損失比は、8ビットの署名されていない整数に正規化されたパーセンテージとして表されます。たとえば、2.5％はフロア（2.5 * 256/100）= 6として保存されます。逆に、6が保存値である場合、パーセンテージとして表される対応するパケット損失比は6 * 100/256 = 2.34％です。この値は、動的なコードレートの場合または統計的な目的で使用されます。計算の選択は、ウィンドウの観測に応じて、テトリーデコーダーに任されていますが、デコードの前に見られるPLRである必要があります。
sack_size:
sack_size：
The size of the SACK vector in 32-bit words. For instance, with a value of 2, the SACK vector is 64 bits long.
32ビット語のサックベクトルのサイズ。たとえば、値は2の値で、サックベクターの長さは64ビットです。
SACK vector:
サックベクター：
Bit vector indicating symbols that must be removed in the encoding window from the first source symbol ID. In most cases, these symbols were received by the receiver. The other cases concern some events with non-recoverable packets (i.e., in the case of a burst of losses) where it is better to drop and abandon some packets and remove them from the encoding window to allow the recovery of the following packets. The "First Source Symbol" is included in this bit vector. A bit equal to 1 at the i-th position means that this window update packet removes the source symbol of the ID equal to "First Source Symbol ID" + i from the encoding window.
最初のソースシンボルIDからエンコードウィンドウで削除する必要があるシンボルを示すビットベクトル。ほとんどの場合、これらの記号は受信機によって受信されました。その他のケースは、一部のパケットをドロップして放棄し、エンコードウィンドウから削除して、次のパケットの回復を可能にする方が良いことをお勧めします。「最初のソースシンボル」は、このビットベクトルに含まれています。i番目の位置で1に少し等しいということは、このウィンドウ更新パケットが、エンコードウィンドウの「最初のソースシンボルID」iに等しいIDのソースシンボルを削除することを意味します。
The present document describes the baseline protocol, allowing communications between a Tetrys encoder and Tetrys decoder. In practice, Tetrys can be used either as a standalone protocol or embedded inside an existing protocol, and either above, within, or below the transport layer. There are different research questions related to each of these scenarios that should be investigated for future protocol improvements. We summarize them in the following subsections.
現在のドキュメントでは、ベースラインプロトコルについて説明し、テトリーエンコーダーとテトリーデコーダー間の通信を可能にします。実際には、テトリーは、スタンドアロンプロトコルとして使用するか、既存のプロトコル内に、および上、内部、または輸送層の下に埋め込まれています。これらの各シナリオに関連するさまざまな研究質問があり、将来のプロトコルの改善について調査する必要があります。次のサブセクションでそれらを要約します。
The Tetrys and congestion control components generate two separate channels (see [RFC9265], Section 2.1):
テトリーと輻輳制御コンポーネントは、2つの別々のチャネルを生成します（[RFC9265]、セクション2.1を参照）：
* The Tetrys channel carries source and coded packets (from the sender to the receiver) and information from the receiver to the sender (e.g., signaling which symbols have been recovered, loss rate before and/or after decoding, etc.).
* Tetrysチャネルには、ソースとコード化されたパケット（送信者から受信機へ）と受信機から送信者への情報（たとえば、どのシンボルが回復されたか、デコードの前後の損失率など）を搭載します。
* The congestion control channel carries packets from a sender to a receiver and packets signaling information about the network (e.g., number of packets received versus lost, Explicit Congestion Notification (ECN) marks, etc.) from the receiver to the sender.
* 輻輳制御チャネルは、送信者からレシーバーへのパケットを搭載し、ネットワークに関する情報を通知するパケット（たとえば、受け取ったパケットの数と失われた、明示的な混雑通知（ECN）マークなど）を受信者から送信者に送信者に届けます。
The following topics, which are identified and discussed by [RFC9265], are adapted to the particular deployment cases of Tetrys (i.e., above, within, or below the transport layer):
[RFC9265]によって特定され、議論されている以下のトピックは、テトリーの特定の展開ケース（すなわち、輸送層内、または輸送層内、または下）に適合しています。
* Congestion-related losses may be hidden if Tetrys is deployed below the transport layer without any precaution (i.e., Tetrys recovering packets lost because of a congested router), which can severely impact the congestion control efficiency. An approach is suggested to avoid hiding such signals in [RFC9265], Section 5.
* うっ血関連の損失は、輸送層の下に輸送層の下に展開されている場合（すなわち、混雑したルーターのために失われたテトリーの回収パケット）、混雑制御効率に深刻な影響を与える可能性がある場合に隠される可能性があります。[RFC9265]、セクション5のこのような信号を隠すことを避けるためのアプローチが提案されています。
* Tetrys and non-Tetrys flows sharing the same network links can raise fairness issues between these flows. In particular, the situation depends on whether some of these flows and not others are congestion controlled and which type of congestion control is used. The details are out of scope of this document, but may have major impacts in practice.
* 同じネットワークリンクを共有するテトリーと非テトリーのフローは、これらのフロー間で公平性の問題を引き起こす可能性があります。特に、状況は、これらのフローの一部が混雑制御されているものではなく、どのタイプの混雑制御が使用されているかに依存します。詳細はこのドキュメントの範囲外ですが、実際に大きな影響を与える可能性があります。
* Coding rate adaptation within Tetrys can have major impacts on congestion control if done inappropriately. This topic is discussed more in detail in Section 6.2.
* 触測定内のコーディングレートの適応は、不適切に行われれば、輻輳制御に大きな影響を与える可能性があります。このトピックについては、セクション6.2で詳しく説明します。
* Tetrys can leverage multipath transmissions, with the Tetrys packets being sent to the same receiver through multiple paths. Since paths can largely differ, a per-path flow control and congestion control adaptation could be needed.
* Tetryは、複数のパスを介して同じ受信機にTetrysパケットを送信して、マルチパストランスミッションを活用できます。パスはほぼ異なる可能性があるため、1路ごとのフロー制御と輻輳制御の適応が必要になる可能性があります。
* Protecting several application flows within a single Tetrys flow raises additional questions. This topic is discussed more in detail in Section 6.3.
* 単一のテトリーフロー内でいくつかのアプリケーションフローを保護すると、追加の疑問が生じます。このトピックについては、セクション6.3で詳しく説明します。
When the network conditions (e.g., delay and loss rate) strongly vary over time, an adaptive coding rate can be used to increase or reduce the amount of coded packets among a transmission dynamically (i.e., the added redundancy) with the help of a dedicated algorithm similar to [A-FEC]. Once again, the strategy differs depending on which layer Tetrys is deployed (i.e., above, within, or below the transport layer). Basically, we can split these strategies into two distinct classes: Tetrys deployment inside the transport layer versus outside the transport layer (i.e., above or below). A deployment within the transport layer means that interactions between transport protocol mechanisms such as error recovery, congestion control, and/or flow control are envisioned. Otherwise, deploying Tetrys within a transport protocol that is not congestion controlled, like UDP, would not bring out any other advantage than deploying it below or above the transport layer.
ネットワークの条件（遅延や損失率など）が時間とともに強く異なる場合、適応コードレートを使用して、専用のコード化されたパケットの量（つまり、追加された冗長性）を増やすことができます。[A-FEC]に類似したアルゴリズム。繰り返しになりますが、戦略は、どの層のテトリーが展開されているかによって異なります（つまり、輸送層内、または輸送層の下、または下）。基本的に、これらの戦略を2つの異なるクラスに分割できます：輸送層内と輸送層の外側（つまり、上または下）の外側のテトリーの展開。輸送層内の展開とは、エラー回復、混雑制御、および/またはフロー制御などの輸送プロトコルメカニズム間の相互作用が想定されることを意味します。それ以外の場合は、UDPのように輻輳制御されていない輸送プロトコル内にテトリーを展開することは、輸送層の下または上に展開する以外の利点をもたらさないでしょう。
The impact deploying a FEC mechanism within the transport layer is further discussed in Section 4 of [RFC9265], where considerations concerning the interactions between congestion control and coding rates, or the impact of fairness, are investigated. This adaptation may be done jointly with the congestion control mechanism of a transport layer protocol as proposed by [CTCP]. This allows the use of monitored congestion control metrics (e.g., RTT, congestion events, or current congestion window size) to adapt the coding rate conjointly with the computed transport sending rate. The rationale is to compute an amount of repair traffic that does not lead to congestion. This joint optimization is mandatory to prevent flows from consuming the whole available capacity as discussed in [RMCAT-ADAPTIVE-FEC], where the authors point out that an increase in the repair ratio should be done conjointly with a decrease in the source sending rate.
輸送層内のFECメカニズムを展開する影響については、[RFC9265]のセクション4でさらに説明します。ここでは、混雑制御とコーディングレートの相互作用、または公平性の影響に関する考慮事項について調査します。この適応は、[CTCP]によって提案されているように、輸送層プロトコルの混雑制御メカニズムと共同で行うことができます。これにより、監視されている輻輳制御メトリック（RTT、渋滞イベント、または現在の輻輳ウィンドウサイズなど）を使用して、計算された輸送送信率とコードレートを適応させることができます。理論的根拠は、混雑につながらない修理トラフィックの量を計算することです。この共同最適化は、[RMCAT適応FEC]で説明されているように、フローが利用可能な容量全体を消費するのを防ぐために必須であり、著者は、修復率の増加を送信速度の減少と組み合わせて行う必要があることを指摘しています。
Finally, adapting a coding rate can also be done outside the transport layer without considering transport-layer metrics. In particular, this adaptation may be done jointly with the network as proposed in [RED-FEC]. In this paper, the authors propose a Random Early Detection FEC mechanism in the context of video transmission over wireless networks. Briefly, the idea is to add more redundancy packets if the queue at the access point is less occupied and vice versa. A first theoretical attempt for video delivery with Tetrys has been proposed [THAI]. This approach is interesting as it illustrates a joint collaboration between the application requirements and the network conditions and combines both signals coming from the application needs and the network state (i.e., signals below or above the transport layer).
最後に、輸送層のメトリックを考慮せずに、コーディングレートの適応も輸送層の外で行うこともできます。特に、この適応は、[Red-fec]で提案されているように、ネットワークと共同で行うことができます。この論文では、著者は、ワイヤレスネットワークを介したビデオ送信のコンテキストで、ランダムな早期検出FECメカニズムを提案しています。簡単に言えば、アイデアは、アクセスポイントのキューがあまり占有されておらず、その逆の場合、さらに冗長性パケットを追加することです。Tetryを使用したビデオ配信の最初の理論的試みが提案されています[Thai]。このアプローチは、アプリケーション要件とネットワーク条件との共同コラボレーションを示し、アプリケーションのニーズとネットワーク状態から来る両方の信号（つまり、輸送層の下またはそれ以上の信号）を組み合わせているため、興味深いです。
To conclude, there are multiple ways to enable an adaptive coding rate. However, all of them depend on:
結論として、適応コーディングレートを有効にするには複数の方法があります。ただし、すべてに依存しています。
* the signal metrics that can be monitored and used to adapt the coding rate;
* 監視できる信号メトリックは、コーディングレートの適応に使用できます。
* the transport layer used, whether it is congestion controlled or not; and
* 混雑が制御されているかどうかにかかわらず、使用される輸送層。そして
* the objective sought (e.g., to minimize congestion or to fit application requirements).
* 目的は求められています（たとえば、混雑を最小限に抑えたり、アプリケーション要件に適合するため）。
The use of Tetrys to protect an aggregate of flows raises research questions when Tetrys is used to recover from IP datagram losses while tunneling. Applying redundancy without flow differentiation may contradict the service requirements of individual flows: some flows may be penalized more by high latency and jitter than by partial reliability, while other flows may be penalized more by partial reliability. In practice, head-of-line blocking impacts all flows in a similar manner despite their different needs, which indicates that more elaborate strategies inside Tetrys are needed.
トンネリング中にIPデータグラムの損失から回復するためにテトリーを使用すると、流れの骨材を保護するためにテトリーを使用すると、研究の疑問が生じます。流れの差別化なしに冗長性を適用することは、個々のフローのサービス要件と矛盾する場合があります。一部のフローは、部分的な信頼性よりも高い遅延とジッターによりペナルティを受ける場合がありますが、他のフローは部分的な信頼性によってより罰せられる場合があります。実際には、ヘッドオブラインブロッキングは、異なるニーズにもかかわらず、すべてのフローに同様の方法で影響を与えます。これは、テトリー内のより精巧な戦略が必要であることを示しています。
First of all, it must be clear that the use of FEC protection on a data stream does not provide any kind of security per se. On the contrary, the use of FEC protection on a data stream raises security risks. The situation with Tetrys is mostly similar to that of other content delivery protocols making use of FEC protection; this is well described in FECFRAME [RFC6363]. This section builds on this reference, adding new considerations to comply with Tetrys specificities when meaningful.
まず第一に、データストリームでのFEC保護を使用しても、それ自体がセキュリティ自体を提供しないことは明らかです。それどころか、データストリームでFEC保護を使用すると、セキュリティリスクが生じます。Tetrysの状況は、FEC保護を使用する他のコンテンツ配信プロトコルの状況とほとんど類似しています。これは、fecframe [rfc6363]でよく説明されています。このセクションは、このリファレンスに基づいて構築され、意味のあるときにtetryの特異性を順守するための新しい考慮事項を追加します。
An attacker can either target the content, protocol, or network. The consequences will largely differ reflecting various types of goals, like gaining access to confidential content, corrupting the content, compromising the Tetrys encoder and/or Tetrys decoder, or compromising the network behavior. In particular, several of these attacks aim at creating a Denial-of-Service (DoS) with consequences that may be limited to a single node (e.g., the Tetrys decoder), or that may impact all the nodes attached to the targeted network (e.g., by making flows unresponsive to congestion signals).
攻撃者は、コンテンツ、プロトコル、またはネットワークをターゲットにすることができます。結果は、機密コンテンツへのアクセスを獲得したり、コンテンツを破壊したり、テトリーエンコーダーやテトリーデコーダーの損傷、ネットワークの動作を損なうなど、さまざまなタイプの目標を反映して大きく異なります。特に、これらの攻撃のいくつかは、単一のノード（たとえば、テトリーデコーダー）に限定される可能性のある結果を持つサービス拒否（DOS）を作成することを目指しています。たとえば、輻輳信号に反応しないフローを行うことにより）。
In the following sections, we discuss these attacks, according to the component targeted by the attacker.
次のセクションでは、攻撃者が標的とするコンポーネントに従って、これらの攻撃について説明します。
An attacker may want to access confidential content by eavesdropping the traffic between the Tetrys encoder/decoder. Traffic encryption is the usual approach to mitigate this risk, and this encryption can be applied to the source flow upstream of the Tetrys encoder or to the output packets downstream of the Tetrys encoder. The choice on where to apply encryption depends on various criteria, in particular the attacker model (e.g., when encryption happens below Tetrys, the security risk is assumed to be on the interconnection network).
攻撃者は、Tetrys Encoder/Decoder間のトラフィックを盗聴することにより、機密コンテンツにアクセスしたい場合があります。トラフィック暗号化は、このリスクを軽減するための通常のアプローチであり、この暗号化は、Tetryエンコーダーの上流のソースフローまたはTetrysエンコーダーの下流の出力パケットに適用できます。暗号化を適用する場所の選択は、さまざまな基準、特に攻撃者モデルに依存します（たとえば、暗号化がテトリー以下で発生する場合、セキュリティリスクは相互接続ネットワーク上にあると想定されます）。
An attacker may also want to corrupt the content (e.g., by injecting forged or modified source and coded packets to prevent the Tetrys decoder from recovering the original source flow). Content integrity and source authentication services at the packet level are then needed to mitigate this risk. Here, these services need to be provided below Tetrys in order to enable the receiver to drop undesired packets and only transfer legitimate packets to the Tetrys decoder. It should be noted that forging or modifying feedback packets will not corrupt the content, although it will certainly compromise Tetrys operation (see Section 7.3).
攻撃者は、コンテンツを破損したい場合もあります（たとえば、元のソースフローを回復するのを防ぐために、鍛造または変更されたソースとコード化されたパケットを注入することにより）。このリスクを軽減するには、パケットレベルでのコンテンツの整合性とソース認証サービスが必要です。ここでは、レシーバーが望ましくないパケットをドロップし、合法的なパケットのみをTetrysデコーダーに転送できるようにするために、これらのサービスをテトリーの下に提供する必要があります。フィードバックパケットの偽造または変更はコンテンツを破損しないことに注意する必要がありますが、それは確かにtetryの動作を妥協します（セクション7.3を参照）。
Attacks on signaling information (e.g., by forging or modifying feedback packets to falsify the good reception or recovery of source content) can easily prevent the Tetrys decoder from recovering the source flow, thereby creating a DoS. In order to prevent this type of attack, content integrity and source authentication services at the packet level are needed for the feedback flow from the Tetrys decoder to the Tetrys encoder as well. These services need to be provided below Tetrys in order to drop undesired packets and only transfer legitimate feedback packets to the Tetrys encoder.
シグナリング情報に対する攻撃（たとえば、フィードバックパケットを鍛造または変更してソースコンテンツの適切な受信または回復を改ざん）は、Tetryのデコーダーがソースフローの回復を容易に防ぎ、DOSを作成できます。このタイプの攻撃を防ぐために、Tetrys DecoderからTetrysエンコーダーへのフィードバックフローには、パケットレベルでのコンテンツの整合性とソース認証サービスが必要です。これらのサービスは、望ましくないパケットをドロップし、合法的なフィードバックパケットのみをTetrysエンコーダーに転送するために、テトリーの下に提供する必要があります。
Conversely, an attacker in position to selectively drop feedback packets (instead of modifying them) will not severely impact the function of Tetrys since it is naturally robust when challenged with such losses. However, it will have side impacts, such as the use of bigger linear systems (since the Tetrys encoder cannot remove well-received or decoded source packets from its linear system), which mechanically increases computational costs on both sides (encoder and decoder).
逆に、フィードバックパケットを選択的にドロップする位置にある攻撃者（それらを変更する代わりに）は、そのような損失に挑戦した場合に自然に堅牢であるため、テトリーの機能に深刻な影響を与えません。ただし、より大きな線形システムの使用など、副作用があります（Tetryエンコーダーは、線形システムから好評またはデコードされたソースパケットを削除できないため）。
Tetrys can react to congestion signals (Section 6.1) in order to provide a certain level of fairness with other flows on a shared network. This ability could be exploited by an attacker to create or reinforce congestion events (e.g., by forging or modifying feedback packets) that can potentially impact a significant number of nodes attached to the network. In order to mitigate the risk, content integrity and source authentication services at the packet level are needed to enable the receiver to drop undesired packets and only transfer legitimate packets to the Tetrys encoder and decoder.
Tetryは、共有ネットワーク上の他のフローとの一定レベルの公平性を提供するために、混雑信号（セクション6.1）に反応する可能性があります。この能力は、ネットワークに接続されているかなりの数のノードに影響を与える可能性のある混雑イベントを作成または強化するために（たとえば、フィードバックパケットを鍛造または変更することにより）攻撃者によって活用される可能性があります。リスクを軽減するには、受信者が望ましくないパケットをドロップし、合法的なパケットをTetrysエンコーダーとデコーダーにのみ転送できるようにするには、パケットレベルでのコンテンツの整合性とソース認証サービスが必要です。
Tetrys can benefit from an IPsec / Encapsulating Security Payload (IPsec/ESP) [RFC4303] that provides confidentiality, origin authentication, integrity, and anti-replay services in particular. IPsec/ESP can be used to protect the Tetrys data flows (both directions) against attackers located within the interconnection network or attackers in position to eavesdrop traffic, inject forged traffic, or replay legitimate traffic.
Tetryは、特に機密性、起源認証、整合性、およびレプレイアンチレプレイサービスを提供するIPSEC /カプセル化セキュリティペイロード（IPSEC / ESP）[RFC4303]の恩恵を受けることができます。IPSEC/ESPを使用して、交通を盗用したり、鍛造トラフィックを注入したり、合法的なトラフィックを再生したりするために、相互接続ネットワーク内にある攻撃者または攻撃者に対する攻撃者に対するTetrysデータフロー（両方の方向）を保護できます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[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>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052,
DOI 10.17487/RFC5052, August 2007,
<https://www.rfc-editor.org/info/rfc5052>.
[RFC5445] Watson, M., "Basic Forward Error Correction (FEC)
Schemes", RFC 5445, DOI 10.17487/RFC5445, March 2009,
<https://www.rfc-editor.org/info/rfc5445>.
[RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo,
"Reed-Solomon Forward Error Correction (FEC) Schemes",
RFC 5510, DOI 10.17487/RFC5510, April 2009,
<https://www.rfc-editor.org/info/rfc5510>.
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding
Transport (LCT) Building Block", RFC 5651,
DOI 10.17487/RFC5651, October 2009,
<https://www.rfc-editor.org/info/rfc5651>.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009,
<https://www.rfc-editor.org/info/rfc5740>.
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", RFC 6363,
DOI 10.17487/RFC6363, October 2011,
<https://www.rfc-editor.org/info/rfc6363>.
[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>.
[RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek,
F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M.,
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>.
[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>.
[RFC9265] Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Forward
Erasure Correction (FEC) Coding and Congestion Control in
Transport", RFC 9265, DOI 10.17487/RFC9265, July 2022,
<https://www.rfc-editor.org/info/rfc9265>.
[A-FEC] Bolot, J., Fosse-Parisis, S., and D. Towsley, "Adaptive
FEC-based error control for Internet telephony", IEEE
INFOCOM '99, Conference on Computer Communications, New
York, NY, USA, Vol. 3, pp. 1453-1460,
DOI 10.1109/INFCOM.1999.752166, March 1999,
<https://doi.org/10.1109/INFCOM.1999.752166>.
[AHL-00] Ahlswede, R., Cai, N., Li, S., and R. Yeung, "Network
information flow", IEEE Transactions on Information
Theory, Vol. 46, Issue 4, pp. 1204-1216,
DOI 10.1109/18.850663, July 2000,
<https://doi.org/10.1109/18.850663>.
[CTCP] Kim, M., Cloud, J., ParandehGheibi, A., Urbina, L., Fouli,
K., Leith, D., and M. Medard, "Network Coded TCP (CTCP)",
arXiv 1212.2291v3, April 2013,
<https://arxiv.org/abs/1212.2291>.
[RED-FEC] Lin, C., Shieh, C., Chilamkurti, N., Ke, C., and W. Hwang,
"A RED-FEC Mechanism for Video Transmission Over WLANs",
IEEE Transactions on Broadcasting, Vol. 54, Issue 3, pp.
517-524, DOI 10.1109/TBC.2008.2001713, September 2008,
<https://doi.org/10.1109/TBC.2008.2001713>.
[RMCAT-ADAPTIVE-FEC]
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>.
[Tetrys] Lacan, J. and E. Lochin, "Rethinking reliability for long-
delay networks", International Workshop on Satellite and
Space Communications, Toulouse, France, pp. 90-94,
DOI 10.1109/IWSSC.2008.4656755, October 2008,
<https://doi.org/10.1109/IWSSC.2008.4656755>.
[Tetrys-RT]
Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and
V. Roca, "On-the-Fly Erasure Coding for Real-Time Video
Applications", IEEE Transactions on Multimedia, Vol. 13,
Issue 4, pp. 797-812, DOI 10.1109/TMM.2011.2126564, August
2011, <http://dx.doi.org/10.1109/TMM.2011.2126564>.
[THAI] Tran Thai, T., Lacan, J., and E. Lochin, "Joint on-the-fly
network coding/video quality adaptation for real-time
delivery", Signal Processing: Image Communication, Vol. 29
Issue 4, pp. 449-461, DOI 10.1016/j.image.2014.02.003,
April 2014, <https://doi.org/10.1016/j.image.2014.02.003>.
First, the authors want sincerely to thank Marie-Jose Montpetit for continuous help and support on Tetrys. Marie-Jo, many thanks!
第一に、著者は、マリー・ジョセ・モンペティットに継続的な支援とタステスのサポートに感謝したいと考えています。マリー・ジョ、どうもありがとう！
The authors also wish to thank NWCRG group members for numerous discussions on on-the-fly coding that helped finalize this document.
著者はまた、このドキュメントの最終化に役立つオンザフライコーディングに関する多数の議論について、NWCRGグループメンバーに感謝したいと考えています。
Finally, the authors would like to thank Colin Perkins for providing comments and feedback on the document.
最後に、著者は、文書に関するコメントとフィードバックを提供してくれたColin Perkinsに感謝したいと思います。
Jonathan Detchart
ISAE-SUPAERO
BP 54032
10, avenue Edouard Belin
31055 Toulouse CEDEX 4
France
Email: jonathan.detchart@isae-supaero.fr
Emmanuel Lochin
ENAC
7, avenue Edouard Belin
31400 Toulouse
France
Email: emmanuel.lochin@enac.fr
Jerome Lacan
ISAE-SUPAERO
BP 54032
10, avenue Edouard Belin
31055 Toulouse CEDEX 4
France
Email: jerome.lacan@isae-supaero.fr
Vincent Roca
INRIA
Inovallee; Montbonnot
655, avenue de l'Europe
38334 St Ismier CEDEX
France
Email: vincent.roca@inria.fr