RFC 8303 - On the Usage of Transport Features Provided by IETF Transport Protocols 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8303
タイトル : RFC 8303 - IETFトランスポートプロトコルによって提供されるトランスポート機能の利用について
翻訳編集 : 自動生成

[要約] このRFCは、トランスポート層プロトコル（TCP, UDP, SCTP等）がアプリケーションに対して提供する機能（信頼性、順序保証、メッセージ境界など）を、抽象化された「トランスポート機能（Transport Features）」として定義し、それらを利用するためのガイドラインを提供しています。TAPS（トランスポート・プロトコル・スタックの刷新）プロジェクトの成果に基づき、特定のプロトコル名ではなく、アプリケーションが必要とする通信特性（機能）を選択してトランスポート層を柔軟に利用するための概念的枠組みを提示しています。

Internet Engineering Task Force (IETF)                          M. Welzl
Request for Comments: 8303                            University of Oslo
Category: Informational                                        M. Tuexen
ISSN: 2070-1721                         Muenster Univ. of Appl. Sciences
                                                              N. Khademi
                                                      University of Oslo
                                                           February 2018

On the Usage of Transport Features Provided by IETF Transport Protocols

IETFトランスポートプロトコルによって提供されるトランスポート機能の利用について

Abstract

概要

This document describes how the transport protocols Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), and Lightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services. It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. The description results in a set of transport abstractions that can be exported in a transport services (TAPS) API.

このドキュメントでは、トランスポートプロトコルの伝送制御プロトコル（TCP）、マルチパスTCP（MPTCP）、ストリーム制御伝送プロトコル（SCTP）、ユーザーデータグラムプロトコル（UDP）、および軽量ユーザーデータグラムプロトコル（UDP-Lite）がアプリケーションとアプリケーションにサービスを公開する方法について説明しますアプリケーションがこれらのサービスを構成する機能を構成および使用する方法。また、Low Extra Delay Background Transport（LEDBAT）輻輳制御メカニズムによって提供されるサービスについても説明します。説明により、トランスポートサービス（TAPS）APIでエクスポートできるトランスポート抽象化のセットが生成されます。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

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 a candidate for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8303.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8303で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................5
   3. Pass 1 ..........................................................6
      3.1. Primitives Provided by TCP .................................6
           3.1.1. Excluded Primitives or Parameters ...................9
      3.2. Primitives Provided by MPTCP ..............................10
      3.3. Primitives Provided by SCTP ...............................11
           3.3.1. Excluded Primitives or Parameters ..................18
      3.4. Primitives Provided by UDP and UDP-Lite ...................18
      3.5. The Service of LEDBAT .....................................19
   4. Pass 2 .........................................................20
      4.1. CONNECTION-Related Primitives .............................21
      4.2. DATA-Transfer-Related Primitives ..........................38
   5. Pass 3 .........................................................41
      5.1. CONNECTION-Related Transport Features .....................41
      5.2. DATA-Transfer-Related Transport Features ..................47
           5.2.1. Sending Data .......................................47
           5.2.2. Receiving Data .....................................48
           5.2.3. Errors .............................................49
   6. IANA Considerations ............................................49
   7. Security Considerations ........................................49
   8. References .....................................................50
      8.1. Normative References ......................................50
      8.2. Informative References ....................................52
   Appendix A. Overview of RFCs Used as Input for Pass 1 .............54
   Appendix B. How This Document Was Developed .......................54
   Acknowledgements ..................................................56
   Authors' Addresses ................................................56

1. Introduction

1. はじめに

This specification describes how transport protocols offer transport services, such that applications using them are no longer directly tied to a specific protocol. Breaking this strict connection can reduce the effort for an application programmer, yet attain greater transport flexibility by pushing complexity into an underlying transport services (TAPS) system.

この仕様は、トランスポートプロトコルがトランスポートサービスをどのように提供するかを説明し、それらを使用するアプリケーションが特定のプロトコルに直接関連付けられないようにします。この厳密な接続を解除すると、アプリケーションプログラマーの労力を軽減できますが、基礎となるトランスポートサービス（TAPS）システムに複雑さを押し込むことにより、トランスポートの柔軟性を高めることができます。

This design process has started with a survey of the services provided by IETF transport protocols and congestion control mechanisms [RFC8095]. The present document and [RFC8304] complement this survey with an in-depth look at the defined interactions between applications and the following unicast transport protocols: Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), and Lightweight User Datagram Protocol (UDP-Lite). We also define a primitive to enable/disable and configure the Low Extra Delay Background Transport (LEDBAT) unicast congestion control mechanism. For UDP and UDP-Lite, the first step of the protocol analysis -- a discussion of relevant RFC text -- is documented in [RFC8304].

この設計プロセスは、IETFトランスポートプロトコルおよび輻輳制御メカニズム[RFC8095]によって提供されるサービスの調査から始まりました。現在のドキュメントと[RFC8304]は、アプリケーションと次のユニキャストトランスポートプロトコルとの間に定義された相互作用を詳細に調べて、この調査を補足しています。伝送制御プロトコル（TCP）、マルチパスTCP（MPTCP）、ストリーム制御伝送プロトコル（SCTP）、ユーザーデータグラムプロトコル（UDP）、および軽量ユーザーデータグラムプロトコル（UDP-Lite）。また、低追加遅延バックグラウンドトランスポート（LEDBAT）ユニキャスト輻輳制御メカニズムを有効/無効にして構成するためのプリミティブを定義します。 UDPおよびUDP-Liteの場合、プロトコル分析の最初のステップ（関連するRFCテキストの説明）が[RFC8304]に文書化されています。

This snapshot in time of the IETF transport protocols is published as an RFC to document the analysis by the authors and the TAPS Working Group; this generates a set of transport abstractions that can be exported in a TAPS API. It provides the basis for the minimal set of transport services that end systems supporting TAPS should implement [TAPS-MINSET].

IETFトランスポートプロトコルのこの時点でのスナップショットは、作者とTAPSワーキンググループによる分析を文書化するためにRFCとして公開されています。これにより、TAPS APIでエクスポートできるトランスポートアブストラクションのセットが生成されます。 TAPSをサポートするエンドシステムが[TAPS-MINSET]を実装する必要がある最小限のトランスポートサービスのセットの基礎を提供します。

The list of primitives, events, and transport features in this document is strictly based on the parts of protocol specifications that describe what the protocol provides to an application using it and how the application interacts with it. Transport protocols provide communication between processes that operate on network endpoints, which means that they allow for multiplexing of communication between the same IP addresses, and this multiplexing is achieved using port numbers. Port multiplexing is therefore assumed to be always provided and not discussed in this document.

このドキュメントのプリミティブ、イベント、およびトランスポート機能のリストは、プロトコルがそれを使用するアプリケーションに何を提供するか、およびアプリケーションがそれと対話する方法を説明するプロトコル仕様の部分に厳密に基づいています。トランスポートプロトコルは、ネットワークエンドポイント上で動作するプロセス間の通信を提供します。つまり、同じIPアドレス間の通信の多重化を可能にし、この多重化はポート番号を使用して実現されます。したがって、ポートの多重化は常に提供されると想定されており、このドキュメントでは説明していません。

Parts of a protocol that are explicitly stated as optional to implement are not covered. Interactions between the application and a transport protocol that are not directly related to the operation of the protocol are also not covered. For example, there are various ways for an application to use socket options to indicate its interest in receiving certain notifications [RFC6458]. However, for the purpose of identifying primitives, events, and transport features, the ability to enable or disable the reception of notifications is irrelevant. Similarly, "one-to-many style sockets"

実装するオプションとして明示的に述べられているプロトコルの部分はカバーされません。プロトコルの動作に直接関係しないアプリケーションとトランスポートプロトコル間の相互作用についても説明しません。たとえば、アプリケーションがソケットオプションを使用して、特定の通知を受信することに関心があることを示すさまざまな方法があります[RFC6458]。ただし、プリミティブ、イベント、およびトランスポート機能を識別するために、通知の受信を有効または無効にする機能は関係ありません。同様に、「1対多スタイルのソケット」

[RFC6458] just affect the application programming style, not how the underlying protocol operates, and they are therefore not discussed here. The same is true for the ability to obtain the unchanged value of a parameter that an application has previously set (e.g., via "get" in get/set operations [RFC6458]).

[RFC6458]は、基礎となるプロトコルの動作方法ではなく、アプリケーションプログラミングスタイルに影響するだけなので、ここでは説明しません。アプリケーションが以前に設定したパラメーターの変更されていない値を取得する機能（たとえば、get/set操作[RFC6458]の「get」を介して）にも同じことが当てはまります。

The document presents a three-pass process to arrive at a list of transport features. In the first pass (pass 1), the relevant RFC text is discussed per protocol. In the second pass (pass 2), this discussion is used to derive a list of primitives and events that are uniformly categorized across protocols. Here, an attempt is made to present or -- where text describing primitives or events does not yet exist -- construct primitives or events in a slightly generalized form to highlight similarities. This is, for example, achieved by renaming primitives or events of protocols or by avoiding a strict 1:1 mapping between the primitives or events in the protocol specification and primitives or events in the list. Finally, the third pass (pass 3) presents transport features based on pass 2, identifying which protocols implement them.

このドキュメントは、トランスポート機能のリストに到達するための3つのパスのプロセスを示しています。最初のパス（パス1）では、関連するRFCテキストがプロトコルごとに説明されます。 2番目のパス（パス2）では、この説明を使用して、プロトコル全体で均一に分類されるプリミティブとイベントのリストを導出します。ここでは、またはプリミティブまたはイベントを説明するテキストがまだ存在しない場合に、プリミティブまたはイベントを少し一般化された形式で作成して類似性を強調する試みが行われています。これは、たとえば、プロトコルのプリミティブまたはイベントの名前を変更することによって、またはプロトコル仕様のプリミティブまたはイベントとリストのプリミティブまたはイベントの間の厳密な1：1マッピングを回避することによって達成されます。最後に、3番目のパス（パス3）は、パス2に基づくトランスポート機能を示し、どのプロトコルがそれらを実装するかを識別します。

In the list resulting from the second pass, some transport features are missing because they are implicit in some protocols, and they only become explicit when we consider the superset of all transport features offered by all protocols. For example, TCP always carries out congestion control; we have to consider it together with a protocol like UDP (which does not have congestion control) before we can consider congestion control as a transport feature. The complete list of transport features across all protocols is therefore only available after pass 3.

2番目のパスの結果のリストでは、一部のトランスポート機能は一部のプロトコルで暗黙的であるため欠落しており、すべてのプロトコルによって提供されるすべてのトランスポート機能のスーパーセットを検討した場合にのみ明示的になります。たとえば、TCPは常に輻輳制御を実行します。トランスポート機能として輻輳制御を検討する前に、UDP（輻輳制御を持たない）のようなプロトコルと共にそれを検討する必要があります。したがって、すべてのプロトコルにわたるトランスポート機能の完全なリストは、パス3以降でのみ利用できます。

Some protocols are connection oriented. Connection-oriented protocols often use an initial call to a specific primitive to open a connection before communication can progress and require communication to be explicitly terminated by issuing another call to a primitive (usually called 'Close'). A "connection" is the common state that some transport primitives refer to, e.g., to adjust general configuration settings. Connection establishment, maintenance, and termination are therefore used to categorize transport primitives of connection-oriented transport protocols in pass 2 and pass 3. For this purpose, UDP is assumed to be used with "connected" sockets, i.e., sockets that are bound to a specific pair of addresses and ports [RFC8304].

一部のプロトコルは接続指向です。接続指向プロトコルは、特定のプリミティブへの最初の呼び出しを使用して通信を開始する前に接続を開き、プリミティブへの別の呼び出し（通常は「閉じる」と呼ばれます）を発行して通信を明示的に終了する必要があります。「接続」とは、一部のトランスポートプリミティブが、たとえば一般的な構成設定を調整するために参照する一般的な状態です。したがって、接続の確立、保守、および終了は、パス2およびパス3の接続指向のトランスポートプロトコルのトランスポートプリミティブを分類するために使用されます。この目的のために、UDPは「接続された」ソケット、つまり、アドレスとポートの特定のペア[RFC8304]。

2. Terminology

2. 用語

Transport Feature: a specific end-to-end feature that the transport layer provides to an application. Examples include confidentiality, reliable delivery, ordered delivery, message-versus-stream orientation, etc.

トランスポート機能：トランスポート層がアプリケーションに提供する特定のエンドツーエンド機能。例としては、機密性、信頼できる配信、順序付き配信、メッセージ対ストリーム指向などが含まれます。

Transport Service: a set of transport features, without an association to any given framing protocol, which provides a complete service to an application.

トランスポートサービス：特定のフレーミングプロトコルに関連付けられていない一連のトランスポート機能。アプリケーションに完全なサービスを提供します。

Transport Protocol: an implementation that provides one or more transport services using a specific framing and header format on the wire.

トランスポートプロトコル：ワイヤー上で特定のフレーミングおよびヘッダー形式を使用して1つ以上のトランスポートサービスを提供する実装。

Transport Protocol Component: an implementation of a transport feature within a protocol.

トランスポートプロトコルコンポーネント：プロトコル内のトランスポート機能の実装。

Transport Service Instance: an arrangement of transport protocols with a selected set of features and configuration parameters that implement a single transport service, e.g., a protocol stack (RTP over UDP).

