[要約] RFC 9426 は、BATched Sparse (BATS) Coding Scheme for Multi-hop Data Transport の効率的な線形ネットワークコーディングスキームであり、通信性能を向上させることを目的としています。NWCRGによるこの文書は、マルチホップネットワークを通じた通信のための基本的なBATSコーディングスキームを説明し、より洗練されたBATSコーディングスキームに向けた関連する研究課題について議論しています。
Internet Research Task Force (IRTF) S. Yang
Request for Comments: 9426 CUHK(SZ) & n-hop technologies
Category: Informational X. Huang
ISSN: 2070-1721 CUHK
R. Yeung
CUHK & n-hop technologies
J. Zao
CUHK
July 2023
In general, linear network coding can improve the network communication performance in terms of throughput, latency, and reliability. BATched Sparse (BATS) code is a class of efficient linear network coding scheme with a matrix generalization of fountain codes as the outer code and batch-based linear network coding as the inner code. This document describes a baseline BATS coding scheme for communication through multi-hop networks and discusses the related research issues towards a more sophisticated BATS coding scheme. This document is a product of the Coding for Efficient Network Communications Research Group (NWCRG).
一般に、線形ネットワークコーディングは、スループット、レイテンシ、信頼性の点でネットワーク通信のパフォーマンスを改善できます。Batched Sparse（BATS）コードは、外部コードとしての噴水コードと内側コードとしてのバッチベースの線形ネットワークコーディングのマトリックス一般化を備えた効率的な線形ネットワークコーディングスキームのクラスです。このドキュメントでは、マルチホップネットワークを介した通信のためのベースラインバットコーディングスキームについて説明し、関連するコウモリのコーディングスキームに関連する研究の問題について説明します。このドキュメントは、効率的なネットワークコミュニケーション研究グループ（NWCRG）のコーディングの製品です。
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 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/rfc9426.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9426で取得できます。
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 Language
2. A Use Case of the BATS Coding Scheme
2.1. Introduction
2.2. DDP Procedures
2.2.1. Source Node Data Partitioning and Padding
2.2.2. Source Node Outer Code Encoding Procedure
2.2.3. Recoding Procedures
2.2.4. Destination Node Procedures
2.3. Recommendation for the Parameters
2.4. Coding Parameters in DDP Packets
2.4.1. Coding Parameter Format
2.4.2. Coded Packet Format
3. BATS Code Specification
3.1. Common Parts
3.2. Outer Code Encoder
3.3. Inner Code Encoder (Recoder)
3.4. Outer Decoder
4. Research Issues
4.1. Coding Design Issues
4.2. Protocol Design Issues
4.3. Usage Scenario Considerations
5. IANA Considerations
6. Security Considerations
6.1. Preventing Eavesdropping
6.2. Privacy Preservation against Traffic Analysis
6.3. Countermeasures against Pollution Attacks
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Authors' Addresses
This document specifies a baseline BATched Sparse (BATS) code [Yang14] scheme for data delivery in multi-hop networks and discusses the related research issues towards a more sophisticated scheme. The BATS code described here includes an outer code and an inner code. The outer code is a matrix generalization of fountain codes (see also the RaptorQ code described in [RFC6330]), which inherits the advantages of reliability and efficiency and possesses the extra desirable property of being compatible with network coding. The inner code, also called recoding, is formed by linear network coding for combating packet loss, improving the multicast efficiency, etc. A detailed design and analysis of BATS codes are provided in the BATS monograph [Yang17].
このドキュメントは、マルチホップネットワークでのデータ配信のためのベースラインバッチスパース（BATS）コード[YANG14]スキームを指定し、関連する研究の問題をより洗練されたスキームに議論します。ここで説明するBATSコードには、外側のコードと内部コードが含まれています。外側のコードは、噴水コードのマトリックス一般化です（[RFC6330]に記載されているRaptorqコードも参照）。これは、信頼性と効率の利点を継承し、ネットワークコーディングと互換性があるという特別な望ましい特性を持っています。再採算とも呼ばれる内部コードは、パケットの損失との戦い、マルチキャスト効率の改善などのための線形ネットワークコーディングによって形成されます。
A BATS coding scheme can be applied in multi-hop networks formed by wireless communication links, which are inherently unreliable due to interference, fading, multipath, etc. Existing transport protocols like TCP use end-to-end retransmission, while network protocols such as IP might enable store-and-forward at the relays so that packet loss would accumulate along the way.
BATSコーディングスキームは、干渉、フェード、マルチパスなどのために本質的に信頼できないワイヤレス通信リンクによって形成されたマルチホップネットワークに適用できます。TCPのような既存の輸送プロトコルは、エンドツーエンドの再送信を使用しますが、ネットワークプロトコルはエンドツーエンドの再送信を使用します。IPは、リレーでストアアンドフォワードを可能にする可能性があるため、パケットの損失が途中で蓄積されるようになります。
A BATS coding scheme can be used for various data delivery applications, like file transmission, video streaming over wireless multi-hop networks, etc. Different from the forward error correction (FEC) schemes that are applied either hop-by-hop or end-to-end, the BATS coding scheme combines the end-to-end coding (the outer code) with certain hop-by-hop coding (the inner code) and hence can potentially achieve better performance.
BATSコーディングスキームは、ファイル送信、ワイヤレスマルチホップネットワーク上のビデオストリーミングなど、さまざまなデータ配信アプリケーションに使用できます。To-endでは、BATSコーディングスキームは、エンドツーエンドのコーディング（外側コード）と特定のホップバイホップコーディング（内部コード）を組み合わせているため、パフォーマンスが向上する可能性があります。
The baseline coding scheme described here considers a network with multiple communication flows. For each flow, the source node encodes the data for transmission separately. However, inside the network, it is possible to mix the packets from different flows for recoding. In this document, we describe a simple case where recoding is performed within each flow. Note that the same encoding/decoding scheme described here can be used with different recoding schemes as long as they follow the principle we illustrate in this document.
ここで説明するベースラインコーディングスキームは、複数の通信フローを持つネットワークを考慮しています。各フローについて、ソースノードは送信のデータを個別にエンコードします。ただし、ネットワーク内では、さまざまなフローからパケットを混合して再調整することができます。このドキュメントでは、各フロー内で再調整が実行される単純なケースについて説明します。ここで説明する同じエンコーディング/デコードスキームは、このドキュメントで説明する原則に従う限り、異なる再確認スキームで使用できることに注意してください。
In this document, we focus on the case that each flow has only one destination node. Communicating the same data to multiple destination nodes is called multicast. Refer to Section 4 for the further discussion of multicast.
このドキュメントでは、各フローには宛先ノードが1つしかないケースに焦点を当てています。同じデータを複数の宛先ノードに通信することは、マルチキャストと呼ばれます。マルチキャストの詳細については、セクション4を参照してください。
The purpose of the baseline BATS coding scheme is twofold. First, it provides researchers and engineers a starting point for developing network communication applications/protocols based on BATS codes. Second, it helps to make the research issues clearer towards a sophisticated network protocol based on BATS codes. Important research directions include the security issues, congestion control, routing algorithms for BATS codes, etc.
ベースラインバットコーディングスキームの目的は2つあります。まず、研究者とエンジニアに、コウモリコードに基づいてネットワーク通信アプリケーション/プロトコルを開発するための出発点を提供します。第二に、BATSコードに基づいた洗練されたネットワークプロトコルに向けて、研究の問題をより明確にするのに役立ちます。重要な研究の方向性には、セキュリティの問題、輻輳制御、BATSコードのルーティングアルゴリズムなどが含まれます。
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 and is not an IETF standard.
このドキュメントは、効率的なネットワークコミュニケーション研究グループ（NWCRG）のコーディングの共同作業とコンセンサスの製品であり、表しています。IETF製品ではなく、IETF標準でもありません。
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 BATS coding scheme described in this document can be used, for example, by a Data Delivery Protocol (DDP). Though this document is not about a DDP, in this section, we briefly illustrate how a BATS coding scheme is employed by a DDP to make the role of the coding scheme clear. Some terms that will be used in this section are summarized here:
このドキュメントで説明されているBATSコーディングスキームは、たとえば、データ配信プロトコル（DDP）で使用できます。このドキュメントはDDPに関するものではありませんが、このセクションでは、CODINGスキームの役割を明確にするためにDDPによってCOTのコーディングスキームがどのように採用されているかを簡単に説明します。このセクションで使用されるいくつかの用語は、ここにまとめられています。
DDP:
DDP：
Data Delivery Protocol
データ配信プロトコル
DDP packet:
DDPパケット：
the packet formed by a DDP employing a BATS coding scheme
BATSコーディングスキームを使用するDDPによって形成されたパケット
source packet:
ソースパケット：
the packet formed by the data for delivery
配信のためにデータによって形成されたパケット
outer encoder:
アウターエンコーダー：
the outer code encoder of a BATS code
BATSコードの外側コードエンコーダー
recoder:
Recoder：
the inner code encoder of a BATS code
BATSコードの内部コードエンコーダー
outer decoder:
外側デコーダー：
the outer code decoder of a BATS code
コウモリコードの外側コードデコーダー
coded packet:
コード化されたパケット：
the packet generated by the outer code encoder or a recoder
アウターコードエンコーダーまたはレコーダーによって生成されたパケット
batch:
バッチ：
a set of coded packets generated by a BATS coding scheme from the same subset of the source packets
ソースパケットの同じサブセットからBATSコーディングスキームによって生成されたコード化されたパケットのセット
recoded packet:
castoded packet：
a coded packet generated by a recoder
レコーダーによって生成されたコード化されたパケット
degree:
程度：
the number of source packets used to generate a batch by the outer encoder. (The degree can be different for a different batch.)
アウターエンコーダーによってバッチを生成するために使用されるソースパケットの数。（別のバッチでは、程度は異なる場合があります。）
Other common terms can be found in [RFC8406].
他の一般的な用語は[RFC8406]に記載されています。
We describe a DDP that involves one source node, one destination node, and multiple intermediate nodes in between. A BATS coding scheme includes an outer code encoder (also called outer encoder), an inner code encoder (also called recoder), and an outer decoder that decodes the outer code and the inner code jointly, as illustrated in Figure 1. The functions of the outer encoder, recoder, and outer decoder are described below:
1つのソースノード、1つの宛先ノード、およびその間に複数の中間ノードを含むDDPについて説明します。BATSコーディングスキームには、外側のコードエンコーダー（アウターエンコーダーとも呼ばれます）、内側のコードエンコーダー（レコーダーとも呼ばれます）、および図1に示すように、外側コードと内部コードを共同でデコードする外側デコーダーが含まれます。外側のエンコーダー、リコーダー、および外側デコーダーについては、以下に説明します。
|
| {set of source packets}
v
+-+-+-+-+-+-+-+-+
| outer encoder |
| v | source node
| recoder |
+-+-+-+-+-+-+-+-+
|
| {set of DDP packets}
v
+-+-+-+-+-+-+-+-+
| |
| recoder | intermediate node
| |
+-+-+-+-+-+-+-+-+
|
| {set of DDP packets}
v
...
|
| {set of DDP packets}
v
+-+-+-+-+-+-+-+-+
| |
| outer decoder | destination node
| |
+-+-+-+-+-+-+-+-+
|
| {set of source packets}
v
Figure 1: A Network Model for Data Delivery
図1：データ配信のネットワークモデル
At the source node, the DDP first processes the data to be delivered into a number of source packets, each of the same number of bits (see details in Section 2.2.1), and then provides all the source packets to the outer encoder. The outer encoder will further generate a sequence of batches, each consisting of a fixed number of coded packets (see the description in Section 2.2.2).
ソースノードでは、DDPは最初にデータを処理し、それぞれ同じ数のビット数（セクション2.2.1の詳細を参照）を使用し、すべてのソースパケットをアウターエンコーダーに提供します。アウターエンコーダーはさらに一連のバッチを生成し、それぞれが固定数のコード化されたパケットで構成されます（セクション2.2.2の説明を参照）。
Each batch generated at the source node is further processed by the recoder separately. The recoder may generate a number of new coded packets using the existing coded packets of the batch (see the description in Section 2.2.3). After it is processed by the recoder, The DDP forms and transmits the DDP packets using the coded packets, together with the corresponding batch information.
ソースノードで生成された各バッチは、レコーダーによってさらに処理されます。Recoderは、バッチの既存のコード化されたパケットを使用して、多数の新しいコード化されたパケットを生成する場合があります（セクション2.2.3の説明を参照）。Recoderによって処理された後、DDPは、コード化されたパケットを使用してDDPパケットをフォームして送信し、対応するバッチ情報を送信します。
We assume that a DDP packet is either correctly received or completely erased during the communication. The DDP extracts the coded packets and the corresponding batch information from its received DDP packets. A recoder is employed at an intermediate node that does not need the data and generates recoded packets for each batch (see the description in Section 2.2.3). The DDP forms and transmits DDP packets using the recoded packets and the corresponding batch information.
DDPパケットは、通信中に正しく受信されるか、完全に消去されると仮定します。DDPは、受信したDDPパケットからコード化されたパケットと対応するバッチ情報を抽出します。レコーダーは、データを必要とせず、各バッチの再認定パケットを生成する中間ノードで採用されています（セクション2.2.3の説明を参照）。DDPは、再認定されたパケットと対応するバッチ情報を使用して、DDPパケットを形成および送信します。
The outer decoder is employed at the destination node that needs the data. The DDP extracts the coded packets and the corresponding batch information from its received DDP packets. The outer decoder tries to recover the transmitted data using the received batches (see the description in Section 2.2.4). The DDP sends the decoded data to the application that needs the data.
外側のデコーダーは、データが必要な宛先ノードで採用されています。DDPは、受信したDDPパケットからコード化されたパケットと対応するバッチ情報を抽出します。外側のデコーダーは、受信したバッチを使用して送信されたデータを回復しようとします（セクション2.2.4の説明を参照）。DDPは、デコードされたデータをデータを必要とするアプリケーションに送信します。
Suppose that the DDP has F octets of data for transmission. We describe the procedures of one BATS session for transmitting the F octets. There is a limit on F of a single BATS session. If the total data has more than the limit, the data needs to be transmitted using multiple BATS sessions. The limit on F of a single BATS session depends on the coding parameters that are discussed in this section and the calculations described at the end of Section 2.4.2.
DDPに送信用のデータのfオクテットがあると仮定します。Fオクテットを送信するための1つのコウモリセッションの手順について説明します。単一のコウモリセッションのFには制限があります。合計データが制限を超えている場合、データを複数のバットセッションを使用して送信する必要があります。単一のコウモリセッションのFの制限は、このセクションで説明するコーディングパラメーターと、セクション2.4.2の最後で説明されている計算に依存します。
The DDP first determines the following parameters:
DDPは最初に次のパラメーターを決定します。
* batch size (M): the number of coded packets in a batch generated by the outer encoder
* バッチサイズ（m）：外側エンコーダーによって生成されたバッチ内のコード化されたパケットの数
* recoding field size (q): the number of elements in the finite field for recoding, i.e., q is 2 or 2^8
* フィールドサイズの再調整（q）：cecodingのための有限フィールドの要素の数、つまりqは2または2^8です
* BATS payload size (TO): the number of payload octets in a BATS packet, including the coded data and the coefficient vector
* コウモリペイロードサイズ（to）：コード化されたデータや係数ベクトルを含むコウモリパケットのペイロードオクテットの数
Based on the above parameters, the parameters T, CO, and K are calculated as follows:
上記のパラメーターに基づいて、パラメーターT、CO、およびKは次のように計算されます。
* CO: the number of octets of a coefficient vector, calculated as CO = ceil(M * log2(q) / 8), which is also called the coefficient vector overhead
* CO：CO = CEIL（M * log2（Q） / 8）として計算された係数ベクトルのオクテットの数。これは係数ベクトルオーバーヘッドとも呼ばれます。
* T: the number of data octets of a coded packet, calculated as T = TO - CO
* T：t = to -coとして計算されたコード化されたパケットのデータオクテットの数
* K: number of source packets, calculated as K = floor(F / T) + 1
* K：k = floor（f / t）1として計算されたソースパケットの数
The data MUST be padded to have T*K octets, which will be partitioned into K source packets b[0], ..., b[K - 1], each of T octets. In our padding scheme, b[0], ..., b[K - 2] are filled with data octets, and b[K - 1] is filled with the remaining data octets and padding octets. Let P = K * T - F denote the number of padding octets. We use b[K - 1, 0], ..., b[K - 1, T - P - 1] to denote the T - P source octets and b[K - 1, T - P], ..., b[K - 1, T - 1] to denote the P padding octets in b[K - 1], respectively. The padding insertion process is shown in Figure 2.
データは、t*kオクテットを持つようにパッドにしている必要があります。これは、それぞれtオクテットのkソースパケットb [0]、...、b [k -1]に分割されます。パディングスキームでは、B [0]、...、B [k -2]はデータオクテットで満たされ、B [k -1]は残りのデータオクテットとパディングオクテットで満たされています。p = k * t -fがパディングのオクテットの数を示します。b [k -1、0]、...、b [k -1、t -p -1]を使用して、t -p源オクテットとb [k -1、t -p]、...を示します。、b [k -1、t -1]は、それぞれB [k -1]のPパディングオクテットを示します。パディング挿入プロセスを図2に示します。
Z = T - P
j = 1
v = 1
Let bl be the last source packet b[K - 1]
for i = Z, Z + 1, ..., T - 1 do
bl[i] = j
if i + 1 >= v + Z do
j += 1
v += j
Figure 2: Data Padding Insertion Process
図2：データパディング挿入プロセス
The DDP provides the BATS encoder with the following information:
DDPは、BATSエンコーダーに次の情報を提供します。
* batch size (M): the number of coded packets in a batch
* バッチサイズ（m）：バッチ内のコード化されたパケットの数
* recoding field size (q): the number of elements in the finite field for recoding
* フィールドサイズの再調整（Q）：復元のための有限フィールドの要素の数
* maximum degree (MAX_DEG): a positive integer that specifies the largest degree can be used
* 最大度（MAX_DEG）：最大の程度を指定する正の整数を使用できます
* degree distribution (DD): an unsigned integer array of size MAX_DEG+1. The i-th entry DD[i] is the probability that i is chosen as the degree, where i is between 0 and MAX_DEG.
* 度分布（DD）：サイズの符号なし整数アレイmax_deg 1. i番目のエントリDD [i]は、私が0とMAX_DEGの間にある程度として選択される確率です。
* a sequence of batch IDs (BIDs) (j, j = 0, 1, ...)
* 一連のバッチID（入札）（j、j = 0、1、...）
* number of source packets (K)
* ソースパケットの数（k）
* packet size (T): the number of octets in a source packet
* パケットサイズ（T）：ソースパケットのオクテットの数
* source packets (b[i], i = 0, 1, ..., K - 1)
* ソースパケット（b [i]、i = 0、1、...、k -1）
Using this information, the outer encoder generates M coded packets for each BID using the following steps that are described in detail in Section 3.2:
この情報を使用して、外側のエンコーダーは、セクション3.2で詳細に説明されている次の手順を使用して、各入札のMコードパケットを生成します。
* Obtain a degree d by sampling DD. Roughly, the value d is chosen with probability DD[d].
* DDをサンプリングすることにより、学位を取得します。大まかに、値dは確率dd [d]で選択されます。
* Choose d source packets uniformly at random from all the K source packets. It is allowed that a source packet is used by multiple batches.
* すべてのKソースパケットからランダムに均一にDソースパケットを選択します。ソースパケットが複数のバッチで使用されることが許可されています。
* Generate M coded packets using the d source packets.
* Dソースパケットを使用してMコード化されたパケットを生成します。
From the outer encoder, the DDP receives a sequence of batches, where the batch with ID j has M coded packets (x[j,i], i =0, 1, ..., M - 1), each containing TO octets.
外側のエンコーダーから、DDPは一連のバッチを受け取ります。このバッチでは、ID jのバッチにはMコードパケット（x [j、i]、i = 0、1、...、m -1）があり、それぞれがオクテットに含まれています。。
The DDP will use the batches to form DDP packets to be transmitted to other network nodes towards the destination nodes. The DDP MUST deliver each coded packet with its batch ID, which will be further used by both the recoder and decoder.
DDPは、バッチを使用してDDPパケットを形成し、宛先ノードに向かって他のネットワークノードに送信されます。DDPは、各コード化されたパケットをバッチIDで配信する必要があります。これは、リコーダーとデコーダーの両方でさらに使用されます。
The DDP MUST deliver some of the information used by the encoder to each of the recoders and the decoder, either embedded in the DDP packets or transmitted using separated protocol messages. For recoders, the DDP MUST deliver the following information to each recoder:
DDPは、エンコーダーによって使用される情報の一部を、DDPパケットに埋め込んだか、分離されたプロトコルメッセージを使用して送信されたデコーダーに使用する情報を提供する必要があります。リコーダーの場合、DDPは次の情報を各レコーダーに配信する必要があります。
* M: batch size
* M：バッチサイズ
* q: recoding field size
* Q：フィールドサイズの再調整
For the decoder, the DDP MUST deliver the following information to the decoder:
デコーダーの場合、DDPは次の情報をデコーダーに配信する必要があります。
* M: batch size
* M：バッチサイズ
* q: recoding field size
* Q：フィールドサイズの再調整
* K: the number of source packets
* K：ソースパケットの数
* T: the number of octets in a source packet
* T：ソースパケットのオクテット数
* DD: the degree distribution
* DD：程度分布
The BID is used by both recoders and decoders. In Section 2.4, we illustrate how to embed BID, M, q, and K into DDP packets. The degree distribution DD does not need to be changed frequently. See Section 6 of [Yang17] about how to design a good degree distribution. Once designed, the degree distribution can be shared between the source node and the destination node by the DDP, which is not further discussed here.
この入札は、リコーダーとデコーダーの両方で使用されます。セクション2.4では、BID、M、Q、およびKをDDPパケットに埋め込む方法を示します。Degree Distribution DDを頻繁に変更する必要はありません。[Yang17]のセクション6を参照してください。設計されたら、DDPによってSourceノードと宛先ノードの間で程度分布を共有できますが、ここではこれ以上説明しません。
Both the source node and the intermediate nodes perform recoding on the batches before transmission. At the source node, the recoder receives the batches from the outer code encoding procedure. At an intermediate node, the DDP receives the DDP packets from the other network nodes. If the DDP chooses not to recode, it just forwards the DDP packets it received. Otherwise, the DDP should be able to extract coded packets and the corresponding batch information from these packets.
ソースノードと中間ノードの両方が、送信前にバッチで再コーディングを実行します。ソースノードでは、レコーダーは外側コードエンコード手順からバッチを受信します。中間ノードでは、DDPは他のネットワークノードからDDPパケットを受信します。DDPが再度再編成しないことを選択した場合、受信したDDPパケットを転送するだけです。それ以外の場合、DDPは、これらのパケットからコード化されたパケットと対応するバッチ情報を抽出できるはずです。
For a received batch, the DDP determines a positive integer (Mr) and the number of recoded packets to be transmitted for the batch, and DDP provides the recoder with the following information:
受信したバッチの場合、DDPは正の整数（MR）とバッチ用に送信される再整理されたパケットの数を決定し、DDPは次の情報をレコーダーに提供します。
* M: batch size
* M：バッチサイズ
* q: recoding field size
* Q：フィールドサイズの再調整
* a number of received coded packets of the same batch, each containing TO octets
* 同じバッチの受信したコード化されたパケットの多数、それぞれがオクテットに含まれています
* Mr: the number of recoded packets to be generated
* MR：生成される再入力されたパケットの数
The recoder uses the information provided by the DDP to generate Mr recoded packets, each containing TO octets, which are described in Section 3.3. The DDP uses the Mr recoded packets to form the DDP packets for transmitting.
Recoderは、DDPが提供する情報を使用して、セクション3.3で説明されているオクテットにそれぞれを含むMR Recodedパケットを生成します。DDPは、MR Cracodedパケットを使用して、送信用のDDPパケットを形成します。
At the destination node, the DDP receives DDP packets from an intermediate network node and should be able to extract coded packets and the corresponding batch information from these packets. The DDP then employs an outer decoder to recover the data transmitted by the source node.
宛先ノードでは、DDPは中間ネットワークノードからDDPパケットを受信し、これらのパケットからコード化されたパケットと対応するバッチ情報を抽出できるはずです。次に、DDPは外側のデコーダーを使用して、ソースノードによって送信されたデータを回復します。
The DDP provides the outer decoder (to be described in Section 3.4) with the following information:
DDPは、外側のデコーダー（セクション3.4で説明する）に次の情報を提供します。
* M: batch size
* M：バッチサイズ
* q: recoding field size
* Q：フィールドサイズの再調整
* K: the number of source packets
* K：ソースパケットの数
* T: the number of octets of a source packet
* T：ソースパケットのオクテット数
* a sequence of batches, each of which is formed by a number of coded packets belonging to the same batch, with their corresponding BIDs
* バッチのシーケンスは、それぞれが同じバッチに属する多数のコード化されたパケットによって形成され、対応する入札があります
The decoder uses this information to decode the outer code and the inner code jointly and recover the K source packets (see details in Section 3.4). If successful, the decoder returns the recovered K source packets to the DDP, which will use the K source packets to form the F octets data. The recommended padding deletion process is shown as follows:
デコーダーはこの情報を使用して、外側コードと内部コードを共同でデコードし、Kソースパケットを回復します（セクション3.4の詳細を参照）。成功した場合、デコーダーは回復したKソースパケットをDDPに返し、Kソースパケットを使用してFオクテットデータを形成します。推奨されるパディングの削除プロセスは、次のように表示されます。
// this procedure returns the number P of padding octets
// at the end of b[K - 1]
Let bl be the last decoded source packet b[K - 1]
PL = bl[T - 1]
if PL == 1 do
return P = 1
WI = T - 1
while bl[WI] == PL do
WI = WI - 1
return P = (1 + bl[WI]) * bl[WI] + T - WI - 1
Figure 3: Data Padding Deletion Process
図3：データパディングの削除プロセス
The recommendation for the parameters M and q is shown as follows:
パラメーターmとqの推奨事項は、次のように示されています。
* when q = 2, M = 16, 32, 64, 128
* q = 2、m = 16、32、64、128の場合
* when q = 256, M = 4, 8, 16, 32
* q = 256、m = 4、8、16、32
It is RECOMMENDED that K is at least 128. The encoder/decoder SHALL support an arbitrary positive integer value less than 2^16. However, the BATS coding scheme to be described is not optimized for small K.
Kは少なくとも128であることをお勧めします。エンコーダー/デコーダーは、2^16未満の任意の正の整数値をサポートするものとします。ただし、説明するコードコーディングスキームは、小さなKに最適化されていません。
Here, we provide an example of embedding the aforementioned BATS coding parameters into the DDP packets that will be used for recoding and decoding. A DDP can form a DDP packet using a coded packet by adding necessary information that can help to deliver the DDP packet to the next node (e.g., the version of the DDP, addresses, and session identifiers). We will not go into the details of formatting these fields in a DDP packet, but we focus on how to format the coding parameters and the coded packet in a DDP packet.
ここでは、前述のコウモリのコーディングパラメーターをDDPパケットに埋め込んだ例を示します。DDPは、DDPパケットを次のノードに配信するのに役立つ必要な情報を追加することにより、コード付きパケットを使用してDDPパケットを形成できます（例：DDP、アドレス、およびセッション識別子のバージョンなど）。これらのフィールドをDDPパケットでフォーマットする詳細については説明しませんが、DDPパケットでコーディングパラメーターとコード化されたパケットをフォーマットする方法に焦点を当てます。
Here, we provide an example of using 32 bits (4 octets) to embed the parameters K, M, q, and BID. The 32 bits are separated into three subfields, denoted as K, Mq, and BID, respectively, as illustrated in Figure 4.
ここでは、32ビット（4オクテット）を使用してパラメーターk、m、q、およびbidを埋め込んだ例を示します。32ビットは、図4に示すように、それぞれK、MQ、およびBIDとして示される3つのサブフィールドに分けられます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| K | Mq | BID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Coding Parameter Field Format
図4：パラメーターフィールド形式のコーディング
K:
K：
16-bit unsigned integer, specifying the number of source packets of the BATS session
16ビットの署名のない整数、コウモリセッションのソースパケットの数を指定する
Mq:
MQ：
3-bit unsigned integer, specifying the value of M and q, as shown in Table 1
表1に示すように、mとqの値を指定する3ビットの符号なし整数。
BID:
入札：
13-bit unsigned integer, specifying the batch ID of the batch the packet belongs to
パケットが属するバッチのバッチIDを指定する13ビットの符号なし整数
+=====+=====+=====+
| Mq | M | q |
+=====+=====+=====+
| 000 | 16 | 2 |
+-----+-----+-----+
| 010 | 32 | 2 |
+-----+-----+-----+
| 100 | 64 | 2 |
+-----+-----+-----+
| 110 | 128 | 2 |
+-----+-----+-----+
| 001 | 4 | 256 |
+-----+-----+-----+
| 011 | 8 | 256 |
+-----+-----+-----+
| 101 | 16 | 256 |
+-----+-----+-----+
| 111 | 32 | 256 |
+-----+-----+-----+
Table 1: Values of the Mq Field
表1：MQフィールドの値
The choice of the coding parameters depends on the computation cost, the network conditions, and the expected end-to-end coding performance. Usually, a larger batch size M will have a better coding performance but higher computation cost for encoding, recoding, and decoding. The field size q affects the coefficient vector overhead and also the computation cost for recoding. Within a BATS session, the BID field should be different for all batches, and hence, the maximum number of batches that can be generated for the outer encoder is 2^13. For different BATS sessions, batches can use the same BID.
コーディングパラメーターの選択は、計算コスト、ネットワーク条件、および予想されるエンドツーエンドコーディングパフォーマンスに依存します。通常、バッチサイズMが大きいほどコーディングパフォーマンスが向上しますが、エンコーディング、リコード、デコードの計算コストが高くなります。フィールドサイズQは、係数ベクトルのオーバーヘッドと、再調整の計算コストにも影響します。BATSセッション内では、すべてのバッチで入札フィールドが異なる必要があります。したがって、外側エンコーダーで生成できるバッチの最大数は2^13です。さまざまなコウモリのセッションでは、バッチは同じ入札を使用できます。
CO T
+-----------------------+-------------------------------+
| coefficient vector | coded data |
+-----------------------+-------------------------------+
Figure 5: Code Packet Format in a DDP Packet
図5：DDPパケットのコードパケット形式
A coded packet has TO=T+CO octets, where the first CO octets contain the coefficient vector and the remaining T octets contain the coded data.
コード化されたパケットには= t Coオクテットが必要です。最初のCOオクテットには係数ベクトルが含まれ、残りのTオクテットにはコード化されたデータが含まれています。
coefficient vector:
係数ベクトル：
CO = M * log2(q) / 8 octets. For the values of M and q in Table 1, CO is at most 32 octets when q is 256 and 6 octets when q is 2.
co = m * log2（q） / 8オクテット。表1のmとqの値の場合、COはqが256の場合は最大32オクテットで、qが2の場合は6オクテットです。
coded data:
コード化されたデータ：
T octets. T should be chosen so that the whole DDP packet is at most Path MTU (PMTU).
tオクテット。DDPパケット全体が最大のPATH MTU（PMTU）になるように、Tを選択する必要があります。
Using the above formation, we can calculate the largest file size (F) for different parameters. For example, when q = 2 and M = 128, we have CO = 6 octets. Counting the 4 octets for embedding the coding parameters, we can choose T = PMTU - H - 10, where H is the header length of a DDP packet. As K can be at most 2^16 - 1, F can be at most (PMTU - H - 10)(2^16 - 1) octets. In this case, K / M is about 2^9 and the BID field allows transmitting 2^4 * K / M batches.
上記のフォーメーションを使用して、さまざまなパラメーターに対して最大のファイルサイズ（f）を計算できます。たとえば、Q = 2およびM = 128の場合、CO = 6オクテットがあります。コードパラメーターを埋め込むための4オクテットをカウントすると、t = PMTU -h -10を選択できます。ここで、HはDDPパケットのヘッダー長です。Kは最大2^16-1である可能性があるため、fはせいぜい（PMTU -h -10）（2^16-1）オクテットになります。この場合、k / mは約2^9であり、入札フィールドでは2^4 * k / mバッチを送信できます。
The T octets of a source packet are treated as a column vector of T elements in GF(256). The CO octets of a coefficient vector are treated as a column vector of CO elements in GF(q), where q = 2 or q = 256. Linear algebra and matrix operations over finite fields are assumed in this section.
ソースパケットのTオクテットは、GF（256）のT要素の列ベクトルとして扱われます。係数ベクトルのCOオクテットは、GF（Q）のCO要素のカラムベクトルとして扱われます。ここで、Q = 2またはQ = 256です。このセクションでは、有限フィールド上の線形代数およびマトリックス操作が想定されています。
For the two elements of GF(2), their multiplication corresponds to a logical AND operation, and their addition is a logical XOR operation. An element of the field GF(256) can be represented by a polynomial with binary coefficients and degree lower or equal to 7. The addition between two elements of GF(256) is defined as the addition of the two binary polynomials. The multiplication between two elements of GF(256) is the multiplication of the two binary polynomials modulo a certain irreducible polynomial of degree 8, called a primitive polynomial. One example of such a primitive polynomial for GF(256) is:
GF（2）の2つの要素の場合、それらの乗算は論理的および操作に対応し、それらの追加は論理XOR操作です。フィールドGF（256）の要素は、バイナリ係数を備えた多項式と7以下の程度で表すことができます。GF（256）の2つの要素間の添加は、2つのバイナリ多項式の添加として定義されます。GF（256）の2つの要素間の乗算は、原始多項式と呼ばれる次数8の特定の既約多項式を測定する2つのバイナリ多項式の乗算です。GF（256）のこのような原始的多項式の1つの例は次のとおりです。
x^8 + x^4 + x^3 + x^2 + 1
x^8 x^4 x^3 x^2 1
A common primitive polynomial MUST be specified for all the finite field multiplications over GF(256). Note that a binary polynomial of degree less than 8 can be represented by a binary sequence of 8 bits, i.e., an octet.
GF（256）を介したすべての有限フィールド乗算に対して、一般的な原始多項式を指定する必要があります。8度未満のバイナリ多項式は、8ビットのバイナリシーケンス、つまりオクテットで表すことができることに注意してください。
Suppose that a pseudorandom number generator, Rand(), which generates an unsigned integer of 32 bits, is shared by both encoding and decoding. The pseudorandom generator can be initialized by Rand_Init(S) with seed S. When S is not provided, the pseudorandom generator is initialized arbitrarily. One example of such a pseudorandom generator is defined in [RFC8682].
32ビットの署名されていない整数を生成する擬似ランダム数ジェネレーターであるRand（）が、エンコードとデコードの両方で共有されるとします。擬似ランダムジェネレーターは、Seed Sを使用してRAND_INIT（S）によって初期化できます。Sが提供されない場合、擬似ランダムジェネレーターは任意に初期化されます。このような擬似ランダムジェネレーターの1つの例は、[RFC8682]で定義されています。
A function called BatchSampler is used in both encoding and decoding. The function takes two integers, j and d, as input and generates an array idx of d integers and a d x M matrix G. The function first initializes the pseudorandom generator with j, sample d distinct integers from 0 to K-1 as idx, and sample d*M integers from 0 to 255 as G. See the pseudocode in Figure 6.
BatchSamplerと呼ばれる関数は、エンコードとデコードの両方で使用されます。この関数は、入力として2つの整数JとDを取得し、d integersとa d x mマトリックスGの配列IDXを生成します。この関数は、最初にJを備えた擬似ランダムジェネレーターを初期化し、0からk-1として個別の整数をidxとして、およびサンプルDのdを初期化し、Gとして0から255のサンプルd*m整数。図6の擬似コードを参照してください。
function BatchSampler(j, d)
// initialize the pseudorandom generator by seed j.
Rand_Init(j)
// sample d distinct integers between 0 and K - 1.
for k = 0, ..., d - 1 do
r = Rand() % K
while r already exists in idx do
r = Rand() % K
idx[k] = r
// sample d x M matrix
for r = 0, ..., d - 1 do
for c = 0, ..., M - 1 do
G[r, c] = Rand() % 256
return idx, G
Figure 6: Batch Sampler Function
図6：バッチサンプラー関数
Define a function called DegreeSampler that returns an integer d using the degree distribution DD. We expect that the empirical distribution of the returning d converges to DD(d) when d < K. One design of DegreeSampler is illustrated in Figure 7. Note that when K < MAX_DEG, the degree value returned by DegreeSampler does not exactly follow the distribution DD, which however would not affect the practical decoding performance for the outer decoder to be described in Section 3.4.
度分布DDを使用して整数Dを返すDegreesamplerという関数を定義します。d <Kの場合、戻るdの経験的分布はDd（d）に収束すると予想されます。Degreesamplerの1つの設計を図7に示します。ただし、セクション3.4で説明する外側デコーダーの実際のデコード性能には影響しません。
function DegreeSampler(j, DD)
Let CDF be an array
CDF[0] = 0
for i = 1, ..., MAX_DEG do
CDF[i] = CDF[i - 1] + DD[i]
Rand_Init(j)
r = Rand() % CDF[MAX_DEG]
for d = 1, ..., MAX_DEG do
if r >= CDF[d] do
return min(d, K)
return min(MAX_DEG, K)
Figure 7: Degree Sampler Function
図7：程度サンプラー関数
Let b[0], b[1], ..., b[K-1] be the K source packets. A batch with BID j is generated using the following steps.
b [0]、b [1]、...、b [k-1]をKソースパケットとします。次の手順を使用して、BID Jのバッチが生成されます。
* Obtain a degree d by calling DegreeSampler with input j.
* 入力jを使用してdegreesamplerを呼び出すことにより、学位を取得します。
* Obtain idx and G[j] by calling BatchSampler with input j and d.
* 入力jとdを使用してbatchsamplerを呼び出すことにより、idxとg [j]を取得します。
* Let B[j] = (b[idx[0]], b[idx[1]], ..., b[idx[d - 1]]). Form the batch X[j] = B[j] * G[j], whose dimension is T x M.
* b [j] =（b [idx [0]]、b [idx [1]]、...、b [idx [d -1]]）とします。バッチx [j] = b [j] * g [j]を形成し、その次元はt x Mです。
* Form the TO x M matrix Xr[j], where the first CO rows of Xr[j] form the M x M identity matrix I with entries in GF(q) and the last T rows of Xr[j] is X[j].
* to x mマトリックスxr [j]を形成します。ここで、Xr [j]の最初のコロウは、GF（q）のエントリとXr [j]の最後のt行のエントリを持つM x M IDアイデンティックマトリックスIを形成します。]。
See the pseudocode of the batch generating process in Figure 8.
図8のバッチ生成プロセスの擬似コードを参照してください。
function GenBatch(j)
d = DegreeSampler(j)
(idx, G) = BatchSampler(j, d)
B = (b[idx[0]], b[idx[i]], ..., b[idx[d - 1]])
X = B * G
Xr = [I; X]
return Xr
Figure 8: Batch Generation Function
図8：バッチ生成機能
In general, the inner code of a BATS code comprises (random) linear network coding applied on the coded packets belonging to the same batch. The recoded packets have the same BID. Suppose that coded packets xr[i], i = 0, 1, ..., r - 1, which have the same BID j, have been received at an intermediate node and Mr recoded packets are supposed to be generated. Following random linear network coding, a recoded packet can be generated by a random linear combination: (randomly) choose a sequence of coefficients c[i], i = 0, 1, ..., r - 1 from GF(q) and generate c[0]xr[0] + c[1]xr[1] + ... + c[r - 1]xr[r - 1] as a recoded packet. This recoding approach, called random linear recoding, achieves good network coding performance for multicast when the batch size is sufficiently large.
一般に、BATSコードの内部コードは、同じバッチに属するコード化されたパケットに適用される（ランダム）線形ネットワークコーディングで構成されています。復元されたパケットには同じ入札があります。コード化されたパケットxr [i]、i = 0、1、...、r -1は、同じ入札jが中間ノードで受信されており、MRの再cadedパケットが生成されることになっているとします。ランダムな線形ネットワークコーディングに続いて、Random Linearの組み合わせによって再作成されたパケットを生成できます。（ランダムに）GF（Q）およびR -1の係数C [i]、i = 0、1、...、R -1のシーケンスを選択できます。c [0] xr [0] c [1] xr [1] ... c [r -1] xr [r -1]を再認めたパケットとして生成します。ランダムな線形復元と呼ばれるこの再登録アプローチは、バッチサイズが十分に大きい場合、マルチキャストの優れたネットワークコーディングパフォーマンスを実現します。
For unicast communications in a single path, as illustrated in Figure 1, it is not necessary to generate all the Mr recoded packets using a random linear combination. Instead, xr[i], i = 0, 1, ..., r - 1 are directly used as recoded packets, and max(Mr - r, 0) recoded packets are generated using linear combinations. Compared with random linear recoding, this recoding approach, called systematic recoding, can reduce both the computation cost and the recoding latency that accumulates linearly with the number of nodes. Note that the use of systematic recoding may not always achieve the optimal network coding performance as random linear recoding in more complicated communication scenarios that include multiple paths and multiple destination nodes.
単一のパスでのユニキャスト通信の場合、図1に示すように、ランダムな線形結合を使用してすべてのMR Cracodedパケットを生成する必要はありません。代わりに、xr [i]、i = 0、1、...、r -1は、再cadedされたパケットとして直接使用され、max（mr -r、0）は線形結合を使用して生成されます。ランダムな線形復元と比較して、系統的リコーディングと呼ばれるこの再登録アプローチは、ノードの数に直線的に蓄積する計算コストと復元レイテンシの両方を減らすことができます。系統的リコーディングの使用は、複数のパスと複数の宛先ノードを含むより複雑な通信シナリオで、ランダムな線形復元として最適なネットワークコーディングパフォーマンスを常に実現するとは限りません。
The decoder receives a sequence of batches, Yr[j], j = 0, 1, ..., n - 1, each of which is a TO-row matrix over GF(256). Let Y[j] be the submatrix of the last T rows of Yr[j]. When q = 256, let H[j] be the first M rows of Yr[j]; when q = 2, let H[j] be the matrix over GF(256) formed by embedding each bit in the first M/8 rows of Yr[j] into GF(256). For successful decoding, we require that the total rank of all the batches is at least K.
デコーダーは、一連のバッチ、yr [j]、j = 0、1、...、n -1を受信します。それぞれがGF上の列のマトリックスです（256）。y [j]をyr [j]の最後のt行のサブマトリックスとします。q = 256の場合、h [j]をyr [j]の最初のm行とします。q = 2の場合、h [j]を、yr [j]の最初のm/8行に各ビットをgf（256）に埋め込むことにより形成されるGF（256）のマトリックスとします。デコードを成功させるには、すべてのバッチの合計ランクが少なくともKである必要があります。
The same degree distribution DD used for the outer encoder is supposed to be known by the outer decoder. By calling DegreeSampler and BatchSampler with input j, we obtain d[j], idx[j], and G[j]. According to the encoding and recoding processes described in Sections 3.2 and 3.3, we have the system of linear equations Y[j] = B[j]G[j]H[j] for each received batch with ID j, where B[j] = (b[idx[j, 0]], b[idx[j, 1]], ..., b[idx[j, d - 1]]) is unknown.
外側のエンコーダーに使用される同じ度分布DDは、外側のデコーダーによって知られているはずです。入力jを使用してdegreesamplerとbatchsamplerを呼び出すことにより、d [j]、idx [j]、およびg [j]を取得します。セクション3.2および3.3で説明されているエンコーディングおよびリコードプロセスによれば、線形方程式のシステムがありますy [j] = b [j] g [j] h [j]は、ID jで受信された各バッチに対してb [j] =（b [idx [j、0]]、b [idx [j、1]]、...、b [idx [j、d -1]]）は不明です。
We first describe a belief propagation (BP) decoder that can efficiently solve the source packets when a sufficient number of batches have been received. A batch j is said to be decodable if rank(G[j]H[j]) = d[j] (i.e., the system of linear equations Y[j] = B[j]G[j]H[j] with B[j] as the variable matrix has a unique solution). The BP decoding algorithm has multiple iterations. Each iteration is formed by the following steps:
最初に、十分な数のバッチを受信したときにソースパケットを効率的に解くことができる信念伝播（BP）デコーダーについて説明します。バッチjは、ランク（g [j] h [j]）= d [j]（すなわち、線形方程式のシステムy [j] = b [j] g [j] h [j]の場合、解読可能であると言われています。可変マトリックスとしてB [J]を使用すると、一意のソリューションがあります）。BPデコードアルゴリズムには複数の反復があります。各反復は、次の手順によって形成されます。
* Decoding Step: Find a batch j that is decodable. Solve the corresponding system of linear equations Y[j] = B[j]G[j]H[j] and decode B[j].
* デコードステップ：デコード可能なバッチJを見つけます。線形方程式の対応するシステムy [j] = b [j] g [j] h [j]とb [j]を解きます。
* Substitution Step: Substitute the decoded source packets into undecodable batches. Suppose that a decoded source packet b[k] is used in generating an undecodable Y[j]. The substitution involves 1) removing the entry in idx[j] corresponding to k, 2) removing the row in G[j] corresponding to b[k], and 3) reducing d[j] by 1.
* 代替手順：デコードされたソースパケットを、削除不可能なバッチに置き換えます。デコードされたソースパケットB [k]が、不可能なY [J]の生成に使用されると仮定します。置換には、1）k、2）k [j]に対応するg [j]の行を削除するidx [j]のエントリを削除し、3）d [j]を1で減少させます。
The BP decoder repeats the above steps until no batches are decodable during the decoding step.
BPデコーダーは、デコードステップ中にバッチがデコードできなくなるまで上記の手順を繰り返します。
When the degree distribution DD in the outer code encoder (see Section 3.2) is properly designed, the BP decoder guarantees a high probability for the recovery of a given fraction of the source packets when K is large. To recover all the source packets, a precode can be applied to the source packets to generate a fraction of redundant packets before applying the outer code encoding. Moreover, when the BP decoder stops, which may happen with a high probability when K is relatively small, it is possible to continue with inactivation decoding, where certain source packets are treated as inactive so that a similar belief propagation process can be resumed. The reader is referred to [RFC6330] for the design of a precode with a good inactivation decoding performance.
外側コードエンコーダーの次数分布DD（セクション3.2を参照）が適切に設計されている場合、BPデコーダーは、Kが大きいときに特定の分数の分数の回復の高い確率を保証します。すべてのソースパケットを回復するために、外部コードエンコードを適用する前に、冗長パケットのほんの一部を生成するために、Precodeをソースパケットに適用できます。さらに、Kが比較的小さい場合に高い確率で発生する可能性のあるBPデコーダーが停止すると、特定のソースパケットが非アクティブとして扱われ、同様の信念伝播プロセスを再開できるように継続することができます。読者は、優れた不活性化デコードパフォーマンスを備えたプレコードの設計について[RFC6330]に紹介されます。
The baseline BATS coding scheme described in Sections 2 and 3 needs various refinements and complements towards becoming a more sophisticated network communication application. Various related research issues are discussed in this section, but the security-related issues are left to Section 6.
セクション2および3で説明されているベースラインバットコーディングスキームは、より洗練されたネットワーク通信アプリケーションになることを補完するさまざまな改良と補完を必要としています。このセクションでは、さまざまな関連研究の問題について説明しますが、セキュリティ関連の問題はセクション6に任されています。
When the number of batches is sufficiently large, the BATS code specification in Section 3 has nearly optimal performance in the sense that the decoding can be successful with a high probability when the total rank of all the batches used for decoding is just slightly larger than the number of source packet K. But when K is small, the DegreeSampler function in Figure 7 and the BatchSampler function in Figure 6 based on a pseudorandom generator may not sample all the source packets evenly so that some of the source packets are not well protected. One approach to solve this issue is to generate a deterministic degree sequence when the number of batches is relatively small and design a special pseudorandom generator that has a good sampling performance when K is small.
バッチの数が十分に大きい場合、セクション3のBATSコード仕様は、デコードに使用されるすべてのバッチの総ランクがわずかに大きい場合に、高い確率でデコードが成功するという意味でほぼ最適なパフォーマンスがあります。ソースパケットKの数。ただし、Kが小さい場合、図7のDegreesampler関数と、擬似ランダム発電機に基づく図6のバッチサンプラー関数は、ソースパケットの一部が十分に保護されていないようにすべてのソースパケットを均等にサンプリングできない場合があります。この問題を解決するためのアプローチの1つは、バッチの数が比較的小さくなったときに決定論的度シーケンスを生成し、Kが小さいときに良いサンプリングパフォーマンスを持つ特別な擬似ランダムジェネレーターを設計することです。
There are research issues related to recoding discussed in Section 3.3. One question is how many recoded packets to generate for each batch. Though it is asymptotically optimal when using the same number of recoded packets for all batches, it has been shown that transmitting a different number of recoded packets for different batches can improve the recoding efficiency. For a batch with a lower rank, the intuition is that a smaller number of recoded packets need to be transmitted. This kind of recoding scheme is called adaptive recoding [Yin19].
セクション3.3で議論されている再記録に関連する研究の問題があります。質問の1つは、バッチごとに生成するパケットの数の数です。すべてのバッチに同じ数の再認めたパケットを使用する場合、漸近的に最適ですが、異なるバッチに異なる数の再認めたパケットを送信すると、復元効率を改善できることが示されています。ランクが低いバッチの場合、直感は、少ない数の再認定パケットを送信する必要があることです。この種のリクセディングスキームは、適応リコーディングと呼ばれます[yin19]。
Packet loss in network communication is usually bursty, which may harm the recoding performance. One way to resolve this issue is to transmit the packets of different batches in a mixed order, which is also called batch interleaving [Yin20]. How to efficiently interleave batches without increasing end-to-end latency too much is a research issue.
ネットワーク通信におけるパケット損失は通常、破裂しているため、再調整パフォーマンスに害を及ぼす可能性があります。この問題を解決する1つの方法は、異なるバッチのパケットを混合順序で送信することです。これは、バッチインターリーブとも呼ばれます[yin20]。エンドツーエンドのレイテンシを増やすことなくバッチを効率的にインターリーブする方法は、研究の問題です。
Though we only focus on the BATS coding scheme with one source node and one destination node, a BATS coding scheme can be used for multiple source and destination nodes. To benefit from multiple source nodes, we would need different source nodes to generate statistically independent batches. It is well-known that linear network coding [Li03] achieves the multicast capacity. BATS codes can benefit from network coding due to its inner code. For multicast, each destination node independently performs the same operations as described in this document, but the inner code should be improved to take multiple destination nodes into consideration. How to efficiently implement multicast needs further research.
1つのソースノードと1つの宛先ノードを使用したBATSコーディングスキームにのみ焦点を当てていますが、複数のソースノードと宛先ノードにBATSコーディングスキームを使用できます。複数のソースノードの恩恵を受けるには、統計的に独立したバッチを生成するために異なるソースノードが必要です。線形ネットワークコーディング[Li03]がマルチキャスト容量を達成することはよく知られています。BATSコードは、内部コードにより、ネットワークコーディングの恩恵を受けることができます。マルチキャストの場合、各宛先ノードはこのドキュメントで説明されているのと同じ操作を個別に実行しますが、複数の宛先ノードを考慮に入れるために内部コードを改善する必要があります。マルチキャストのニーズを効率的に実装する方法さらなる研究。
The baseline scheme in this document focuses on reliable communication. There are other issues to be considered towards designing a fully functional DDP based on a BATS coding scheme. Here, we discuss some network management issues that are closely related to a BATS coding scheme: routing, congestion control, and media access control.
このドキュメントのベースラインスキームは、信頼できるコミュニケーションに焦点を当てています。BATSコーディングスキームに基づいて、完全に機能するDDPの設計に考慮すべき他の問題があります。ここでは、BATSコーディングスキーム、ルーティング、渋滞制御、メディアアクセス制御に密接に関連するネットワーク管理の問題について説明します。
The outer code of a BATS code can be regarded as a channel code for the channel induced by the inner code, and hence, the network management algorithms should try to maximize the capacity of the channel induced by the inner code. A network utility maximization problem [Dong20] for BATS coding can be applied to study routing, congestion control, and media access control jointly. Compared with the network utility maximization for the Internet, there are two major differences. First, the network flow rate is not measured by the rate of the raw packets. Instead, a rank-based measurement induced by the inner code is applied for BATS coding schemes. Second, due to recoding, the raw packet rate may not be the same for different links of a flow, i.e., no flow conservation for BATS coding schemes. These differences affect both the objective and the constraints of the utility maximization problem.
BATSコードの外側コードは、内部コードによって誘導されるチャネルのチャネルコードと見なすことができます。したがって、ネットワーク管理アルゴリズムは、内部コードによって誘導されるチャネルの容量を最大化しようとする必要があります。コウモリのコーディングのネットワークユーティリティの最大化問題[DONG20]を適用して、ルーティング、混雑制御、メディアアクセス制御を共同で研究することができます。インターネットのネットワークユーティリティの最大化と比較して、2つの大きな違いがあります。まず、ネットワークの流量は、生のパケットの速度によって測定されません。代わりに、内側のコードによって誘導されるランクベースの測定が、コードコーディングスキームに適用されます。第二に、復旧のため、生のパケットレートは、フローの異なるリンクで同じではない場合があります。つまり、コウモリのコーディングスキームのフロー保存はありません。これらの違いは、ユーティリティの最大化問題の目的と制約の両方に影響します。
Practical congestion control, routing, and media access control algorithms for BATS coding schemes deserve more research efforts. The rate of transmitting batches can be controlled end-to-end. Due to the recoding operation, however, congestion control cannot be only performed end-to-end. The number of recoded packets generated for a batch must be controlled at the intermediate nodes, which introduces new research issues for congestion control. A BATS coding scheme is an extension of forward erasure correction coding. See [RFC9265] for more discussion of forward erasure correction coding and congestion control.
コウモリのコーディングスキームの実用的な混雑制御、ルーティング、およびメディアアクセス制御アルゴリズムは、より多くの研究努力に値します。送信バッチの速度は、エンドツーエンドを制御できます。ただし、操作が再生されているため、混雑制御はエンドツーエンドのみを実行することはできません。バッチ用に生成された再認定パケットの数は、中間ノードで制御する必要があります。これにより、混雑制御のための新しい研究問題が導入されます。コウモリのコーディングスキームは、前方消去補正コーディングの拡張です。前方消去補正のコーディングと輻輳制御の詳細については、[RFC9265]を参照してください。
For routing, the BATS coding scheme is flexible for implementing data transmission on multiple paths simultaneously. For unicast, it is optimal to transmit all the packets of a batch on the same path between the source node and the destination node, and for multicast, network coding gain can be obtained by transmitting packets of the same batch on different paths [Yang17]. Lastly, under the scenario of BATS coding schemes, media access control can have some different considerations: Retransmission is not necessary, and a reasonably high packet loss rate can be tolerated.
ルーティングの場合、BATSコーディングスキームは、複数のパスで同時にデータ送信を実装するために柔軟です。ユニキャストの場合、ソースノードと宛先ノードの間の同じパス上のバッチのすべてのパケットを送信することが最適です。マルチキャストの場合、ネットワークコーディングゲインは、異なるパスで同じバッチのパケットを送信することで取得できます[Yang17]。最後に、CODING CODING SCHEMSのシナリオでは、メディアアクセス制御にはいくつかの異なる考慮事項があります。再送信は必要ありません。合理的に高いパケット損失率は許容できます。
There are more research issues pertaining to various usage scenarios. The reliable communication technique provided by BATS codes can be used for a broad range of network communication scenarios. In general, a BATS coding scheme is suitable for data delivery in networks with multiple hops and unreliable links.
さまざまな使用シナリオに関連するより多くの研究問題があります。BATSコードによって提供される信頼できる通信手法は、幅広いネットワーク通信シナリオに使用できます。一般に、BATSコーディングスキームは、複数のホップと信頼性の低いリンクを備えたネットワークでのデータ配信に適しています。
One class of typical usage scenario is wireless mesh and ad hoc networks [Toh02], including vehicular networks, wireless sensor networks, smart lamppost networks, etc. These networks are characterized by a large number of network devices connected wirelessly with each other without a centralized network infrastructure. A BATS coding scheme is suitable for high data load delivery in such networks without the requirement that the point-to-point or one-hop communication is highly reliable. Therefore, employing a BATS coding scheme can provide more freedom for media access control, including power control, and physical-layer design so that the overall network throughput can be improved.
典型的な使用シナリオの1つのクラスは、車両ネットワーク、ワイヤレスセンサーネットワーク、スマートランプスポストネットワークなどを含むワイヤレスメッシュとアドホックネットワーク[TOH02]です。これらのネットワークは、集中化されずに互いにワイヤレスでワイヤレスで接続された多数のネットワークデバイスによって特徴付けられます。ネットワークインフラストラクチャ。BATSコーディングスキームは、ポイントツーポイントまたはワンホップ通信が非常に信頼性が高いことを要求することなく、そのようなネットワークでの高いデータ負荷配信に適しています。したがって、BATSコーディングスキームを採用することで、ネットワークスループット全体を改善できるように、パワーコントロールや物理レイヤー設計など、メディアアクセス制御により多くの自由を提供できます。
Another typical usage scenario of BATS coding schemes is underwater acoustic networks [Sprea19], where the propagation delay of acoustic waves underwater can be as long as several seconds. Due to the long delay, feedback-based mechanisms become inefficient. Moreover, point-to-point/one-hop underwater acoustic communication (for both the forward and reverse directions) is highly unreliable. Due to these reasons, the networking techniques developed for radio and wireline networks cannot be directly applied to underwater networks. As a BATS coding scheme does not rely on the feedback for reliability communication and can tolerate highly unreliable links, it makes a good candidate for developing data delivery protocols for underwater acoustic networks.
コウモリコーディングスキームのもう1つの典型的な使用シナリオは、水中音響ネットワーク[SPRA19]です。ここでは、水中の音波の伝播遅延は数秒も長くなります。長い遅延により、フィードバックベースのメカニズムは非効率的になります。さらに、ポイントツーポイント/ワンホップ水中音響通信（前方方向と逆方向の両方）は非常に信頼できません。これらの理由により、無線および有線ネットワーク向けに開発されたネットワーキング手法は、水中ネットワークに直接適用することはできません。BATSコーディングスキームは、信頼性通信のフィードバックに依存せず、非常に信頼性の低いリンクに耐えることができるため、水中音響ネットワークのデータ配信プロトコルを開発するための優れた候補になります。
Last but not least, due to its capability of performing multi-source, multi-destination communications, a BATS coding scheme can be applied in various content distribution scenarios. For example, a BATS coding scheme can be a candidate for the erasure code used in the liquid data networking framework [Byers20] of content-centric networking (CCN) and provides the extra benefit of network coding [Zhang16].
最後になりましたが、マルチソース、マルチデスティングコミュニケーションを実行する能力により、さまざまなコンテンツ配布シナリオにBATSコーディングスキームを適用できます。たとえば、BATSコーディングスキームは、コンテンツ中心のネットワーキング（CCN）の液体データネットワークフレームワーク[BYERS20]で使用される消去コードの候補になる可能性があり、ネットワークコーディング[Zhang16]の追加の利点を提供します。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
Subsuming both random linear network codes (RLNCs) and fountain codes, BATS codes naturally inherit both their desirable security capability of preventing eavesdropping as well as their vulnerability towards pollution attacks. In this section, we discuss some related research issues.
ランダムな線形ネットワークコード（RLNC）と噴水コードの両方を包含すると、コウモリコードは、盗聴を防ぐという望ましいセキュリティ能力と汚染攻撃に対する脆弱性の両方を自然に継承します。このセクションでは、いくつかの関連する研究の問題について説明します。
Suppose that an eavesdropper obtains a batch where the degree value d is strictly larger than the batch size M. Even if the eavesdropper has all the related encoding information, the system of linear equations related to this batch does not have a unique solution, and the probability that the eavesdropper can guess the d source packets used for encoding the batch correctly is 2^(-(d-M)T)<=2^(-T), where T is the number of octets of a source packet (see also [Bhattad07]). When inactivation decoding is applied, we can design the degree distribution DD so that the smallest degree is M+1 and hence prevent the eavesdropper from decoding source packets from individual batches.
盗聴者が次数値dがバッチサイズMより厳密に大きいバッチを取得すると仮定します。盗聴者が関連するすべてのエンコード情報を持っていても、このバッチに関連する線形方程式のシステムには一意のソリューションがなく、盗聴者がバッチを正しくエンコードするために使用されるdソースパケットを推測できる確率は2^（ - （d-m）t）<= 2^（ - t）です。ここで、tはソースパケットのオクテットの数です（[も参照」bhattad07]）。不活性化デコードが適用されると、次の度合いがM 1になるように等級分布DDを設計するため、盗聴者が個々のバッチからソースパケットを解読するのを防ぎます。
If we allow the eavesdropper to collect multiple batches and use inactivation decoding, the same security holds if the total rank of all the batches collected by the eavesdropper is less than the number of source packet. Therefore, if the DDP can manage to restrict the eavesdropper from collecting a sufficient number of coded packets, the security of BATS code is effective when T is sufficiently large. Here, by "intrinsic security", we mean the security protection provided by the BATS coding scheme without extra enhancement.
盗聴者が複数のバッチを収集し、不活性化デコードを使用できるようにすると、盗聴者によって収集されたすべてのバッチの総ランクがソースパケットの数よりも少ない場合と同じセキュリティが保持されます。したがって、DDPが十分な数のコード化されたパケットを収集することを盗聴者に制限できる場合、Tが十分に大きい場合、BATSコードのセキュリティは効果的です。ここでは、「本質的なセキュリティ」とは、追加の強化なしでコウモリコーディングスキームによって提供されるセキュリティ保護を意味します。
If the eavesdropper can collect a sufficient number of coded packets for correctly decoding, the intrinsic security of BATS code is ineffective. One solution in this case is to encrypt the whole data before using the BATS code scheme. Better schemes are desired towards reducing the computation cost of the whole data encryption solution. This is a research issue that depends on specific BATS code schemes and will not be further discussed here.
盗聴者が十分に数のコード化されたパケットを収集して正しくデコードできる場合、コウモリコードの固有のセキュリティは効果がありません。この場合の解決策の1つは、BATSコードスキームを使用する前に、データ全体を暗号化することです。データ暗号化ソリューション全体の計算コストを削減するために、より良いスキームが望まれます。これは、特定のBATSコードスキームに依存する研究問題であり、ここではこれ以上議論されません。
The threat exists for eavesdropping on the initial encoding process, which takes place at the encoding nodes. In these nodes, the transported data are presented in plain text and can be read along their transfer paths. Hence, information isolation between the encoding process and all other user processes running on the source node MUST be assured.
この脅威は、エンコードノードで行われる初期エンコードプロセスで盗聴されるために存在します。これらのノードでは、輸送されたデータはプレーンテキストで表示され、転送パスに沿って読み取ることができます。したがって、エンコードプロセスとソースノードで実行されている他のすべてのユーザープロセスとの間の情報分離を保証する必要があります。
In addition, the authenticity and trustworthiness of the encoding, recoding, and decoding program running on all the nodes MUST be attested by a trusted authority. Such a measure is also necessary in countering pollution attacks.
さらに、すべてのノードで実行されているエンコーディング、リコード、デコードプログラムの信頼性と信頼性は、信頼できる当局によって証明されなければなりません。このような措置は、汚染攻撃に対抗する際にも必要です。
A security issue closely related to eavesdropping is traffic analysis. Even when eavesdropping is prevented, tracking the traffic flow patterns can help an attacker to know certain information about the communication. Preventing traffic analysis is critical for communications that need to be anonymous. In [Fan09], an approach based on homomorphic encryption is proposed for network coding to prevent traffic analysis. However, homomorphic encryption could be too computationally expensive for practical applications and cannot help with the traffic analysis by monitoring the frequency and timing of network traffic.
盗聴に密接に関連するセキュリティの問題は、トラフィック分析です。盗聴が防止された場合でも、トラフィックフローパターンを追跡すると、攻撃者がコミュニケーションに関する特定の情報を知ることができます。トラフィック分析を防ぐことは、匿名である必要がある通信にとって重要です。[FAN09]では、トラフィック分析を防ぐために、ネットワークコーディングには準同型暗号化に基づくアプローチが提案されています。ただし、同型暗号化は、実用的なアプリケーションには計算上高すぎる可能性があり、ネットワークトラフィックの頻度とタイミングを監視することでトラフィック分析を助けることはできません。
The network traffic using network coding does not necessarily satisfy the flow conservation property, and hence, network coding can be used as a tool for defeating traffic analysis. For example, redundant network traffic can be generated by network coding to make it harder for an attacker to learn the true communication. Moreover, traffic analysis countermeasures can benefit from multipath communication [Yang15], and network coding makes multipath communication more flexible and efficient. Therefore, using network coding brings new research issues for both traffic analysis and its countermeasure.
ネットワークコーディングを使用したネットワークトラフィックは、必ずしもフロー保護プロパティを満たすわけではないため、ネットワークコーディングはトラフィック分析を打ち負かすためのツールとして使用できます。たとえば、ネットワークコーディングによって冗長ネットワークトラフィックを生成して、攻撃者が真のコミュニケーションを学習することを難しくすることができます。さらに、トラフィック分析対策は、マルチパス通信[YANG15]の恩恵を受けることができ、ネットワークコーディングにより、マルチパス通信がより柔軟で効率的になります。したがって、ネットワークコーディングを使用すると、トラフィック分析とその対策の両方に新しい研究の問題が発生します。
Like all network codes, BATS codes are vulnerable to pollution attacks. In these attacks, one or more compromised coding node(s) can pollute the coded messages by injecting forged packets into the network and thus prevent the receivers from recovering the transported data correctly. Moreover, a small number of polluted packets can infect a large number of packets by recoding and decoding [Zhao07].
すべてのネットワークコードと同様に、BATSコードは汚染攻撃に対して脆弱です。 これらの攻撃では、1つまたは複数の侵害されたコーディングノードが、鍛造パケットをネットワークに注入することにより、コード化されたメッセージを汚染し、受信機が輸送されたデータを正しく回復しないようにすることができます。 さらに、少数の汚染されたパケットは、[Zhao07]を再設計および解読することにより、多数のパケットに感染する可能性があります。
The research community has long been investigating the use of homomorphic signatures to identify the forged packets and stall the attacks (see [Zhao07], [Yu08], and [Agrawal09]). In these schemes, the source node attaches a signature to each packet to transmit, and the signature is allowed to be processed by network coding in the same way as the payload. All the intermediate nodes and the destination node can verify the signature attached to a received packet. However, these countermeasures are regarded as being too computationally expensive to be employed in broadband communications.
研究コミュニティは、鍛造パケットを特定して攻撃を停止するために、同性愛者の署名の使用を長い間調査してきました（[Zhao07]、[Yu08]、および[Agrawal09]を参照）。これらのスキームでは、ソースノードは各パケットに署名を添付して送信し、署名はペイロードと同じ方法でネットワークコーディングによって処理されます。すべての中間ノードと宛先ノードは、受信したパケットに添付された署名を確認できます。ただし、これらの対策は、ブロードバンド通信で採用するには計算上高すぎると見なされています。
A system-level approach based on trusted computing [TC-Wikipedia] can provide an alternative to protect BATS codes against pollution attacks. Trusted computing consists of software and hardware technologies so that a computer behaves as expected. Suppose that all the network nodes employ trusted computing. Two nodes will first gain trust with each other and then negotiate an authentication method for exchanging the coded packets of the BATS coding scheme. A network node would not use any packets received from other nodes without trust to avoid the pollution attack.
信頼できるコンピューティング[TC-Wikipedia]に基づくシステムレベルのアプローチは、汚染攻撃からコウモリのコードを保護する代替手段を提供できます。信頼できるコンピューティングは、ソフトウェアとハードウェアテクノロジーで構成されているため、コンピューターが予想どおりに動作します。すべてのネットワークノードが信頼できるコンピューティングを使用していると仮定します。2つのノードは最初に互いに信頼を獲得し、次にコードコードスキームのコード化されたパケットを交換するための認証方法を交渉します。ネットワークノードは、汚染攻撃を避けるために、信頼なしに他のノードから受信したパケットを使用しません。
[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>.
[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>.
[RFC8682] Saito, M., Matsumoto, M., Roca, V., Ed., and E. Baccelli,
"TinyMT32 Pseudorandom Number Generator (PRNG)", RFC 8682,
DOI 10.17487/RFC8682, January 2020,
<https://www.rfc-editor.org/info/rfc8682>.
[Agrawal09]
Agrawal, S. and D. Boneh, "Homomorphic MACs: MAC-Based
Integrity for Network Coding", International Conference on
Applied Cryptography and Network Security,
DOI 10.1007/978-3-642-01957-9_18, May 2009,
<https://doi.org/10.1007/978-3-642-01957-9_18>.
[Bhattad07]
Bhattad, K. and K. Narayanan, "Weakly Secure Network
Coding", April 2005.
[Byers20] Byers, J. and M. Luby, "Liquid Data Networking",
Proceedings of the 7th ACM Conference on Information-
Centric Networking, DOI 10.1145/3405656.3418710, September
2020, <https://doi.org/10.1145/3405656.3418710>.
[Dong20] Dong, Y., Jin, S., Yang, S., and H. Yin, "Network Utility
Maximization for BATS Code Enabled Multihop Wireless
Networks", ICC 2020 - 2020 IEEE International Conference
on Communications (ICC),
DOI 10.1109/ICC40277.2020.9148834, June 2020,
<https://doi.org/10.1109/ICC40277.2020.9148834>.
[Fan09] Yanfei, Y., Yixin, Y., Haojin, H., and X. Sherman, "An
Efficient Privacy-Preserving Scheme against Traffic
Analysis Attacks in Network Coding", IEEE INFOCOM 2009,
DOI 10.1109/INFCOM.2009.5062146, April 2009,
<https://doi.org/10.1109/INFCOM.2009.5062146>.
[Li03] Li, S.-Y., Yeung, R., and N. Cai, "Linear network coding",
IEEE Transactions on Information Theory,
DOI 10.1109/TIT.2002.807285, February 2003,
<https://doi.org/10.1109/TIT.2002.807285>.
[RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T.,
and L. Minder, "RaptorQ Forward Error Correction Scheme
for Object Delivery", RFC 6330, DOI 10.17487/RFC6330,
August 2011, <https://www.rfc-editor.org/info/rfc6330>.
[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>.
[Sprea19] Sprea, N., Bashir, M., Truhachev, D., Srinivas, K.,
Schlegel, C., and C. Sacchi, "BATS Coding for Underwater
Acoustic Communication Networks", OCEANS 2019 - Marseille,
DOI 10.1109/OCEANSE.2019.8867299, June 2019,
<https://doi.org/10.1109/OCEANSE.2019.8867299>.
[TC-Wikipedia]
Wikipedia, "Trusted Computing", April 2023,
<https://en.wikipedia.org/w/
index.php?title=Trusted_Computing&oldid=1151565594>.
[Toh02] Toh, C., "Ad Hoc Mobile Wireless Networks", Prentice Hall
Publishers, December 2001.
[Yang14] Yang, S. and R. Yeung, "Batched Sparse Codes", IEEE
Transactions on Information Theory, Vol. 60, Issue 9, pgs.
5322-5346, DOI 10.1109/TIT.2014.2334315, September 2014,
<https://doi.org/10.1109/TIT.2014.2334315>.
[Yang15] Yang, L. and F. Fengjun, "mTor: A multipath Tor routing
beyond bandwidth throttling", 2015 IEEE Conference on
Communications and Network Security (CNS),
DOI 10.1109/CNS.2015.7346860, September 2015,
<https://doi.org/10.1109/CNS.2015.7346860>.
[Yang17] Yang, S. and R. Yeung, "BATS Codes: Theory and Practice",
Morgan & Claypool Publishers, September 2017.
[Yin19] Yin, H., Tang, B., Ng, K., Yang, S., Wang, X., and Q.
Zhou, "A Unified Adaptive Recoding Framework for Batched
Network Coding", 2019 IEEE International Symposium on
Information Theory (ISIT), DOI 10.1109/ISIT.2019.8849277,
July 2019, <https://doi.org/10.1109/ISIT.2019.8849277>.
[Yin20] Yin, H., Yeung, R., and S. Yang, "A Protocol Design
Paradigm for Batched Sparse Codes", Entropy,
DOI 10.3390/e22070790, July 2020,
<https://doi.org/10.3390/e22070790>.
[Yu08] Yu, Z., Wei, Y., Ramkumar, B., and Y. Guan, "An Efficient
Signature-Based Scheme for Securing Network Coding Against
Pollution Attacks", IEEE INFOCOM 2008 - The 27th
Conference on Computer Communications,
DOI 10.1109/INFOCOM.2008.199, April 2008,
<https://doi.org/10.1109/INFOCOM.2008.199>.
[Zhang16] Zhang, G. and Z. Xu, "Combing CCN with network coding: An
architectural perspective", Computer Networks,
DOI 10.1016/j.comnet.2015.11.008, January 2016,
<https://doi.org/10.1016/j.comnet.2015.11.008>.
[Zhao07] Zhao, F., Kalker, T., Medard, M., and K. Han, "Signatures
for content distribution with network coding", 2007 IEEE
International Symposium on Information Theory,
DOI 10.1109/ISIT.2007.4557283, June 2007,
<https://doi.org/10.1109/ISIT.2007.4557283>.
The authors would like to thank the NWCRG chairs, Vincent Roca (our shepherd) and Marie-Jose Montpetit, as well as all those who provided comments, namely (in alphabetical order), Emmanuel Lochin, David Oran, and Colin Perkins.
著者は、NWCRGの椅子、ヴィンセント・ロカ（私たちの羊飼い）とマリー・ジョセ・モンペティット、つまり（アルファベット順）、エマニュエル・ロチン、デビッド・オラン、コリン・パーキンスを提供したすべての人々に感謝したいと思います。
Shenghao Yang
CUHK(SZ) & n-hop technologies
Shenzhen
Guangdong,
China
Phone: +86 755 8427 3827
Email: shyang@cuhk.edu.cn
Xuan Huang
CUHK
Hong Kong
Hong Kong SAR,
China
Phone: +852 3943 8375
Email: 1155136647@link.cuhk.edu.hk
Raymond W. Yeung
CUHK & n-hop technologies
Hong Kong
Hong Kong SAR,
China
Phone: +852 3943 8375
Email: whyeung@ie.cuhk.edu.hk
John K. Zao
CUHK
Hong Kong
Hong Kong SAR,
China
Phone: +852 3943 8346
Email: johnzao@ie.cuhk.edu.hk