[要約] RFC 9006は、インターネット・オブ・シングス(IoT)におけるTCPの使用に関するガイダンスを提供します。この文書の目的は、リソースが限られた環境でTCPを効果的に使用するための推奨事項を提供することです。利用場面には、省電力と信頼性の高い通信が求められるIoTデバイス間のデータ転送が含まれます。
Internet Engineering Task Force (IETF) C. Gomez
Request for Comments: 9006 UPC
Category: Informational J. Crowcroft
ISSN: 2070-1721 University of Cambridge
M. Scharf
Hochschule Esslingen
March 2021
TCP Usage Guidance in the Internet of Things (IoT)
物事のインターネットでのTCP使用上のガイダンス（IoT）
Abstract
概要
This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characteristic of the Internet of Things (IoT). Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding trade-offs. The objective is to help embedded developers with decisions on which TCP features to use.
この資料は、インターネットのインターネット（IoT）の特性である、制約ノードネットワーク（CNN）の伝送制御プロトコル（TCP）を実装して使用する方法に関するガイダンスを提供します。そのような環境では、軽量TCP実装が必要であり、オプションの機能を使用することはできません。この文書では、TCPスタックと対応するトレードオフを簡素化するための多数の既知のおよび展開されたテクニックについて説明します。目的は、TCP機能を使用する決定を備えた開発者を組み込み開発者に支援することです。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9006.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9006で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Characteristics of CNNs Relevant for TCP
2.1. Network and Link Properties
2.2. Usage Scenarios
2.3. Communication and Traffic Patterns
3. TCP Implementation and Configuration in CNNs
3.1. Addressing Path Properties
3.1.1. Maximum Segment Size (MSS)
3.1.2. Explicit Congestion Notification (ECN)
3.1.3. Explicit Loss Notifications
3.2. TCP Guidance for Single-MSS Stacks
3.2.1. Single-MSS Stacks -- Benefits and Issues
3.2.2. TCP Options for Single-MSS Stacks
3.2.3. Delayed Acknowledgments for Single-MSS Stacks
3.2.4. RTO Calculation for Single-MSS Stacks
3.3. General Recommendations for TCP in CNNs
3.3.1. Loss Recovery and Congestion/Flow Control
3.3.1.1. Selective Acknowledgments (SACKs)
3.3.2. Delayed Acknowledgments
3.3.3. Initial Window
4. TCP Usage Recommendations in CNNs
4.1. TCP Connection Initiation
4.2. Number of Concurrent Connections
4.3. TCP Connection Lifetime
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. TCP Implementations for Constrained Devices
A.1. uIP
A.2. lwIP
A.3. RIOT
A.4. TinyOS
A.5. FreeRTOS
A.6. uC/OS
A.7. Summary
Acknowledgments
Authors' Addresses
The Internet Protocol suite is being used for connecting Constrained-Node Networks (CNNs) to the Internet, enabling the so-called Internet of Things (IoT) [RFC7228]. In order to meet the requirements that stem from CNNs, the IETF has produced a suite of new protocols specifically designed for such environments (see, e.g., [RFC8352]). New IETF protocol stack components include the IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) adaptation layer [RFC4944][RFC6282][RFC6775], the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550], and the Constrained Application Protocol (CoAP) [RFC7252].
インターネットプロトコルスイートは、制約付きノードネットワーク（CNN）をインターネットに接続するために使用されており、いわゆるもののインターネット（IoT）[RFC7228]を有効にしています。CNNSから生じる要件を満たすために、IETFはそのような環境用に特別に設計されたスイートの新しいプロトコルを作成しました（例えば、[RFC8352]参照）。新しいIETFプロトコルスタックコンポーネントには、低電力無線パーソナルエリアネットワーク（6lowpans）適応レイヤ[RFC4944] [RFC6282] [RFC6775] [RFC6775]（RPL）[RFC6550]、および制約付きアプリケーションプロトコル（COAP）[RFC7252]。
As of this writing, the main transport-layer protocols in IP-based IoT scenarios are UDP and TCP. TCP has been criticized, often unfairly, as a protocol that is unsuitable for the IoT. It is true that some TCP features, such as relatively long header size, unsuitability for multicast, and always-confirmed data delivery, are not optimal for IoT scenarios. However, many typical claims on TCP unsuitability for IoT (e.g., a high complexity, connection-oriented approach incompatibility with radio duty-cycling and spurious congestion control activation in wireless links) are not valid, can be solved, or are also found in well-accepted IoT end-to-end reliability mechanisms (see a detailed analysis in [IntComp]).
この書き込みの時点で、IPベースのIOTシナリオの主なトランスポート層プロトコルはUDPとTCPです。TCPは、IoTには不適切なプロトコルとして、不当に批判されています。比較的長いヘッダーサイズ、マルチキャストの不適切性、常に確認されたデータ配信など、いくつかのTCP機能は、IOTシナリオにとって最適ではないことです。しかしながら、IoTのためのTCP不適切性（例えば、無線リンクにおける無線デューティサイクルおよびスプリアス輻輳制御の活性化との不適合性）のTCP不適切性に関する多くの典型的な特許請求の範囲は無効であり、また解決することができ、または順番にも見られる-Accepted IoTエンドツーエンドの信頼性メカニズム（[INTCOMP]の詳細な分析を参照）。
At the application layer, CoAP was developed over UDP [RFC7252]. However, the integration of some CoAP deployments with existing infrastructure is being challenged by middleboxes such as firewalls, which may limit and even block UDP-based communications. This is the main reason why a CoAP over TCP specification has been developed [RFC8323].
アプリケーション層では、UDP [RFC7252]でCOAPが開発されました。ただし、既存のインフラストラクチャとのいくつかのCOAP展開を統合することは、ファイアウォールなどのミドルボックスによって課題されています。これは、UDPベースの通信を制限し、さらにはブロックできます。これが、TCP仕様を超えるTCP仕様が開発された主な理由です[RFC8323]。
Other application-layer protocols not specifically designed for CNNs are also being considered for the IoT space. Some examples include HTTP/2 and even HTTP/1.1, both of which run over TCP by default [RFC7230] [RFC7540], and the Extensible Messaging and Presence Protocol (XMPP) [RFC6120]. TCP is also used by non-IETF application-layer protocols in the IoT space such as the Message Queuing Telemetry Transport (MQTT) [MQTT] and its lightweight variants.
IOT空間については、CNN用に特別に設計されていない他のアプリケーション層プロトコルも考慮されています。いくつかの例にはHTTP / 2、さらにはHTTP / 1.1が含まれ、どちらもデフォルトの[RFC7230] [RFC7540]、およびExtensible Messaging and Presence Protocol（XMPP）[RFC6120]を介してTCPを介して実行されます。TCPは、メッセージ待ちテレメトリトランスポート（MQTT）[MQTT]、およびその軽量の変形などのIOT空間内のIETFアプリケーション層プロトコルによっても使用されます。
TCP is a sophisticated transport protocol that includes optional functionality (e.g., TCP options) that may improve performance in some environments. However, many optional TCP extensions require complex logic inside the TCP stack and increase the code size and the memory requirements. Many TCP extensions are not required for interoperability with other standard-compliant TCP endpoints. Given the limited resources on constrained devices, careful selection of optional TCP features can make an implementation more lightweight.
TCPは、一部の環境でパフォーマンスを向上させる可能性があるオプションの機能（例えば、TCPオプション）を含む洗練されたトランスポートプロトコルです。ただし、多くのオプションのTCP拡張機能は、TCPスタック内で複雑なロジックを必要とし、コードサイズとメモリ要件を増やします。多くのTCP拡張機能は、他の標準準拠のTCPエンドポイントとの相互運用性には必要ありません。制約付きデバイス上のリソースが限られている場合、オプションのTCP機能を慎重に選択すると、実装をより軽量にすることができます。
This document provides guidance on how to implement and configure TCP and guidance on how applications should use TCP in CNNs. The overarching goal is to offer simple measures to allow for lightweight TCP implementation and suitable operation in such environments. A TCP implementation following the guidance in this document is intended to be compatible with a TCP endpoint that is compliant to the TCP standards, albeit possibly with a lower performance. This implies that such a TCP client would always be able to connect with a standard-compliant TCP server, and a corresponding TCP server would always be able to connect with a standard-compliant TCP client.
このドキュメントでは、アプリケーションがCNNでTCPを使用する方法に関するTCPとガイダンスの実装と設定方法に関するガイダンスを提供します。包括的な目標は、このような環境で軽量TCPの実装と適切な操作を可能にするための簡単な措置を提供することです。このドキュメントのガイダンスに続くTCP実装は、おそらく低い性能を持つ可能性があるが、TCP規格に準拠しているTCPエンドポイントと互換性があることを意図しています。これは、そのようなTCPクライアントが常に標準準拠のTCPサーバと接続できることを意味し、対応するTCPサーバは常に標準準拠のTCPクライアントと接続できることを意味します。
This document assumes that the reader is familiar with TCP. A comprehensive survey of the TCP standards can be found in RFC 7414 [RFC7414]. Similar guidance regarding the use of TCP in special environments has been published before, e.g., for cellular wireless networks [RFC3481].
この文書はリーダーがTCPに精通していると想定しています。TCP規格の包括的な調査は、RFC 7414 [RFC7414]にあります。特別な環境におけるTCPの使用に関する同様のガイダンスは、例えば、セルラーワイヤレスネットワークの場合は、RFC3481のために公開されています。
CNNs are defined in [RFC7228] as networks whose characteristics are influenced by being composed of a significant portion of constrained nodes. The latter are characterized by significant limitations on processing, memory, and energy resources, among others [RFC7228]. The first two dimensions pose constraints on the complexity and memory footprint of the protocols that constrained nodes can support. The latter requires techniques to save energy, such as radio duty-cycling in wireless devices [RFC8352] and the minimization of the number of messages transmitted/received (and their size).
CNNは、特性が制約されたノードのかなりの部分からなることによって影響を受けるネットワークとして[RFC7228]で定義されています。後者は、とりわけ、処理、メモリ、およびエネルギー資源に関する重大な制限を特徴としています[RFC7228]。最初の2次元は、制約されたノードがサポートできるプロトコルの複雑さとメモリフットプリントに対する制約を維持します。後者は、無線装置[RFC8352]の無線デューティサイクリングなどのエネルギーを節約するための技術と、送受信されるメッセージの数の最小化（およびそれらのサイズ）を必要とする。
[RFC7228] lists typical network constraints in CNNs, including low achievable bitrate/throughput, high packet loss and high variability of packet loss, highly asymmetric link characteristics, severe penalties for using larger packets, limits on reachability over time, etc. CNNs may use wireless or wired technologies (e.g., Power Line Communication), and the transmission rates are typically low (e.g., below 1 Mbps).
[RFC7228]は、低達成可能なビットレート/スループット、高いパケット損失、パケット損失の高いパケット損失、および高いパケット損失、高いパケットの使用、より大きなパケットの使用のための重度のペナルティ、時間の経過とともに制限など、CNNの典型的なネットワーク制約を示しています。無線または有線技術（例えば、電力線通信）、および伝送速度は典型的には低い（例えば、1Mbps未満）。
For use of TCP, one challenge is that not all technologies in a CNN may be aligned with typical Internet subnetwork design principles [RFC3819]. For instance, constrained nodes often use physical- / link-layer technologies that have been characterized as 'lossy', i.e., exhibit a relatively high bit error rate. Dealing with corruption loss is one of the open issues in the Internet [RFC6077].
TCPの使用のために、1つの課題は、CNN内のすべての技術が典型的なインターネットサブネットワーク設計原則と整列されているわけではないことがわかります[RFC3819]。例えば、制約されたノードは、「非可逆」として特徴付けられた物理/リンク層技術を使用することがよくあり、すなわち比較的高いビットの誤り率を示す。腐敗損失を扱うことは、インターネットの開かれた問題の1つです[RFC6077]。
There are different deployment and usage scenarios for CNNs. Some CNNs follow the star topology, whereby one or several hosts are linked to a central device that acts as a router connecting the CNN to the Internet. Alternatively, CNNs may also follow the multihop topology [RFC6606].
CNNSのためのさまざまな展開シナリオがあります。一部のCNNはスタートポロジに従います。これにより、1つまたは複数のホストがCNNをインターネットに接続するルータとして機能する中央デバイスにリンクされています。あるいは、CNNはマルチホップトポロジー[RFC6606]に従うこともできる。
In constrained environments, there can be different types of devices [RFC7228]. For example, there can be devices with a single combined send/receive buffer, a separate send and receive buffer, or a pool of multiple send/receive buffers. In the latter case, it is possible that buffers are also shared for other protocols.
制約付き環境では、さまざまな種類のデバイスがあります[RFC7228]。例えば、単一の組み合わされた送信/受信バッファ、個別の送信および受信バッファ、または複数の送信/受信バッファのプールを有する装置があり得る。後者の場合、バッファは他のプロトコルとも共有される可能性があります。
One key use case for TCP in CNNs is a model where constrained devices connect to unconstrained servers in the Internet. But it is also possible that both TCP endpoints run on constrained devices. In the first case, communication will possibly traverse a middlebox (e.g., a firewall, NAT, etc.). Figure 1 illustrates such a scenario. Note that the scenario is asymmetric, as the unconstrained device will typically not suffer the severe constraints of the constrained device. The unconstrained device is expected to be mains-powered, have a high amount of memory and processing power, and be connected to a resource-rich network.
CNNSのTCPの1つのキーユースケースは、制約付きデバイスがインターネット内の制約されていないサーバーに接続するモデルです。しかし、TCPエンドポイントの両方が制約付きデバイス上で実行される可能性もあります。第1の場合において、通信はミドルボックス（例えば、ファイアウォール、NATなど）を通過する可能性がある。図1はそのようなシナリオを示しています。制約されていないデバイスは、通常、制約されたデバイスの厳しい制約を受けないように、シナリオは非対称です。制約されていないデバイスは主電源であると予想され、大量のメモリおよび処理電力を有し、リソースに富むネットワークに接続されます。
Assuming that a majority of constrained devices will correspond to sensor nodes, the amount of data traffic sent by constrained devices (e.g., sensor node measurements) is expected to be higher than the amount of data traffic in the opposite direction. Nevertheless, constrained devices may receive requests (to which they may respond), commands (for configuration purposes and for constrained devices including actuators), and relatively infrequent firmware/software updates.
拘束されたデバイスの大部分がセンサノードに対応すると仮定すると、制約付きデバイスによって送信されたデータトラフィックの量（例えば、センサノード測定）は、反対方向のデータトラフィックの量よりも多いと予想される。それにもかかわらず、制約付きデバイスは、（それらが応答する可能性がある）、コマンド（設定目的およびアクチュエータを含む制約付きデバイスのために）、および比較的まれなファームウェア/ソフトウェアの更新を受信することができる。
+---------------+
o o <-------- TCP communication -----> | |
o o | |
o o | Unconstrained |
o o +-----------+ | device |
o o o ------ | Middlebox | ------- | |
o o +-----------+ | (e.g., cloud) |
o o o | |
+---------------+
Constrained devices
Figure 1: TCP Communication between a Constrained Device and an Unconstrained Device, Traversing a Middlebox
図1：制約付きデバイスと制約のないデバイス間のTCP通信、ミドルボックスを横断する
IoT applications are characterized by a number of different communication patterns. The following non-comprehensive list explains some typical examples:
IOTアプリケーションは、さまざまな通信パターンを特徴としています。以下の非包括的なリストは、いくつかの典型的な例を説明しています。
Unidirectional transfers: An IoT device (e.g., a sensor) can (repeatedly) send updates to the other endpoint. There is not always a need for an application response back to the IoT device.
一方向転送：IoT装置（例えば、センサ）は（繰り返し）更新を他のエンドポイントに送信することができる。アプリケーション応答がIOTデバイスに戻す必要性が常に必要とされない。
Request-response patterns: An IoT device receiving a request from the other endpoint, which triggers a response from the IoT device.
要求応答パターン：他のエンドポイントから要求を受信するIOTデバイスは、IOTデバイスからの応答をトリガします。
Bulk data transfers: A typical example for a long file transfer would be an IoT device firmware update.
バルクデータ転送：長いファイル転送の典型的な例はIOTデバイスファームウェアアップデートになります。
A typical communication pattern is that a constrained device communicates with an unconstrained device (cf. Figure 1). But it is also possible that constrained devices communicate amongst themselves.
典型的な通信パターンは、制約されていないデバイスが制約されていないデバイスと通信することである（図1）。しかし、制約付きデバイスが自分の間で通信することも可能です。
This section explains how a TCP stack can deal with typical constraints in CNN. The guidance in this section relates to the TCP implementation and its configuration.
このセクションでは、TCPスタックがCNN内の一般的な制約にどのように対処できるかについて説明します。このセクションのガイダンスは、TCP実装とその構成に関するものです。
Assuming that IPv6 is used, and for the sake of lightweight implementation and operation, unless applications require handling large data units (i.e., leading to an IPv6 datagram size greater than 1280 bytes), it may be desirable to limit the IP datagram size to 1280 bytes in order to avoid the need to support Path MTU Discovery [RFC8201]. In addition, an IP datagram size of 1280 bytes avoids incurring IPv6-layer fragmentation [RFC8900].
IPv6が使用されていると仮定して、アプリケーションが大規模なデータユニットを処理する必要がある（すなわち、1280バイトを超えるIPv6データグラムサイズにつながる）ことがない限り、IPデータグラムサイズを1280に制限することが望ましいかもしれません。PATU Discovery [RFC8201]をサポートする必要性を避けるためのバイト。さらに、1280バイトのIPデータグラムサイズがIPv6層のフラグメンテーション[RFC8900]を招くことを回避します。
An IPv6 datagram size exceeding 1280 bytes can be avoided by setting the TCP MSS to 1220 bytes or less. Note that it is already a requirement for TCP implementations to consume payload space instead of increasing datagram size when including IP or TCP options in an IP packet to be sent [RFC6691]. Therefore, it is not required to advertise an MSS smaller than 1220 bytes in order to accommodate TCP options.
TCP MSを1220バイト以下に設定することで、1280バイトを超えるIPv6データグラム・サイズを回避できます。送信されるIPパケット内のIPまたはTCPオプションを含めたときにデータグラム・サイズを増やすのではなく、TCP実装の要件はすでに必要です。したがって、TCPオプションに対応するために、1220バイトより小さいMSSをアドバタイズする必要はありません。
Note that setting the MTU to 1280 bytes is possible for link-layer technologies in the CNN space, even if some of them are characterized by a short data unit payload size, e.g., up to a few tens or hundreds of bytes. For example, the maximum frame size in IEEE 802.15.4 is 127 bytes. 6LoWPAN defined an adaptation layer to support IPv6 over IEEE 802.15.4 networks. The adaptation layer includes a fragmentation mechanism, since IPv6 requires the layer below to support an MTU of 1280 bytes [RFC8200], while IEEE 802.15.4 lacks fragmentation mechanisms. 6LoWPAN defines an IEEE 802.15.4 link MTU of 1280 bytes [RFC4944]. Other technologies, such as Bluetooth low energy [RFC7668], ITU-T G.9959 [RFC7428], or Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) [RFC8105], also use 6LoWPAN-based adaptation layers in order to enable IPv6 support. These technologies do support link-layer fragmentation. By exploiting this functionality, the adaptation layers that enable IPv6 over such technologies also define an MTU of 1280 bytes.
MTUを1280バイトに設定することは、CNN空間内のリンクレイヤテクノロジで、それらのいくつかが短いデータユニットペイロードサイズ、例えば数十億または数百バイトである。たとえば、IEEE 802.15.4の最大フレームサイズは127バイトです。 6LOWPANは、IEEE 802.15.4ネットワーク上のIPv6をサポートするための適応層を定義しました。 IPv6は1280バイト[RFC8200]のMTUをサポートするために下のレイヤを必要とするので、適応層はフラグメンテーションメカニズムを含み、IEEE 802.15.4は断片化メカニズムを欠いている。 6LOWPANは、1280バイトのIEEE 802.15.4リンクMTUを定義します[RFC4944]。 Bluetooth Low Energy [RFC7668]、ITU-T G.9959 [RFC7428]、またはデジタル強化コードレス電気通信（DECT）超低エネルギー（ULE）[RFC8105]などの他のテクノロジ。 IPv6サポートを有効にします。これらの技術はリンク層の断片化をサポートしています。この機能を利用することで、そのようなテクノロジを介してIPv6を有効にする適応レイヤは1280バイトのMTUを定義します。
On the other hand, there exist technologies also used in the CNN space, such as Master Slave (MS) / Token Passing (TP) [RFC8163], Narrowband IoT (NB-IoT) [RFC8376], or IEEE 802.11ah [6LO-WLANAH], that do not suffer the same degree of frame size limitations as the technologies mentioned above. It is recommended that the MTU for MS/ TP be 1500 bytes [RFC8163]; the MTU in NB-IoT is 1600 bytes, and the maximum frame payload size for IEEE 802.11ah is 7991 bytes.
一方、マスタースレーブ（MS）/トークン通過（TP）[RFC8163]、狭帯域IOT（NB-IOT）[RFC8376]、またはIEEE 802.11AHのようなCNN空間でも使用されている技術が存在しています[610]上記の技術と同じ程度のフレームサイズの制限を受けていないWlanah]。MS / TPのMTUが1500バイト[RFC8163]にすることをお勧めします。NB-IOTのMTUは1600バイトで、IEEE 802.11AHの最大フレームペイロードサイズは7991バイトです。
Using a larger MSS (to a suitable extent) may be beneficial in some scenarios, especially when transferring large payloads, as it reduces the number of packets (and packet headers) required for a given payload. However, the characteristics of the constrained network need to be considered. In particular, in a lossy network where unreliable fragment delivery is used, the amount of data that TCP unnecessarily retransmits due to fragment loss increases (and throughput decreases) quickly with the MSS. This happens because the loss of a fragment leads to the loss of the whole fragmented packet being transmitted. Unnecessary data retransmission is particularly harmful in CNNs due to the resource constraints of such environments. Note that, while the original 6LoWPAN fragmentation mechanism [RFC4944] does not offer reliable fragment delivery, fragment recovery functionality for 6LoWPAN or 6Lo environments has been standardized [RFC8931].
より大きなMSを（適切な範囲に）を使用すると、特に大きなペイロードを転送するときに、特に大きなペイロードを転送するときには、所与のペイロード（およびパケットヘッダ）が減少するときに、いくつかのシナリオで有益であり得る。しかしながら、制約されたネットワークの特性を考慮する必要がある。特に、信頼性の低いフラグメント配信が使用されている損失のあるネットワークでは、TCPがフラグメント損失のために不必要に再送信するデータの量は、MSSと急速に増加する（およびスループットは減少します）。これは、フラグメントの損失が送信されている断片化されたパケット全体の損失をもたらすために発生します。不要なデータ再送信は、そのような環境のリソースの制約のためにCNNに特に有害です。オリジナルの6LOWPANフラグメンテーションメカニズム[RFC4944]は信頼できるフラグメント配信を提供していないが、6LOWPANまたは6LO環境のフラグメントリカバリ機能が標準化されている[RFC8931]。
ECN [RFC3168] allows a router to signal in the IP header of a packet that congestion is rising, for example, when a queue size reaches a certain threshold. An ECN-enabled TCP receiver will echo back the congestion signal to the TCP sender by setting a flag in its next TCP Acknowledgment (ACK). The sender triggers congestion control measures as if a packet loss had happened.
ECN [RFC3168]は、キューサイズが特定のしきい値に達すると、輻輳が増加しているパケットのIPヘッダー内でルータが信号を送信できます。ECN対応TCP受信機は、次のTCP確認応答（ACK）にフラグを設定することによって、輻輳信号をTCP送信側にエコーバックします。送信者は、パケット損失が発生したかのように輻輳制御尺度を引き起こします。
RFC 8087 [RFC8087] outlines the principal gains in terms of increased throughput, reduced delay, and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking. In the context of CNNs, a remarkable feature of ECN is that congestion can be signaled without incurring packet drops (which will lead to retransmissions and consumption of limited resources such as energy and bandwidth).
RFC 8087 [RFC8087]は、輻輳経験豊富なマーキングをサポートする機器を含むネットワーク経路を介してECNが使用されている場合のスループット、減少した遅延、およびその他の利点の点で主な利益を概説しています。CNNSの文脈では、ECNの注目に値する特徴は、輻輳がパケット滴を発生させることなくシグナリングできることです（それはエネルギーや帯域幅などのリソースの限られたリソースの消費につながります）。
ECN can further reduce packet losses since congestion control measures can be applied earlier [RFC2884]. Fewer lost packets implies that the number of retransmitted segments decreases, which is particularly beneficial in CNNs, where energy and bandwidth resources are typically limited. Also, it makes sense to try to avoid packet drops for transactional workloads with small data sizes, which are typical for CNNs. In such traffic patterns, it is more difficult and often impossible to detect packet loss without retransmission timeouts (e.g., as there may not be three duplicate ACKs). Any retransmission timeout slows down the data transfer significantly. In addition, if the constrained device uses power-saving techniques, a retransmission timeout will incur a wake-up action, in contrast to ACK clock-triggered sending. When the congestion window of a TCP sender has a size of one segment and a TCP ACK with an ECN signal (ECN-Echo (ECE) flag) arrives at the TCP sender, the TCP sender resets the retransmit timer, and the sender will only be able to send a new packet when the retransmit timer expires. Effectively, at that moment, the TCP sender reduces its sending rate from 1 segment per Round-Trip Time (RTT) to 1 segment per Retransmission Timeout (RTO) and reduces the sending rate further on each ECN signal received in subsequent TCP ACKs. Otherwise, if an ECN signal is not present in a subsequent TCP ACK, the TCP sender resumes the normal ACK-clocked transmission of segments [RFC3168].
輻輳制御措置を早期に適用できるため、ECNはさらにパケット損失を減らすことができます[RFC2884]。紛失したパケットが少ないことは、再送信されたセグメントの数が減少することを意味します。また、CNNに典型的な小さなデータサイズのトランザクションワークロードのパケットドロップを回避することを理解しています。そのようなトラフィックパターンでは、再送タイムアウトなしにパケット損失を検出することが困難でしばしば不可能であり、（例えば、3つの重複していない可能性がある。）。再送タイムアウトは、データ転送を大幅に遅くします。さらに、制約付きデバイスが省電力技術を使用している場合、ACKクロックトリガ送信とは対照的に、再送信タイムアウトが起動アクションを発生させます。 TCP送信側の輻輳ウィンドウが1つのセグメントのサイズを持ち、ECN信号（ECN-ECHO（ECE）フラグ）のTCP ACKがTCP送信側に到着すると、TCP送信者は再送信タイマーをリセットし、送信者はのみ再送信タイマが期限切れになると、新しいパケットを送信できるようになります。効果的に、その瞬間、TCP送信者は、再送タイムアウトあたり1セグメント（RTT）から1セグメント（RTO）に1セグメントから1セグメントまで減少し、後続のTCP ACKで受信された各ECN信号でさらに送信レートを短縮します。そうではなく、ECN信号が後続のTCP ACKに存在しない場合、TCP送信側はセグメントの通常のACKクロック送信送信を再開する[RFC3168]。
ECN can be incrementally deployed in the Internet. Guidance on configuration and usage of ECN is provided in RFC 7567 [RFC7567]. Given the benefits, more and more TCP stacks in the Internet support ECN, and it makes sense to specifically leverage ECN in controlled environments such as CNNs. As of this writing, there is ongoing work to extend the types of TCP packets that are ECN capable, including pure ACKs [TCPM-ECN]. Such a feature may further increase the benefits of ECN in CNN environments. Note, however, that supporting ECN increases implementation complexity.
ECNはインターネットに増分的に展開できます。RFC 7567 [RFC7567]には、ECNの設定と使用に関するガイダンスが提供されています。インターネットサポートECN内の利点、ますます多くのTCPスタックを考えると、CNNのような制御された環境でECNを特に活用することは理にかなっています。この書き込みの時点で、純粋なACKS [TCPM-ECN]を含むECN対応のTCPパケットの種類を拡張するための継続的な作業があります。そのような特徴は、CNN環境におけるECNの利点をさらに増加させるかもしれない。ただし、ECNをサポートすると、実装の複雑さが向上します。
There has been a significant body of research on solutions capable of explicitly indicating whether a TCP segment loss is due to corruption, in order to avoid activation of congestion control mechanisms [ETEN] [RFC2757]. While such solutions may provide significant improvement, they have not been widely deployed and remain as experimental work. In fact, as of today, the IETF has not standardized any such solution.
輻輳制御メカニズムの活性化を回避するために、TCPセグメントの損失が破損によるものかどうかを明示的に示すことができる解決策についての重要な研究が行われています[RFC2757]。そのような解決策は大きな改善をもたらすかもしれませんが、それらは広く展開されていないこと、そして実験的な仕事として残る。実際、今日の時点で、IETFはそのような解決策を標準化していません。
This section discusses TCP stacks that allow transferring a single MSS. More general guidance is provided in Section 3.3.
このセクションでは、単一のMSSを転送できるTCPスタックについて説明します。3.3セクション3.3では、より一般的なガイダンスが提供されています。
A TCP stack can reduce the memory requirements by advertising a TCP window size of 1 MSS and also transmit, at most, 1 MSS of unacknowledged data. In that case, both congestion and flow control implementation are quite simple. Such a small receive and send window may be sufficient for simple message exchanges in the CNN space. However, only using a window of 1 MSS can significantly affect performance. A stop-and-wait operation results in low throughput for transfers that exceed the length of 1 MSS, e.g., a firmware download. Furthermore, a single-MSS solution relies solely on timer-based loss recovery, therefore missing the performance gain of Fast Retransmit and Fast Recovery (which requires a larger window size; see Section 3.3.1).
TCPスタックは、1msのTCPウィンドウサイズを広告し、最大1ミリ秒の未確認データを送信することによってメモリ要件を減らすことができる。その場合、輻輳とフロー制御の両方の実装は非常に簡単です。そのような小さい受信および送信ウィンドウは、CNN空間内の単純なメッセージ交換には十分であり得る。ただし、1ミリ秒のウィンドウを使用するだけで、パフォーマンスに大きな影響を与える可能性があります。ストップアンドウェイト操作は、1msの長さを超える転送、例えばファームウェアのダウンロードを実行するためのスループットをもたらす。さらに、単一MSSソリューションはタイマーベースの損失回復のみに依存しているため、高速再送信と高速回復のパフォーマンスゲイン（より大きなウィンドウサイズが必要です。セクション3.3.1を参照）。
If CoAP is used over TCP with the default setting for NSTART in RFC 7252 [RFC7252], a CoAP endpoint is not allowed to send a new message to a destination until a response for the previous message sent to that destination has been received. This is equivalent to an application-layer window size of 1 data unit. For this use of CoAP, a maximum TCP window of 1 MSS may be sufficient, as long as the CoAP message size does not exceed 1 MSS. An exception in CoAP over TCP, though, is the Capabilities and Settings Message (CSM) that must be sent at the start of the TCP connection. The first application message carrying user data is allowed to be sent immediately after the CSM message. If the sum of the CSM size plus the application message size exceeds the MSS, a sender using a single-MSS stack will need to wait for the ACK confirming the CSM before sending the application message.
RFC 7252 [RFC7252]のNSTARTのデフォルト設定でCOAPを介してCOAPを使用している場合、その宛先に送信された前のメッセージに対する応答が受信されるまで、COAPエンドポイントが宛先に新しいメッセージを送信することはできません。これは、1データ単位のアプリケーション層ウィンドウサイズと同じです。COAPの使用の使用では、COAPメッセージサイズが1msを超えない限り、1msの最大TCPウィンドウでもよい。ただし、TCPを介したCOAPの例外は、TCP接続の開始時に送信されなければならない機能と設定メッセージ（CSM）です。ユーザデータを運ぶ最初のアプリケーションメッセージは、CSMメッセージの直後に送信されることが許可されています。CSMサイズとアプリケーションメッセージサイズの合計がMSSを超えると、シングルMSSスタックを使用する送信者は、アプリケーションメッセージを送信する前にCSMの確認を確認するのを待つ必要があります。
A TCP implementation needs to support, at a minimum, TCP options 2, 1, and 0. These are, respectively, the MSS option, the No-Operation option, and the End Of Option List marker [RFC0793]. None of these are a substantial burden to support. These options are sufficient for interoperability with a standard-compliant TCP endpoint, albeit many TCP stacks support additional options and can negotiate their use. A TCP implementation is permitted to silently ignore all other TCP options.
TCP実装は、最小限のTCPオプション2,1、および0でサポートする必要があります。これらはそれぞれ、MSSオプション、無効オプション、およびオプションリストマーカー[RFC0793]です。これらのどれもサポートするかなりの負担はありません。これらのオプションは、多くのTCPスタックが追加のオプションをサポートし、それらの使用を交渉することができますが、標準準拠のTCPエンドポイントとの相互運用性に十分です。TCP実装は、他のすべてのTCPオプションを静かに無視することを許可されています。
A TCP implementation for a constrained device that uses a single-MSS TCP receive or transmit window size may not benefit from supporting the following TCP options: Window Scale [RFC7323], TCP Timestamps [RFC7323], Selective Acknowledgment (SACK) [RFC2018], and SACK-Permitted [RFC2018]. Also, other TCP options may not be required on a constrained device with a very lightweight implementation. With regard to the Window Scale option, note that it is only useful if a window size greater than 64 kB is needed.
シングルMSS TCP受信または送信ウィンドウサイズを使用する制約付きデバイスのTCP実装は、次のTCPオプションをサポートするのに役立ちません。ウィンドウスケール[RFC7323]、TCPタイムスタンプ[RFC7323]、選択認識（SACK）[RFC2018]、そして袋許可[RFC2018]。また、非常に軽量の実装を備えた制約付きデバイスに他のTCPオプションが必要とされない場合があります。ウィンドウスケールオプションに関しては、64 KBを超えるウィンドウサイズが必要な場合にのみ役立ちます。
Note that a TCP sender can benefit from the TCP Timestamps option [RFC7323] in detecting spurious RTOs. The latter are quite likely to occur in CNN scenarios due to a number of reasons (e.g., route changes in a multihop scenario, link-layer retries, etc.). The header overhead incurred by the Timestamps option (of up to 12 bytes) needs to be taken into account.
TCP送信者は、スプリアスRTOSを検出する際のTCPタイムスタンプオプション[RFC7323]から利益を得ることができます。後者は、いくつかの理由から（例えば、マルチホップシナリオ、リンク層再試行などの経路の変化）のために、CNNシナリオでは非常に起こる可能性が高い。timestampsオプション（最大12バイト）によって発生したヘッダーオーバーヘッドを考慮する必要があります。
TCP Delayed Acknowledgments are meant to reduce the number of ACKs sent within a TCP connection, thus reducing network overhead, but they may increase the time until a sender may receive an ACK. In general, usefulness of Delayed ACKs depends heavily on the usage scenario (see Section 3.3.2). There can be interactions with single-MSS stacks.
TCP遅延確認応答は、TCP接続内で送信されたACKの数を減らすことを意味し、したがってネットワークオーバーヘッドを削減するが、送信者がACKを受信するまでの時間を長くすることができる。一般に、遅延ACKの有用性は使用シナリオに大きく依存します（セクション3.3.2を参照）。シングルMSSスタックとの相互作用がある可能性があります。
When traffic is unidirectional, if the sender can send at most 1 MSS of data or the receiver advertises a receive window not greater than the MSS, Delayed ACKs may unnecessarily contribute delay (up to 500 ms) to the RTT [RFC5681], which limits the throughput and can increase data delivery time. Note that, in some cases, it may not be possible to disable Delayed ACKs. One known workaround is to split the data to be sent into two segments of smaller size. A standard-compliant TCP receiver may immediately acknowledge the second MSS of data, which can improve throughput. However, this "split hack" may not always work since a TCP receiver is required to acknowledge every second full-sized segment, but not two consecutive small segments. The overhead of sending two IP packets instead of one is another downside of the "split hack".
トラフィックが一方向の場合、送信者が最大1ミリ秒のデータで送信できる場合、または受信側はMSS以下の受信ウィンドウをアドバタイズすると、RTT [RFC5681]に遅延ACKが遅延（最大500 ms）に貢献する可能性があります。スループットとデータ送達時間を増やすことができます。なお、場合によっては、遅延ACKを無効にすることは不可能である可能性があることに注意してください。1つの既知の回避策は、データを小さいサイズの2つのセグメントに分割することです。標準準拠のTCP受信機は、直ちにデータの第2のMSSを確認することができ、これはスループットを改善することができる。ただし、この「分割ハック」は、TCP受信機が毎秒ごとに承認する必要があるが、2つの連続した小セグメントを承認する必要があるため、常に機能するとは限らない。1つの代わりに2つのIPパケットを送信するオーバーヘッドは、「スプリットハック」のもう一つの下側です。
Similar issues may happen when the sender uses the Nagle algorithm, since the sender may need to wait for an unnecessarily Delayed ACK to send a new segment. Disabling the algorithm will not have impact if the sender can only handle stop-and-wait operation at the TCP level.
送信者が不必要に遅延されたACKを送信して新しいセグメントを送信するのを待つ必要があるため、送信者がNagleアルゴリズムを使用するときに同様の問題が発生する可能性があります。送信者がTCPレベルでの停止および待機操作のみを処理できる場合、アルゴリズムを無効にすると、影響はありません。
For request-response traffic, when the receiver uses Delayed ACKs, a response to a data message can piggyback an ACK, as long as the latter is sent before the Delayed ACK timer expires, thus avoiding unnecessary ACKs without payload. Disabling Delayed ACKs at the request sender allows an immediate ACK for the data segment carrying the response.
要求応答トラフィックの場合、受信機が遅延ACKを使用すると、後者が遅延ACKタイマーが満了する前に送信される限り、データメッセージへの応答がACKにピギーバックすることができ、したがってペイロードなしで不要なACKを回避することができる。リクエスト送信者で遅延ACKを無効にすると、応答を伝送するデータセグメントに即時のACKが可能になります。
The RTO calculation is one of the fundamental TCP algorithms [RFC6298]. There is a fundamental trade-off: a short, aggressive RTO behavior reduces wait time before retransmissions, but it also increases the probability of spurious timeouts. The latter leads to unnecessary waste of potentially scarce resources in CNNs such as energy and bandwidth. In contrast, a conservative timeout can result in long error recovery times and, thus, needlessly delay data delivery.
RTO計算は、基本的なTCPアルゴリズム[RFC6298]の1つです。基本的なトレードオフがあります。短い、積極的なRTOの行動は再送信の前の待ち時間を短縮しますが、スプリアスタイムアウトの可能性も高まります。後者は、エネルギーや帯域幅などのCNNにおける潜在的に乏しいリソースの不要な浪費をもたらします。対照的に、保守的なタイムアウトは、長いエラー回復時間をもたらす可能性があり、したがってデータ配信を必要に遅らせる可能性があります。
If a TCP sender uses a very small window size, and it cannot benefit from Fast Retransmit and Fast Recovery or SACK, the RTO algorithm has a large impact on performance. In that case, RTO algorithm tuning may be considered, although careful assessment of possible drawbacks is recommended [RFC8961].
TCP送信者が非常に小さなウィンドウサイズを使用していて、高速再送信と高速回復または袋から利益を得ることができない場合、RTOアルゴリズムはパフォーマンスに大きな影響を与えます。その場合、RTOアルゴリズムの調整が考慮される可能性がありますが、考えられる欠点を慎重に評価することをお勧めします[RFC8961]。
As an example, adaptive RTO algorithms defined for CoAP over UDP have been found to perform well in CNN scenarios [Commag] [CORE-FASOR].
一例として、UDPを介したCOAPを介して定義されたAdaptive RTOアルゴリズムは、CNNシナリオ[CORM-FASOR]でうまく機能することがわかっています。
This section summarizes some widely used techniques to improve TCP, with a focus on their use in CNNs. The TCP extensions discussed here are useful in a wide range of network scenarios, including CNNs. This section is not comprehensive. A comprehensive survey of TCP extensions is published in RFC 7414 [RFC7414].
このセクションでは、TCPを改善するためのいくつかの広く使用されている技術をまとめ、CNNSでの使用に焦点を当てています。ここで説明されているTCP拡張機能は、CNNSを含む広範囲のネットワークシナリオで役立ちます。このセクションは包括的ではありません。TCP拡張の包括的な調査は、RFC 7414 [RFC7414]に掲載されています。
Devices that have enough memory to allow a larger (i.e., more than 3 MSS of data) TCP window size can leverage a more efficient loss recovery than the timer-based approach used for a smaller TCP window size (see Section 3.2.1) by using Fast Retransmit and Fast Recovery [RFC5681], at the expense of slightly greater complexity and Transmission Control Block (TCB) size. Assuming that Delayed ACKs are used by the receiver, a window size of up to 5 MSS is required for Fast Retransmit and Fast Recovery to work efficiently: in a given TCP transmission of full-sized segments 1, 2, 3, 4, and 5, if segment 2 gets lost, and the ACK for segment 1 is held by the Delayed ACK timer, then the sender should get an ACK for segment 1 when 3 arrives and duplicate ACKs when segments 4, 5, and 6 arrive. It will retransmit segment 2 when the third duplicate ACK arrives. In order to have segments 2, 3, 4, 5, and 6 sent, the window has to be of at least 5 MSS. With an MSS of 1220 bytes, a buffer of a size of 5 MSS would require 6100 bytes.
より大きく（すなわち、3ミリ秒以上のデータを超える）TCPウィンドウサイズを許可するのに十分なメモリを有する装置は、より小さなTCPウィンドウサイズに使用されるタイマーベースのアプローチよりも効率的な損失回復を活用することができる（セクション3.2.1を参照）。速い再送と速い回復[RFC5681]を使用して、わずかに大きく複雑さと伝送制御ブロック（TCB）のサイズを犠牲にしてください。遅延ACKが受信機によって使用されると仮定すると、高速再送信および高速回復のために最大5msのウィンドウサイズが必要とされる。 、セグメント2が紛失し、セグメント1のACKが遅延ACKタイマーによって保持されている場合、セグメント4,5、および6が到着したときに3が到着して重複する場合、送信者はセグメント1のACKを取得する必要があります。 3番目の重複ACKが到着すると、セグメント2を再送信します。送信されたセグメント2,3,4,5、および6を持つためには、ウィンドウは少なくとも5ミリ秒でなければならない。 1220バイトのMSSでは、5ミリ秒のサイズのバッファが6100バイトを必要とします。
The example in the previous paragraph did not use a further TCP improvement such as Limited Transmit [RFC3042]. The latter may also be useful for any transfer that has more than one segment in flight. Small transfers tend to benefit more from Limited Transmit, because they are more likely to not receive enough duplicate ACKs. Assuming the example in the previous paragraph, Limited Transmit allows sending 5 MSS with a congestion window (cwnd) of three segments, plus two additional segments for the first two duplicate ACKs. With Limited Transmit, even a cwnd of two segments allows sending 5 MSS, at the expense of additional delay contributed by the Delayed ACK timer for the ACK that confirms segment 1.
前の段落の例では、制限された送信[RFC3042]のようなさらなるTCP改善を使用していませんでした。後者は、飛行中に複数のセグメントを有する任意の転送にも有用であり得る。小さい転送は、限られた送信からのより多くの利益を得る傾向があります。前の段落の例を想定して、制限された送信により、3つのセグメントの輻輳ウィンドウ（CWND）と最初の2つの重複したACKの2つの追加のセグメントを使用して5ミリ秒を送信できます。幅広い送信では、2つのセグメントのCWNDでさえも、セグメント1を確認するACKの遅延ACKタイマーによって寄与された追加の遅延を犠牲にして5msの送信を可能にします。
When a multiple-segment window is used, the receiver will need to manage the reception of possible out-of-order received segments, requiring sufficient buffer space. Note that even when a window of 1 MSS is used, out-of-order arrival should also be managed, as the sender may send multiple sub-MSS packets that fit in the window. (On the other hand, the receiver is free to simply drop out-of-order segments, thus forcing retransmissions.)
複数セグメントウィンドウが使用されるとき、受信機は可能な限り不倍の受信セグメントの受信を管理する必要があり、十分なバッファスペースを必要とする。送信者がウィンドウに収まる複数のサブMSSパケットを送信することができるので、1msのウィンドウを使用しても順序が管理されるべきであることに注意してください。（一方、受信機は単に順序外セグメントを解放することができ、したがって再送信を強制することができます。）
If a device with less severe memory and processing constraints can afford advertising a TCP window size of several MSSs, it makes sense to support the SACK option to improve performance. SACK allows a data receiver to inform the data sender of non-contiguous data blocks received, thus a sender (having previously sent the SACK-Permitted option) can avoid performing unnecessary retransmissions, saving energy and bandwidth, as well as reducing latency. In addition, SACK often allows for faster loss recovery when there is more than one lost segment in a window of data, since SACK recovery may complete with less RTTs. SACK is particularly useful for bulk data transfers. A receiver supporting SACK will need to keep track of the data blocks that need to be received. The sender will also need to keep track of which data segments need to be resent after learning which data blocks are missing at the receiver. SACK adds 8*n+2 bytes to the TCP header, where n denotes the number of data blocks received, up to four blocks. For a low number of out-of-order segments, the header overhead penalty of SACK is compensated by avoiding unnecessary retransmissions. When the sender discovers the data blocks that have already been received, it needs to also store the necessary state to avoid unnecessary retransmission of data segments that have already been received.
厳しいメモリと処理の制約を持つデバイスが、複数のMSSのTCPウィンドウサイズを広告することができれば、パフォーマンスを向上させるためにSACKオプションをサポートするのは理にかなっています。 SACKを使用すると、データ受信機が受信されていない非連続データブロックのデータ送信者に通知することができ、したがって、送信者（以前にSack-許可オプションを送信したこと）は、不要な再送信、エネルギーおよび帯域幅を節約するだけでなく待ち時間の低下を回避することができる。さらに、Sack RecoveryがRTTが少ないので、SACKの回復が完了する可能性があるため、SACKはデータのウィンドウに複数の紛失したセグメントがあると、より速い損失回復を可能にします。 SACKはバルクデータ転送に特に便利です。サックをサポートする受信機は、受信する必要があるデータブロックを追跡する必要があります。送信者はまた、どのデータブロックが受信機で行方不明になっているかを学習した後にどのデータセグメントを再実行する必要があるかを追跡する必要がある。 SACKはTCPヘッダーに8 * N 2バイトを追加します。ここで、nは受信されたデータブロックの数、最大4ブロックです。順不同セグメントの数が少ないため、不要な再送信を回避することで、袋のヘッダーのオーバーヘッドペナルティが補正されます。送信者がすでに受信されているデータブロックを検出すると、すでに受信されているデータセグメントの不要な再送信を避けるために必要な状態を格納する必要があります。
For certain traffic patterns, Delayed ACKs may have a detrimental effect, as already noted in Section 3.2.3. Advanced TCP stacks may use heuristics to determine the maximum delay for an ACK. For CNNs, the recommendation depends on the expected communication patterns.
特定のトラフィックパターンの場合、遅延ACKは、既に3.2.3節で述べたように、有害な影響を与える可能性があります。高度なTCPスタックは、ACKの最大遅延を決定するためにヒューリスティックを使用することができます。CNNSの場合、推奨は予想される通信パターンによって異なります。
When traffic over a CNN is expected mostly to be unidirectional messages with a size typically up to 1 MSS, and the time between two consecutive message transmissions is greater than the Delayed ACK timeout, it may make sense to use a smaller timeout or disable Delayed ACKs at the receiver. This avoids incurring additional delay, as well as the energy consumption of the sender (which might, e.g., keep its radio interface in receive mode) during that time. Note that disabling Delayed ACKs may only be possible if the peer device is administered by the same entity managing the constrained device. For request-response traffic, enabling Delayed ACKs is recommended at the server end, in order to allow combining a response with the ACK into a single segment, thus increasing efficiency. In addition, if a client issues requests infrequently, disabling Delayed ACKs at the client allows an immediate ACK for the data segment carrying the response.
CNN上のトラフィックが典型的には1ミリ秒までのサイズの単方向メッセージであり、2つの連続したメッセージ送信間の時間は遅延ACKタイムアウトよりも大きい場合、より小さなタイムアウトまたはディレイリングACKを無効にすることが理にかなっている可能性があります。受信機で。これにより、その間に追加の遅延、および送信者のエネルギー消費量だけでなく、（例えば、これは受信モードに保存する可能性がある）。ピアデバイスが制約されたデバイスを管理するのと同じエンティティによって管理されている場合にのみ、遅延ACKを無効にすることができます。要求 - 応答トラフィックの場合、ACKとの応答を単一のセグメントに組み合わせることを可能にするために、サーバーエンドで遅延ACKを有効にすることをお勧めします。さらに、クライアントが要求を頻度に頻繁に発行すると、クライアントで遅延ACKを無効にすると、応答を伝えるデータセグメントに即時のACKが可能になります。
In contrast, Delayed ACKs allow for a reduced number of ACKs in bulk transfer types of traffic, e.g., for firmware/software updates or for transferring larger data units containing a batch of sensor readings.
対照的に、遅延ACKは、バルク転送タイプのトラフィックの数の減少した数のACKを可能にし、例えば、ファームウェア/ソフトウェアの更新のための、またはセンサ読み取り値のバッチを含むより大きなデータユニットを転送するために。
Note that, in many scenarios, the peer that a constrained device communicates with will be a general purpose system that communicates with both constrained and unconstrained devices. Since Delayed ACKs are often configured through system-wide parameters, the behavior of Delayed ACKs at the peer will be the same regardless of the nature of the endpoints it talks to. Such a peer will typically have Delayed ACKs enabled.
多くのシナリオでは、拘束されたデバイスが通信するピアは、制約付きデバイスと制約の両方のデバイスと通信する汎用システムとなることに注意してください。遅延ACKはシステム全体のパラメータを介して構成されているため、ピアでの遅延ACKの動作は、それが話すエンドポイントの性質に関係なく同じになります。そのようなピアは通常、ACKを遅らせることができます。
[RFC5681] specifies a TCP Initial Window (IW) of roughly 4 kB. Subsequently, RFC 6928 [RFC6928] defines an experimental new value for the IW, which in practice will result in an IW of 10 MSS. Nowadays, the latter is used in many TCP implementations.
[RFC5681]は、約4 KBのTCP初期ウィンドウ（IW）を指定します。その後、RFC 6928 [RFC6928]はIWの実験的な新しい値を定義します。これにより、実際には10ミリ秒のIWが発生します。今日、後者は多くのTCP実装で使用されています。
Note that a 10-MSS IW was recommended for resource-rich environments (e.g., broadband environments), which are significantly different from CNNs. In CNNs, many application-layer data units are relatively small (e.g., below 1 MSS). However, larger objects (e.g., large files containing sensor readings, firmware updates, etc.) may also need to be transferred in CNNs. If such a large object is transferred in CNNs, with an IW setting of 10 MSS, there is significant buffer overflow risk, since many CNN devices support network or radio buffers of a size smaller than 10 MSS. In order to avoid such a problem, the IW needs to be carefully set in CNNs, based on device and network resource constraints. In many cases, a safe IW setting will be smaller than 10 MSS.
CNNと著しく異なるリソースに富む環境（例えば、ブロードバンド環境）には10mssのIWが推奨されていました。CNNSでは、多くのアプリケーション層データユニットが比較的小さい（例えば、1ms未満）。しかしながら、より大きなオブジェクト（例えば、センサ読み取り値、ファームウェアアップデートなどを含む大きなファイル）もまたCNNで転送される必要があるかもしれない。このような大きなオブジェクトが10msのIW設定でCNNSで転送される場合、多くのCNNデバイスは10ミリ秒未満のサイズのネットワークまたは無線バッファをサポートするため、大きなバッファオーバーフローリスクがあります。このような問題を回避するためには、デバイスとネットワークリソースの制約に基づいて、IWをCNNに慎重に設定する必要があります。多くの場合、安全なIW設定は10ミリ秒よりも小さくなります。
This section discusses how TCP can be used by applications that are developed for CNN scenarios. These remarks are by and large independent of how TCP is exactly implemented.
このセクションでは、CNNシナリオ用に開発されたアプリケーションでTCPを使用できる方法について説明します。これらの発言は、TCPが正確に実装されている方法とのかかわらず大きいことです。
In the scenario of a constrained device to an unconstrained device illustrated above, a TCP connection is typically initiated by the constrained device, in order for the device to support possible sleep periods to save energy.
上述の制約されていない装置への制約付き装置のシナリオでは、デバイスがエネルギーを節約する可能性のある睡眠期間をサポートするために、TCP接続が典型的には制約付きデバイスによって開始される。
TCP endpoints with a small amount of memory may only support a small number of connections. Each TCP connection requires storing a number of variables in the TCB. Depending on the internal TCP implementation, each connection may result in further memory overhead, and connections may compete for scarce resources (e.g., further memory overhead for send and receive buffers, etc.).
少量のメモリを持つTCPエンドポイントは、少数の接続をサポートするだけです。各TCP接続は、TCBに多数の変数を格納する必要があります。内部TCP実装に応じて、各接続はさらなるメモリオーバーヘッドをもたらし、接続が乏しいリソース（例えば、送信および受信バッファなどのさらなるメモリオーバーヘッドなど）を競合することがある。
A careful application design may try to keep the number of concurrent connections as small as possible. A client can, for instance, limit the number of simultaneous open connections that it maintains to a given server. Multiple connections could, for instance, be used to avoid the "head-of-line blocking" problem in an application transfer. However, in addition to consuming resources, using multiple connections can also cause undesirable side effects in congested networks. For example, the HTTP/1.1 specification encourages clients to be conservative when opening multiple connections [RFC7230]. Furthermore, each new connection will start with a three-way handshake, therefore increasing message overhead.
慎重なアプリケーション設計は、同時接続の数をできるだけ小さくしておくことを試みるかもしれません。たとえば、クライアントは、特定のサーバーに維持する同時オープン接続の数を制限できます。例えば、アプリケーション転送における「ラインブロック」問題を回避するために、複数の接続が使用され得る。ただし、リソースを消費することに加えて、複数の接続を使用すると、混雑したネットワークで望ましくない副作用も引き起こす可能性があります。たとえば、HTTP / 1.1仕様は、複数の接続を開くときにクライアントが保守的であることを奨励します[RFC7230]。さらに、新しい接続ごとに3方向ハンドシェイクから始まります。したがって、メッセージオーバーヘッドを増やします。
Being conservative when opening multiple TCP connections is of particular importance in Constrained-Node Networks.
複数のTCP接続を開くときに保守的であることは、制約付きノードネットワークにおいて特に重要です。
In order to minimize message overhead, it makes sense to keep a TCP connection open as long as the two TCP endpoints have more data to send. If applications exchange data rather infrequently, i.e., if TCP connections would stay idle for a long time, the idle time can result in problems. For instance, certain middleboxes such as firewalls or NAT devices are known to delete state records after an inactivity interval. RFC 5382 [RFC5382] specifies a minimum value for such an interval of 124 minutes. Measurement studies have reported that TCP NAT binding timeouts are highly variable across devices, with the median being around 60 minutes, the shortest timeout being around 2 minutes, and more than 50% of the devices with a timeout shorter than the aforementioned minimum timeout of 124 minutes [HomeGateway]. The timeout duration used by a middlebox implementation may not be known to the TCP endpoints.
メッセージオーバーヘッドを最小限に抑えるために、2つのTCPエンドポイントが送信するデータが多くなる限り、TCP接続を開くことは理にかなっています。アプリケーションがデータを無限に交換する場合、すなわちTCP接続が長時間アイドル状態に留まる場合、アイドル時間は問題を引き起こす可能性がある。たとえば、ファイアウォールやNATデバイスなどの特定のミドルボックスは、非アクティブ間隔の後に状態レコードを削除することがわかっています。RFC 5382 [RFC5382]は、124分の間隔の最小値を指定します。測定研究は、TCP NAT結合タイムアウトがデバイス間で非常に変動し、中央値が約60分であることを報告しており、最短タイムアウトは約2分で、前述の最小タイムアウトよりもタイムアウトが短いデバイスの50％以上が124分[ホームゲートウェイ]。ミドルボックスの実装で使用されるタイムアウト期間は、TCPエンドポイントに認識されない可能性があります。
In CNNs, such middleboxes may, e.g., be present at the boundary between the CNN and other networks. If the middlebox can be optimized for CNN use cases, it makes sense to increase the initial value for filter state inactivity timers to avoid problems with idle connections. Apart from that, this problem can be dealt with by different connection-handling strategies, each having pros and cons.
CNNでは、そのようなミドルボックスは、例えば、CNNと他のネットワークとの間の境界に存在してもよい。MiddleBoxがCNNユースケースに最適化できる場合は、アイドル接続の問題を回避するために、フィルタ状態不活動タイマの初期値を増やすことが理にかなっています。それとは別に、この問題は異なる接続処理戦略によって扱われ、それぞれ長所と短所を持つことができます。
One approach for infrequent data transfer is to use short-lived TCP connections. Instead of trying to maintain a TCP connection for a long time, it is possible that short-lived connections can be opened between two endpoints, which are closed if no more data needs to be exchanged. For use cases that can cope with the additional messages and the latency resulting from starting new connections, it is recommended to use a sequence of short-lived connections instead of maintaining a single long-lived connection.
まれなデータ転送のための1つのアプローチは、短期間のTCP接続を使用することです。TCP接続を長時間維持しようとする代わりに、もう2つのエンドポイント間で短寿命の接続を開くことができます。これは、もうデータを交換する必要がない場合は閉じられます。追加のメッセージと新しい接続の開始に起因するレイテンシに対処できる使用例は、単一の長寿命の接続を維持する代わりに一連の短寿命の接続を使用することをお勧めします。
The message and latency overhead that stems from using a sequence of short-lived connections could be reduced by TCP Fast Open (TFO) [RFC7413], which is an experimental TCP extension, at the expense of increased implementation complexity and increased TCB size. TFO allows data to be carried in SYN (and SYN-ACK) segments and to be consumed immediately by the receiving endpoint. This reduces the message and latency overhead compared to the traditional three-way handshake to establish a TCP connection. For security reasons, the connection initiator has to request a TFO cookie from the other endpoint. The cookie, with a size of 4 or 16 bytes, is then included in SYN packets of subsequent connections. The cookie needs to be refreshed (and obtained by the client) after a certain amount of time. While a given cookie is used for multiple connections between the same two endpoints, the latter may become vulnerable to privacy threats. In addition, a valid cookie may be stolen from a compromised host and may be used to perform SYN flood attacks, as well as amplified reflection attacks to victim hosts (see Section 5 of [RFC7413]). Nevertheless, TFO is more efficient than frequently opening new TCP connections with the traditional three-way handshake, as long as the cookie can be reused in subsequent connections. However, as stated in [RFC7413], TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, e.g., by using TLS [RFC7413]. A comprehensive discussion on TFO can be found in RFC 7413 [RFC7413].
短寿命の接続のシーケンスを使用することから生じるメッセージと待ち時間のオーバーヘッドは、実験的なTCP拡張であり、実験的なTCP拡張であり、実装の複雑さとTCBサイズの増加を犠牲にして削減することができます。 TFOを使用すると、データをSYN（およびSYN-ACK）セグメントで実行し、受信エンドポイントですぐに消費されることができます。これにより、TCP接続を確立するための従来の三方ハンドシェイクと比較して、メッセージおよび待ち時間のオーバーヘッドが短縮されます。セキュリティ上の理由から、接続イニシエータは他のエンドポイントからTFO Cookieを要求する必要があります。 4または16バイトのサイズを持つCookieは、後続の接続のSYNパケットに含まれます。一定時間後にクッキーをリフレッシュする（そしてクライアントによって取得された）必要があります。特定のCookieが同じ2つのエンドポイント間の複数の接続に使用されている間、後者はプライバシーの脅威に対して脆弱になる可能性があります。さらに、有効なクッキーは、侵入先のホストから盗まれ、統合洪水攻撃、および被害者ホストへの増幅された反射攻撃を実行するために使用され得る（[RFC7413]のセクション5参照）。それにもかかわらず、TFOは、クッキーが後続の接続で再利用できる限り、従来の三方ハンドシェイクとの新しいTCP接続を頻繁に開くよりも効率的です。ただし、[RFC7413]に記載されているように、SYN内のデータはいくつかのまれな状況でアプリケーションに再生することができるので、TFOは標準的なTCPセマンティクスから逸脱します。 TLS [RFC7413]を使用して、この問題を解決できる限り、アプリケーションはTFOを使用しないでください。 TFOに関する包括的な議論は、RFC 7413 [RFC7413]にあります。
Another approach is to use long-lived TCP connections with application-layer heartbeat messages. Various application protocols support such heartbeat messages (e.g., CoAP over TCP [RFC8323]). Periodic application-layer heartbeats can prevent early filter state record deletion in middleboxes. If the TCP binding timeout for a middlebox to be traversed by a given connection is known, middlebox filter state deletion will be avoided if the heartbeat period is lower than the middlebox TCP binding timeout. Otherwise, the implementer needs to take into account that middlebox TCP binding timeouts fall in a wide range of possible values [HomeGateway], and it may be hard to find a proper heartbeat period for application-layer heartbeat messages.
別の方法は、アプリケーションレイヤのハートビートメッセージとの長寿命のTCP接続を使用することです。さまざまなアプリケーションプロトコルは、そのようなハートビートメッセージ（例えば、TCP [RFC8323]を介したCOAP）をサポートする。周期的なアプリケーション層のハートビートは、ミドルボックスでの早期フィルタ状態レコードの削除を防ぐことができます。特定の接続によってトラバースされるミドルボックスのTCPバインディングタイムアウトが既知である場合、ハートビート期間がミドルボックスTCPバインディングタイムアウトより低いと、ミドルボックスフィルタ状態の削除が回避されます。それ以外の場合、MiddleBox TCPバインディングタイムアウトが幅広い可能な値[HomeGateway]になることを考慮に入れる必要があります。
One specific advantage of heartbeat messages is that they also allow liveness checks at the application level. In general, it makes sense to realize liveness checks at the highest protocol layer possible that is meaningful to the application, in order to maximize the depth of the liveness check. In addition, timely detection of a dead peer may allow savings in terms of TCB memory use. However, the transmission of heartbeat messages consumes resources. This aspect needs to be assessed carefully, considering the characteristics of each specific CNN.
ハートビートメッセージの1つの特定の利点は、アプリケーションレベルでのLivessチェックも許可することです。一般に、Livity Checkの深さを最大化するために、アプリケーションにとって意味がある最高プロトコル層でのLivessチェックを実現することは理にかなっています。さらに、デッドピアのタイムリーな検出により、TCBメモリの使用の観点から節約することができます。ただし、ハートビートメッセージの送信はリソースを消費します。各特定のCNNの特性を考慮して、この局面を注意深く評価する必要があります。
A TCP implementation may also be able to send "keep-alive" segments to test a TCP connection. According to [RFC1122], keep-alives are an optional TCP mechanism that is turned off by default, i.e., an application must explicitly enable it for a TCP connection. The interval between keep-alive messages must be configurable, and it must default to no less than two hours. With this large timeout, TCP keep-alive messages might not always be useful to avoid deletion of filter state records in some middleboxes. However, sending TCP keep-alive probes more frequently risks draining power on energy-constrained devices.
TCP実装は、TCP接続をテストするために「キープアライブ」セグメントを送信することもできます。[RFC1122]によると、キープアライブはデフォルトでオフになっているオプションのTCPメカニズムです。キープアライブメッセージ間の間隔は設定可能でなければならず、デフォルトは2時間以上にする必要があります。この大きなタイムアウトでは、TCPキープアライブメッセージは、いくつかのミドルボックス内のフィルタ状態レコードの削除を避けるために必ずしも便利ではないかもしれません。しかしながら、TCPキープアライブプローブを送信すると、エネルギー拘束デバイスの電力を排出することが頻繁にリスクされます。
Best current practices for securing TCP and TCP-based communication also applies to CNN. As an example, use of TLS [RFC8446] is strongly recommended if it is applicable. However, note that TLS protects only the contents of the data segments.
TCPおよびTCPベースの通信を確保するための最良の現在の慣行は、CNNにも適用されます。一例として、適用可能であればTLS [RFC8446]を使用することを強くお勧めします。ただし、TLSはデータセグメントの内容のみを保護します。
There are TCP options that can actually protect the transport layer. One example is the TCP Authentication Option (TCP-AO) [RFC5925]. However, this option adds overhead and complexity. TCP-AO typically has a size of 16-20 bytes. An implementer needs to asses the trade-off between security and performance when using TCP-AO, considering the characteristics (in terms of energy, bandwidth, and computational power) of the environment where TCP will be used.
実際にトランスポート層を保護できるTCPオプションがあります。一例はTCP認証オプション（TCP-AO）[RFC5925]です。ただし、このオプションはオーバーヘッドと複雑さを追加します。TCP-AOは通常16~20バイトのサイズを持ちます。TCPが使用される環境の特性（エネルギー、帯域幅、計算パワーの点で）を考慮して、TCP-AOを使用している場合、実装者はセキュリティとパフォーマンスとの間でトレードオフを求める必要があります。
For the mechanisms discussed in this document, the corresponding considerations apply. For instance, if TFO is used, the security considerations of RFC 7413 [RFC7413] apply.
この文書で説明したメカニズムの場合、対応する考慮事項が適用されます。たとえば、TFOが使用されている場合は、RFC 7413 [RFC7413]のセキュリティに関する考慮事項が適用されます。
Constrained devices are expected to support smaller TCP window sizes than less-limited devices. In such conditions, segment retransmission triggered by RTO expiration is expected to be relatively frequent, due to lack of (enough) duplicate ACKs, especially when a constrained device uses a single-MSS implementation. For this reason, constrained devices running TCP may appear as particularly appealing victims of the so-called "shrew" Denial-of-Service (DoS) attack [SHREW], whereby one or more sources generate a packet spike targeted to coincide with consecutive RTO-expiration-triggered retry attempts of a victim node. Note that the attack may be performed by Internet-connected devices, including constrained devices in the same CNN as the victim, as well as remote ones. Mitigation techniques include RTO randomization and attack blocking by routers able to detect shrew attacks based on their traffic pattern.
制約付きデバイスは、制限されていないデバイスよりも小さいTCPウィンドウサイズをサポートすることが予想されます。このような条件では、RTOの有効期限によって引き起こされるセグメント再送信は、特に制約されたデバイスが単一のMSS実装を使用する場合、（十分な）重複ACKの欠如のために比較的頻繁であると予想されます。このため、TCPを実行している制約付きデバイスは、いわゆる「鋸」攻撃拒否（DOS）攻撃[Shrew]の魅力的な犠牲者として現れることがあります。 - 被害者ノードの散合トリガー再試行試行。攻撃は、被害者と同じCNN内の制約付きデバイス、ならびにリモートのデバイスを含むインターネット接続されたデバイスによって実行され得ることに留意されたい。緩和技術には、トラフィックパターンに基づいてシュール攻撃を検出できるルーターによるRTOランダム化と攻撃ブロッキングが含まれます。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J.、 "Transmission Control Protocol"、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R.、ED。、「インターネットホストの要求 - 通信層の要求」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https：//www.rfc-editor.org/info/RFC1122>。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, <https://www.rfc-editor.org/info/rfc2018>.
[RFC2018] Mathis、M.、Mahdavi、J.、Floyd、S.、およびA. Romanow、「TCP選択認証オプション」、RFC 2018、DOI 10.17487 / RFC2018、<https：///www.rfc-editor.org/info/rfc2018>
[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, DOI 10.17487/RFC3042, January 2001, <https://www.rfc-editor.org/info/rfc3042>.
[RFC3042] Allman、M.、Balakrishnan、H.、およびS. Floyd、2001年1月、<https：///www.rfc-編集者。ORG / INFO / RFC3042>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168] Ramakrishnan、K.、Floyd、S.、およびD. Black、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<https：// www。rfc-editor.org/info/rfc3168>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V.およびE.Blanton、「TCP輻輳制御」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<https：//www.rfc-editor.org/info/RFC5681>。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.
[RFC6298] Paxson、V.、Allman、M.、Chu、J.、およびM.Sargent、「コンピューティングTCPの再送信タイマー」、RFC 6298、DOI 10.17487 / RFC6298、2011年6月、<https：///www.rfc-editor.org/info/rfc6298>。
[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", RFC 6691, DOI 10.17487/RFC6691, July 2012, <https://www.rfc-editor.org/info/rfc6691>.
[RFC6691] Borman、D.、「TCPオプションと最大セグメントサイズ（MSS）」、RFC 6691、DOI 10.17487 / RFC6691、2012年7月、<https://www.rfc-editor.org/info/rfc6691>。
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, DOI 10.17487/RFC6928, April 2013, <https://www.rfc-editor.org/info/rfc6928>.
[RFC6928] Chu、J.、Dukkipati、N.、Cheng、Y.、およびM. Mathis、「TCPの初期ウィンドウの増加」、RFC 6928、DOI 10.17487 / RFC6928、2013年4月、<https：//www.rfc-editor.org/info/rfc6928>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Eresut、M.およびA.ケラネン、「拘束ノードネットワークのための用語」、RFC 7228、DOI 10.17487 / RFC 7228、2014年5月、<https：//www.rfc-editor.org/ info / rfc7228>。
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.
[RFC7323] Borman、D.、Braden、B.、Jacobson、V.、およびR.Scheffenegger、ED。、「高性能のためのTCP拡張」、RFC 7323、DOI 10.17487 / RFC7323、2014年9月、<https：//www.rfc-editor.org/info/rfc7323>。
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[RFC7413] Cheng、Y.、Chu、J.、Radhakrishnan、S.、A. Jain、 "TCP Fast Open"、RFC 7413、DOI 10.17487 / RFC7413、2014年12月、<https：///www.rfc-編集者.ORG / INFO / RFC7413>。
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <https://www.rfc-editor.org/info/rfc7567>.
[RFC7567] Baker、F.、ED。G. FairHurst、Ed。、「アクティブキュー管理に関するIETF勧告」、BCP 197、RFC 7567、DOI 10.17487 / RFC7567、2015年7月、<https：//www.rfc-editor.org/info/rfc7567>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] The'th、S.およびR.hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https：//www.rfc-editor.org/ info / rfc8200>。
[6LO-WLANAH] Del Carpio Vega, L., Robles, M., and R. Morabito, "IPv6 over 802.11ah", Work in Progress, Internet-Draft, draft-delcarpio-6lo-wlanah-01, 19 October 2015, <https://tools.ietf.org/html/draft-delcarpio-6lo-wlanah-01>.
[6lo-Wlanah] Del Carpio Vega、L.、Roble、M.、R. Morabito、「IPv6 over 802.11ah」、進行中の作業、インターネットドラフト、ドラフト - デルカルピオ-61,19 2015年10月19日<https：//tools.ietf.org/html/draft-delcarpio-6lo-wlanah-01>。
[Commag] Betzler, A., Gomez, C., Demirkol, I., and J. Paradells, "CoAP Congestion Control for the Internet of Things", IEEE Communications Magazine, Vol. 54, Issue 7, pp. 154-160, DOI 10.1109/MCOM.2016.7509394, July 2016, <https://doi.org/10.1109/MCOM.2016.7509394>.
[COMMAG] Betzler、A.、Gomez、C.、Demirkol、I.、およびJ.Paradells、「インターネットのインターネットのためのCoap Comgention Control」、IEEE Communications Magazine、Vol。54、問題7、PP。154-160、DOI 10.1109 / MCOM.2016.7509394、2016年7月、<https：//doi.org/10.1109/mcom.2016.7509394>。
[CORE-FASOR] Jarvinen, I., Kojo, M., Raitahila, I., and Z. Cao, "Fast-Slow Retransmission Timeout and Congestion Control Algorithm for CoAP", Work in Progress, Internet-Draft, draft-ietf-core-fasor-01, 19 October 2020, <https://tools.ietf.org/html/draft-ietf-core-fasor-01>.
[Core-Fasor] Jarvinen、I.、Kojo、M.、Raitahila、I.、およびZ. Cao、「CoAPの急速遅い再送信タイムアウトと輻輳制御アルゴリズム」、進行中の作業、インターネットドラフト、ドラフトIETF-core-fasor-01、2020年10月19日、<https://tools.ietf.org/html/draft-ietf-core-fasor-01>。
[Dunk] Dunkels, A., "Full TCP/IP for 8-Bit Architectures", MobiSys '03, pp. 85-98, DOI 10.1145/1066116.106611, May 2003, <https://doi.org/10.1145/1066116.106611>.
[ダンク]ダンケルス、A。、「8ビットアーキテクチャ用のフルTCP / IP」、MobiSys '03、PP。85-98、DOI 10.1145 / 1066116.106611、2003年5月、<https：//doi.org/10.1145/1066116.106611>。
[ETEN] Krishnan, R., Sterbenz, J., Eddy, W., and C. Partridge, "Explicit transport error notification (ETEN) for error-prone wireless and satellite networks", Computer Networks, DOI 10.1016/j.comnet.2004.06.012, June 2004, <https://doi.org/10.1016/j.comnet.2004.06.012>.
[ETEN]クリシュナン、R.、Sterbenz、J.、Eddy、W.、およびC.パターリッジ、「エラーが発生しやすい無線および衛星ネットワークのための明示的なトランスポートエラー通知（ETEN）」、コンピュータネットワーク、DOI 10.1016 / J.0nnet2004年6月、<https://doi.org/10.1016/j.01.2004.06.012> .2004.06.012。
[GNRC] Lenders, M., Kietzmann, P., Hahm, O., Petersen, H., Gündoğa, C., Baccelli, E., Schleiser, K., Schmidt, T., and M. Wählisch, "Connecting the World of Embedded Mobiles: The RIOT Approach to Ubiquitous Networking for the IoT", arXiv:1801.02833v1 [cs.NI], January 2018.
[GNRC]レンダリング、M.、Kietzmann、P.、HAHM、O、Petersen、H.、Gündoła、C.、Baccelli、E.、Sch Leiser、K.、Schmidt、T.、およびM.Wählisch、M.Wählisch、 "Connecting組み込み携帯電話の世界：IoTのユビキタスネットワーキングへの暴動的アプローチ、arxiv：1801.02833v1 [CS.NI]、2018年1月。
[HomeGateway] Haetoenen, S., Nyrhinen, A., Eggert, L., Strowes, S., Sarolahti, P., and M. Kojo, "An Experimental Study of Home Gateway Characteristics", Proceedings of the 10th ACM SIGCOMM conference on Internet measurement, pp. 260-266, DOI 10.1145/1879141.1879174, November 2010, <https://doi.org/10.1145/1879141.1879174>.
[HomeGateway] Haetoenen、S.、Nyrhinen、A.、Eggert、L.、Strowes、S.、Sarolahti、P.、およびM. kojo、「ホームゲートウェイの特徴の実験的研究」、第10回ACM SIGCOMM会議の手続きインターネット測定、PP。260-266、DOI 10.1145 / 1879141.1879174、2010年11月、<https：//doi.org/10.1145/1879141-1879174>。
[IntComp] Gomez, C., Arcia-Moret, A., and J. Crowcroft, "TCP in the Internet of Things: from Ostracism to Prominence", IEEE Internet Computing, Vol. 22, Issue 1, pp. 29-41, DOI 10.1109/MIC.2018.112102200, January 2018, <https://doi.org/10.1109/MIC.2018.112102200>.
[INTCOMP] Gomez、C.、Arcia-Moret、A.、およびJ.Crowcroft、「物事のインターネットのTCP：オストラシズムからプロミネンスへ」、IEEEインターネットコンピューティング、Vol。22、PP.29-41、DOI 10.1109 / MIC.2018.112102200、2018年1月、<https：//doi.org/10.1109/mic.2018.1121022200>。
[MQTT] ISO/IEC, "Information technology -- Message Queuing Telemetry Transport (MQTT) v3.1.1", ISO/IEC 20922:2016, June 2016.
[MQTT] ISO / IEC、「情報技術 - メッセージキューイング遠隔測定輸送（MQTT）V3.1.1」、ISO / IEC 20922：2016、2016年6月。
[RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N. Vaidya, "Long Thin Networks", RFC 2757, DOI 10.17487/RFC2757, January 2000, <https://www.rfc-editor.org/info/rfc2757>.
[RFC2757]モンテネグロ、G.、Dawkins、S.、Kojo、M.、Magret、V.、およびN. Vaidya、「長薄いネットワーク」、RFC 2757、DOI 10.17487 / RFC2757、2000年1月、<https：//www.rfc-editor.org/info/rfc2757>。
[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks", RFC 2884, DOI 10.17487/RFC2884, July 2000, <https://www.rfc-editor.org/info/rfc2884>.
[RFC2884]ハディサリム、J.およびU. AHMED、「IPネットワークにおける明示的輻輳通知（ECN）の性能評価」、RFC 2884、DOI 10.17487 / RFC2884、2000年7月、<https：//www.rfc-編集者。ORG / INFO / RFC2884>。
[RFC3481] Inamura, H., Ed., Montenegro, G., Ed., Ludwig, R., Gurtov, A., and F. Khafizov, "TCP over Second (2.5G) and Third (3G) Generation Wireless Networks", BCP 71, RFC 3481, DOI 10.17487/RFC3481, February 2003, <https://www.rfc-editor.org/info/rfc3481>.
[RFC3481] Inamura、H.、Ed。、Montenegro、G.、ED。、Ludwig、R.、Gurtov、A.、F.Khafizov、「2.5G）および第3世代の無線ネットワーク「、BCP 71、RFC 3481、DOI 10.17487 / RFC3481、2003年2月、<https://www.rfc-editor.org/info/rfc3481>。
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, DOI 10.17487/RFC3819, July 2004, <https://www.rfc-editor.org/info/rfc3819>.
[RFC3819]カーン、P.、ED、Bormann、C.、Fairhurst、G.、Grossman、D.、Ludwig、R.、Mahdavi、J.、Montenegro、G.、G.、L. Wood、「インターネットサブネットワークデザイナーのためのアドバイス」、BCP 89、RFC 3819、DOI 10.17487 / RFC3819、2004年7月、<https：//www.rfc-editor.org/info/rfc3819>。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G.、Kushalnagar、N.、Hui、J.、およびD.Culler、「IEEE 802.15.4ネットワーク上のIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<https：//www.rfc-editor.org/info/rfc4944>。
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, <https://www.rfc-editor.org/info/rfc5382>.
[RFC5382] GUA、S、ED。、Biswas、K.、Ford、B.、Sivakumar、S.、およびP. Srisuresh、「TCPのNAT行動要件」、BCP 142、RFC 5382、DOI 10.17487 / RFC5382、2008年10月、<https：//www.rfc-editor.org/info/rfc5382>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A.、R.ボニカ、「TCP認証オプション」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<https://www.rfc-editor.org/info/ RFC5925>。
[RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B. Briscoe, "Open Research Issues in Internet Congestion Control", RFC 6077, DOI 10.17487/RFC6077, February 2011, <https://www.rfc-editor.org/info/rfc6077>.
[RFC6077] Papadimitriou、D.、Ed。、Welzl、M.、Scharf、M.、B. Briscoe、RFC 6077、DOI 10.17487 / RFC6077、2011年2月、<HTTPS：//www.rfc-editor.org/info/rfc6077>。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6120] Saint-Andre、P.、 "Extensible Messaging and Presence Protocol（XMPP）：コア"、RFC 6120、DOI 10.17487 / RFC6120、2011年3月、<https://www.rfc-editor.org/info/rfc6120>。
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>.
[RFC6282] HUI、J.、ED。2011年9月、2011年9月、2011年9月、<https：//www.rfc-editor.org/info/rfc6282、<https：//www.rfc-editor.org/info/rfc6282>。
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>.
[RFC6550]冬、T.、ED。、Thubert、P.、Ed。、Brandt、A.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R.、Vasseur、JP。、およびR.RPL：低消費電力ネットワークの「RPL：IPv6ルーティングプロトコル」、RFC 6550、DOI 10.17487 / RFC6550、2012年3月、<https：//www.rfc-editor.org/info/RFC6550>。
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing", RFC 6606, DOI 10.17487/RFC6606, May 2012, <https://www.rfc-editor.org/info/rfc6606>.
[RFC6606] KIM、E.、KASPAR、D.、Gomez、C、およびC. Bormann、「低電力無線パーソナルエリアネットワーク（6LOWPAN）ルーティングにおけるIPv6の要件」、RFC 6606、DOI 10.17487 /rfc6606、2012年5月、<https://www.rfc-editor.org/info/rfc6606>。
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <https://www.rfc-editor.org/info/rfc6775>.
[RFC6775] Shelby、Z.、ED。、Chakrabarti、S.、Nordmark、E.、およびC. Bormann、「低電力無線パーソナルエリアネットワークにおけるIPv6の近隣探索最適化（6lowpans）」、RFC 6775、DOI 10.17487/ RFC6775、2012年11月、<https：//www.rfc-editor.org/info/rfc6775>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールド、R.、ED。J.Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：メッセージ構文とルーティング」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https：//www.rfc-editor.org/info/RFC7230>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K.、C. Bormann、「制約付きアプリケーションプロトコル（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<https：//www.rfc-編集者。ORG / INFO / RFC7252>。
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 7414, DOI 10.17487/RFC7414, February 2015, <https://www.rfc-editor.org/info/rfc7414>.
[RFC7414] Duke、M.、Braden、R.、Eddy、W.、Blanton、E.、A.Zimmermann、「トランスミッション制御プロトコル（TCP）仕様書のロードマップ」、RFC 7414、DOI 10.17487 / RFC7414、2015年2月、<https：//www.rfc-editor.org/info/rfc7414>。
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets over ITU-T G.9959 Networks", RFC 7428, DOI 10.17487/RFC7428, February 2015, <https://www.rfc-editor.org/info/rfc7428>.
[RFC7428] Brandt、A.およびJ.Büron、「ITU-T G.9959ネットワーク上のIPv6パケットの送信」、RFC 7428、DOI 10.17487 / RFC7428、2015年2月、<https：//www.rfc-editor.org/ info / rfc7428>。
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540] Belshe、M.、Peon、R.およびM.Thomson、Ed。、「Hypertext Transfer Protocol Version 2（HTTP / 2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<https：//www.rfc-editor.org/info/rfc7540>。
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, <https://www.rfc-editor.org/info/rfc7668>.
[RFC7668] Nieminen、J.、Savolainen、T.、Isomaki、M.、Patil、B.、Shelby、Z.、およびC.Gomez、「IPv6 over Bluetooth（R）低エネルギー」、RFC 7668、DOI 10.17487 /RFC7668、2015年10月、<https://www.rfc-editor.org/info/rfc7668>。
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using Explicit Congestion Notification (ECN)", RFC 8087, DOI 10.17487/RFC8087, March 2017, <https://www.rfc-editor.org/info/rfc8087>.
[RFC8087] FairHurst、G.およびM. Welzl、「明示的輻輳通知（ECN）を使用する利点」、RFC 8087、DOI 10.17487 / RFC8087、2017年3月、<https：//www.rfc-editor.org/info/ RFC8087>。
[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, M., and D. Barthel, "Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 2017, <https://www.rfc-editor.org/info/rfc8105>.
[RFC8105] Mariager、P.、Petersen、J.、Ed。、Shelby、Z.、Van De Logt、M.、およびD. Barthel、「デジタル強化コードレス電気通信（DECT）超低エネルギー（DECT）のIPv6パケットの伝送ULE） "、RFC 8105、DOI 10.17487 / RFC8105、2017年5月、<https://www.rfc-editor.org/info/rfc8105>。
[RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. Donaldson, "Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, May 2017, <https://www.rfc-editor.org/info/rfc8163>.
[RFC8163] Lynn、K。、ED。、Martocci、J.、Neilson、C.、S.Donaldson、「Master-Slave / Token-Passion（MS / TP）ネットワーク（MS / TP）ネットワークにおけるIPv6の送信」、RFC 8163、DOI10.17487 / RFC8163、2017年5月、<https：//www.rfc-editor.org/info/rfc8163>。
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.
[RFC8201] McCann、J.、Theer、S.、Mogul、J.、およびR. Hinden、Ed。、「IPバージョン6のためのパスMTUディスカバリー」、STD 87、RFC 8201、DOI 10.17487 / RFC8201、2017年7月、<https://www.rfc-editor.org/info/rfc8201>。
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, <https://www.rfc-editor.org/info/rfc8323>.
[RFC8323] Bormann、C、LeMay、S.、Tschofenig、H.、Hartke、K.、Silverajan、B.、およびB.Raymor、Ed。、TCP、TLS、およびWebocketsの上のCOAP（制約付きアプリケーションプロトコル）"、RFC 8323、DOI 10.17487 / RFC8323、2018年2月、<https://www.rfc-editor.org/info/rfc8323>。
[RFC8352] Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, Ed., "Energy-Efficient Features of Internet of Things Protocols", RFC 8352, DOI 10.17487/RFC8352, April 2018, <https://www.rfc-editor.org/info/rfc8352>.
[RFC8352] Gomez、C、Kovatch、M.、Tian、H.、およびZ. Cao、Ed。、「プロトコルのインターネットのエネルギー効率の高い特徴」、RFC 8352、DOI 10.17487 / RFC8352、2018年4月、<https://www.rfc-editor.org/info/rfc8352>。
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, <https://www.rfc-editor.org/info/rfc8376>.
[RFC8376] Farrell、S、ED。、「低電力広域ネットワーク（LPWAN）概要」、RFC 8376、DOI 10.17487 / RFC8376、2018年5月、<https：//www.rfc-editor.org/info/RFC8376>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, <https://www.rfc-editor.org/info/rfc8900>.
[RFC8900]ボニャ、R.、Baker、F.、Huston、G.、Hinden、R.、Troan、O.、F.ゴント、「IPフラグメンテーションと見なす」、BCP 230、RFC 8900、DOI 10.17487 / RFC8900、2020年9月、<https://www.rfc-editor.org/info/rfc8900>。
[RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery", RFC 8931, DOI 10.17487/RFC8931, November 2020, <https://www.rfc-editor.org/info/rfc8931>.
[RFC8931] Thubert、P.、ED。、「低消費電力無線パーソナルエリアネットワーク（6lowpan）選択フラグメントリカバリの「IPv6」、RFC 8931、DOI 10.17487 / RFC8931、2020年11月、<https：///www.rfc-編集者.ORG / INFO / RFC8931>。
[RFC8961] Allman, M., "Requirements for Time-Based Loss Detection", BCP 233, RFC 8961, DOI 10.17487/RFC8961, November 2020, <https://www.rfc-editor.org/info/rfc8961>.
[RFC8961] Allman、M.、「時間ベースの損失検出の要件」、BCP 233、RFC 8961、DOI 10.17487 / RFC8961、2020年11月、<https://www.rfc-editor.org/info/rfc8961>。
[RIOT] Baccelli, E., Gündoğa, C., Hahm, O., Kietzmann, P., Lenders, M., Petersen, H., Schleiser, K., Schmidt, T., and M. Wählisch, "RIOT: An Open Source Operating System for Low-End Embedded Devices in the IoT", IEEE Internet of Things Journal, Vol. 5, Issue 6, DOI 10.1109/JIOT.2018.2815038, March 2018, <https://doi.org/10.1109/JIOT.2018.2815038>.
[暴動] Baccelli、E.、Gündoa、C.、Hahm、O.、Kietzmann、P.、Lenders、M.、Petersen、H.、Sch Leiser、K.、Schmidt、T.、およびM.Wählisch、 "Riot：IOT内のローエンド埋め込みデバイス用のオープンソースオペレーティングシステム、Theone Journal、Vol。5、DISI 10.1109 / Jiot 2018.2815038、<https：//doi.org/10.1109/jiot.2018.2815038>。
[SHREW] Nyrhinen, A. and E. Knightly, "Low-Rate TCP-Targeted Denial of Service Attacks (The Shrew vs. the Mice and Elephants)", SIGCOMM'03, DOI 10.1145/863955.863966, August 2003, <https://doi.org/10.1145/863955.863966>.
[Shrew] Nyrhinen、A.およびE.騎士団の「低価格TCPターゲットサービス攻撃攻撃攻撃攻撃攻撃拒否攻撃】、SIGCOMM'03、DOI 10.1145 / 863955.863966、<https：//doi.org/10.1145/863955.863966>。
[TCPM-ECN] Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets", Work in Progress, Internet-Draft, draft-ietf-tcpm-generalized-ecn-07, 16 February 2021, <https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-07>.
[TCPM-ECN] Bagnulo、M.およびB. Brisco、 "ECN：明示的輻輳通知（ECN）への明示的輻輳通知（ECN）へのTCP制御パケットの追加"、進行中の作業、インターネットドラフト、草案-TCPM一般化ECN-07、2021年2月16日、<https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-07>。
This section overviews the main features of TCP implementations for constrained devices. The survey is limited to open-source stacks with a small footprint. It is not meant to be all-encompassing. For more powerful embedded systems (e.g., with 32-bit processors), there are further stacks that comprehensively implement TCP. On the other hand, please be aware that this Annex is based on information available as of the writing.
このセクションでは、制約付きデバイスのTCP実装の主な機能を概説します。調査は小さな設置面積を持つオープンソーススタックに限定されています。全く囲まれていることを意味していません。より強力な組み込みシステム（例えば、32ビットプロセッサを有する）については、TCPを包括的に実装するスタックがさらにある。一方、この附属書は書込の時点で利用可能な情報に基づいていることに注意してください。
uIP is a TCP/IP stack, targeted for 8- and 16-bit microcontrollers, which pioneered TCP/IP implementations for constrained devices. uIP has been deployed with Contiki and the Arduino Ethernet shield. A code size of ~5 kB (which comprises checksumming, IPv4, ICMP, and TCP) has been reported for uIP [Dunk]. Later versions of uIP implement IPv6 as well.
UIPは、8ビットマイクロコントローラと16ビットのマイクロコントローラを対象としたTCP / IPスタックです。これは、制約付きデバイスのTCP / IP実装を開始しました。UIPはContikiとArduino Ethernet Shieldでデプロイされています。UIP [Dunk]のために、~5 KB（チェックサム、IPv4、ICMP、およびTCPを含む）のコードサイズが報告されています。UIPの後のバージョンIPv6も実装します。
uIP uses the same global buffer for both incoming and outgoing traffic, which has a size of a single packet. In case of a retransmission, an application must be able to reproduce the same user data that had been transmitted. Multiple connections are supported but need to share the global buffer.
UIPは、単一のパケットのサイズを持つ着信トラフィックと発信トラフィックの両方に同じグローバルバッファを使用します。再送の場合、アプリケーションは送信された同じユーザーデータを再現できなければなりません。複数の接続がサポートされていますが、グローバルバッファを共有する必要があります。
The MSS is announced via the MSS option on connection establishment, and the receive window size (of 1 MSS) is not modified during a connection. Stop-and-wait operation is used for sending data. Among other optimizations, this allows for the avoidance of sliding window operations, which use 32-bit arithmetic extensively and are expensive on 8-bit CPUs.
MSSは接続確立時のMSSオプションを介して発表され、（1ミリ秒の）受信ウィンドウサイズは接続中に変更されません。データの送信には、ストップアンドウェイト操作が使用されます。他の最適化の中で、これはスライディングウィンドウ操作を回避することを可能にし、これは32ビット算術を広く使用し、8ビットCPU上で高価である。
Contiki uses the "split hack" technique (see Section 3.2.3) to avoid Delayed ACKs for senders using a single segment.
Contikiは、単一セグメントを使用した送信者の遅延ACKを避けるために、「スプリットハック」テクニック（セクション3.2.3を参照）を使用します。
The code size of the TCP implementation in Contiki-NG has been measured to be 3.2 kB on CC2538DK, cross-compiling on Linux.
CONTIKI-NGのTCP実装のコードサイズは、Linux上でクロスコンパイルされたCC2538DKでは3.2 KBであると測定されています。
lwIP is a TCP/IP stack, targeted for 8- and 16-bit microcontrollers. lwIP has a total code size of ~14 kB to ~22 kB (which comprises memory management, checksumming, network interfaces, IPv4, ICMP, and TCP) and a TCP code size of ~9 kB to ~14 kB [Dunk]. Both IPv4 and IPv6 are supported in lwIP since v2.0.0.
LWIPは、8ビットマイクロコントローラと16ビットのマイクロコントローラを対象としたTCP / IPスタックです。LWIPには、~14 KB（メモリ管理、チェックサム、ネットワークインタフェース、IPv4、ICMP、TCP）、およびTCPコードサイズ~9 KB~~ 14 KB ~14 KBのTCPコードサイズがあります。IPv4とIPv6の両方がv2.0.0以降のLWIPでサポートされています。
In contrast with uIP, lwIP decouples applications from the network stack. lwIP supports a TCP transmission window greater than a single segment, as well as the buffering of incoming and outgoing data. Other implemented mechanisms comprise slow start, congestion avoidance, fast retransmit, and fast recovery. SACK and Window Scale support has been recently added to lwIP.
UIPとは対照的に、LWIPはネットワークスタックからアプリケーションを切り離します。LWIPは、単一のセグメントよりも大きいTCP送信ウィンドウ、および着信データと発信データのバッファリングをサポートしています。他の実施されたメカニズムは、スロースタート、輻輳回避、高速再送信、および高速回復を含む。最近LWIPにSACKとWINDOW SCALEのサポートが追加されました。
The RIOT TCP implementation (called "GNRC TCP") has been designed for Class 1 devices [RFC7228]. The main target platforms are 8- and 16-bit microcontrollers, with 32-bit platforms also supported. GNRC TCP offers a similar function set as uIP, but it provides and maintains an independent receive buffer for each connection. In contrast to uIP, retransmission is also handled by GNRC TCP. For simplicity, GNRC TCP uses a single-MSS implementation. The application programmer does not need to know anything about the TCP internals; therefore, GNRC TCP can be seen as a user-friendly uIP TCP implementation.
RIOT TCP実装（「GNRC TCP」と呼ばれる）は、クラス1デバイスの用に設計されています[RFC7228]。主なターゲットプラットフォームは8ビットおよび16ビットのマイクロコントローラで、32ビットプラットフォームもサポートされています。GNRC TCPは、UIPと同様の機能セットを提供しますが、接続ごとに独立した受信バッファを提供して維持します。UIPとは対照的に、再送信もGNRC TCPによって処理されます。簡単にするために、GNRC TCPはシングルMSS実装を使用します。アプリケーション・プログラマーは、TCP内部について何も知る必要はありません。したがって、GNRC TCPはユーザーフレンドリーなUIP TCP実装と見なすことができます。
The MSS is set on connections establishment and cannot be changed during connection lifetime. GNRC TCP allows multiple connections in parallel, but each TCB must be allocated somewhere in the system. By default, there is only enough memory allocated for a single TCP connection, but it can be increased at compile time if the user needs multiple parallel connections.
MSSは接続確立に設定され、接続寿命中に変更することはできません。GNRC TCPは複数の接続を並行して許可しますが、各TCBはシステム内のどこかに割り当てられている必要があります。デフォルトでは、単一のTCP接続に割り当てられているのに十分なメモリしかありませんが、ユーザーが複数の並列接続を必要とする場合はコンパイル時に増やすことができます。
The RIOT TCP implementation offers an optional Portable Operating System Interface (POSIX) socket wrapper that enables POSIX compliance, if needed.
RIOT TCP実装は、必要に応じてPOSIX準拠を可能にするオプションのポータブルオペレーティングシステムインタフェース（POSIX）ソケットラッパーを提供します。
Further details on RIOT and GNRC can be found in [RIOT] and [GNRC].
暴動およびGNRCに関するさらなる詳細は[暴動]および[GNRC]に見出すことができる。
TinyOS was important as a platform for early constrained devices. TinyOS has an experimental TCP stack that uses a simple non-blocking library-based implementation of TCP, which provides a subset of the socket interface primitives. The application is responsible for buffering. The TCP library does not do any receive-side buffering. Instead, it will immediately dispatch new, in-order data to the application or otherwise drop the segment. A send buffer is provided by the application. Multiple TCP connections are possible. Recently, there has been little work on the stack.
Tinyosは、早期の制約付きデバイスのプラットフォームとして重要でした。TinyOSには、Socket Interfaceプリミティブのサブセットが提供される、TCPの単純な非ブロッキングライブラリベースの実装を使用する実験的なTCPスタックがあります。アプリケーションはバッファリングを担当します。TCPライブラリは受信側のバッファリングをしません。代わりに、直ちに新しい順序データをアプリケーションにディスパッチするか、その他の方法でセグメントを削除します。送信バッファはアプリケーションによって提供されます。複数のTCP接続が可能です。最近、スタックにはほとんど作業が少なかった。
FreeRTOS is a real-time operating system kernel for embedded devices that is supported by 16- and 32-bit microprocessors. Its TCP implementation is based on multiple-segment window size, although a "Tiny-TCP" option, which is a single-MSS variant, can be enabled. Delayed ACKs are supported, with a 20 ms Delayed ACK timer as a technique intended "to gain performance".
Freertosは、16ビットおよび32ビットのマイクロプロセッサによってサポートされている組み込みデバイス用のリアルタイムオペレーティングシステムカーネルです。そのTCP実装は複数セグメントウィンドウサイズに基づいていますが、「Tiny-TCP」オプションは単一MSSバリアントであることを有効にすることができます。遅延ACKは、「パフォーマンスを得る」という意図した技術として、20ミリ秒遅延ACKタイマーでサポートされています。
uC/OS is a real-time operating system kernel for embedded devices, which is maintained by Micrium. uC/OS is intended for 8-, 16-, and 32-bit microprocessors. The uC/OS TCP implementation supports a multiple-segment window size.
UC / OSは、Micriumによって維持されている組み込みデバイス用のリアルタイムオペレーティングシステムカーネルです。UC / OSは、8、16、および32ビットのマイクロプロセッサを対象としています。UC / OS TCP実装は、複数セグメントウィンドウサイズをサポートしています。
None of the implementations considered in this Annex support ECN or TFO.
この附属書には、ECNまたはTFOで検討されていない実装はありません。
+==========+=====+======+==========+======+========+==========+=====+
| | uIP |lwIP | lwIP 2.1 | RIOT | TinyOS | FreeRTOS |uC/OS|
| | |orig | | | | | |
+==========+=====+======+==========+======+========+==========+=====+
| Code | <5 |~9 to | 38 | <7 | N/A | <9.2 | N/A |
| Size | | ~14 | | | | | |
| (kB) | | | | | | | |
+----------+-----+------+----------+------+--------+----------+-----+
| Memory | (a) | (T1) | (T4) | (T3) | N/A | (T2) | N/A |
+==========+=====+======+==========+======+========+==========+=====+
| TCP |
| Features |
+==========+=====+======+==========+======+========+==========+=====+
| Single- | Yes | No | No | Yes | No | No | No |
| Segm. | | | | | | | |
+----------+-----+------+----------+------+--------+----------+-----+
| Slow | No | Yes | Yes | No | Yes | No | Yes |
| start | | | | | | | |
+----------+-----+------+----------+------+--------+----------+-----+
| Fast | No | Yes | Yes | No | Yes | No | Yes |
| rec/retx | | | | | | | |
+----------+-----+------+----------+------+--------+----------+-----+
| Keep- | No | No | Yes | No | No | Yes | Yes |
| alive | | | | | | | |
+----------+-----+------+----------+------+--------+----------+-----+
| Win. | No | No | Yes | No | No | Yes | No |
| Scale | | | | | | | |
+----------+-----+------+----------+------+--------+----------+-----+
| TCP | No | No | Yes | No | No | Yes | No |
| timest. | | | | | | | |
+----------+-----+------+----------+------+--------+----------+-----+
| SACK | No | No | Yes | No | No | Yes | No |
+----------+-----+------+----------+------+--------+----------+-----+
| Del. | No | Yes | Yes | No | No | Yes | Yes |
| ACKs | | | | | | | |
+----------+-----+------+----------+------+--------+----------+-----+
| Socket | No | No | Optional | (I) | Subset | Yes | Yes |
+----------+-----+------+----------+------+--------+----------+-----+
| Concur. | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Conn. | | | | | | | |
+==========+=====+======+==========+======+========+==========+=====+
| TLS supp | No | No | Yes | Yes | Yes | Yes | Yes |
| orted | | | | | | | |
+==========+=====+======+==========+======+========+==========+=====+
Table 1: Summary of TCP Features for Different Lightweight TCP Implementations
表1：さまざまな軽量TCP実装のためのTCP機能の概要
Legend:
伝説：
(T1): TCP-only, on x86 and AVR platforms
（T1）：TCP専用、x86およびAVRプラットフォーム上
(T2): TCP-only, on ARM Cortex-M platform
（T2）：TCP専用、ARM Cortex-Mプラットフォーム上
(T3): TCP-only, on ARM Cortex-M0+ platform (NOTE: RAM usage for the
same platform is ~2.5 kB for one TCP connection plus ~1.2 kB
for each additional connection)
(T4): TCP-only, on CC2538DK, cross-compiling on Linux
（T4）：TCP専用、CC2538DK、Linuxのクロスコンパイル
(a): Includes IP, ICMP, and TCP on x86 and AVR platforms. The Contiki-NG TCP implementation has a code size of 3.2 kB on CC2538DK, cross-compiling on Linux
（a）：x86およびAVRプラットフォームでIP、ICMP、およびTCPを含む。CONTIKI-NG TCP実装には、CC2538DKで3.2 KBのコードサイズがあり、Linuxのクロスコンパイル
(I): Optional POSIX socket wrapper that enables POSIX compliance if needed
（i）：必要に応じてPOSIXコンプライアンスを可能にするオプションのPOSIXソケットラッパー
Mult.: Multiple
マルチ
N/A: Not Available
N / A：利用できません
Acknowledgments
謝辞
The work of Carles Gomez has been funded in part by the Spanish Government (Ministerio de Educacion, Cultura y Deporte) through Jose Castillejo grants CAS15/00336 and CAS18/00170; the European Regional Development Fund (ERDF); the Spanish Government through projects TEC2016-79988-P, PID2019-106808RA-I00, AEI/FEDER, and UE; and the Generalitat de Catalunya Grant 2017 SGR 376. Part of his contribution to this work has been carried out during his stays as a visiting scholar at the Computer Laboratory of the University of Cambridge.
Carles Gomezの作品は、Jose Castillejo Argants Cas 15/00336とCas 18/00170を通じて、スペイン政府（大臣ededucacion、Cultura y Deporte）によって参加してきました。ヨーロッパの地域開発基金（ERDF）。スペイン政府はプロジェクトを通じてTEC2016-79988-P、PID2019-106808RA-I00、AEI / Feder、およびUE;そして、ジェネラルタイトドカタルーニャグラント2017 SGR 376.この作品への貢献の一部は、ケンブリッジ大学コンピュータ研究所での訪問学者としての滞在中に行われてきました。
The authors appreciate the feedback received for this document. The following folks provided comments that helped improve the document: Carsten Bormann, Zhen Cao, Wei Genyu, Ari Keränen, Abhijan Bhattacharyya, Andres Arcia-Moret, Yoshifumi Nishida, Joe Touch, Fred Baker, Nik Sultana, Kerry Lynn, Erik Nordmark, Markku Kojo, Hannes Tschofenig, David Black, Ilpo Jarvinen, Emmanuel Baccelli, Stuart Cheshire, Gorry Fairhurst, Ingemar Johansson, Ted Lemon, and Michael Tüxen. Simon Brummer provided details and kindly performed Random Access Memory (RAM) and Read-Only Memory (ROM) usage measurements on the RIOT TCP implementation. Xavi Vilajosana provided details on the OpenWSN TCP implementation. Rahul Jadhav kindly performed code size measurements on the Contiki-NG and lwIP 2.1.2 TCP implementations. He also provided details on the uIP TCP implementation.
著者らはこの文書に対して受け取ったフィードバックを感謝します。以下の人々は、文書を改善するのに役立つコメントを提供しました：Carsten Bormann、Zhen Cao、Wei Genyu、AriKeränen、Anhijan Bhattacharyya、Andres Arcia-Moret、Joe Touch、Fred Baker、Nik Sultana、Kerry Lynn、Kerry Lynn、Markku鯉、ザコフェニヒ、デビッドブラック、Ilpo Jarvinen、Emmanuel Baccelli、Stuart Cheshire、Gorry Fairhurst、Ingemar Johansson、Ted Lemon、MichaelTüxen。Simon Brummerは、Riot TCP実装に関するランダムアクセスメモリ（RAM）と読み取り専用メモリ（ROM）の使用測定値を提供しました。Xavi Vilajosana OpenWSN TCP実装の詳細を提供しました。Rahul Jadhavは、Contiki-NGおよびLWIP 2.1.2 TCP実装でコードサイズの測定を行いました。彼はまたUIP TCP実装の詳細を提供しました。
Authors' Addresses
著者の住所
Carles Gomez UPC C/Esteve Terradas, 7 08860 Castelldefels Spain
Carles Gomez UPC C / ESTEVE TERRADAS、7 08860 CastellDefelsスペイン
Email: carlesgo@entel.upc.edu
Jon Crowcroft University of Cambridge JJ Thomson Avenue Cambridge CB3 0FD United Kingdom
Jon Crowcroft大学ケンブリッジJJトムソンアベニューケンブリッジCB3 0FDイギリス
Email: jon.crowcroft@cl.cam.ac.uk
Michael Scharf Hochschule Esslingen University of Applied Sciences Flandernstr. 101 73732 Esslingen am Neckar Germany
Michael Scharf Hochschule Esslingen応用科学大学FLANDERNSTR。101 73732 Esslingen am Neckar Germany
Email: michael.scharf@hs-esslingen.de