トランスポートサービスインスタンス：プロトコルスタック（RTP over UDP）などの単一のトランスポートサービスを実装する、選択された機能と構成パラメーターのセットを備えたトランスポートプロトコルの配置。

Application: an entity that uses the transport layer for end-to-end delivery of data across the network (this may also be an upper-layer protocol or tunnel encapsulation).

アプリケーション：ネットワークを介したエンドツーエンドのデータ配信にトランスポート層を使用するエンティティ（これは、上位層プロトコルまたはトンネルカプセル化の場合もあります）。

Endpoint: an entity that communicates with one or more other endpoints using a transport protocol.

エンドポイント：トランスポートプロトコルを使用して1つ以上の他のエンドポイントと通信するエンティティ。

Connection: shared state of two or more endpoints that persists across messages that are transmitted between these endpoints.

接続：2つ以上のエンドポイントの共有状態。これらのエンドポイント間で送信されるメッセージ全体で持続します。

Primitive: a function call that is used to locally communicate between an application and a transport endpoint. A primitive is related to one or more transport features.

プリミティブ：アプリケーションとトランスポートエンドポイントの間でローカルに通信するために使用される関数呼び出し。プリミティブは、1つ以上のトランスポート機能に関連しています。

Event: a primitive that is invoked by a transport endpoint.

イベント：トランスポートエンドポイントによって呼び出されるプリミティブ。

Parameter: a value passed between an application and a transport protocol by a primitive.

パラメータ：プリミティブによってアプリケーションとトランスポートプロトコルの間で渡される値。

Socket: the combination of a destination IP address and a destination port number.

ソケット：宛先IPアドレスと宛先ポート番号の組み合わせ。

Transport Address: the combination of an IP address, transport protocol, and the port number used by the transport protocol.

トランスポートアドレス：IPアドレス、トランスポートプロトコル、およびトランスポートプロトコルで使用されるポート番号の組み合わせ。

3. Pass 1

3. パス1

This first iteration summarizes the relevant text parts of the RFCs describing the protocols, focusing on what each transport protocol provides to the application and how it is used (abstract API descriptions, where they are available). When presenting primitives, events, and parameters, the use of lower- and upper-case characters is made uniform for the sake of readability.

この最初の反復では、プロトコルを説明するRFCの関連テキスト部分を要約し、各トランスポートプロトコルがアプリケーションに提供するものとそれがどのように使用されるかに焦点を当てています（使用可能な場合は、抽象APIの説明）。プリミティブ、イベント、およびパラメーターを提示する場合、読みやすさのために小文字と大文字の使用は統一されています。

3.1. Primitives Provided by TCP

3.1. TCPが提供するプリミティブ

The initial TCP specification [RFC0793] states:

最初のTCP仕様[RFC0793]は次のように述べています：

The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and in interconnected systems of such networks.

伝送制御プロトコル（TCP）は、パケット交換コンピュータ通信ネットワーク内のホスト間、およびそのようなネットワークの相互接続されたシステム内のホスト間の信頼性の高いホスト間プロトコルとして使用することを目的としています。

Section 3.8 of [RFC0793] further specifies the interaction with the application by listing several transport primitives. It is also assumed that an Operating System provides a means for TCP to asynchronously signal the application; the primitives representing such signals are called 'events' in this section. This section describes the relevant primitives.

[RFC0793]のセクション3.8は、いくつかのトランスポートプリミティブをリストすることで、アプリケーションとの相互作用をさらに指定しています。また、オペレーティングシステムは、TCPがアプリケーションに非同期で信号を送るための手段を提供すると想定されています。このような信号を表すプリミティブは、このセクションでは「イベント」と呼ばれます。このセクションでは、関連するプリミティブについて説明します。

Open: This is either active or passive, to initiate a connection or listen for incoming connections. All other primitives are associated with a specific connection, which is assumed to first have been opened. An active open call contains a socket. A passive open call with a socket waits for a particular connection; alternatively, a passive open call can leave the socket unspecified to accept any incoming connection. A fully specified passive call can later be made active by calling 'Send'. Optionally, a timeout can be specified, after which TCP will abort the connection if data has not been successfully delivered to the destination (else a default timeout value is used). A procedure for aborting the connection is used to avoid excessive retransmissions, and an application is able to control the threshold used to determine the condition for aborting; this threshold may be measured in time units or as a count of retransmission [RFC1122]. This indicates that the timeout could also be specified as a count of retransmission.

オープン：これはアクティブまたはパッシブであり、接続を開始したり、着信接続をリッスンしたりします。他のすべてのプリミティブは特定の接続に関連付けられており、最初に開かれたと見なされます。アクティブなオープンコールにはソケットが含まれています。ソケットを使用するパッシブオープンコールは、特定の接続を待ちます。または、パッシブオープンコールでは、ソケットを未指定のままにして、着信接続を受け入れることができます。完全に指定されたパッシブコールは、後で「送信」を呼び出すことによってアクティブにすることができます。オプションで、タイムアウトを指定できます。その後、データが宛先に正常に配信されなかった場合、TCPは接続を中止します（そうでない場合、デフォルトのタイムアウト値が使用されます）。接続を中止する手順は、過度の再送信を回避するために使用され、アプリケーションは中止の条件を決定するために使用されるしきい値を制御できます。このしきい値は、時間単位で、または再送信のカウントとして測定できます[RFC1122]。これは、タイムアウトを再送信の回数として指定することもできることを示しています。

Also optional, for multihomed hosts, the local IP address can be provided [RFC1122]. If it is not provided, a default choice will be made in case of active open calls. A passive open call will await incoming connection requests to all local addresses and then maintain usage of the local IP address where the incoming connection request has arrived. Finally, the 'options' parameter allows the application to specify IP options such as Source Route, Record Route, or Timestamp [RFC1122]. It is not stated on which segments of a connection these options should be applied, but probably on all segments, as this is also stated in a specification given for the usage of the Source Route IP option (Section 4.2.3.8 of [RFC1122]). Source Route is the only non-optional IP option in this parameter, allowing an application to specify a source route when it actively opens a TCP connection.

また、オプションで、マルチホームホストの場合、ローカルIPアドレスを提供できます[RFC1122]。指定しない場合、アクティブなオープンコールの場合にデフォルトの選択が行われます。パッシブオープンコールは、すべてのローカルアドレスへの着信接続要求を待機し、着信接続要求が到着したローカルIPアドレスの使用を維持します。最後に、「options」パラメータを使用すると、アプリケーションでソースルート、レコードルート、タイムスタンプなどのIPオプションを指定できます[RFC1122]。接続のどのセグメントにこれらのオプションを適用する必要があるかは明記されていませんが、ソースルートIPオプションの使用に関する仕様（[RFC1122]のセクション4.2.3.8）に記載されているため、おそらくすべてのセグメントに適用されます。。ソースルートは、このパラメーターのオプションではない唯一のIPオプションであり、アプリケーションがTCP接続をアクティブに開いたときにソースルートを指定できるようにします。

Master Key Tuples (MKTs) for authentication can optionally be configured when calling 'Open' (Section 7.1 of [RFC5925]). When authentication is in use, complete TCP segments are authenticated, including the TCP IPv4 pseudoheader, TCP header, and TCP data.

認証用のマスターキータプル（MKT）は、「開く」を呼び出すときにオプションで設定できます（[RFC5925]のセクション7.1）。認証が使用されている場合、TCP IPv4疑似ヘッダー、TCPヘッダー、TCPデータを含む完全なTCPセグメントが認証されます。

TCP Fast Open (TFO) [RFC7413] allows applications to immediately hand over a message from the active open to the passive open side of a TCP connection together with the first message establishment packet (the SYN). This can be useful for applications that are sensitive to TCP's connection setup delay. [RFC7413] states that "TCP implementations MUST NOT use TFO by default, but only use TFO if requested explicitly by the application on a per-service-port basis." The size of the message sent with TFO cannot be more than TCP's maximum segment size (minus options used in the SYN). For the active open side, it is recommended to change or replace the connect() call in order to support a user data buffer argument [RFC7413]. For the passive open side, the application needs to enable the reception of Fast Open requests, e.g., via a new TCP_FASTOPEN setsockopt() socket option before listen(). The receiving application must be prepared to accept duplicates of the TFO message, as the first data written to a socket can be delivered more than once to the application on the remote host.

TCP Fast Open（TFO）[RFC7413]を使用すると、アプリケーションは、TCP接続のアクティブオープン側からパッシブオープン側に、最初のメッセージ確立パケット（SYN）とともにメッセージをすぐに渡すことができます。これは、TCPの接続セットアップ遅延の影響を受けやすいアプリケーションに役立ちます。 [RFC7413]は、「TCP実装はデフォルトでTFOを使用してはならず、サービスポートごとにアプリケーションによって明示的に要求された場合にのみTFOを使用する必要がある」と述べています。 TFOで送信されるメッセージのサイズは、TCPの最大セグメントサイズ（SYNで使用されるマイナスオプション）を超えることはできません。アクティブなオープン側では、ユーザーデータバッファー引数[RFC7413]をサポートするために、connect()コールを変更または置き換えることをお勧めします。パッシブオープンサイドの場合、アプリケーションは、Fast Openリクエストの受信を有効にする必要があります。たとえば、listen()の前に新しいTCP_FASTOPEN setsockopt()ソケットオプションを使用します。ソケットに書き込まれた最初のデータは、リモートホスト上のアプリケーションに複数回配信される可能性があるため、受信アプリケーションはTFOメッセージの複製を受け入れる準備をする必要があります。

Send: This is the primitive that an application uses to give the local TCP transport endpoint a number of bytes that TCP should reliably send to the other side of the connection. The 'urgent' flag, if set, states that the data handed over by this send call is urgent and this urgency should be indicated to the receiving process in case the receiving application has not yet consumed all non-urgent data preceding it. An optional timeout parameter can be provided that updates the connection's timeout (see 'Open'). Additionally, optional parameters allow the ability to indicate the preferred outgoing MKT (current_key) and/or the preferred incoming MKT (rnext_key) of a connection (Section 7.1 of [RFC5925]).

送信：これは、TCPが接続の反対側に確実に送信する必要があるバイト数をローカルTCPトランスポートエンドポイントに与えるためにアプリケーションが使用するプリミティブです。「緊急」フラグが設定されている場合は、この送信呼び出しによって渡されたデータが緊急であることを示し、受信アプリケーションがその前のすべての非緊急データをまだ消費していない場合に備えて、この緊急性を受信プロセスに示す必要があります。オプションのタイムアウトパラメータを指定して、接続のタイムアウトを更新できます（「開く」を参照）。さらに、オプションのパラメータを使用すると、接続の優先送信MKT（current_key）や優先受信MKT（rnext_key）を指定できます（[RFC5925]のセクション7.1）。

Receive: This primitive allocates a receiving buffer for a provided number of bytes. It returns the number of received bytes provided in the buffer when these bytes have been received and written into the buffer by TCP. The application is informed of urgent data via an 'urgent' flag: if it is on, there is urgent data; if it is off, there is no urgent data or this call to 'Receive' has returned all the urgent data. The application is also informed about the current_key and rnext_key information carried in a recently received segment via an optional parameter (Section 7.1 of [RFC5925]).

受信：このプリミティブは、指定されたバイト数の受信バッファーを割り当てます。これらのバイトが受信され、TCPによってバッファーに書き込まれたときに、バッファーに提供された受信バイト数を返します。アプリケーションは、「緊急」フラグを介して緊急データを通知されます。オンの場合、緊急データがあります。オフの場合、緊急データはないか、この 'Receive'の呼び出しによりすべての緊急データが返されました。アプリケーションは、オプションのパラメーターを介して、最近受信したセグメントで運ばれるcurrent_keyおよびrnext_key情報についても通知されます（[RFC5925]のセクション7.1）。

Close: This primitive closes one side of a connection. It is semantically equivalent to "I have no more data to send" but does not mean "I will not receive any more", as the other side may still have data to send. This call reliably delivers any data that has already been given to TCP (and if that fails, 'Close' becomes 'abort').

Close：このプリミティブは、接続の片側を閉じます。これは、意味的には「送信するデータがない」と同じですが、「もう受信しない」という意味ではありません。相手側に送信するデータがある可能性があるためです。この呼び出しは、TCPにすでに与えられているすべてのデータを確実に配信します（失敗した場合、「閉じる」は「中止」になります）。

Abort: This primitive causes all pending 'Send' and 'Receive' calls to be aborted. A TCP "RESET" message is sent to the TCP endpoint on the other side of the connection [RFC0793].

中止：このプリミティブにより、保留中のすべての「送信」および「受信」呼び出しが中止されます。 TCP "RESET"メッセージは、接続の反対側のTCPエンドポイントに送信されます[RFC0793]。

Close Event: TCP uses this primitive to inform an application that the application on the other side has called the 'Close' primitive, so the local application can also issue a 'Close' and terminate the connection gracefully. See [RFC0793], Section 3.5.

Closeイベント：TCPはこのプリミティブを使用して、反対側のアプリケーションが「Close」プリミティブを呼び出したことをアプリケーションに通知します。したがって、ローカルアプリケーションも「Close」を発行して接続を正常に終了できます。 [RFC0793]、セクション3.5をご覧ください。

Abort Event: When TCP aborts a connection upon receiving a "RESET" from the peer, it "advises the user and goes to the CLOSED state." See [RFC0793], Section 3.4.

中止イベント：ピアから「リセット」を受信したときにTCPが接続を中止すると、「ユーザーに通知してCLOSED状態になります」。 [RFC0793]のセクション3.4をご覧ください。

User Timeout Event: This event is executed when the user timeout (Section 3.9 of [RFC0793]) expires (see the definition of 'Open' in this section). All queues are flushed, and the application is informed that the connection had to be aborted due to user timeout.

ユーザータイムアウトイベント：このイベントは、ユーザータイムアウト（[RFC0793]のセクション3.9）が期限切れになると実行されます（このセクションの「開く」の定義を参照）。すべてのキューがフラッシュされ、ユーザータイムアウトのために接続を中止する必要があることがアプリケーションに通知されます。

Error_Report event: This event informs the application of "soft errors" that can be safely ignored [RFC5461], including the arrival of an ICMP error message or excessive retransmissions (reaching a threshold below the threshold where the connection is aborted). See Section 4.2.4.1 of [RFC1122].

Error_Reportイベント：このイベントは、安全に無視できる[ソフトエラー]をアプリケーションに通知します[RFC5461]。これには、ICMPエラーメッセージの到着や過度の再送信（接続が中止されるしきい値を下回るしきい値に達する）が含まれます。 [RFC1122]のセクション4.2.4.1を参照してください。

Type-of-Service: Section 4.2.4.2 of the requirements for Internet hosts [RFC1122] states that "The application layer MUST be able to specify the Type-of-Service (TOS) for segments that are sent on a connection." The application should be able to change the TOS during the connection lifetime, and the TOS value should be passed to the IP layer unchanged. Since then, the TOS field has been redefined. The Differentiated Services (Diffserv) model [RFC2475] [RFC3260] replaces this field in the IP header, assigning the six most significant bits to carry the Differentiated Services Code Point (DSCP) field [RFC2474].

Type-of-Service：インターネットホストの要件のセクション4.2.4.2 [RFC1122]には、「アプリケーションレイヤーは、接続で送信されるセグメントのType-of-Service（TOS）を指定できなければならない」と述べています。アプリケーションは接続の存続期間中にTOSを変更でき、TOS値は変更されずにIP層に渡される必要があります。その後、TOSフィールドが再定義されました。 Differentiated Services（Diffserv）モデル[RFC2475] [RFC3260]は、IPヘッダーのこのフィールドを置き換え、Differentiated Services Code Point（DSCP）フィールド[RFC2474]を伝送するために最上位6ビットを割り当てます。

Nagle: The Nagle algorithm delays sending data for some time to increase the likelihood of sending a full-sized segment (Section 4.2.3.4 of [RFC1122]). An application can disable the Nagle algorithm for an individual connection.

Nagle：Nagleアルゴリズムは、フルサイズのセグメントを送信する可能性を高めるために、データの送信をしばらく遅延させます（[RFC1122]のセクション4.2.3.4）。アプリケーションは、個々の接続に対してNagleアルゴリズムを無効にすることができます。

User Timeout Option: The User Timeout Option (UTO) [RFC5482] allows one end of a TCP connection to advertise its current user timeout value so that the other end of the TCP connection can adapt its own user timeout accordingly. In addition to the configurable value of the user timeout (see 'Send'), there are three per-connection state variables that an application can adjust to control the operation of the UTO: 'adv_uto' is the value of the UTO advertised to the remote TCP peer (default: system-wide default user timeout); 'enabled' (default false) is a boolean-type flag that controls whether the UTO option is enabled for a connection. This applies to both sending and receiving. 'changeable' is a boolean-type flag (default true) that controls whether the user timeout may be changed based on a UTO option received from the other end of the connection. 'changeable' becomes false when an application explicitly sets the user timeout (see 'Send').

ユーザータイムアウトオプション：ユーザータイムアウトオプション（UTO）[RFC5482]を使用すると、TCP接続の一方の端で現在のユーザータイムアウト値をアドバタイズできるため、TCP接続のもう一方の端で独自のユーザータイムアウトを適切に調整できます。ユーザータイムアウトの構成可能な値（「送信」を参照）に加えて、アプリケーションがUTOの操作を制御するために調整できる接続ごとの状態変数が3つあります。「adv_uto」は、アドバタイズされたUTOの値です。リモートTCPピア（デフォルト：システム全体のデフォルトのユーザータイムアウト）; 'enabled'（デフォルトはfalse）は、接続に対してUTOオプションを有効にするかどうかを制御するブール型のフラグです。これは送信と受信の両方に適用されます。 'changeable'は、接続の反対側から受信したUTOオプションに基づいてユーザータイムアウトを変更できるかどうかを制御するブール型のフラグ（デフォルトはtrue）です。アプリケーションがユーザータイムアウトを明示的に設定すると、「変更可能」はfalseになります（「送信」を参照）。

Set/Get Authentication Parameters: The preferred outgoing MKT (current_key) and/or the preferred incoming MKT (rnext_key) of a connection can be configured. Information about current_key and rnext_key carried in a recently received segment can be retrieved (Section 7.1 of [RFC5925]).

認証パラメータの設定/取得：接続の優先送信MKT（current_key）および/または優先受信MKT（rnext_key）を構成できます。最近受信したセグメントに含まれるcurrent_keyとrnext_keyに関する情報を取得できます（[RFC5925]のセクション7.1）。

3.1.1. Excluded Primitives or Parameters

3.1.1. 除外されたプリミティブまたはパラメーター

The 'Open' primitive can be handed optional precedence or security/ compartment information [RFC0793], but this was not included here because it is mostly irrelevant today [RFC7414].

「Open」プリミティブは、オプションの優先順位またはセキュリティ/コンパートメント情報を渡すことができます[RFC0793]が、今日はほとんど関係がないため、ここには含まれていません[RFC7414]。

   The 'Status' primitive was not included because the initial TCP
   specification describes this primitive as "implementation dependent"
   and states that it "could be excluded without adverse effect"
   [RFC0793].  Moreover, while a data block containing specific
   information is described, it is also stated that not all of this
   information may always be available.  While [RFC5925] states that
   'Status' "SHOULD be augmented to allow the MKTs of a current or
   pending connection to be read (for confirmation)", the same
   information is also available via 'Receive', which, following
   [RFC5925], "MUST be augmented" with that functionality.  The 'Send'
   primitive includes an optional 'push' flag which, if set, requires
   data to be promptly transmitted to the receiver without delay
   [RFC0793]; the 'Receive' primitive described in can (under some
   conditions) yield the status of the 'push' flag.  Because "push"
   functionality is optional to implement for both the 'Send' and
   'Receive' primitives [RFC1122], this functionality is not included
   here.  The requirements for Internet hosts [RFC1122] also introduce
   keep-alives to TCP, but these are optional to implement and hence not
   considered here.  The same document also describes that "some TCP
   implementations have included a FLUSH call", indicating that this
   call is also optional to implement; therefore, it is not considered
   here.

3.2. Primitives Provided by MPTCP

3.2. MPTCPが提供するプリミティブ

MPTCP is an extension to TCP that allows the use of multiple paths for a single data stream. It achieves this by creating different so-called TCP subflows for each of the interfaces and scheduling the traffic across these TCP subflows. The service provided by MPTCP is described as follows in [RFC6182]:

MPTCPはTCPの拡張機能で、単一のデータストリームに複数のパスを使用できます。これは、インターフェイスごとに異なるいわゆるTCPサブフローを作成し、これらのTCPサブフロー全体でトラフィックをスケジュールすることによって実現します。 MPTCPによって提供されるサービスは、[RFC6182]で次のように説明されています。

Multipath TCP MUST follow the same service model as TCP [RFC0793]: in-order, reliable, and byte-oriented delivery. Furthermore, a Multipath TCP connection SHOULD provide the application with no worse throughput or resilience than it would expect from running a single TCP connection over any one of its available paths.

マルチパスTCPは、TCP [RFC0793]と同じサービスモデルに従わなければなりません (MUST)：順序正しく、信頼性があり、バイト指向の配信。さらに、マルチパスTCP接続は、利用可能なパスのいずれかを介して単一のTCP接続を実行することから期待されるよりも悪いスループットや回復力をアプリケーションに提供すべきです（SHOULD）。

Further, there are some constraints on the API exposed by MPTCP, as stated in [RFC6182]:

さらに、[RFC6182]で述べられているように、MPTCPによって公開されるAPIにはいくつかの制約があります。

A multipath-capable equivalent of TCP MUST retain some level of backward compatibility with existing TCP APIs, so that existing applications can use the newer transport merely by upgrading the operating systems of the end hosts.

既存のアプリケーションがエンドホストのオペレーティングシステムをアップグレードするだけで新しいトランスポートを使用できるよう、TCPのマルチパス対応版は、既存のTCP APIとの一定レベルの後方互換性を保たなければなりません (MUST)。

As such, the primitives provided by MPTCP are equivalent to the ones provided by TCP. Nevertheless, the MPTCP RFCs [RFC6824] and [RFC6897] clarify some parts of TCP's primitives with respect to MPTCP and add some extensions for better control on MPTCP's subflows. Hereafter is a list of the clarifications and extensions the above-cited RFCs provide to TCP's primitives.

そのため、MPTCPが提供するプリミティブは、TCPが提供するプリミティブと同等です。それにもかかわらず、MPTCP RFC [RFC6824]および[RFC6897]は、MPTCPに関するTCPのプリミティブの一部を明確にし、MPTCPのサブフローをより適切に制御するためにいくつかの拡張機能を追加します。以下は、上記のRFCがTCPのプリミティブに提供する明確化と拡張のリストです。

Open: "An application should be able to request to turn on or turn off the usage of MPTCP" [RFC6897]. This functionality can be provided through a socket option called 'tcp_multipath_enable'. Further, MPTCP must be disabled in case the application is binding to a specific address [RFC6897].

開く：「アプリケーションは、MPTCPの使用をオンまたはオフにするように要求できる必要があります」[RFC6897]。この機能は、「tcp_multipath_enable」と呼ばれるソケットオプションを通じて提供できます。さらに、アプリケーションが特定のアドレスにバインドしている場合は、MPTCPを無効にする必要があります[RFC6897]。

Send/Receive: The sending and receiving of data does not require any changes to the application when MPTCP is being used [RFC6824]. The MPTCP-layer will take one input data stream from an application, and split it into one or more subflows, with sufficient control information to allow it to be reassembled and delivered reliably and in order to the recipient application.

送受信：MPTCPが使用されている場合、データの送受信でアプリケーションを変更する必要はありません[RFC6824]。 MPTCP層は、アプリケーションから1つの入力データストリームを受け取り、それを1つまたは複数のサブフローに分割します。十分な制御情報を使用して、再構築し、受信側アプリケーションに確実に配信できるようにします。

The use of the Urgent Pointer is special in MPTCP [RFC6824], which states: "a TCP subflow MUST NOT use the Urgent Pointer to interrupt an existing mapping."

緊急ポインターの使用はMPTCP [RFC6824]で特別であり、「TCPサブフローは、既存のマッピングを中断するために緊急ポインターを使用してはなりません（MUST NOT）」。

Address and Subflow Management: MPTCP uses different addresses and allows a host to announce these addresses as part of the protocol. The MPTCP API Considerations RFC [RFC6897] says "An application should be able to restrict MPTCP to binding to a given set of addresses" and thus allows applications to limit the set of addresses that are being used by MPTCP. Further, "An application should be able to obtain information on the pairs of addresses used by the MPTCP subflows."

アドレスとサブフローの管理：MPTCPは異なるアドレスを使用し、ホストがこれらのアドレスをプロトコルの一部としてアナウンスできるようにします。 MPTCP APIに関する考慮事項RFC [RFC6897]は、「アプリケーションはMPTCPを特定のアドレスセットへのバインドに制限できる必要がある」と述べており、アプリケーションがMPTCPによって使用されているアドレスセットを制限できるようにします。さらに、「アプリケーションは、MPTCPサブフローで使用されるアドレスのペアに関する情報を取得できる必要があります。」

3.3. Primitives Provided by SCTP

3.3. SCTPが提供するプリミティブ

TCP has a number of limitations that SCTP removes (Section 1.1 of [RFC4960]). The following three removed limitations directly translate into transport features that are visible to an application using SCTP: 1) it allows for preservation of message delimiters; 2) it does not provide in-order or reliable delivery unless the application wants that; 3) multihoming is supported. In SCTP, connections are called "associations" and they can be between not only two (as in TCP) but multiple addresses at each endpoint.

TCPには、SCTPによって削除されるいくつかの制限があります（[RFC4960]のセクション1.1）。削除された次の3つの制限は、SCTPを使用するアプリケーションに表示されるトランスポート機能に直接変換されます。1）メッセージ区切り文字の保持を可能にします。 2）アプリケーションが必要としない限り、順序どおりの配信や信頼性の高い配信は提供されません。 3）マルチホーミングがサポートされています。 SCTPでは、接続は「アソシエーション」と呼ばれ、2つの（TCPの場合のような）間だけでなく、各エンドポイントの複数のアドレス間でも可能です。

Section 10 of the SCTP base protocol specification [RFC4960] specifies the interaction with the application (which SCTP calls the "Upper-Layer Protocol (ULP)"). It is assumed that the Operating System provides a means for SCTP to asynchronously signal the application; the primitives representing such signals are called 'events' in this section. Here, we describe the relevant primitives. In addition to the abstract API described in Section 10 of [RFC4960], an extension to the sockets API is described in [RFC6458]. This covers the functionality of the base protocol [RFC4960] and some of its extensions [RFC3758] [RFC4895] [RFC5061]. For other protocol extensions [RFC6525] [RFC6951] [RFC7053] [RFC7496] [RFC7829]

SCTP基本プロトコル仕様[RFC4960]のセクション10は、アプリケーション（SCTPが「上位層プロトコル（ULP）と呼ぶ」との対話を指定しています。オペレーティングシステムは、SCTPがアプリケーションに非同期に信号を送るための手段を提供すると想定されています。このような信号を表すプリミティブは、このセクションでは「イベント」と呼ばれます。ここでは、関連するプリミティブについて説明します。 [RFC4960]のセクション10で説明されている抽象APIに加えて、ソケットAPIの拡張機能が[RFC6458]で説明されています。これは、基本プロトコル[RFC4960]とその拡張機能[RFC3758] [RFC4895] [RFC5061]の機能をカバーしています。他のプロトコル拡張[RFC6525] [RFC6951] [RFC7053] [RFC7496] [RFC7829]

[RFC8260], the corresponding extensions of the sockets API are specified in these protocol specifications. The functionality exposed to the ULP through all these APIs is considered here.

[RFC8260]、ソケットAPIの対応する拡張機能は、これらのプロトコル仕様で指定されています。これらすべてのAPIを通じてULPに公開される機能は、ここで考慮されます。

The abstract API contains a 'SetProtocolParameters' primitive that allows elements of a parameter list [RFC4960] to be adjusted; it is stated that SCTP implementations "may allow ULP to customize some of these protocol parameters", indicating that none of the elements of this parameter list are mandatory to make ULP configurable. Thus, we only consider the parameters in the abstract API that are also covered in one of the other RFCs listed above, which leads us to exclude the parameters 'RTO.Alpha', 'RTO.Beta', and 'HB.Max.Burst'. For clarity, we also replace 'SetProtocolParameters' itself with primitives that adjust parameters or groups of parameters that fit together.

抽象APIには、パラメータリスト[RFC4960]の要素を調整できる「SetProtocolParameters」プリミティブが含まれています。 SCTP実装は「ULPがこれらのプロトコルパラメータの一部をカスタマイズできるようにする」と述べられており、このパラメータリストのどの要素もULPを構成可能にするために必須ではないことを示しています。したがって、上記にリストされた他のRFCの1つでもカバーされている抽象APIのパラメーターのみを考慮するため、パラメーター 'RTO.Alpha'、 'RTO.Beta'、および 'HB.Max.Burstが除外されます。 '。わかりやすくするために、「SetProtocolParameters」自体も、パラメータまたはパラメータグループを調整して調整するプリミティブに置き換えます。

Initialize: Initialize creates a local SCTP instance that it binds to a set of local addresses (and, if provided, a local port number) [RFC4960]. Initialize needs to be called only once per set of local addresses. A number of per-association initialization parameters can be used when an association is created, but before it is connected (via the primitive 'Associate' below): the maximum number of inbound streams the application is prepared to support, the maximum number of attempts to be made when sending the INIT (the first message of association establishment), and the maximum retransmission timeout (RTO) value to use when attempting an INIT [RFC6458]. At this point, before connecting, an application can also enable UDP encapsulation by configuring the remote UDP encapsulation port number [RFC6951].

Initialize：Initializeは、ローカルSCTPインスタンスを作成します。このインスタンスは、一連のローカルアドレス（および、指定されている場合はローカルポート番号）[RFC4960]にバインドします。 Initializeは、ローカルアドレスのセットごとに1回だけ呼び出す必要があります。アソシエーションの作成時に、アソシエーションごとにいくつかの初期化パラメーターを使用できますが、アソシエーションが接続される前に（以下のプリミティブ「Associate」を介して）、アプリケーションがサポートする準備ができているインバウンドストリームの最大数、最大試行回数INIT（アソシエーション確立の最初のメッセージ）を送信するときに行われ、INIT [RFC6458]を試行するときに使用する最大再送信タイムアウト（RTO）値。この時点で、アプリケーションは接続する前に、リモートUDPカプセル化ポート番号[RFC6951]を構成することにより、UDPカプセル化を有効にすることもできます。

Associate: This creates an association (the SCTP equivalent of a connection) that connects the local SCTP instance and a remote SCTP instance. To identify the remote endpoint, it can be given one or multiple (using "connectx") sockets (Section 9.9 of [RFC6458]). Most primitives are associated with a specific association, which is assumed to first have been created. Associate can return a list of destination transport addresses so that multiple paths can later be used. One of the returned sockets will be selected by the local endpoint as the default primary path for sending SCTP packets to this peer, but this choice can be changed by the application using the list of destination addresses. Associate is also given the number of outgoing streams to request and optionally returns the number of negotiated outgoing streams. An optional parameter of 32 bits, the adaptation layer indication, can be provided [RFC5061]. If authenticated chunks are used, the chunk types required to be sent authenticated by the peer can be provided [RFC4895]. An 'SCTP_Cant_Str_Assoc' notification is used to inform the application of a failure to create an association [RFC6458]. An application could use sendto() or sendmsg() to implicitly set up an association, thereby handing over a message that SCTP might send during the association setup phase [RFC6458]. Note that this mechanism is different from TCP's TFO mechanism: the message would arrive only once, after at least one RTT, as it is sent together with the third message exchanged during association setup, the COOKIE-ECHO chunk).

関連付け：これにより、ローカルSCTPインスタンスとリモートSCTPインスタンスを接続する関連付け（接続に相当するSCTP）が作成されます。リモートエンドポイントを識別するために、1つまたは複数の（「connectx」を使用して）ソケットを指定できます（[RFC6458]のセクション9.9）。ほとんどのプリミティブは特定の関連付けに関連付けられており、最初に作成されたと見なされます。 Associateは宛先トランスポートアドレスのリストを返すことができるため、後で複数のパスを使用できます。返されたソケットの1つは、ローカルエンドポイントによって、このピアにSCTPパケットを送信するためのデフォルトのプライマリパスとして選択されますが、この選択は、宛先アドレスのリストを使用するアプリケーションによって変更できます。アソシエイトには、要求する発信ストリームの数も与えられ、オプションでネゴシエートされた発信ストリームの数を返します。 32ビットのオプションのパラメーターであるアダプテーション層の表示を提供できます[RFC5061]。認証されたチャンクが使用される場合、ピアによって認証されて送信される必要があるチャンクタイプを提供することができます[RFC4895]。 'SCTP_Cant_Str_Assoc'通知は、アソシエーションの作成の失敗をアプリケーションに通知するために使用されます[RFC6458]。アプリケーションは、sendto()またはsendmsg()を使用して関連付けを暗黙的にセットアップし、それによって、関連付けセットアップフェーズ中にSCTPが送信するメッセージを引き渡すことができます[RFC6458]。このメカニズムはTCPのTFOメカニズムとは異なることに注意してください。メッセージは、アソシエーションのセットアップ中に交換される3番目のメッセージであるCOOKIE-ECHOチャンクと一緒に送信されるため、少なくとも1つのRTTの後で1回だけ到着します。

Send: This sends a message of a certain length in bytes over an association. A number can be provided to later refer to the correct message when reporting an error, and a stream id is provided to specify the stream to be used inside an association (we consider this as a mandatory parameter here for simplicity: if not provided, the stream id defaults to 0). A condition to abandon the message can be specified (for example limiting the number of retransmissions or the lifetime of the user message). This allows control of the partial reliability extension [RFC3758] [RFC7496]. An optional maximum lifetime can specify the time after which the message should be discarded rather than sent. A choice (advisory, i.e., not guaranteed) of the preferred path can be made by providing a socket, and the message can be delivered out-of-order if the 'unordered' flag is set. An advisory flag indicates that the peer should not delay the acknowledgement of the user message provided [RFC7053]. Another advisory flag indicates whether the application prefers to avoid bundling user data with other outbound DATA chunks (i.e., in the same packet). A payload protocol-id can be provided to pass a value that indicates the type of payload protocol data to the peer. If authenticated chunks are used, the key identifier for authenticating DATA chunks can be provided [RFC4895].

送信：これは、関連付けを介してバイト単位で特定の長さのメッセージを送信します。後でエラーを報告するときに正しいメッセージを参照するために番号を指定できます。関連付け内で使用するストリームを指定するためにストリームIDを指定します（ここでは、簡単にするためにこれを必須パラメーターと見なします。指定しない場合は、ストリームIDのデフォルトは0です）。メッセージを破棄する条件を指定できます（たとえば、再送信の数やユーザーメッセージの有効期間を制限します）。これにより、部分信頼性拡張[RFC3758] [RFC7496]を制御できます。オプションの最大有効期間は、メッセージが送信されるのではなく破棄されるまでの時間を指定できます。優先パスの選択（助言、つまり保証されない）は、ソケットを提供することによって行うことができ、「順序付けられていない」フラグが設定されている場合、メッセージは順序どおりに配信されない可能性があります。助言フラグは、ピアが提供されたユーザーメッセージ[RFC7053]の確認応答を遅延させてはならないことを示します。別の助言フラグは、アプリケーションがユーザーデータを他の送信DATAチャンク（つまり、同じパケット内）にバンドルすることを避けることを好むかどうかを示します。ペイロードプロトコルデータのタイプを示す値をピアに渡すために、ペイロードプロトコルIDを提供できます。認証されたチャンクが使用される場合、DATAチャンクを認証するためのキー識別子を提供できます[RFC4895]。

Receive: Messages are received from an association, and optionally a stream within the association, with their size returned. The application is notified of the availability of data via a 'Data Arrive' notification. If the sender has included a payload protocol-id, this value is also returned. If the received message is only a partial delivery of a whole message, a 'partial' flag will indicate so, in which case the stream id and a stream sequence number are provided to the application.

受信：アソシエーションからメッセージが受信され、オプションでアソシエーション内のストリームが受信され、サイズが返されます。アプリケーションは、「データ到着」通知を介してデータの可用性を通知されます。送信者がペイロードのプロトコルIDを含めた場合、この値も返されます。受信したメッセージがメッセージ全体の一部のみの配信である場合、「部分的」フラグがそうであることを示します。この場合、ストリームIDとストリームシーケンス番号がアプリケーションに提供されます。

Shutdown: This primitive gracefully closes an association, reliably delivering any data that has already been handed over to SCTP. A parameter lets the application control whether further receive or send operations or both are disabled when the call is issued. A return code informs about success or failure of this procedure.

シャットダウン：このプリミティブは関連付けを適切に閉じ、すでにSCTPに渡されたデータを確実に配信します。パラメータを使用すると、アプリケーションは、呼び出しが発行されたときに、以降の受信操作または送信操作、あるいはその両方を無効にするかどうかを制御できます。戻りコードは、この手順の成功または失敗を通知します。

Abort: This ungracefully closes an association, by discarding any locally queued data and informing the peer that the association was aborted. Optionally, an abort reason to be passed to the peer may be provided by the application. A return code informs about success or failure of this procedure.

中止：これは、ローカルでキューに入れられたデータを破棄し、関連付けが中止されたことをピアに通知することで、関連付けを不注意に閉じます。必要に応じて、ピアに渡される中止理由がアプリケーションによって提供されます。戻りコードは、この手順の成功または失敗を通知します。

Change Heartbeat / Request Heartbeat: This allows the application to enable/disable heartbeats and optionally specify a heartbeat frequency as well as requesting a single heartbeat to be carried out upon a function call, with a notification about success or failure of transmitting the HEARTBEAT chunk to the destination.

ハートビートの変更/ハートビートの要求：これにより、アプリケーションはハートビートを有効/無効にしたり、オプションでハートビート頻度を指定したり、関数呼び出し時に単一のハートビートを実行したり、HEARTBEATチャンクの送信の成功または失敗に関する通知を要求したりできます。目的地。

Configure Max. Retransmissions of an Association: The parameter 'Association.Max.Retrans' [RFC4960] (called "sasoc_maxrxt" in the SCTP sockets API extensions [RFC6458]) allows the configuration of the number of unsuccessful retransmissions after which an entire association is considered as failed; this should invoke a 'Communication Lost' notification.

最大を構成します。アソシエーションの再送信：パラメータ 'Association.Max.Retrans' [RFC4960]（SCTPソケットAPI拡張[RFC6458]では "sasoc_maxrxt"と呼ばれます）により、アソシエーション全体が失敗したと見なされるまでの再送信の失敗回数を設定できます。 ;これにより、「通信喪失」通知が呼び出されます。

Set Primary: This allows the ability to set a new primary default path for an association by providing a socket. Optionally, a default source address to be used in IP datagrams can be provided.

プライマリの設定：ソケットを提供することで、関連付けの新しいプライマリデフォルトパスを設定できます。オプションで、IPデータグラムで使用されるデフォルトの送信元アドレスを指定できます。

Change Local Address / Set Peer Primary: This allows an endpoint to add/remove local addresses to/from an association. In addition, the peer can be given a hint for which address to use as the primary address [RFC5061].

ローカルアドレスの変更/ピアプライマリの設定：これにより、エンドポイントはローカルアドレスを関連付けに追加したり、関連付けから削除したりできます。さらに、ピアには、プライマリアドレスとして使用するアドレスのヒントを与えることができます[RFC5061]。

Configure Path Switchover: The abstract API contains a primitive called 'Set Failure Threshold' [RFC4960]. This configures the parameter 'Path.Max.Retrans', which determines after how many retransmissions a particular transport address is considered as unreachable. If there are more transport addresses available in an association, reaching this limit will invoke a path switchover. An extension called "SCTP-PF" adds a concept of "Potentially Failed (PF)" paths to this method [RFC7829]. When a path is in PF state, SCTP will not entirely give up sending on that path, but it will preferably send data on other active paths if such paths are available. Entering the PF state is done upon exceeding a configured maximum number of retransmissions. Thus, for all paths where this mechanism is used, there are two configurable error thresholds: one to decide that a path is in PF state, and one to decide that the transport address is unreachable.

パスの切り替えの構成：抽象APIには、「Set Failure Threshold」というプリミティブが含まれています[RFC4960]。これは、パラメーター 'Path.Max.Retrans'を構成します。これは、特定のトランスポートアドレスが到達不能と見なされる再送信回数を決定します。アソシエーションで使用可能なトランスポートアドレスがさらにある場合、この制限に達すると、パススイッチオーバーが呼び出されます。「SCTP-PF」と呼ばれる拡張機能は、「Potentially Failed（PF）」パスの概念をこのメソッドに追加します[RFC7829]。パスがPF状態の場合、SCTPはそのパスでの送信を完全に中止するわけではありませんが、他のアクティブなパスが使用可能な場合は、そのパスでデータを送信することが望ましいです。 PF状態に入るのは、構成済みの再送信の最大数を超えると行われます。したがって、このメカニズムが使用されるすべてのパスには、2つの構成可能なエラーしきい値があります。1つはパスがPF状態であることを決定するためのもので、もう1つはトランスポートアドレスが到達不能であることを決定するためのものです。

Set/Get Authentication Parameters: This allows an endpoint to add/ remove key material to/from an association. In addition, the chunk types being authenticated can be queried [RFC4895].

認証パラメータの設定/取得：これにより、エンドポイントは、関連付けに対してキーマテリアルを追加/削除できます。さらに、認証されているチャンクタイプを照会できます[RFC4895]。

Add/Reset Streams, Reset Association: This allows an endpoint to add streams to an existing association or to reset them individually. Additionally, the association can be reset [RFC6525].

ストリームの追加/リセット、関連付けのリセット：これにより、エンドポイントはストリームを既存の関連付けに追加したり、個別にリセットしたりできます。さらに、関連付けはリセットできます[RFC6525]。

Status: The 'Status' primitive returns a data block with information about a specified association, containing: an association connection state; a destination transport address list; destination transport address reachability states; current local and peer receiver window sizes; current local congestion window sizes; number of unacknowledged DATA chunks; number of DATA chunks pending receipt; a primary path; the most recent Smoothed Round-Trip Time (SRTT) on a primary path; RTO on a primary path; SRTT and RTO on other destination addresses [RFC4960]; and an MTU per path [RFC6458].

ステータス：「ステータス」プリミティブは、指定された関連付けに関する情報を含むデータブロックを返します。宛先トランスポートアドレスリスト;宛先トランスポートアドレスの到達可能性の状態。現在のローカルおよびピアレシーバーウィンドウのサイズ。現在のローカルの輻輳ウィンドウサイズ。未確認のDATAチャンクの数。受信保留中のDATAチャンクの数。プライマリパス;プライマリパス上の最新の平滑化ラウンドトリップ時間（SRTT）。プライマリパスのRTO。他の宛先アドレスのSRTTおよびRTO [RFC4960];パスごとのMTU [RFC6458]。

Enable/Disable Interleaving: This allows the negotiation of user message interleaving support for future associations to be enabled or disabled. For existing associations, it is possible to query whether user message interleaving support was negotiated or not on a particular association [RFC8260].

インターリーブの有効化/無効化：これにより、ユーザーメッセージインターリービングサポートのネゴシエーションを有効にしたり無効にしたりできるようになります。既存のアソシエーションの場合、特定のアソシエーションでユーザーメッセージインターリービングのサポートがネゴシエートされたかどうかを照会できます[RFC8260]。

Set Stream Scheduler: This allows the ability to select a stream scheduler per association, with a choice of: First-Come, First-Served; Round-Robin; Round-Robin per Packet; Priority-Based; Fair Bandwidth; and Weighted Fair Queuing [RFC8260].

ストリームスケジューラの設定：これにより、関連付けごとにストリームスケジューラを選択でき、次の選択肢があります。ラウンドロビン;パケットごとのラウンドロビン。優先度ベース;公平な帯域幅;および重み付けされたフェアキューイング[RFC8260]。

Configure Stream Scheduler: This allows the ability to change a parameter per stream for the schedulers: a priority value for the Priority-Based scheduler and a weight for the Weighted Fair Queuing scheduler.

ストリームスケジューラの構成：これにより、スケジューラーのストリームごとのパラメーターを変更できます。優先度ベースのスケジューラーの優先度の値と、均等化キュースケジューラーの重みです。

Enable/Disable NoDelay: This turns on/off any Nagle-like algorithm for an association [RFC6458].

NoDelayの有効化/無効化：これは、関連付けのNagleのようなアルゴリズムをオン/オフにします[RFC6458]。

Configure Send Buffer Size: This controls the amount of data SCTP may have waiting in internal buffers to be sent or retransmitted [RFC6458].

送信バッファサイズの構成：これは、SCTPが送信または再送信される内部バッファで待機しているデータの量を制御します[RFC6458]。

Configure Receive Buffer Size: This sets the receive buffer size in octets, thereby controlling the receiver window for an association [RFC6458].

受信バッファサイズの構成：これは受信バッファサイズをオクテットで設定し、それによって関連付けの受信ウィンドウを制御します[RFC6458]。

Configure Message Fragmentation: If a user message causes an SCTP packet to exceed the maximum fragmentation size (which can be provided by the application and is otherwise the Path MTU (PMTU) size), then the message will be fragmented by SCTP. Disabling message fragmentation will produce an error instead of fragmenting the message [RFC6458].

メッセージの断片化の構成：ユーザーメッセージによってSCTPパケットが最大の断片化サイズ（アプリケーションによって提供され、それ以外の場合はパスMTU（PMTU）サイズ）を超える場合、メッセージはSCTPによって断片化されます。メッセージの断片化を無効にすると、メッセージを断片化する代わりにエラーが生成されます[RFC6458]。

Configure Path MTU Discovery: Path MTU Discovery (PMTUD) can be enabled or disabled per peer address of an association (Section 8.1.12 of [RFC6458]). When it is enabled, the current Path MTU value can be obtained. When it is disabled, the Path MTU to be used can be controlled by the application.

パスMTU検出の構成：パスMTU検出（PMTUD）は、関連付けのピアアドレスごとに有効または無効にできます（[RFC6458]のセクション8.1.12）。有効にすると、現在のパスMTU値を取得できます。無効にすると、使用するパスMTUをアプリケーションで制御できます。

Configure Delayed SACK Timer: The time before sending a SACK can be adjusted; delaying SACKs can be disabled; and the number of packets that must be received before a SACK is sent without waiting for the delay timer to expire can be configured [RFC6458].

遅延SACKタイマーの構成：SACKを送信するまでの時間を調整できます。 SACKの遅延は無効にできます。また、遅延タイマーの期限が切れるのを待たずにSACKが送信される前に受信する必要があるパケットの数を構成できます[RFC6458]。

Set Cookie Life Value: The cookie life value can be adjusted (Section 8.1.2 of [RFC6458]). 'Valid.Cookie.Life' is also one of the parameters that is potentially adjustable with 'SetProtocolParameters' [RFC4960].

Cookieの有効期限の設定：Cookieの有効期限の値を調整できます（[RFC6458]のセクション8.1.2）。 'Valid.Cookie.Life'も 'SetProtocolParameters' [RFC4960]で調整できる可能性のあるパラメーターの1つです。

Set Maximum Burst: The maximum burst of packets that can be emitted by a particular association (default 4, and values above 4 are optional to implement) can be adjusted (Section 8.1.2 of [RFC6458]). 'Max.Burst' is also one of the parameters that is potentially adjustable with 'SetProtocolParameters' [RFC4960].

最大バーストの設定：特定のアソシエーション（デフォルト4、および4を超える値の実装はオプションです）が送信できるパケットの最大バーストを調整できます（[RFC6458]のセクション8.1.2）。 'Max.Burst'も、 'SetProtocolParameters' [RFC4960]で調整可能なパラメータの1つです。

Configure RTO Calculation: The abstract API contains the following adjustable parameters: 'RTO.Initial'; 'RTO.Min'; 'RTO.Max'; 'RTO.Alpha'; and 'RTO.Beta'. Only the initial, minimum and maximum RTOs are also described as configurable in the SCTP sockets API extensions [RFC6458].

RTO計算の構成：抽象APIには、次の調整可能なパラメーターが含まれています。 'RTO.Initial'; 'RTO.Min'; 'RTO.Max'; 'RTO.Alpha';および「RTO.Beta」。 SCTPソケットAPI拡張[RFC6458]では、初期RTO、最小RTO、最大RTOのみが構成可能であると説明されています。

Set DSCP Value: The DSCP value can be set per peer address of an association (Section 8.1.12 of [RFC6458]).

DSCP値の設定：DSCP値は、関連付けのピアアドレスごとに設定できます（[RFC6458]のセクション8.1.12）。

Set IPv6 Flow Label: The flow label field can be set per peer address of an association (Section 8.1.12 of [RFC6458]).

IPv6フローラベルの設定：フローラベルフィールドは、関連付けのピアアドレスごとに設定できます（[RFC6458]のセクション8.1.12）。

Set Partial Delivery Point: This allows the ability to specify the size of a message where partial delivery will be invoked. Setting this to a lower value will cause partial deliveries to happen more often [RFC6458].

部分配信ポイントの設定：これにより、部分配信が呼び出されるメッセージのサイズを指定できます。これを低い値に設定すると、部分配信がより頻繁に発生します[RFC6458]。

Communication Up Notification: When a lost communication to an endpoint is restored or when SCTP becomes ready to send or receive user messages, this notification informs the application process about the affected association, the type of event that has occurred, the complete set of sockets of the peer, the maximum number of allowed streams, and the inbound stream count (the number of streams the peer endpoint has requested). If interleaving is supported by both endpoints, this information is also included in this notification.

通信アップ通知：エンドポイントとの通信が失われた場合、またはSCTPがユーザーメッセージを送受信できるようになると、この通知は、影響を受ける関連付け、発生したイベントのタイプ、ソケットの完全なセットについてアプリケーションプロセスに通知しますピア、許可されたストリームの最大数、およびインバウンドストリームの数（ピアエンドポイントが要求したストリームの数）。インターリーブが両方のエンドポイントでサポートされている場合、この情報もこの通知に含まれます。

Restart Notification: When SCTP has detected that the peer has restarted, this notification is passed to the upper layer [RFC6458].

再起動通知：ピアが再起動したことをSCTPが検出すると、この通知は上位層[RFC6458]に渡されます。

Data Arrive Notification: When a message is ready to be retrieved via the 'Receive' primitive, the application is informed by this notification.

データ到着通知：「受信」プリミティブを介してメッセージを取得する準備ができると、アプリケーションにこの通知が通知されます。

Send Failure Notification / Receive Unsent Message / Receive Unacknowledged Message: When a message cannot be delivered via an association, the sender can be informed about it and learn whether the message has just not been acknowledged or (e.g., in case of lifetime expiry) if it has not even been sent. This can also inform the sender that a part of the message has been successfully delivered.

失敗通知の送信/未送信メッセージの受信/未確認メッセージの受信：アソシエーションを介してメッセージを配信できない場合、送信者はそのことを通知され、メッセージが確認されていないかどうか（たとえば、有効期限切れの場合）を確認できます。それも送られていません。これは、メッセージの一部が正常に配信されたことを送信者に通知することもできます。

Network Status Change Notification: This informs the application about a socket becoming active/inactive [RFC4960] or "Potentially Failed" [RFC7829].

ネットワークステータス変更通知：これは、ソケットがアクティブ/非アクティブになること[RFC4960]または「潜在的に失敗した」[RFC7829]についてアプリケーションに通知します。

Communication Lost Notification: When SCTP loses communication to an endpoint (e.g., via heartbeats or excessive retransmission) or detects an abort, this notification informs the application process of the affected association and the type of event (failure OR termination in response to a shutdown or abort request).

通信喪失通知：SCTPがエンドポイントとの通信を失う（たとえば、ハートビートまたは過剰な再送信を介して）か、異常終了を検出すると、この通知は、影響を受けるアソシエーションとイベントのタイプ（失敗またはシャットダウンへの応答での終了または終了）をアプリケーションプロセスに通知します中止リクエスト）。

Shutdown Complete Notification: When SCTP completes the shutdown procedures, this notification is passed to the upper layer, informing it about the affected association.

シャットダウン完了通知：SCTPがシャットダウン手順を完了すると、この通知は上位層に渡され、影響を受ける関連付けについて通知されます。

Authentication Notification: When SCTP wants to notify the upper layer regarding the key management related to authenticated chunks [RFC4895], this notification is passed to the upper layer.

認証通知：認証されたチャンクに関連するキー管理[RFC4895]に関してSCTPが上位層に通知する場合、この通知は上位層に渡されます。

Adaptation Layer Indication Notification: When SCTP completes the association setup and the peer provided an adaptation layer indication, this is passed to the upper layer [RFC5061] [RFC6458].

適応層表示通知：SCTPがアソシエーションセットアップを完了し、ピアが適応層表示を提供すると、これは上位層[RFC5061] [RFC6458]に渡されます。

Stream Reset Notification: When SCTP completes the procedure for resetting streams [RFC6525], this notification is passed to the upper layer, informing it about the result.

ストリームリセット通知：SCTPがストリームのリセット手順[RFC6525]を完了すると、この通知は上位層に渡され、結果が通知されます。

Association Reset Notification: When SCTP completes the association reset procedure [RFC6525], this notification is passed to the upper layer, informing it about the result.

アソシエーションリセット通知：SCTPがアソシエーションリセット手順[RFC6525]を完了すると、この通知は上位層に渡され、結果が通知されます。

Stream Change Notification: When SCTP completes the procedure used to increase the number of streams [RFC6525], this notification is passed to the upper layer, informing it about the result.

ストリーム変更通知：SCTPがストリーム数を増やすために使用される手順[RFC6525]を完了すると、この通知は上位層に渡され、結果が通知されます。

Sender Dry Notification: When SCTP has no more user data to send or retransmit on a particular association, this notification is passed to the upper layer [RFC6458].

送信者ドライ通知：特定のアソシエーションで送信または再送信するユーザーデータがSCTPになくなると、この通知は上位層[RFC6458]に渡されます。

Partial Delivery Aborted Notification: When a receiver has begun to receive parts of a user message but the delivery of this message is then aborted, this notification is passed to the upper layer (Section 6.1.7 of [RFC6458]).

部分配信中止通知：受信者がユーザーメッセージの一部の受信を開始したが、このメッセージの配信が中止された場合、この通知は上位層に渡されます（[RFC6458]のセクション6.1.7）。

3.3.1. Excluded Primitives or Parameters

3.3.1. 除外されたプリミティブまたはパラメーター

The 'Receive' primitive can return certain additional information, but this is optional to implement and therefore not considered. With a 'Communication Lost' notification, some more information may optionally be passed to the application (e.g., identification to retrieve unsent and unacknowledged data). SCTP "can invoke" a 'Communication Error' notification and "may send" a 'Restart' notification, making these two notifications optional to implement. The list provided under 'Status' includes "etc.", indicating that more information could be provided. The primitive 'Get SRTT Report' returns information that is included in the information that 'Status' provides and is therefore not discussed. The 'Destroy SCTP Instance' API function was excluded: it erases the SCTP instance that was created by 'Initialize' but is not a primitive as defined in this document because it does not relate to a transport feature. The 'Shutdown' event informs an application that the peer has sent a SHUTDOWN, and hence no further data should be sent on this socket (Section 6.1 of [RFC6458]). However, if an application would try to send data on the socket, it would get an error message anyway; thus, this event is classified as "just affecting the application programming style, not how the underlying protocol operates" and is not included here.

'Receive'プリミティブは特定の追加情報を返すことができますが、これは実装のオプションであるため、考慮されません。「通信が失われた」通知では、さらにいくつかの情報をオプションでアプリケーションに渡すことができます（たとえば、未送信および未確認のデータを取得するための識別）。 SCTPは「通信エラー」通知を「呼び出す」ことができ、「再起動」通知を「送信する」ことができるため、これら2つの通知の実装はオプションになります。「ステータス」の下に表示されるリストには「その他」が含まれ、より多くの情報を提供できることを示しています。プリミティブ「Get SRTT Report」は、「Status」が提供する情報に含まれているため、説明されていない情報を返します。「SCTPインスタンスの破棄」API関数は除外されました。「初期化」によって作成されたSCTPインスタンスは消去されますが、トランスポート機能に関連しないため、このドキュメントで定義されているプリミティブではありません。「Shutdown」イベントは、ピアがSHUTDOWNを送信したことをアプリケーションに通知するため、このソケットでこれ以上データを送信しないでください（[RFC6458]のセクション6.1）。ただし、アプリケーションがソケットでデータを送信しようとすると、とにかくエラーメッセージが表示されます。したがって、このイベントは「基礎となるプロトコルの動作方法ではなく、アプリケーションプログラミングスタイルにのみ影響する」と分類され、ここには含まれません。

3.4. Primitives Provided by UDP and UDP-Lite

3.4. UDPおよびUDP-Liteが提供するプリミティブ

The set of pass 1 primitives for UDP and UDP-Lite is documented in [RFC8304].

UDPおよびUDP-Liteのパス1プリミティブのセットは、[RFC8304]で文書化されています。

3.5. The Service of LEDBAT

3.5. LEDBATのサービス

The service of the LEDBAT congestion control mechanism is described as follows:

LEDBAT輻輳制御メカニズムのサービスは次のとおりです。

LEDBAT is designed for use by background bulk-transfer applications to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows [RFC6817].

LEDBATは、バックグラウンドのバルク転送アプリケーションが標準のTCP輻輳制御（RFC 5681で指定されている）よりも積極的でなく、競合するフローが存在する場合に制御できるように設計されているため、競合するフローのネットワークパフォーマンスへの干渉が制限されます[RFC6817 ]。

LEDBAT does not have any primitives, as LEDBAT is not a transport protocol. According to its specification [RFC6817]:

LEDBATはトランスポートプロトコルではないため、LEDBATにはプリミティブがありません。その仕様によれば[RFC6817]：

LEDBAT can be used as part of a transport protocol or as part of an application, as long as the data transmission mechanisms are capable of carrying timestamps and acknowledging data frequently. LEDBAT can be used with TCP, Stream Control Transmission Protocol (SCTP), and Datagram Congestion Control Protocol (DCCP), with appropriate extensions where necessary; and it can be used with proprietary application protocols, such as those built on top of UDP for peer-to-peer (P2P) applications.

LEDBATは、データ転送メカニズムがタイムスタンプを伝送し、データを頻繁に確認できる限り、トランスポートプロトコルの一部として、またはアプリケーションの一部として使用できます。 LEDBATは、TCP、ストリーム制御伝送プロトコル（SCTP）、およびデータグラム輻輳制御プロトコル（DCCP）で使用でき、必要に応じて適切な拡張を行います。また、ピアツーピア（P2P）アプリケーションのUDPの上に構築されたプロトコルなど、独自のアプリケーションプロトコルで使用できます。

At the time of writing, the appropriate extensions for TCP, SCTP, or DCCP do not exist.

執筆時点では、TCP、SCTP、またはDCCPの適切な拡張機能は存在しません。

A number of configurable parameters exist in the LEDBAT specification: TARGET, which is the queuing delay target at which LEDBAT tries to operate, must be set to 100 ms or less. 'allowed_increase' (should be 1, must be greater than 0) limits the speed at which LEDBAT increases its rate. 'gain', which according to [RFC6817] "MUST be set to 1 or less" to avoid a faster ramp-up than TCP Reno, determines how quickly the sender responds to changes in queueing delay. Implementations may divide 'gain' into two parameters: one for increase and a possibly larger one for decrease. We call these parameters 'Gain_Inc' and 'Gain_Dec' here. 'Base_History' is the size of the list of measured base delays, and, according to [RFC6817], "SHOULD be 10". This list can be filtered using a 'Filter' function, which is not prescribed [RFC6817], that yields a list of size 'Current_Filter'. The initial and minimum congestion windows, 'Init_CWND' and 'Min_CWND', should both be 2.

LEDBAT仕様にはいくつかの構成可能なパラメーターが存在します。LEDBATが動作しようとするキューイング遅延ターゲットであるTARGETは、100 ms以下に設定する必要があります。「allowed_increase」（1である必要があります。0より大きい必要があります）は、LEDBATがレートを増加させる速度を制限します。 [ゲイン]は、[RFC6817]に従って「1以下に設定する必要がある」ことで、TCP Renoよりも高速のランプアップを回避し、送信者がキューイング遅延の変化に応答する速さを決定します。実装では、「ゲイン」を2つのパラメータに分割する場合があります。1つは増加用、もう1つはおそらく減少用です。ここでは、これらのパラメーターを「Gain_Inc」および「Gain_Dec」と呼びます。「Base_History」は、測定された基本遅延のリストのサイズであり、[RFC6817]によれば、「SHOULD be 10」です。このリストは、サイズが「Current_Filter」のリストを生成する「RFC6817」で規定されていない「Filter」関数を使用してフィルタリングできます。初期および最小の輻輳ウィンドウである「Init_CWND」と「Min_CWND」は両方とも2である必要があります。

Regarding which of these parameters should be under control of an application, the possible range goes from exposing nothing on the one hand to considering everything that is not prescribed with a "MUST" in the specification as a parameter on the other hand. Function implementations are not provided as a parameter to any of the transport protocols discussed here; hence, we do not regard the

これらのパラメーターのどれがアプリケーションの制御下にあるべきかに関して、可能な範囲は、一方では何も公開しないことから、他方ではパラメーターとして仕様で「MUST」で規定されていないすべてを考慮することになります。関数の実装は、ここで説明するトランスポートプロトコルのパラメーターとして提供されていません。したがって、私たちは考慮しません

'Filter' function as a parameter. However, to avoid unnecessarily limiting future implementations, we consider all other parameters above as tunable parameters that should be exposed.

パラメータとしての「フィルタ」機能。ただし、将来の実装を不必要に制限することを避けるために、上記の他のすべてのパラメーターを公開する必要のある調整可能なパラメーターと見なします。

4. Pass 2

4. パス2

This pass categorizes the primitives from pass 1 based on whether they relate to a connection or to data transmission. Primitives are presented following the nomenclature "CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL". The CATEGORY can be CONNECTION or DATA. Within the CONNECTION category, ESTABLISHMENT, AVAILABILITY, MAINTENANCE, and TERMINATION subcategories can be considered. The DATA category does not have any SUBCATEGORY. The PROTOCOL name "UDP(-Lite)" is used when primitives are equivalent for UDP and UDP-Lite; the PROTOCOL name "TCP" refers to both TCP and MPTCP. We present "connection" as a general protocol-independent concept and use it to refer to, e.g., TCP connections (identifiable by a unique pair of IP addresses and TCP port numbers), SCTP associations (identifiable by multiple IP address and port number pairs), as well UDP and UDP-Lite connections (identifiable by a unique socket pair).

このパスは、接続に関連するかデータ送信に関連するかに基づいて、パス1のプリミティブを分類します。プリミティブは、「CATEGORY。[SUBCATEGORY] .PRIMITIVENAME.PROTOCOL」という命名法に従って表示されます。 CATEGORYはCONNECTIONまたはDATAです。 CONNECTIONカテゴリでは、ESTABLISHMENT、AVAILABILITY、MAINTENANCE、およびTERMINATIONサブカテゴリを検討できます。 DATAカテゴリにはSUBCATEGORYがありません。プロトコル名「UDP（-Lite）」は、プリミティブがUDPとUDP-Liteで同等である場合に使用されます。プロトコル名「TCP」は、TCPとMPTCPの両方を指します。プロトコルに依存しない一般的な概念として「接続」を提示し、それを使用して、たとえば、TCP接続（IPアドレスとTCPポート番号の一意のペアによって識別可能）、SCTPアソシエーション（複数のIPアドレスとポート番号のペアによって識別可能））、UDPおよびUDP-Lite接続（一意のソケットペアで識別可能）。

Some minor details are omitted for the sake of generalization -- e.g., SCTP's 'Close' [RFC4960] returns success or failure and lets the application control whether further receive or send operations, or both, are disabled [RFC6458]. This is not described in the same way for TCP [RFC0793], but these details play no significant role for the primitives provided by either TCP or SCTP (for the sake of being generic, it could be assumed that both receive and send operations are disabled in both cases).

一般化のために、いくつかの細かい詳細は省略されています。たとえば、SCTPの「Close」[RFC4960]は成功または失敗を返し、アプリケーションは、以降の受信または送信操作、あるいはその両方が無効かどうかを制御できます[RFC6458]。これはTCP [RFC0793]について同じ方法で説明されていませんが、これらの詳細はTCPまたはSCTPのいずれかによって提供されるプリミティブには重要な役割を果たしません（一般的に、受信と送信の両方の操作が無効になっていると想定できます）両方の場合において）。

The TCP 'Send' and 'Receive' primitives include usage of an 'urgent' parameter. This parameter controls a mechanism that is required to implement the "synch signal" used by telnet [RFC0854], but [RFC6093] states that "new applications SHOULD NOT employ the TCP urgent mechanism." Because pass 2 is meant as a basis for the creation of future systems, the "urgent" mechanism is excluded. This also concerns the notification 'Urgent Pointer Advance' in the 'Error_Report' (Section 4.2.4.1 of [RFC1122]).

TCPの「Send」および「Receive」プリミティブには、「urgent」パラメータの使用が含まれます。このパラメータは、telnet [RFC0854] が使用する「同期信号」を実装するために必要なメカニズムを制御しますが、[RFC6093] は「新しいアプリケーションはTCPの緊急メカニズムを採用すべきではない (SHOULD NOT)」と述べています。パス2は将来のシステムを作成するための基礎として意図されているため、「urgent」メカニズムは除外されます。これは「Error_Report」における「Urgent Pointer Advance」通知（[RFC1122] のセクション4.2.4.1）にも関係します。

Since LEDBAT is a congestion control mechanism and not a protocol, it is not currently defined when to enable/disable or configure the mechanism. For instance, it could be a one-time choice upon connection establishment or when listening for incoming connections, in which case it should be categorized under CONNECTION.ESTABLISHMENT or CONNECTION.AVAILABILITY, respectively. To avoid unnecessarily limiting future implementations, it was decided to place it under CONNECTION.MAINTENANCE, with all parameters that are described in the specification [RFC6817] made configurable.

LEDBATはプロトコルではなく輻輳制御メカニズムであるため、現在メカニズムを有効化/無効化または構成するタイミングは定義されていません。たとえば、接続の確立時または着信接続のリッスン時に一度だけ選択できます。その場合、それぞれCONNECTION.ESTABLISHMENTまたはCONNECTION.AVAILABILITYに分類する必要があります。将来の実装を不必要に制限することを避けるために、仕様[RFC6817]で説明されているすべてのパラメーターを構成可能にして、CONNECTION.MAINTENANCEの下に配置することが決定されました。

4.1. 接続関連のプリミティブ

4.2. データ転送関連のプリミティブ

5. Pass 3

5. パス3

This section presents the superset of all transport features in all protocols that were discussed in the preceding sections, based on the list of primitives in pass 2 but also on text in pass 1 to include transport features that can be configured in one protocol and are static properties in another (congestion control, for example). Again, some minor details are omitted for the sake of generalization -- e.g., TCP may provide various different IP options, but only source route is mandatory to implement, and this detail is not visible in the pass 3 transport feature "Specify IP options". As before, "UDP(-Lite)" represents both UDP and UDP-Lite, and "TCP" refers to both TCP and MPTCP.

このセクションでは、前のセクションで説明したすべてのプロトコルのすべてのトランスポート機能のスーパーセットを、パス2のプリミティブのリストだけでなく、パス1のテキストにも基づいて示し、1つのプロトコルで構成でき、静的なトランスポート機能を含めます。別のプロパティ（輻輳制御など）。繰り返しになりますが、一般化のためにいくつかの細かい詳細は省略されています。たとえば、TCPはさまざまな異なるIPオプションを提供することがありますが、実装にはソースルートのみが必須であり、この詳細はパス3トランスポート機能の「Specify IP options」には表示されません。。以前と同様に、「UDP（-Lite）」はUDPとUDP-Liteの両方を表し、「TCP」はTCPとMPTCPの両方を表します。

5.1. 接続関連のトランスポート機能

5.2. データ転送関連のトランスポート機能

5.2.1. Sending Data

5.2.1. データの送信

All transport features in this section are provided by DATA.SEND from pass 2. DATA.SEND is given a data block from the application, which here we call a "message" if the beginning and end of the data block can be identified at the receiver, and "data" otherwise.

このセクションのすべてのトランスポート機能は、パス2のDATA.SENDによって提供されます。DATA.SENDには、アプリケーションからデータブロックが与えられます。データブロックの開始と終了がレシーバー、それ以外の場合は「データ」。

o Reliably transfer data, with congestion control Protocols: TCP

o 輻輳制御プロトコルでデータを確実に転送しますプロトコル：TCP

o Reliably transfer a message, with congestion control Protocols: SCTP

o 輻輳制御プロトコルでメッセージを確実に転送するプロトコル：SCTP

o Unreliably transfer a message, with congestion control Protocols: SCTP

o 輻輳制御プロトコルを使用してメッセージを信頼できない方法で転送する：SCTP

o Unreliably transfer a message, without congestion control Protocols: UDP(-Lite)

o 輻輳制御なしでメッセージを確実に転送しないプロトコル：UDP（-Lite）

o Configurable Message Reliability Protocols: SCTP

o 構成可能なメッセージ信頼性プロトコル：SCTP

o Choice of stream Protocols: SCTP

o ストリームプロトコルの選択：SCTP

o Choice of path (destination address) Protocols: SCTP

o パスの選択（宛先アドレス）プロトコル：SCTP

o Ordered message delivery (potentially slower than unordered) Protocols: SCTP

o 順序付けられたメッセージ配信（順序付けされていないものよりも潜在的に遅い）プロトコル：SCTP

o Unordered message delivery (potentially faster than ordered) Protocols: SCTP and UDP(-Lite)

o 順序付けられていないメッセージ配信（順序付けよりも潜在的に高速）プロトコル：SCTPおよびUDP（-Lite）

o Request not to bundle messages Protocols: SCTP

o メッセージをバンドルしないように要求するプロトコル：SCTP

o Specifying a 'payload protocol-id' (handed over as such by the receiver) Protocols: SCTP

o 「ペイロードプロトコルID」の指定（受信者から引き渡されるなど）プロトコル：SCTP

o Specifying a key identifier to be used to authenticate a message Protocols: SCTP

o メッセージの認証に使用されるキー識別子の指定プロトコル：SCTP

o Request not to delay the acknowledgement (SACK) of a message Protocols: SCTP

o メッセージの確認（SACK）を遅らせないように要求するプロトコル：SCTP

5.2.2. Receiving Data

5.2.2. データ受信中

All transport features in this section are provided by DATA.RECEIVE from pass 2. DATA.RECEIVE fills a buffer provided by the application, with what here we call a "message" if the beginning and end of the data block can be identified at the receiver, and "data" otherwise.

このセクションのすべてのトランスポート機能は、パス2のDATA.RECEIVEによって提供されます。DATA.RECEIVEは、アプリケーションによって提供されるバッファーを満たします。データブロックの開始と終了がレシーバー、それ以外の場合は「データ」。

o Receive data (with no message delimiting) Protocols: TCP

o データの受信（メッセージ区切りなし）プロトコル：TCP

o Receive a message Protocols: SCTP and UDP(-Lite)

o メッセージの受信プロトコル：SCTPおよびUDP（-Lite）

o Choice of stream to receive from Protocols: SCTP

o プロトコルから受信するストリームの選択：SCTP

o Information about partial message arrival Protocols: SCTP Comments: in SCTP, partial messages are combined with a stream sequence number so that the application can restore the correct order of data blocks an entire message consists of.

o メッセージの部分的な到着に関する情報プロトコル：SCTPコメント：SCTPでは、メッセージ全体が構成するデータブロックの正しい順序をアプリケーションが復元できるように、部分的なメッセージがストリームシーケンス番号と組み合わされます。

5.2.3. Errors

5.2.3. エラー

This section describes sending failures that are associated with a specific call to DATA.SEND from pass 2.

このセクションでは、パス2からDATA.SENDへの特定の呼び出しに関連する送信エラーについて説明します。

o Notification of an unsent (part of a) message Protocols: SCTP and UDP(-Lite)

o 未送信（一部）のメッセージの通知プロトコル：SCTPおよびUDP（-Lite）

o Notification of an unacknowledged (part of a) message Protocols: SCTP

o 未確認（aの一部）メッセージの通知プロトコル：SCTP

o Notification that the stack has no more user data to send Protocols: SCTP

o スタックに送信するユーザーデータがなくなったという通知プロトコル：SCTP

o Notification to a receiver that a partial message delivery has been aborted Protocols: SCTP

o 部分的なメッセージ配信が中止されたという受信者への通知プロトコル：SCTP

6. IANA Considerations

6. IANAに関する考慮事項

This document does not require any IANA actions.

このドキュメントでは、IANAアクションは必要ありません。

7. Security Considerations

7. セキュリティに関する考慮事項

Authentication, confidentiality protection, and integrity protection are identified as transport features [RFC8095]. These transport features are generally provided by a protocol or layer on top of the transport protocol; none of the transport protocols considered in this document provides these transport features on its own. Therefore, these transport features are not considered in this document, with the exception of native authentication capabilities of TCP and SCTP for which the security considerations in [RFC5925] and [RFC4895] apply.

認証、機密保護、および整合性保護は、トランスポート機能[RFC8095]として識別されます。これらのトランスポート機能は、通常、トランスポートプロトコルの上にあるプロトコルまたはレイヤーによって提供されます。このドキュメントで検討されているトランスポートプロトコルは、それ自体でこれらのトランスポート機能を提供していません。したがって、[RFC5925]および[RFC4895]のセキュリティに関する考慮事項が適用されるTCPおよびSCTPのネイティブ認証機能を除いて、これらのトランスポート機能はこのドキュメントでは考慮されていません。

Security considerations for the use of UDP and UDP-Lite are provided in the referenced RFCs. Security guidance for application usage is provided in the UDP Guidelines [RFC8085].

UDPおよびUDP-Liteの使用に関するセキュリティの考慮事項は、参照されているRFCで提供されています。アプリケーション使用のセキュリティガイダンスは、UDPガイドライン[RFC8085]で提供されています。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[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>。

[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, <https://www.rfc-editor.org/info/rfc3758>.

[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad、「Stream Control Transmission Protocol（SCTP）Partial Reliability Extension」、RFC 3758、DOI 10.17487/RFC3758、May 2004、<https://www.rfc-editor.org/info/rfc3758>。

[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2007, <https://www.rfc-editor.org/info/rfc4895>.

[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla、「Authenticated Chunks for the Stream Control Transmission Protocol（SCTP）」、RFC 4895、DOI 10.17487/RFC4895、2007年8月、<https://www.rfc-editor.org/info/rfc4895>。

[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.

[RFC4960] Stewart, R., Ed.、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487/RFC4960、2007年9月、<https://www.rfc-editor.org/info/rfc4960>。

[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/RFC5061, September 2007, <https://www.rfc-editor.org/info/rfc5061>.

[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka、「Stream Control Transmission Protocol（SCTP）Dynamic Address Reconfiguration」、RFC 5061、DOI 10.17487/RFC5061、9月2007、<https://www.rfc-editor.org/info/rfc5061>。

[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC 5482, DOI 10.17487/RFC5482, March 2009, <https://www.rfc-editor.org/info/rfc5482>.

[RFC5482] Eggert, L. and F. Gont、「TCPユーザータイムアウトオプション」、RFC 5482、DOI 10.17487/RFC5482、2009年3月、<https://www.rfc-editor.org/info/rfc5482>。

[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., and R. Bonica、「The TCP Authentication Option」、RFC 5925、DOI 10.17487/RFC5925、2010年6月、<https://www.rfc-editor.org/info/rfc5925>。

[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, <https://www.rfc-editor.org/info/rfc6182>.

[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar、「マルチパスTCP開発のアーキテクチャガイドライン」、RFC 6182、DOI 10.17487/RFC6182、2011年3月、<https://www.rfc-editor.org/info/rfc6182>。

[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/RFC6458, December 2011, <https://www.rfc-editor.org/info/rfc6458>.

[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich、「Socket Control Extensions for the Stream Control Transmission Protocol（SCTP）」、RFC 6458、DOI 10.17487/RFC6458 、2011年12月、<https://www.rfc-editor.org/info/rfc6458>。

[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, DOI 10.17487/RFC6525, February 2012, <https://www.rfc-editor.org/info/rfc6525>.

[RFC6525] Stewart, R., Tuexen, M., and P. Lei、「Stream Control Transmission Protocol（SCTP）Stream Reconfiguration」、RFC 6525、DOI 10.17487/RFC6525、2012年2月、<https://www.rfc-editor.org/info/rfc6525>。

[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <https://www.rfc-editor.org/info/rfc6817>.

[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind、「Low Extra Delay Background Transport（LEDBAT）」、RFC 6817、DOI 10.17487/RFC6817、2012年12月、<https://www.rfc-editor.org/info/rfc6817>。

[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <https://www.rfc-editor.org/info/rfc6824>.

[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure、「複数のアドレスによるマルチパス操作のためのTCP拡張機能」、RFC 6824、DOI 10.17487/RFC6824、2013年1月、<https://www.rfc-editor.org/info/rfc6824>。

[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, March 2013, <https://www.rfc-editor.org/info/rfc6897>.

[RFC6897] Scharf, M. and A. Ford、「マルチパスTCP（MPTCP）アプリケーションインターフェイスの考慮事項」、RFC 6897、DOI 10.17487/RFC6897、2013年3月、<https://www.rfc-editor.org/info/rfc6897>。

[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013, <https://www.rfc-editor.org/info/rfc6951>.

[RFC6951] Tuexen, M. and R. Stewart、「エンドホストからエンドホストへの通信用のストリーム制御伝送プロトコル（SCTP）パケットのUDPカプセル化」、RFC 6951、DOI 10.17487/RFC6951、2013年5月、<https://www.rfc-editor.org/info/rfc6951>。

[RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, <https://www.rfc-editor.org/info/rfc7053>.

[RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart、「SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol」、RFC 7053、DOI 10.17487/RFC7053、2013年11月、<https://www.rfc-editor.org/info/rfc7053>。

[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., and A. Jain、「TCP Fast Open」、RFC 7413、DOI 10.17487/RFC7413、2014年12月、<https://www.rfc-editor.org/info/rfc7413>。

[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, "Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension", RFC 7496, DOI 10.17487/RFC7496, April 2015, <https://www.rfc-editor.org/info/rfc7496>.

[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto、「Partially Reliable Stream Control Transmission Protocol Extensionの追加ポリシー」、RFC 7496、DOI 10.17487/RFC7496、2015年4月、<https://www.rfc-editor.org/info/rfc7496>。

[RFC7829] Nishida, Y., Natarajan, P., Caro, A., Amer, P., and K. Nielsen, "SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol", RFC 7829, DOI 10.17487/RFC7829, April 2016, <https://www.rfc-editor.org/info/rfc7829>.

[RFC7829] Nishida, Y., Natarajan, P., Caro, A., Amer, P., and K. Nielsen、「SCTP-PF：ストリーム制御伝送プロトコルのクイックフェイルオーバーアルゴリズム」、RFC 7829、DOI 10.17487/RFC7829、2016年4月、<https://www.rfc-editor.org/info/rfc7829>。

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487/RFC8085、2017年3月、<https://www.rfc-editor.org/info/rfc8085>。

[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol", RFC 8260, DOI 10.17487/RFC8260, November 2017, <https://www.rfc-editor.org/info/rfc8260>.

[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann、「Stream Scheduler and User Message Interleaving for the Stream Control Transmission Protocol」、RFC 8260、DOI 10.17487/RFC8260、2017年11月、<https://www.rfc-editor.org/info/rfc8260>。

[RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, <https://www.rfc-editor.org/info/rfc8304>.

[RFC8304] Fairhurst, G. and T. Jones、「ユーザーデータグラムプロトコル（UDP）および軽量UDP（UDP-Lite）のトランスポート機能」、RFC 8304、DOI 10.17487/RFC8304、2018年2月、<https://www.rfc-editor.org/info/rfc8304>。

8.2. Informative References

8.2. 参考引用

[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1983, <https://www.rfc-editor.org/info/rfc854>.

[RFC0854] Postel, J. and J. Reynolds、「Telnet Protocol Specification」、STD 8、RFC 854、DOI 10.17487/RFC0854、1983年5月、<https://www.rfc-editor.org/info/rfc854>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner, S.、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/rfc2119>。

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487/RFC2474、 1998年12月、<https://www.rfc-editor.org/info/rfc2474>。

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services"、RFC 2475、DOI 10.17487/RFC2475、December 1998、<https://www.rfc-editor.org/info/rfc2475>。

[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, <https://www.rfc-editor.org/info/rfc3260>.

[RFC3260] Grossman, D.、「Diffservの新しい用語と説明」、RFC 3260、DOI 10.17487/RFC3260、2002年4月、<https://www.rfc-editor.org/info/rfc3260>。

[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, DOI 10.17487/RFC5461, February 2009, <https://www.rfc-editor.org/info/rfc5461>.

[RFC5461] Gont, F.、「ソフトエラーに対するTCPの反応」、RFC 5461、DOI 10.17487/RFC5461、2009年2月、<https://www.rfc-editor.org/info/rfc5461>。

[RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, January 2011, <https://www.rfc-editor.org/info/rfc6093>.

[RFC6093] Gont, F. and A. Yourtchenko、「TCP緊急メカニズムの実装について」、RFC 6093、DOI 10.17487/RFC6093、2011年1月、<https://www.rfc-editor.org/info/rfc6093>。

[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., and A. Zimmermann、「A Transmission map for Transmission Control Protocol（TCP）Specification Documents」、RFC 7414、DOI 10.17487/RFC7414、 2015年2月、<https://www.rfc-editor.org/info/rfc7414>。

[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.

[RFC7657] Black, D., Ed. and P. Jones、「Differentiated Services（Diffserv）and Real-Time Communication」、RFC 7657、DOI 10.17487/RFC7657、2015年11月、<https://www.rfc-editor.org/info/rfc7657>。

[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017, <https://www.rfc-editor.org/info/rfc8095>.

[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed.、「IETFトランスポートプロトコルおよび輻輳制御メカニズムによって提供されるサービス」、RFC 8095、DOI 10.17487/RFC8095、2017年3月、<https://www.rfc-editor.org/info/rfc8095>。

[TAPS-MINSET] Welzl, M. and S. Gjessing, "A Minimal Set of Transport Services for TAPS Systems", Work in Progress, draft-ietf-taps-minset-01, February 2018.

[TAPS-MINSET] Welzl, M. and S. Gjessing、「TAPSシステムの最小限のトランスポートサービス」、作業中、draft-ietf-taps-minset-01、2018年2月。

Appendix A. Overview of RFCs Used as Input for Pass 1

付録A.パス1の入力として使用されるRFCの概要

TCP: [RFC0793], [RFC1122], [RFC5482], [RFC5925], and [RFC7413].

TCP：[RFC0793]、[RFC1122]、[RFC5482]、[RFC5925]、および[RFC7413]。

MPTCP: [RFC6182], [RFC6824], and [RFC6897].

MPTCP：[RFC6182]、[RFC6824]、および[RFC6897]。

SCTP: RFCs without a sockets API specification: [RFC3758], [RFC4895], [RFC4960], and [RFC5061].

SCTP：ソケットAPI仕様のないRFC：[RFC3758]、[RFC4895]、[RFC4960]、および[RFC5061]。

RFCs that include a sockets API specification: [RFC6458], [RFC6525], [RFC6951], [RFC7053], [RFC7496], and [RFC7829].

ソケットAPI仕様を含むRFC：[RFC6458]、[RFC6525]、[RFC6951]、[RFC7053]、[RFC7496]、および[RFC7829]。

UDP(-Lite): See [RFC8304].

UDP（-Lite）：[RFC8304]を参照してください。

LEDBAT: [RFC6817].

LEDBAT：[RFC6817]。

Appendix B. How This Document Was Developed

付録B.このドキュメントの作成方法

This section gives an overview of the method that was used to develop this document. It was given to contributors for guidance, and it can be helpful for future updates or extensions.

このセクションでは、このドキュメントの開発に使用された方法の概要を示します。これはガイダンスとして寄稿者に提供されたものであり、将来の更新や拡張に役立つ可能性があります。

This document is only concerned with transport features that are explicitly exposed to applications via primitives. It also strictly follows RFC text: if a transport feature is truly relevant for an application, the RFCs should say so, and they should describe how to use and configure it. Thus, the approach followed for developing this document was to identify the right RFCs, then analyze and process their text.

このドキュメントは、プリミティブを介してアプリケーションに明示的に公開されるトランスポート機能にのみ関係しています。また、厳密にRFCテキストに従います。トランスポート機能がアプリケーションに本当に関連している場合、RFCはそのように述べ、使用方法と構成方法を説明する必要があります。したがって、このドキュメントを作成するために採用されたアプローチは、適切なRFCを特定し、そのテキストを分析して処理することでした。

Primitives that "MAY" be implemented by a transport protocol were excluded. To be included, the minimum requirement level for a primitive to be implemented by a protocol was "SHOULD". Where style requirement levels as described in [RFC2119] are not used, primitives were excluded when they are described in conjunction with statements like, e.g., "some implementations also provide" or "an implementation may also". Excluded primitives or parameters were briefly described in a dedicated subsection.

トランスポートプロトコルによって「MAY」を実装できるプリミティブは除外されました。含まれるには、プロトコルによって実装されるプリミティブの最小要件レベルは「SHOULD」でした。 [RFC2119]で説明されているスタイル要件レベルが使用されていない場合、「一部の実装も提供する」または「実装も可能」などのステートメントと一緒に記述されるプリミティブは除外されました。除外されたプリミティブまたはパラメーターについては、専用のサブセクションで簡単に説明しました。

Pass 1: This began by identifying text that talks about primitives. An API specification, abstract or not, obviously describes primitives -- but we are not *only* interested in API specifications. The text describing the 'Send' primitive in the API specified in [RFC0793], for instance, does not say that data transfer is reliable. TCP's reliability is clear, however, from this text in Section 1 of [RFC0793]:

パス1：これは、プリミティブについて話すテキストを識別することから始まりました。 API仕様は、抽象であろうとなかろうと、明らかにプリミティブを記述しますが、API仕様にのみ関心があるわけではありません。たとえば、[RFC0793]で指定されているAPIの「送信」プリミティブを説明するテキストは、データ転送が信頼できるとは述べていません。ただし、TCPの信頼性は[RFC0793]のセクション1の次のテキストから明らかです。

Some text for the pass 1 subsections was developed by copying and pasting all the relevant text parts from the relevant RFCs then adjusting the terminology to match that in Section 2 and shortening phrasing to match the general style of the document. An effort was made to formulate everything as a primitive description such that the primitive descriptions became as complete as possible (e.g., the 'SEND.TCP' primitive in pass 2 is explicitly described as reliably transferring data); text that is relevant for the primitives presented in this pass but still does not fit directly under any primitive was used in a subsection's introduction.

パス1のサブセクションの一部のテキストは、関連するRFCからすべての関連するテキスト部分をコピーして貼り付け、セクション2の用語と一致するように用語を調整し、文書の一般的なスタイルに一致するように句を短くすることによって開発されました。プリミティブ記述が可能な限り完全になるように、すべてをプリミティブ記述として定式化する努力が行われました（たとえば、パス2の「SEND.TCP」プリミティブは、確実にデータを転送すると明示されています）;このパスで提示されたプリミティブに関連するが、どのプリミティブにも直接適合しないテキストは、サブセクションの概要で使用されました。

Pass 2: The main goal of this pass is unification of primitives. As input, only text from pass 1 was used (no exterior sources). The list in pass 2 is not arranged by protocol (i.e., "first protocol X, here are all the primitives; then protocol Y, here are all the primitives, ...") but by primitive (i.e., "primitive A, implemented this way in protocol X, this way in protocol Y, ..."). It was a goal to obtain as many similar pass 2 primitives as possible. For instance, this was sometimes achieved by not always maintaining a 1:1 mapping between pass 1 and pass 2 primitives, renaming primitives, etc. For every new primitive, the already-existing primitives were considered to try to make them as coherent as possible.

パス2：このパスの主な目的は、プリミティブの統合です。入力として、パス1のテキストのみが使用されました（外部ソースはありません）。パス2のリストはプロトコル（つまり、「最初のプロトコルX、ここにすべてのプリミティブがあります。次にプロトコルY、ここにすべてのプリミティブがあります...」）ではなく、プリミティブ（つまり、「プリミティブA、実装済み」この方法でプロトコルX、この方法でプロトコルY、...」）。同様のパス2プリミティブをできるだけ多く取得することが目標でした。たとえば、これは、パス1プリミティブとパス2プリミティブの間の1：1マッピングを常に維持することではなく、プリミティブの名前を変更することによって達成された。。

For each primitive, the following style was used:

プリミティブごとに、次のスタイルが使用されました。

o PRIMITIVENAME.PROTOCOL: Pass 1 primitive/event: Parameters: Returns: Comments:

o PRIMITIVENAME.PROTOCOL：1つのプリミティブ/イベントを渡します：パラメータ：戻り値：コメント：

The entries "Parameters", "Returns", and "Comments" were skipped when a primitive had no parameters, no described return value, or no comments seemed necessary, respectively. Optional parameters are followed by "(optional)". When known, default values were provided.

プリミティブにパラメーターがない場合、記述された戻り値がない場合、またはコメントが必要ないように見える場合、エントリー「パラメーター」、「戻り値」、および「コメント」はそれぞれスキップされました。オプションのパラメーターの後には「（オプション）」が続きます。既知の場合、デフォルト値が提供されました。

Pass 3: The main point of this pass is to identify transport features that are the result of static properties of protocols, for which all protocols have to be listed together; this is then the final list of all available transport features. This list was primarily based on text from pass 2, with additional input from pass 1 (but no external sources).

パス3：このパスの主なポイントは、プロトコルの静的プロパティの結果であるトランスポート機能を特定することです。これについて、すべてのプロトコルをまとめてリストする必要があります。これは、使用可能なすべてのトランスポート機能の最終的なリストです。このリストは主にパス2からのテキストに基づいており、パス1からの追加の入力があります（外部ソースはありません）。

Acknowledgements

謝辞

The authors would like to thank (in alphabetical order) Bob Briscoe, Spencer Dawkins, Aaron Falk, David Hayes, Karen Nielsen, Tommy Pauly, Joe Touch, and Brian Trammell for providing valuable feedback on this document. We especially thank Christoph Paasch for providing input related to Multipath TCP and Gorry Fairhurst and Tom Jones for providing input related to UDP(-Lite). This work has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT).

このドキュメントに関する貴重なフィードバックを提供してくれたBob Briscoe、Spencer Dawkins、Aaron Falk、David Hayes、Karen Nielsen、Tommy Pauly、Joe Touch、およびBrian Trammellに感謝します（アルファベット順）。マルチパスTCPに関連する入力を提供してくれたChristoph Paaschと、UDP（-Lite）に関連した入力を提供してくれたGorry FairhurstとTom Jonesに特に感謝します。この作品は、EUのHorizon 2020研究およびイノベーションプログラムから、助成金契約番号644334（NEAT）のもとで資金提供を受けています。

Authors' Addresses

著者のアドレス

Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway

マイケルウェルズル大学オスロ私書箱1080ブリンデンオスロN-0316ノルウェー

   Email: michawe@ifi.uio.no

Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 Steinfurt 48565 Germany

Michael Tuexenミュンスター応用科学大学Stegerwaldstrasse 39シュタインフルト48565ドイツ

   Email: tuexen@fh-muenster.de

Naeem Khademi University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway

   Email: naeemk@ifi.uio.no