[要約] RFC 8923は、エンドシステムのための最小限のトランスポートサービスセットに関するものです。この文書の目的は、アプリケーションが必要とする基本的なトランスポート機能を定義することにあります。利用場面としては、開発者がアプリケーションの通信要件を簡潔に理解し、適切なトランスポートプロトコルを選択する際の指針となることです。
Internet Engineering Task Force (IETF) M. Welzl
Request for Comments: 8923 S. Gjessing
Category: Informational University of Oslo
ISSN: 2070-1721 October 2020
A Minimal Set of Transport Services for End Systems
エンドシステムのための輸送サービスの最小セット
Abstract
概要
This document recommends a minimal set of Transport Services offered by end systems and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features in RFC 8303.
この文書では、エンドシステムによって提供される最小限のトランスポートサービスを推奨し、利用可能なメカニズムとプロトコルの中から選択することを指導します。RFC 8303の輸送機能のセットに基づいています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8923.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc8923で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Deriving the Minimal Set
4. The Reduced Set of Transport Features
4.1. CONNECTION-Related Transport Features
4.2. DATA-Transfer-Related Transport Features
4.2.1. Sending Data
4.2.2. Receiving Data
4.2.3. Errors
5. Discussion
5.1. Sending Messages, Receiving Bytes
5.2. Stream Schedulers without Streams
5.3. Early Data Transmission
5.4. Sender Running Dry
5.5. Capacity Profile
5.6. Security
5.7. Packet Size
6. The Minimal Set of Transport Features
6.1. ESTABLISHMENT, AVAILABILITY, and TERMINATION
6.2. MAINTENANCE
6.2.1. Connection Groups
6.2.2. Individual Connections
6.3. DATA Transfer
6.3.1. Sending Data
6.3.2. Receiving Data
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. The Superset of Transport Features
A.1. CONNECTION-Related Transport Features
A.2. DATA-Transfer-Related Transport Features
A.2.1. Sending Data
A.2.2. Receiving Data
A.2.3. Errors
Acknowledgements
Authors' Addresses
Currently, the set of Transport Services that most applications use is based on TCP and UDP (and protocols that are layered on top of them); this limits the ability for the network stack to make use of features of other transport protocols. For example, if a protocol supports out-of-order message delivery but applications always assume that the network provides an ordered byte stream, then the network stack can not immediately deliver a message that arrives out of order; doing so would break a fundamental assumption of the application. The net result is unnecessary head-of-line blocking delay.
現在、ほとんどのアプリケーションが使用するトランスポートサービスのセットは、TCPとUDP（およびそれらの上に階層化されているプロトコル）に基づいています。これにより、ネットワークスタックが他のトランスポートプロトコルの機能を利用する機能が制限されます。たとえば、プロトコルが順不同メッセージ配信をサポートしていますが、アプリケーションは常にネットワークが順序付きバイトストリームを提供していると想定している場合、ネットワークスタックはすぐに順番に到着したメッセージを配信できません。そうすることは、アプリケーションの基本的な仮定を破るでしょう。正味の結果は不要な回線のブロック遅延です。
By exposing the Transport Services of multiple transport protocols, a transport system can make it possible for applications to use these services without being statically bound to a specific transport protocol. The first step towards the design of such a system was taken by [RFC8095], which surveys a large number of transports, and [RFC8303] as well as [RFC8304], which identify the specific transport features that are exposed to applications by the protocols TCP, Multipath TCP (MPTCP), UDP(-Lite), and Stream Control Transmission Protocol (SCTP), as well as the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. LEDBAT was included as the only congestion control mechanism in this list because the "low extra delay background transport" service that it offers is significantly different from the typical service provided by other congestion control mechanisms. This memo is based on these documents and follows the same terminology (also listed below). Because the considered transport protocols conjointly cover a wide range of transport features, there is reason to hope that the resulting set (and the reasoning that led to it) will also apply to many aspects of other transport protocols that may be in use today or may be designed in the future.
複数のトランスポートプロトコルのトランスポートサービスを公開することによって、トランスポートシステムは、特定のトランスポートプロトコルに静的にバインドされずにこれらのサービスを使用することを可能にすることができる。そのようなシステムの設計への最初のステップは[RFC8095]によって撮影され、[RFC8303]と[RFC8303]と[RFC8303]が採用されており、プロトコルによるアプリケーションにさらされる特定のトランスポート機能TCP、マルチパスTCP（MPTCP）、UDP（ - ライト）、およびストリーム制御伝送プロトコル（SCTP）、および低級遅延背景トランスポート（LEDBAT）輻輳制御メカニズム。このリストの唯一の輻輳制御メカニズムとしては、他の輻輳制御メカニズムによって提供される典型的なサービスとは大きく異なるため、LEDBATはこのリストの唯一の輻輳制御メカニズムとして含まれていました。このメモはこれらの文書に基づいており、同じ用語に従います（下記の）。検討された輸送プロトコルは幅広い範囲の輸送機能をカバーしているため、結果のセット（およびそれを導いた推論）が今日使用されている可能性がある他のトランスポートプロトコルの多くの側面にも適用されることを願う理由があります。将来的に設計される。
By decoupling applications from transport protocols, a transport system provides a different abstraction level than the Berkeley sockets interface [POSIX]. As with high- vs. low-level programming languages, a higher abstraction level allows more freedom for automation below the interface, yet it takes some control away from the application programmer. This is the design trade-off that a transport system developer is facing, and this document provides guidance on the design of this abstraction level. Some transport features are currently rarely offered by APIs, yet they must be offered or they can never be used. Other transport features are offered by the APIs of the protocols covered here, but not exposing them in an API would allow for more freedom to automate protocol usage in a transport system. The minimal set presented here is an effort to find a middle ground that can be recommended for transport systems to implement, on the basis of the transport features discussed in [RFC8303].
トランスポートプロトコルからアプリケーションを切り離すことによって、トランスポートシステムはBerkeley Socketsインターフェイス[POSIX]よりも異なる抽象化レベルを提供します。低レベルのプログラミング言語と同様に、より高い抽象化レベルでは、インターフェースの下に自動化の自由度が向上しますが、アプリケーションプログラマーからいくらかのコントロールが必要です。これは、トランスポートシステム開発者が直面しているデザイントレードオフであり、この文書はこの抽象化レベルの設計に関するガイダンスを提供します。いくつかのトランスポート機能は現在APIによって提供されていません、それでも彼らは提供されなければならないか、それらが決して使われないことがあります。他のトランスポート機能は、ここでカバーされているプロトコルのAPIによって提供されますが、APIでそれらを公開していないと、トランスポートシステムでプロトコル使用量を自動化することができます。ここに提示された最小セットは、[RFC8303]で説明した輸送機能に基づいて、輸送システムに推奨することができる中間地を見つけるための努力である。
Applications use a wide variety of APIs today. While this document was created to ensure the API developed in the Transport Services (TAPS) Working Group [TAPS-INTERFACE] includes the most important transport features, the minimal set presented here must be reflected in *all* network APIs in order for the underlying functionality to become usable everywhere. For example, it does not help an application that talks to a library that offers its own communication interface if the underlying Berkeley Sockets API is extended to offer "unordered message delivery", but the library only exposes an ordered byte stream. Both the Berkeley Sockets API and the library would have to expose the "unordered message delivery" transport feature (alternatively, there may be ways for certain types of libraries to use this transport feature without exposing it, based on knowledge about the applications, but this is not the general case). Similarly, transport protocols such as the Stream Control Transmission Protocol (SCTP) offer multi-streaming, which cannot be utilized, e.g., to prioritize messages between streams, unless applications communicate the priorities and the group of connections upon which these priorities should be applied. In most situations, in the interest of being as flexible and efficient as possible, the best choice will be for a library to expose at least all of the transport features that are recommended as a "minimal set" here.
アプリケーションは今日さまざまなAPIを使用しています。この文書は、トランスポートサービス（TAPS）ワーキンググループ[TAPS-Interface]で開発されたAPIを確実にするために作成されていますが、ここに提示された最小セットは、基礎となるために*すべての*ネットワークAPIに反映されなければなりません。どこでも使える機能。たとえば、基礎となるBerkeley Sockets APIが「順序付けられていないメッセージ配信」を提供するために拡張されている場合は、独自の通信インタフェースを提供するライブラリとの通信を提供するのは役立ちませんが、ライブラリは順序付きバイトストリームのみを公開します。 Berkeley Sockets APIとライブラリの両方が「順不同のメッセージ配信」トランスポート機能を公開しなければならないであろう（代替的に、特定の種類のライブラリーには、アプリケーションに関する知識に基づいてこのトランスポート機能を使用する方法がある場合がありますが、これに基づいてこのトランスポート機能を使用する方法があるかもしれません。一般的なケースではありません）。同様に、ストリーム制御伝送プロトコル（SCTP）のようなトランスポートプロトコルはマルチストリーミングを提供し、これは、アプリケーションが優先順位とこれらの優先順位を適用する接続のグループを通信しない限り、ストリーム間のメッセージを優先することができない。ほとんどの状況では、できるだけ柔軟で効率的であることの興味において、最良の選択は、ここで「最小セット」として推奨されるトランスポート機能の少なくとも全てのトランスポート機能を公開するための最良の選択である。
This "minimal set" can be implemented "one-sided" over TCP. This means that a sender-side transport system can talk to a standard TCP receiver, and a receiver-side transport system can talk to a standard TCP sender. If certain limitations are put in place, the "minimal set" can also be implemented "one-sided" over UDP. While the possibility of such "one-sided" implementation may help deployment, it comes at the cost of limiting the set to services that can also be provided by TCP (or, with further limitations, UDP). Thus, the minimal set of transport features here is applicable for many, but not all, applications; some application protocols have requirements that are not met by this "minimal set".
この「最小セット」は、TCPを介して「片面」に実装することができます。これは、送信側送信システムが標準のTCP受信機と通信できることを意味し、受信側のトランスポートシステムは標準のTCP送信者と通信することができる。特定の制限がある場合は、「最小セット」をUDP上の「片面」にも実装できます。そのような「一方的な」実装の可能性は展開を助けるかもしれないが、それはTCPによって提供され得るサービス（またはさらなる制限、UDP）によって提供され得るサービスへのセットを制限するコストがある。したがって、ここでは、ここでのトランスポートフィーチャの最小セットは、多くのアプリケーションに適用できます。このアプリケーションプロトコルでは、この「最小セット」で満たされていない要件があります。
Note that, throughout this document, protocols are meant to be used natively. For example, when transport features of TCP, or "implementation over" TCP is discussed, this refers to native usage of TCP rather than TCP being encapsulated in some other transport protocol such as UDP.
この文書を通して、プロトコルはネイティブに使用されることを意図しています。たとえば、TCPのトランスポート機能、または「実装over」TCPについて説明した場合、これは、UDPなどの他のトランスポートプロトコルでカプセル化されているTCPではなくTCPのネイティブ使用量を指します。
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, that provides a complete service to an application.
トランスポートサービス：特定のフレーミングプロトコルとの関連付けがない一連のトランスポート機能は、アプリケーションに完全なサービスを提供します。
Transport Protocol: An implementation that provides one or more different Transport Services using a specific framing and header format on the wire.
トランスポートプロトコル：ワイヤ上の特定のフレーミングおよびヘッダフォーマットを使用して1つ以上の異なるトランスポートサービスを提供する実装。
Application: An entity that uses a transport-layer interface for end-to-end delivery of data across the network (this may also be an upper-layer protocol or tunnel encapsulation).
アプリケーション：ネットワーク全体のデータのエンドツーエンド配信のためのトランスポート層インタフェースを使用するエンティティ（これは、上位レイヤプロトコルまたはトンネルカプセル化でもよい）でもよい。
Application-specific knowledge: Knowledge that only applications have.
アプリケーション固有の知識アプリケーションのみがあるという知識。
End system: An entity that communicates with one or more other end systems using a transport protocol. An end system provides a transport-layer interface to applications.
エンドシステム：トランスポートプロトコルを使用して1つまたは複数の他のエンドシステムと通信するエンティティ。エンドシステムはアプリケーションにトランスポート層インタフェースを提供します。
Connection: Shared state of two or more end systems that persists across messages that are transmitted between these end systems.
接続：これらのエンドシステム間で送信されるメッセージ間で続く2つ以上のエンドシステムの共有状態。
Connection Group: A set of connections that share the same configuration (configuring one of them causes all other connections in the same group to be configured in the same way). We call connections that belong to a connection group "grouped", while "ungrouped" connections are not a part of a connection group.
接続グループ：同じ設定を共有する接続のセット（それらの1つを設定すると、同じグループ内の他のすべての接続が同じように設定されます）。「グループ化されていない」接続が接続グループの一部ではありませんが、接続グループに属する接続を呼び出します。
Socket: The combination of a destination IP address and a destination port number.
ソケット：宛先IPアドレスと宛先ポート番号の組み合わせ。
Moreover, throughout the document, the protocol name "UDP(-Lite)" is used when discussing transport features that are equivalent for UDP and UDP-Lite; similarly, the protocol name "TCP" refers to both TCP and MPTCP.
さらに、文書全体を通して、UDPおよびUDP-Liteに相当するトランスポート機能を議論するときに、プロトコル名「UDP（-Lite）」が使用されます。同様に、プロトコル名「TCP」はTCPとMPTCPの両方を参照しています。
We assume that applications have no specific requirements that need knowledge about the network, e.g., regarding the choice of network interface or the end-to-end path. Even with these assumptions, there are certain requirements that are strictly kept by transport protocols today, and these must also be kept by a transport system. Some of these requirements relate to transport features that we call "Functional".
アプリケーションでは、ネットワークに関する知識を必要とする特定の要件は、例えば、ネットワークインターフェイスの選択、またはエンドツーエンドパスについての特定の要件がないと仮定します。これらの仮定でさえも、今日の輸送プロトコルによって厳密に保存されている特定の要件があり、これらもトランスポートシステムによって保管されなければなりません。これらの要件のいくつかは、「機能」と呼ぶトランスポート機能に関するものです。
Functional transport features provide functionality that cannot be used without the application knowing about them, or else they violate assumptions that might cause the application to fail. For example, ordered message delivery is a functional transport feature: it cannot be configured without the application knowing about it because the application's assumption could be that messages always arrive in order. Failure includes any change of the application behavior that is not performance oriented, e.g., security.
機能トランスポート機能は、アプリケーションを知っていないアプリケーションなしで使用できない機能を提供します。そうしないと、アプリケーションが失敗する可能性がある前提となります。たとえば、順序付けられたメッセージ配信は機能転送機能です。アプリケーションの前提が常に順番に到着する可能性があるため、アプリケーションを知っていないアプリケーションなしで設定することはできません。失敗には、パフォーマンス指向ではないアプリケーションの動作の変更、例えばセキュリティが含まれます。
"Change DSCP" and "Disable Nagle algorithm" are examples of transport features that we call "Optimizing"; if a transport system autonomously decides to enable or disable them, an application will not fail, but a transport system may be able to communicate more efficiently if the application is in control of this optimizing transport feature. These transport features require application-specific knowledge (e.g., about delay/bandwidth requirements or the length of future data blocks that are to be transmitted).
「DSCPの変更」と「無効化NAGLEアルゴリズム」は、「最適化」と呼ぶトランスポート機能の例です。トランスポートシステムが自律的にそれらを有効または無効にすることを決定した場合、アプリケーションがこの最適化トランスポート機能を制御する場合、アプリケーションは失敗しませんが、アプリケーションがこの最適化トランスポート機能を制御している場合はトランスポートシステムがより効率的に通信できます。これらのトランスポート機能は、アプリケーション固有の知識（例えば、遅延/帯域幅要件または送信されるべき将来のデータブロックの長さ）を必要とする。
The transport features of IETF transport protocols that do not require application-specific knowledge and could therefore be utilized by a transport system on its own without involving the application are called "Automatable".
アプリケーション固有の知識を必要としないIETF輸送プロトコルのトランスポート機能は、そのアプリケーションを含まずに自分自身のトランスポートシステムによって利用される可能性がある。
We approach the construction of a minimal set of transport features in the following way:
次のようにして、最小限の輸送機能の構築に近づきます。
1. Categorization (Appendix A): The superset of transport features from [RFC8303] is presented, and transport features are categorized as Functional, Optimizing, or Automatable for later reduction.
1. 分類（付録A）：[RFC8303]からのトランスポート機能のスーパーセットが表示され、トランスポート機能は後で低減のために機能的、最適化、または自動化可能性として分類されます。
2. Reduction (Section 4): A shorter list of transport features is derived from the categorization in the first step. This removes all transport features that do not require application-specific knowledge or would result in semantically incorrect behavior if they were implemented over TCP or UDP.
2. 縮小（セクション4）：トランスポート機能の短いリストは、最初のステップでの分類から導き出されます。これにより、アプリケーション固有の知識を必要としないすべてのトランスポート機能が削除されているか、TCPまたはUDPを介して実装されている場合は意味的に誤った動作をもたらすであろう。
3. Discussion (Section 5): The resulting list shows a number of peculiarities that are discussed, to provide a basis for constructing the minimal set.
3. 議論（セクション5）：結果のリストは、最小セットを構築するための基礎を提供するために、説明されている数の特異性を示しています。
4. Construction (Section 6): Based on the reduced set and the discussion of the transport features therein, a minimal set is constructed.
4. 構成（セクション6）：縮小されたセットとその中の輸送機構の説明に基づいて、最小のセットが構築されます。
Following [RFC8303] and retaining its terminology, we divide the transport features into two main groups as follows:
[RFC8303]をフォローしてその用語を保持すると、トランスポート機能を次のように2つの主グループに分割します。
1. CONNECTION-related transport features
1. 接続関連のトランスポート機能
* ESTABLISHMENT * AVAILABILITY * MAINTENANCE * TERMINATION
* 設立*可用性*メンテナンス*終了
2. DATA-Transfer-related transport features
2. データ転送関連のトランスポート機能
* Sending Data * Receiving Data * Errors
* データの送信*データの受信*エラー
By hiding automatable transport features from the application, a transport system can gain opportunities to automate the usage of network-related functionality. This can facilitate using the transport system for the application programmer and it allows for optimizations that may not be possible for an application. For instance, system-wide configurations regarding the usage of multiple interfaces can better be exploited if the choice of the interface is not entirely up to the application. Therefore, since they are not strictly necessary to expose in a transport system, we do not include automatable transport features in the reduced set of transport features. This leaves us with only the transport features that are either optimizing or functional.
アプリケーションから自動化可能なトランスポート機能を非表示にすることで、トランスポートシステムはネットワーク関連の機能の使用を自動化する機会を得ることができます。これにより、アプリケーション・プログラマーのトランスポートシステムの使用が容易になり、アプリケーションが不可能な最適化を可能にします。たとえば、インターフェイスの選択が完全にアプリケーションまでの場合、複数のインターフェイスの使用方法に関するシステム全体の構成を利用することができます。したがって、それらは輸送システムを露出させるために厳密に必要ではないので、短縮された輸送機関のセットの自動化可能な輸送機能を含まない。これにより、最適化または機能的なトランスポート機能だけが残ります。
A transport system should be able to communicate via TCP or UDP if alternative transport protocols are found not to work. For many transport features, this is possible, often by simply not doing anything when a specific request is made. For some transport features, however, it was identified that direct usage of neither TCP nor UDP is possible; in these cases, even not doing anything would incur semantically incorrect behavior. Whenever an application would make use of one of these transport features, this would eliminate the possibility to use TCP or UDP. Thus, we only keep the functional and optimizing transport features for which an implementation over either TCP or UDP is possible in our reduced set.
交通システムが機能しないことが判明した場合、トランスポートシステムはTCPまたはUDPを介して通信できるはずです。多くのトランスポート機能については、特定の要求が行われたときに単に何もしていないことが可能です。しかし、いくつかの輸送機能のために、TCPもUDPも可能でないという直接使用が可能であることが確認された。このような場合、何もしていないことさえ、意味的に間違った行動を招くでしょう。アプリケーションがこれらのトランスポート機能の1つを利用するときはいつでも、これによりTCPまたはUDPを使用する可能性がなくなります。したがって、我々は、縮小されたセットにおいてTCPまたはUDPのいずれかにわたる実施が可能である機能的および最適化の輸送機能を維持するだけである。
The following list contains the transport features from Appendix A, reduced using these rules. The "minimal set" derived in this document is meant to be implementable "one-sided" over TCP and, with limitations, UDP. In the list, we therefore precede a transport feature with "T:" if an implementation over TCP is possible, "U:" if an implementation over UDP is possible, and "T,U:" if an implementation over either TCP or UDP is possible.
以下のリストには、付録Aのトランスポート機能が含まれており、これらの規則を使用して削減されます。この文書で導き出された「最小セット」は、TCPを介して「片面」、および制限事項、UDPを介して実装可能な「一方的」であることを意味しています。リストでは、TCPを介した実装が可能な場合は「T：」を使用してトランスポート機能に先行して、UDPを介して実装が可能な場合は「U：」、TCPまたはUDPのいずれかを超える実装が可能な場合は "T、U："可能です。
ESTABLISHMENT:
確立：
* T,U: Connect * T,U: Specify number of attempts and/or timeout for the first establishment message * T,U: Disable MPTCP * T: Configure authentication * T: Hand over a message to reliably transfer (possibly multiple times) before connection establishment * T: Hand over a message to reliably transfer during connection establishment
* T、U：CONNECT * T、U：最初の確立メッセージの試行回数やタイムアウトを指定します。接続確立の前に* T：接続確立中に確実に転送するメッセージを渡す
AVAILABILITY:
可用性：
* T,U: Listen * T,U: Disable MPTCP * T: Configure authentication
* t、u：listen * t、u：mptcp * t：認証の設定
MAINTENANCE:
メンテナンス：
* T: Change timeout for aborting connection (using retransmit limit or time value) * T: Suggest timeout to the peer * T,U: Disable Nagle algorithm * T,U: Notification of Excessive Retransmissions (early warning below abortion threshold) * T,U: Specify DSCP field * T,U: Notification of ICMP error message arrival * T: Change authentication parameters * T: Obtain authentication information * T,U: Set Cookie life value * T,U: Choose a scheduler to operate between streams of an association * T,U: Configure priority or weight for a scheduler * T,U: Disable checksum when sending * T,U: Disable checksum requirement when receiving * T,U: Specify checksum coverage used by the sender * T,U: Specify minimum checksum coverage required by receiver * T,U: Specify DF field * T,U: Get max. transport-message size that may be sent using a non-fragmented IP packet from the configured interface * T,U: Get max. transport-message size that may be received from the configured interface * T,U: Obtain ECN field * T,U: Enable and configure a "Low Extra Delay Background Transfer"
* T：接続を中止するためのタイムアウトを変更する（再送制限または時間値を使用して）* T：ピアへのタイムアウト* T、U：無効にする* T、U：過度の再送信の通知（中絶閾値以下の早期警告）* T、 U：DSCPフィールドを指定します。* T、U：ICMPエラーメッセージ到着通知* T：認証パラメータの変更* T：認証情報* T、U：セットCookie Life Value * T、U：のストリーム間で動作するスケジューラを選択する協会* T、U：スケジューラ* Tの優先順位または重みを設定します。* T、U：チェックサムを無効にします* T、U：受信したときのチェックサム要件を無効にする* T、U：送信側* T、Uで使用されるチェックサムカバレッジを指定Receiver * T、U：DFフィールド* T、U：GET MAXを指定します。設定されたインタフェース* tから、断片化されていないIPパケットを使用して送信され得るトランスポートメッセージサイズ* T、U：MAXを取得します。設定されたインタフェース* tから受信できるトランスポートメッセージサイズ* t、u：ECNフィールド* t、u： "低特別遅延バックグラウンド転送"を有効にして設定します。
TERMINATION:
終了：
* T: Close after reliably delivering all remaining data, causing an event informing the application on the other side * T: Abort without delivering remaining data, causing an event informing the application on the other side * T,U: Abort without delivering remaining data, not causing an event informing the application on the other side * T,U: Timeout event when data could not be delivered for too long
* T：残りのすべてのデータを確実に配信した後に閉じる、残りのデータを配信せずにアプリケーションをアプリケーションに通知するイベントを引き起こし、残りのデータを配信せずにアプリケーションに通知するイベントを引き起こし、残りのデータを配信せずに中止されます。データが長すぎるために配信できなかった場合、アプリケーションに他の側面にアプリケーションに通知されないようにしていません。
* T: Reliably transfer data, with congestion control * T: Reliably transfer a message, with congestion control * T,U: Unreliably transfer a message * T: Configurable Message Reliability * T: Ordered message delivery (potentially slower than unordered) * T,U: Unordered message delivery (potentially faster than ordered) * T,U: Request not to bundle messages * T: Specifying a key id to be used to authenticate a message * T,U: Request not to delay the acknowledgement (SACK) of a message
* T：確実にデータを輻輳制御で転送する* T：輻輳制御を確実に転送します。輻輳制御* T、U：UNERURIUNICATIONを再構築しますU：順序付けられていないメッセージ配信（注文よりも潜在的に早く）* T、U：メッセージをバンドルしない要求* T：メッセージの認証に使用されるキーIDの指定* t、u：承認（袋）を遅らせることはできません。メッセージ
* T,U: Receive data (with no message delimiting) * U: Receive a message * T,U: Information about partial message arrival
* T、U：データを受信（メッセージの区切りなし）* U：メッセージを受信* T、U：部分メッセージ到着に関する情報
This section describes sending failures that are associated with a specific call to in the "Sending Data" category (Appendix A.2.1).
このセクションでは、「データの送信データ」カテゴリ（付録A.2.1）での特定の呼び出しに関連付けられている障害の送信について説明します。
* T,U: Notification of send failures * T,U: Notification that the stack has no more user data to send * T,U: Notification to a receiver that a partial message delivery has been aborted
* T、U：送信失敗の通知* t、u：スタックに* T、U：部分メッセージ配信が中止されたことを受信側に通知するための通知
The reduced set in the previous section exhibits a number of peculiarities, which we will discuss in the following. This section focuses on TCP because, with the exception of one particular transport feature ("Receive a message"; we will discuss this in Section 5.1), the list shows that UDP is strictly a subset of TCP. We can first try to understand how to build a transport system that can run over TCP, and then narrow down the result further to allow that the system can always run over either TCP or UDP (which effectively means removing everything related to reliability, ordering, authentication, and closing/aborting with a notification to the peer).
前のセクションの設定されたセットは数多くの特殊性を示します。これについては、以下で説明します。このセクションは、1つの特定のトランスポート機能を除いて（「メッセージを受信する」を除いてTCPに焦点を当てています。これをセクション5.1で説明します）、リストはUDPがTCPのサブセットであることを示しています。最初にTCPを介して実行できるトランスポートシステムを構築する方法を理解してから、システムが常にTCPまたはUDPのどちらかを介して実行できるようにするためにさらに結果を絞り込みます（これは、信頼性、注文に関連するすべてのものを取り除くことを意味します。ピアへの通知を使用した認証、および閉鎖/中止。
Note that, because the functional transport features of UDP are, with the exception of "Receive a message", a subset of TCP, TCP can be used as a replacement for UDP whenever an application does not need message delimiting (e.g., because the application-layer protocol already does it). This has been recognized by many applications that already do this in practice, by trying to communicate with UDP at first and falling back to TCP in case of a connection failure.
UDPの機能転送機能は、「メッセージの受信」を除いて、TCPのサブセットを除いて、アプリケーションがメッセージの区切りを必要としないときはいつでも、TCPのサブセットをUDPの置き換えとして使用することができます（たとえば、アプリケーションのため）。-layerプロトコルはすでにそれをしています）。これは、最初にUDPと通信し、接続障害の場合にはTCPに戻ることを試みることによって、これを実際に行う多くのアプリケーションによって認識されています。
For implementing a transport system over TCP, there are several transport features related to sending, but only a single transport feature related to receiving: "Receive data (with no message delimiting)" (and, strangely, "information about partial message arrival"). Notably, the transport feature "Receive a message" is also the only non-automatable transport feature of UDP(-Lite) for which no implementation over TCP is possible.
TCPを介してトランスポートシステムを実装するために、送信に関連するトランスポート機能はいくつかありますが、受信に関連する単一のトランスポート機能のみです。。特に、「メッセージを受信する」は、TCPよりも実装が可能でないUDP（ - ライト）の唯一の自動化可能な輸送機能でもある。
To support these TCP receiver semantics, we define an "Application-Framed Byte Stream" (AFra Byte Stream). AFra Byte Streams allow senders to operate on messages while minimizing changes to the TCP socket API. In particular, nothing changes on the receiver side; data can be accepted via a normal TCP socket.
これらのTCP受信側の意味論をサポートするには、「アプリケーションフレームのバイトストリーム」（AFRAバイトストリーム）を定義します。AFRAバイトストリームにより、送信者はTCP Socket APIへの変更を最小限に抑えながら、メッセージを操作できます。特に、受信側には何も変わらない。データは通常のTCPソケットを介して受け入れることができます。
In an AFra Byte Stream, the sending application can optionally inform the transport about message boundaries and required properties per message (configurable order and reliability, or embedding a request not to delay the acknowledgement of a message). Whenever the sending application specifies per-message properties that relax the notion of reliable in-order delivery of bytes, it must assume that the receiving application is 1) able to determine message boundaries, provided that messages are always kept intact, and 2) able to accept these relaxed per-message properties. Any signaling of such information to the peer is up to an application-layer protocol and considered out of scope of this document.
AFRAバイトストリームでは、送信側アプリケーションは、メッセージごとにメッセージ境界と必要なプロパティ（設定可能な順序と信頼性、またはメッセージの確認応答を遅らせる必要がない要求の埋め込み）をオプションで通知することができます。送信側アプリケーションがバイトの信頼できる順序配信の概念を緩和するメッセージごとのプロパティを指定するたびに、メッセージが常にUNTACTに保たれている場合には、受信アプリケーションがメッセージ境界を決定できると仮定しなければならず、2）これらのリラックスしたメッセージごとのプロパティを受け入れるには。ピアへのそのような情報のシグナリングは、アプリケーション層プロトコルまで、この文書の範囲外であると考えられています。
For example, if an application requests to transfer fixed-size messages of 100 bytes with partial reliability, this needs the receiving application to be prepared to accept data in chunks of 100 bytes. Then, if some of these 100-byte messages are missing (e.g., if SCTP with Configurable Reliability is used), this is the expected application behavior. With TCP, no messages would be missing, but this is also correct for the application, and the possible retransmission delay is acceptable within the best-effort service model (see Section 3.5 of [RFC7305]). Still, the receiving application would separate the byte stream into 100-byte chunks.
たとえば、アプリケーションが部分的な信頼性を持つ100バイトの固定サイズのメッセージを転送する要求を要求する場合、これにより、100バイトのチャンク内のデータを受け入れる準備をできてください。次に、これらの100バイトのメッセージのうちのいくつかが欠落している場合（例えば、設定可能な信頼性を持つSCTPが使用されている場合）、これが予想されるアプリケーションの動作です。TCPでは、メッセージは不足していませんが、これはアプリケーションにも正しいものです。それでも、受信側アプリケーションはバイトストリームを100バイトのチャンクに分離します。
Note that this usage of messages does not require all messages to be equal in size. Many application protocols use some form of Type-Length-Value (TLV) encoding, e.g., by defining a header including length fields; another alternative is the use of byte stuffing methods such as Consistent Overhead Byte Stuffing (COBS) [COBS]. If an application needs message numbers, e.g., to restore the correct sequence of messages, these must also be encoded by the application itself, as SCTP's transport features that are related to the sequence number are not provided by the "minimum set" (in the interest of enabling usage of TCP).
このメッセージの使用方法では、すべてのメッセージがサイズで等しくなる必要はありません。多くのアプリケーションプロトコルは、長さフィールドを含むヘッダを定義することによって、ある形式のタイプ長値（TLV）エンコードを使用する。もう1つの代替案は、一貫したオーバーヘッドバイトスタッフィング（COB）[COBS]などのバイトスタッフィング方法の使用です。アプリケーションがメッセージ番号を必要とする場合、例えばメッセージの正しいシーケンスを復元するためには、シーケンス番号に関連するSCTPのトランスポート機能が「最小セット」によって提供されていないため、これらはアプリケーション自体によって符号化されなければならない（）。TCPの使用を可能にするための利益）。
We have already stated that multi-streaming does not require application-specific knowledge. Potential benefits or disadvantages of, e.g., using two streams of an SCTP association versus using two separate SCTP associations or TCP connections are related to knowledge about the network and the particular transport protocol in use, not the application. However, the transport features "Choose a scheduler to operate between streams of an association" and "Configure priority or weight for a scheduler" operate on streams. Here, streams identify communication channels between which a scheduler operates, and they can be assigned a priority. Moreover, the transport features in the MAINTENANCE category all operate on associations in case of SCTP, i.e., they apply to all streams in that association.
マルチストリーミングではアプリケーション固有の知識が必要ではないと述べています。例えば、2つの別々のSCTPアソシエーションまたはTCP接続を使用して2つのSCTP関連の2つのストリームを使用することの可能性のある利点または短所は、アプリケーションではなく、ネットワークに関する知識と使用中の特定のトランスポートプロトコルとに関連しています。ただし、トランスポート機能は「アソシエーションのストリーム間で動作するスケジューラを選択」、「スケジューラの優先順位または重みを設定する」ストリームで動作します。ここで、ストリームはスケジューラが動作する通信チャネルを識別し、優先順位を割り当てることができる。さらに、メンテナンスカテゴリのトランスポート機能は、SCTPの場合、すなわちその関連付けのすべてのストリームに適用される場合に、関連付けられています。
With only these semantics necessary to represent, the interface to a transport system becomes easier if we assume that connections may be not only a transport protocol's connection or association, but could also be a stream of an existing SCTP association, for example. We only need to allow for a way to define a possible grouping of connections. Then, all MAINTENANCE transport features can be said to operate on connection groups, not connections, and a scheduler operates on the connections within a group.
これらのセマンティクスのみを表すために必要な場合、接続がトランスポートプロトコルの接続または関連付けられているだけでなく、たとえば既存のSCTPアソシエーションのストリームでもあると仮定すると、トランスポートシステムへのインタフェースが簡単になります。接続の可能なグループ化を定義する方法を許可する必要があります。次に、すべてのメンテナンストランスポート機能を接続しない接続グループで動作すると言える、スケジューラはグループ内の接続で動作します。
To be compatible with multiple transport protocols and uniformly allow access to both transport connections and streams of a multi-streaming protocol, the semantics of opening and closing need to be the most restrictive subset of all of the underlying options. For example, TCP's support of half-closed connections can be seen as a feature on top of the more restrictive "ABORT"; this feature cannot be supported because not all protocols used by a transport system (including streams of an association) support half-closed connections.
複数のトランスポートプロトコルと互換性があり、マルチストリーミングプロトコルのトランスポート接続とストリームの両方へのアクセスを均一に許可するためには、開閉のセマンティクスは、基礎となるすべてのオプションの最も制限的なサブセットである必要があります。例えば、TCPの半閉鎖接続のサポートは、より制限的な「中止」の上の特徴として見ることができます。トランスポートシステムで使用されるすべてのプロトコル（Associationのストリームを含む）が半クローズをサポートするわけではないため、この機能はサポートできません。
There are two transport features related to transferring a message early: "Hand over a message to reliably transfer (possibly multiple times) before connection establishment", which relates to TCP Fast Open [RFC7413], and "Hand over a message to reliably transfer during connection establishment", which relates to SCTP's ability to transfer data together with the COOKIE-Echo chunk. Also without TCP Fast Open, TCP can transfer data during the handshake, together with the SYN packet; however, the receiver of this data may not hand it over to the application until the handshake has completed. Also, different from TCP Fast Open, this data is not delimited as a message by TCP (thus, not visible as a "message"). This functionality is commonly available in TCP and supported in several implementations, even though the TCP specification does not explain how to provide it to applications.
メッセージの転送に関連する2つのトランスポート機能があります。「接続確立前に（おそらく複数回）、これはTCP Fast Open [RFC7413]、および「確実に転送するメッセージの上に手を差し伸ばす」Cookie-Echoチャンクと一緒にデータを転送するSCTPの能力に関連する接続確立。TCP Fast Openを使用することなく、TCPはシンクパケットとともにハンドシェイク中にデータを転送できます。ただし、このデータの受信者は、ハンドシェイクが完了するまでアプリケーションにそれを扱うことはできません。また、TCP Fast Openとは異なり、このデータはTCPによるメッセージとして区切られていません（したがって、「メッセージ」として表示されません）。この機能はTCPで一般的に利用可能であり、TCP仕様ではアプリケーションに提供する方法を説明していなくても、いくつかの実装でサポートされています。
A transport system could differentiate between the cases of transmitting data "before" (possibly multiple times) or "during" the handshake. Alternatively, it could also assume that data that are handed over early will be transmitted as early as possible, and "before" the handshake would only be used for messages that are explicitly marked as "idempotent" (i.e., it would be acceptable to transfer them multiple times).
輸送システムは、データを送信する場合（おそらく複数回）またはハンドシェイクを「中」に送信する場合を区別することができる。あるいは、早期に渡されるデータができるだけ早く送信されることを仮定することもでき、ハンドシェイクは「IDEmpotent」として明示的にマークされているメッセージに対してのみ使用されます（つまり、転送に受け入れられるのは許容されます。それらを複数回）。
The amount of data that can successfully be transmitted before or during the handshake depends on various factors: the transport protocol, the use of header options, the choice of IPv4 and IPv6, and the Path MTU. A transport system should therefore allow a sending application to query the maximum amount of data it can possibly transmit before (or, if exposed, during) connection establishment.
ハンドシェイクの前または間に正常に送信されるデータの量は、トランスポートプロトコル、ヘッダオプションの使用、IPv4およびIPv6の選択、およびパスMTUによって異なります。したがって、トランスポートシステムは、送信アプリケーションが最大量のデータ量をクエリすることを許可する必要があります。
The transport feature "Notification that the stack has no more user data to send" relates to SCTP's "SENDER DRY" notification. Such notifications can, in principle, be used to avoid having an unnecessarily large send buffer, yet ensure that the transport sender always has data available when it has an opportunity to transmit it. This has been found to be very beneficial for some applications [WWDC2015]. However, "SENDER DRY" truly means that the entire send buffer (including both unsent and unacknowledged data) has emptied, i.e., when it notifies the sender, it is already too late; the transport protocol already missed an opportunity to send data. Some modern TCP implementations now include the unspecified "TCP_NOTSENT_LOWAT" socket option that was proposed in [WWDC2015], which limits the amount of unsent data that TCP can keep in the socket buffer; this allows specifying at which buffer filling level the socket becomes writable, rather than waiting for the buffer to run empty.
SCTPの「送信者ドライ」通知に関連しています。そのような通知は、原則として、不必要に大きな送信バッファを有することを回避するために使用されていても、それがそれを送信する機会があるときにトランスポート送信者が常に利用可能なデータを有することを確実にすることができる。これはいくつかのアプリケーションにとって非常に有益であることがわかっています[WWDC2015]。しかしながら、「送信者ドライ」は本当に（未送信および未確認データの両方を含む）送信バッファ全体が空になった、すなわち送信者に通知されたとき、すでに遅すぎることを意味する。トランスポートプロトコルはすでにデータを送信する機会を逃していました。いくつかの最新のTCP実装には、[WWDC2015]で提案されていない未指定の「TCP_NOTSENT_LOWAT」ソケットオプションが含まれています。これにより、TCPがソケットバッファに保持できるわけではないデータの量が制限されます。これにより、バッファが空の実行を待機するのを待つのではなく、ソケットが書き込み可能になるかを指定できます。
SCTP allows configuring the sender-side buffer too; the automatable Transport Feature "Configure send buffer size" provides this functionality, but only for the complete buffer, which includes both unsent and unacknowledged data. SCTP does not allow to control these two sizes separately. It therefore makes sense for a transport system to allow for uniform access to "TCP_NOTSENT_LOWAT" as well as the "SENDER DRY" notification.
SCTPは送信側バッファを設定することを可能にします。自動化可能なトランスポート機能「SEND BUFFER SIZEの設定」はこの機能を提供しますが、完全なバッファに対してのみ、未送信のデータと未確認データの両方を含みます。SCTPは、これら2つのサイズを別々に制御することを可能にしません。したがって、「送信者ドライ」通知と同様に、「TCP_NOTSENT_LOWAT」と同様に「TCP_NOTSENT_LOWAT」への統一アクセスを可能にすることが理にかなっています。
The transport features:
トランスポート機能：
* Disable Nagle algorithm * Enable and configure a "Low Extra Delay Background Transfer" * Specify DSCP field
* Nagle Algorithmを無効にする*「余分な遅延バックグラウンド転送」を有効にして設定する* DSCPフィールドを指定する
All relate to a QoS-like application need such as "low latency" or "scavenger". In the interest of flexibility of a transport system, they could therefore be offered in a uniform, more abstract way, where a transport system could, e.g., decide by itself how to use combinations of LEDBAT-like congestion control and certain DSCP values, and an application would only specify a general "capacity profile" (a description of how it wants to use the available capacity). A need for "lowest possible latency at the expense of overhead" could then translate into automatically disabling the Nagle algorithm.
すべて「低遅延」または「スカベンジャー」などのQoS様アプリケーションの必要性に関するものです。輸送システムの柔軟性の利点において、それらは、例えば、輸送システムがLEDBATのような輻輳制御および特定のDSCP値の組み合わせを使用する方法によって決定されることができる、統一されたより抽象的な方法で提供され得る。アプリケーションは、一般的な「容量プロファイル」（使用可能な容量を使用したい方法の説明）のみを指定します。「オーバーヘッドを犠牲にして可能な限り低い待ち時間」の必要性は、NAGLEアルゴリズムを自動的に無効にするように変換できます。
In some cases, the Nagle algorithm is best controlled directly by the application because it is not only related to a general profile but also to knowledge about the size of future messages. For fine-grain control over Nagle-like functionality, the "Request not to bundle messages" is available.
場合によっては、NAGLEアルゴリズムは、一般的なプロファイルだけでなく、将来のメッセージのサイズに関する知識にも対応しているため、アプリケーションによって直接管理されています。Nagleのような機能を越えて細かく穀物制御するために、「メッセージをバンドルしない要求」が利用可能です。
Both TCP and SCTP offer authentication. TCP authenticates complete segments. SCTP allows configuring which of SCTP's chunk types must always be authenticated; if this is exposed as such, it creates an undesirable dependency on the transport protocol. For compatibility with TCP, a transport system should only allow to configure complete transport layer packets, including headers, IP pseudo-header (if any) and payload.
TCPとSCTPの両方が認証を提供します。TCPは完全なセグメントを認証します。SCTPでは、SCTPのチャンクタイプのどれが常に認証されている必要がある設定を可能にします。このようにさらされると、トランスポートプロトコルに望ましくない依存関係が生じます。TCPとの互換性のために、トランスポートシステムは、ヘッダー、IP疑似ヘッダー（ある場合）およびペイロードを含む、完全なトランスポートレイヤパケットを設定できるだけです。
Security is discussed in a separate document [RFC8922]. The minimal set presented in the present document excludes all security-related transport features from Appendix A: "Configure authentication", "Change authentication parameters", "Obtain authentication information", and "Set Cookie life value", as well as "Specifying a key id to be used to authenticate a message". It also excludes security transport features not listed in Appendix A, including content privacy to in-path devices.
セキュリティは別の文書で説明されています[RFC8922]。本文書に提示された最小セットは、付録A：「認証の設定」、「認証パラメータの変更」、「認証情報の変更」、「認証情報の変更」、「Cookie Life Value」、および「設定を指定する」というすべてのセキュリティ関連のトランスポート機能を除外します。メッセージの認証に使用されるキーID」また、In-PATHデバイスに対するコンテンツのプライバシーを含む、付録Aに記載されていないセキュリティトランスポート機能も除外します。
UDP(-Lite) has a transport feature called "Specify DF field". This yields an error message in the case of sending a message that exceeds the Path MTU, which is necessary for a UDP-based application to be able to implement Path MTU Discovery (a function that UDP-based applications must do by themselves). The "Get max. transport-message size that may be sent using a non-fragmented IP packet from the configured interface" transport feature yields an upper limit for the Path MTU (minus headers) and can therefore help to implement Path MTU Discovery more efficiently.
UDP（-Lite）には、「DFフィールドの指定」と呼ばれるトランスポート機能があります。これにより、UDPベースのアプリケーションがパスMTU検出を実装できるようにする必要があるメッセージMTUを超えるメッセージを送信する場合のエラーメッセージが得られます（UDPベースのアプリケーションが自分自体で行わなければならない関数）。「MAXを取得します。設定されたインターフェイスから断片化されていないIPパケットを使用して送信できるトランスポートメッセージサイズ」トランスポート機能は、パスMTU（マイナスヘッダー）の上限をもたらし、したがってPATUディスカバリをより効率的に実装するのに役立ちます。。
Based on the categorization, reduction, and discussion in Section 3, this section describes a minimal set of transport features that end systems should offer. Any configuration based on the described minimum set of transport feature can always be realized over TCP but also gives the transport system flexibility to choose another transport if implemented. In the text of this section, "not UDP" is used to indicate elements of the system that cannot be implemented over UDP. Conversely, all elements of the system that are not marked with "not UDP" can also be implemented over UDP.
セクション3の分類、削減、および議論に基づいて、このセクションでは、システムをエンドシステムを提供すべき最小限の移送機能について説明します。記載された最小のトランスポート機能セットに基づく構成は、常にTCPを介して実現することができますが、実行されている場合は別のトランスポートを選択するためのトランスポートシステムの柔軟性も与えます。このセクションのテキストでは、UDPを介して実装できないシステムの要素を示すために「UDPではなく」されます。逆に、「UDPではなく」マークされていないシステムのすべての要素もUDPを介して実装できます。
The arguments laid out in Section 5 ("discussion") were used to make the final representation of the minimal set as short, simple, and general as possible. There may be situations where these arguments do not apply, e.g., implementers may have specific reasons to expose multi-streaming as a visible functionality to applications, or the restrictive open/close semantics may be problematic under some circumstances. In such cases, the representation in Section 4 ("reduction") should be considered.
セクション5（「ディスカッション」）に配置された議論を使用して、最小限のセットの最終的な表現をできるだけ短く、単純で一般的に表現した。これらの引数が適用されない状況があるかもしれない、例えば、実装者は、アプリケーションへの可視機能としてマルチストリーミングを公開するための特定の理由があるかもしれないし、または制限的なオープン/クローズセマンティクスは状況下では問題があるかもしれない。そのような場合は、セクション4（「減少」）の表現を考慮する必要があります。
As in Section 3, Section 4, and [RFC8303], we categorize the minimal set of transport features as 1) CONNECTION related (ESTABLISHMENT, AVAILABILITY, MAINTENANCE, TERMINATION) and 2) DATA Transfer related (Sending Data, Receiving Data, Errors). Here, the focus is on connections that the transport system offers as an abstraction to the application, as opposed to connections of transport protocols that the transport system uses.
セクション3、セクション4、および[RFC8303]のように、最小限のトランスポートフィーチャのセットを1）接続関連（確立、可用性、メンテナンス、終了）、および2）データ転送関連（データの送信、データの受信、エラー）。ここで、輸送システムが使用するトランスポートプロトコルの接続とは対照的に、輸送システムがアプリケーションへの抽象化として提供する接続に焦点を当てています。
A connection must first be "created" to allow for some initial configuration to be carried out before the transport system can actively or passively establish communication with a remote end system. As a configuration of the newly created connection, an application can choose to disallow usage of MPTCP. Furthermore, all configuration parameters in Section 6.2 can be used initially, although some of them may only take effect when a connection has been established with a chosen transport protocol. Configuring a connection early helps a transport system make the right decisions. For example, grouping information can influence whether or not the transport system implements a connection as a stream of a multi-streaming protocol's existing association.
移送システムがリモートエンドシステムとの通信を能動的にまたは受動的に確立することができる前に、最初に接続を「作成」する必要があります。新しく作成された接続の構成として、アプリケーションはMPTCPの使用を許可することを選択できます。さらに、セクション6.2のすべての構成パラメータは最初に使用できますが、それらのいくつかは、選択されたトランスポートプロトコルで接続が確立されたときにのみ有効になるかもしれません。接続の設定早期にトランスポートシステムが正しい決定を下すのに役立ちます。例えば、グループ化情報は、トランスポートシステムがマルチストリーミングプロトコルの既存の関連付けのストリームとして接続を実装するかどうかに影響を与える可能性がある。
For ungrouped connections, early configuration is necessary because it allows the transport system to know which protocols it should try to use. In particular, a transport system that only makes a one-time choice for a particular protocol must know early about strict requirements that must be kept, or it can end up in a deadlock situation (e.g., having chosen UDP and later be asked to support reliable transfer). As an example description of how to correctly handle these cases, we provide the following decision tree (this is derived from Section 4.1 excluding authentication, as explained in Section 8):
グループ化されていない接続の場合、トランスポートシステムがどのプロトコルを使用しようとするプロトコルを知ることができるため、初期の設定が必要です。特に、特定のプロトコルのために1回限りの選択されている輸送システムは、保存されなければならない厳格な要件について早期に知らなければならない、またはそれがデッドロック状況で終わることができる（例えば、後でサポートするように求められたものにする）信頼できる転送）これらのケースを正しく処理する方法の例として、次の決定ツリーを提供します（セクション8で説明されているように、これはセクション4.1の認証を除く）。
+----------------------------------------------------------+
| Will it ever be necessary to offer any of the following? |
| * Reliably transfer data |
| * Notify the peer of closing/aborting |
| * Preserve data ordering |
+----------------------------------------------------------+
| |
|Yes |No
| (SCTP or TCP) | (All protocols
| can be used.) | can be used.)
V V
+--------------------------------------+ +-----------------------------+
| Is any of the following useful to | | Is any of the following |
| the application? | | useful to the application? |
| * Choosing a scheduler to operate | | * Specify checksum coverage |
| between connections in a group, | | used by the sender |
| with the possibility to configure | | * Specify minimum checksum |
| a priority or weight per connection| | coverage required by the |
| * Configurable message reliability | | receiver |
| * Unordered message delivery | +-----------------------------+
| * Request not to delay the | | |
| acknowledgement (SACK) of a message| |Yes |No
+--------------------------------------+ | |
| | | |
|Yes |No | |
V | V V
SCTP is | UDP-Lite is UDP is
preferred. | preferred. preferred.
V
+------------------------------------------------------+
| Is any of the following useful to the application? |
| * Hand over a message to reliably transfer (possibly |
| multiple times) before connection establishment |
| * Suggest timeout to the peer |
| * Notification of Excessive Retransmissions (early |
| warning below abortion threshold) |
| * Notification of ICMP error message arrival |
+------------------------------------------------------+
| |
|Yes |No
V V
TCP is preferred. SCTP and TCP
are equally preferable.
Note that this decision tree is not optimal for all cases. For example, if an application wants to use "Specify checksum coverage used by the sender", which is only offered by UDP-Lite, and "Configure priority or weight for a scheduler", which is only offered by SCTP, the above decision tree will always choose UDP-Lite, making it impossible to use SCTP's schedulers with priorities between grouped connections. Also, several other factors may influence the decisions for or against a protocol, e.g., penetration rates, the ability to work through NATs, etc. We caution implementers to be aware of the full set of trade-offs, for which we recommend consulting the list in Section 4.1 when deciding how to initialize a connection.
この決定木はすべての場合に最適ではないことに注意してください。たとえば、アプリケーションがUDP-Liteによってのみ提供される「送信者によって使用されるチェックサムカバレッジの指定」を使用したい場合は、SCTPによってのみ提供されます。常にUDP-Liteを選択し、グループ化された接続間の優先順位でSCTPのスケジューラを使用することは不可能です。また、他のいくつかの要因は、プロトコル、例えば侵入率、NATを通して作業する能力などの決定に影響を与える可能性があります。これについては、推奨されています。接続の初期化方法を決定するときは、セクション4.1のリスト。
To summarize, the following parameters serve as input for the transport system to help it choose and configure a suitable protocol:
要約すると、以下のパラメータは、適切なプロトコルを選択して設定するのを助けるためにトランスポートシステムの入力として機能します。
Reliability: a boolean that should be set to true when any of the following will be useful to the application: reliably transfer data; notify the peer of closing/aborting; or preserve data ordering.
信頼性：以下のいずれかがアプリケーションに役立つ場合にTRUEに設定されるべきブール値：確実にデータを転送します。閉鎖/中止のピアに通知します。またはデータの順序を保存します。
Checksum coverage: a boolean to specify whether it will be useful to the application to specify checksum coverage when sending or receiving.
チェックサムカバレッジ：送信または受信時にチェックサムカバレッジを指定するためにアプリケーションに役立つかどうかを指定するためのブール値。
Configure message priority: a boolean that should be set to true when any of the following per-message configuration or prioritization mechanisms will be useful to the application: choosing a scheduler to operate between grouped connections, with the possibility to configure a priority or weight per connection; configurable message reliability; unordered message delivery; or requesting not to delay the acknowledgement (SACK) of a message.
メッセージ優先順位の設定：次のメッセージごとの構成または優先順位付けメカニズムのいずれかがアプリケーションに役立つ場合は、trueに設定する必要があるブール値が、グループ化された接続間で操作するためのスケジューラを選択します。接続;設定可能なメッセージの信頼性。順不同のメッセージ配信。またはメッセージの確認応答（袋）を遅らせないことを要求します。
Early message timeout notifications: a boolean that should be set to true when any of the following will be useful to the application: hand over a message to reliably transfer (possibly multiple times) before connection establishment; suggest timeout to the peer; notification of excessive retransmissions (early warning below abortion threshold); or notification of ICMP error message arrival.
初期のメッセージタイムアウト通知：次のいずれかがアプリケーションに役立つときにtrueに設定する必要があるブール値は、接続確立の前に（おそらく複数回）のメッセージを渡します。ピアへのタイムアウトを提案する。過度の再送信の通知（中絶しきい値以下の早期警告）。またはICMPエラーメッセージ到着の通知。
Once a connection is created, it can be queried for the maximum amount of data that an application can possibly expect to have reliably transmitted before or during transport connection establishment (with zero being a possible answer) (see Section 6.2.1). An application can also give the connection a message for reliable transmission before or during connection establishment (not UDP); the transport system will then try to transmit it as early as possible. An application can facilitate sending a message particularly early by marking it as "idempotent" (see Section 6.3.1); in this case, the receiving application must be prepared to potentially receive multiple copies of the message (because idempotent messages are reliably transferred, asking for idempotence is not necessary for systems that support UDP).
接続が作成されると、アプリケーションがトランスポート接続確立の前または通過中に確実に送信された可能性があることができる可能性があるデータの最大量のデータ（ゼロが可能な答えである）を照会することができる（セクション6.2.1を参照）。アプリケーションは、接続確立前または接続確立の間（UDPではなく）、信頼できる送信のためのメッセージを接続することもできます。トランスポートシステムはそれをできるだけ早く送信しようとします。アプリケーションは、それを「IDEmpotent」とマークすることによって特に早期にメッセージを送信することを容易にすることができます（6.3.1項を参照）。この場合、受信側アプリケーションは、メッセージの複数のコピーを受信することができます（IDEmpotentメッセージが確実に転送されるため、IDEmpotenceがUDPをサポートするシステムには必要ありません）。
After creation, a transport system can actively establish communication with a peer, or it can passively listen for incoming connection requests. Note that active establishment may or may not trigger a notification on the listening side. It is possible that the first notification on the listening side is the arrival of the first data that the active side sends (a receiver-side transport system could handle this by continuing to block a "Listen" call, immediately followed, for example, by issuing "Receive"; callback-based implementations could simply skip the equivalent of "Listen"). This also means that the active opening side is assumed to be the first side sending data.
作成後、トランスポートシステムは能動的にピアとの通信を確立することも、着信接続要求を受信的にリッスンすることもできます。アクティブな確立は、リスニング側の通知を引き起こす場合があります。リスニング側の最初の通知が、アクティブサイドが送信する最初のデータの到着（受信側トランスポートシステムがこれを扱うことによってこれを処理することができ、その直後に繰り返すことによってこれを処理することができる）の到着である可能性がある。「受信」を発行する。コールバックベースの実装は単に「listen」の相当量をスキップすることができます。これはまた、アクティブな開口側が第1の側面送信データであると仮定されることを意味する。
A transport system can actively close a connection, i.e., terminate it after reliably delivering all remaining data to the peer (if reliable data delivery was requested earlier (not UDP)), in which case the peer is notified that the connection is closed. Alternatively, a connection can be aborted without delivering outstanding data to the peer. In case reliable or partially reliable data delivery was requested earlier (not UDP), the peer is notified that the connection is aborted. A timeout can be configured to abort a connection when data could not be delivered for too long (not UDP); however, timeout-based abortion does not notify the peer application that the connection has been aborted. Because half-closed connections are not supported, when a host implementing a transport system receives a notification that the peer is closing or aborting the connection (not UDP), its peer may not be able to read outstanding data. This means that unacknowledged data residing in a transport system's send buffer may have to be dropped from that buffer upon arrival of a "close" or "abort" notification from the peer.
トランスポートシステムは、接続を積極的に閉じることができ、すなわちピアへのすべての残りのデータを確実に配信した後に終了することができる（信頼できるデータ配信が早く（UDPではなく要求された場合）、その場合、接続は接続が閉じられることを通知される。あるいは、接続データをピアに配信することなく接続を中止することができる。確実か部分的に信頼できるデータ配信が以前（UDPではない）要求された場合、接続が中止されることをピアに通知します。データを長時間配信できない場合は、タイムアウトを中止するようにタイムアウトを設定できます（UDPではありません）。ただし、タイムアウトベースの中絶は、接続が中止されたことをピアアプリケーションに通知しません。半閉接続はサポートされていないため、トランスポートシステムを実装するホストがピアが接続または接続を終了している通知（UDPではなく）を受信すると、そのピアは未処理のデータを読み取ることができない可能性があります。これは、トランスポートシステムの送信バッファに存在する未確認データが、ピアから「閉じる」または「中止」通知の到着時にそのバッファからドロップされなければならないことを意味します。
A transport system must offer means to group connections, but it cannot guarantee truly grouping them using the transport protocols that it uses (e.g., it cannot be guaranteed that connections become multiplexed as streams on a single SCTP association when SCTP may not be available). The transport system must therefore ensure that group- versus non-group-configurations are handled correctly in some way (e.g., by applying the configuration to all grouped connections even when they are not multiplexed, or informing the application about grouping success or failure).
トランスポートシステムは接続をグループ化するための手段を提供しなければなりませんが、それが使用するトランスポートプロトコルを使用してそれらをグループ化することはできません（例えば、SCTPが利用できない場合は単一のSCTPアソシエーション上で接続が単一のSCTPアソシエーション上で多重化されることが保証できません）。したがって、トランスポートシステムは、グループ対非グループ構成が何らかの方法で正しく処理されることを保証する必要があります（例えば、それらが多重化されていなくてもすべてのグループ化された接続に構成すること、またはアプリケーションに成功または失敗をグループ化することについて）。
As a general rule, any configuration described below should be carried out as early as possible to aid the transport system's decision making.
一般的な規則として、輸送システムの意思決定を支援するために、以下に説明する構成はできるだけ早く実行されるべきである。
The following transport features and notifications (some directly from Section 4; some new or changed, based on the discussion in Section 5) automatically apply to all grouped connections:
次のトランスポート機能と通知（セクション4から直接アクセスしています。セクション5の説明に基づいて、新しくまたは変更されたもの）は、すべてのグループ化された接続に自動的に適用されます。
Configure a timeout (not UDP) This can be done with the following parameters:
タイムアウトを設定する（UDPではなく）これは、次のパラメータで実行できます。
* A timeout value for aborting connections, in seconds.
* 接続を中止するためのタイムアウト値（秒）。
* A timeout value to be suggested to the peer (if possible), in seconds.
* ピア（可能であれば）に提案されるタイムアウト値（秒単位）。
* The number of retransmissions after which the application should be notified of "Excessive Retransmissions".
* アプリケーションに「過剰な再送信」を通知する必要がある後の再送信の数。
Configure urgency This can be done with the following parameters:
緊急性を設定するこれは、次のパラメータで実行できます。
* A number to identify the type of scheduler that should be used to operate between connections in the group (no guarantees given). Schedulers are defined in [RFC8260].
* グループ内の接続間で動作するために使用されるスケジューラの種類を識別するための数値（与えられた保証なし）。スケジューラは[RFC8260]で定義されています。
* A "capacity profile" number to identify how an application wants to use its available capacity. Choices can be "lowest possible latency at the expense of overhead" (which would disable any Nagle-like algorithm), "scavenger", or values that help determine the DSCP value for a connection.
* アプリケーションが利用可能な容量を使用したいのかを識別するための「容量プロファイル」番号。選択は、「オーバーヘッドを犠牲にして可能な限り低い待ち時間」（つまり、Nagle様アルゴリズムを無効にする）、「Scavenger」、または接続のDSCP値を決定するのに役立つ値。
* A buffer limit (in bytes); when the sender has less than the provided limit of bytes in the buffer, the application may be notified. Notifications are not guaranteed, and it is optional for a transport system to support buffer limit values greater than 0. Note that this limit and its notification should operate across the buffers of the whole transport system, i.e., also any potential buffers that the transport system itself may use on top of the transport's send buffer.
* バッファ制限（バイト単位）。送信者がバッファ内の提供されたバイト数未満の場合、アプリケーションに通知されてもよい。通知は保証されておらず、トランスポートシステムが0より大きいバッファリミット値をサポートするのはオプションです。この制限とその通知は、トランスポートシステム全体のバッファ全体、すなわちトランスポートシステムの潜在的なバッファーのバッファに動作する必要があります。それ自体がトランスポートの送信バッファの上に使用することができます。
Following Section 5.7, these properties can be queried:
5.7節後、これらのプロパティは照会できます。
* The maximum message size that may be sent without fragmentation via the configured interface. This is optional for a transport system to offer and may return an error ("not available"). It can aid applications implementing Path MTU Discovery.
* 構成されたインターフェイスを介してフラグメンテーションなしで送信できる最大メッセージサイズ。これは、提供するトランスポートシステムがオプションであり、エラーを返すことがあります（「使用不可」）。パスMTUディスカバリを実装するアプリケーションを支援できます。
* The maximum transport message size that can be sent, in bytes. Irrespective of fragmentation, there is a size limit for the messages that can be handed over to SCTP or UDP(-Lite); because the service provided by a transport system is independent of the transport protocol, it must allow an application to query this value: the maximum size of a message in an Application-Framed Byte Stream (see Section 5.1). This may also return an error when data is not delimited ("not available").
* 送信できる最大トランスポートメッセージサイズ（バイト単位）。断片化に関係なく、SCTPまたはUDP（-Lite）に引き渡すことができるメッセージのサイズ制限があります。トランスポートシステムによって提供されるサービスはトランスポートプロトコルとは無関係であるため、アプリケーションがこの値をクエリすることを許可する必要があります。アプリケーションフレームバイトストリーム内のメッセージの最大サイズ（セクション5.1を参照）。データが区切られていないときにエラーも戻ることがあります（「使用不可」）。
* The maximum transport message size that can be received from the configured interface, in bytes (or "not available").
* 構成されたインターフェイスから受信できる最大トランスポートメッセージサイズ（または「使用不可」）。
* The maximum amount of data that can possibly be sent before or during connection establishment, in bytes.
* 接続確立の前または間に送信される可能性がある最大データの最大量（バイト単位）。
In addition to the already mentioned closing/aborting notifications and possible send errors, the following notifications can occur:
既に述べた閉鎖/中止通知および可能性のある送信エラーに加えて、以下の通知が発生する可能性があります。
Excessive Retransmissions: The configured (or a default) number of retransmissions has been reached, yielding this early warning below an abortion threshold.
過度の再送信：設定された（またはデフォルトの）再送信の数に達し、この早期警告が中絶しきい値を下回ります。
ICMP Arrival (parameter: ICMP message): An ICMP packet carrying the conveyed ICMP message has arrived.
ICMP到着（パラメータ：ICMPメッセージ）：伝達されたICMPメッセージを運ぶICMPパケットが到着しました。
ECN Arrival (parameter: ECN value): A packet carrying the conveyed Explicit Congestion Notification (ECN) value has arrived. This can be useful for applications implementing congestion control.
ECN到着（パラメータ：ECN値）：伝達された明示的輻輳通知（ECN）値を搬送するパケットが到着しました。これは、輻輳制御を実装するアプリケーションに役立ちます。
Timeout (parameter: s seconds): Data could not be delivered for s seconds.
timeout（パラメータ：S秒）：データをS秒間配信できませんでした。
Drain: The send buffer has either drained below the configured buffer limit or it has become completely empty. This is a generic notification that tries to enable uniform access to "TCP_NOTSENT_LOWAT" as well as the "SENDER DRY" notification (as discussed in Section 5.4; SCTP's "SENDER DRY" is a special case where the threshold (for unsent data) is 0 and there is also no more unacknowledged data in the send buffer).
ドレイン：送信バッファは設定されたバッファリミットの下に排出されたか、完全に空になっています。これは、「TCP_NOTSENT_LOWAT」および「送信者ドライ」通知（セクション5.4で説明されているように、SCTPの "Sender Dry"の場合は、（SCTPの "Sender Dry"という名前の汎用通知です。また、送信バッファ内の未確認データもありません）。
Configure priority or weight for a scheduler, as described in [RFC8260].
[RFC8260]の説明に従って、スケジューラの優先順位または重みを設定します。
Configure checksum usage: This can be done with the following parameters, but there is no guarantee that any checksum limitations will indeed be enforced (the default behavior is "full coverage, checksum enabled"):
CheckSumの使用法を設定する：これは次のパラメータで実行できますが、チェックサムの制限が実際に適用されることが保証されていません（デフォルトの動作は「全カバレッジ、チェックサム有効」です）。
* a boolean to enable/disable usage of a checksum when sending
* 送信時にチェックサムの使用を有効/無効にするためのブール値
* the desired coverage (in bytes) of the checksum used when sending
* 送信時に使用されたチェックサムの希望のカバレッジ（バイト単位）
* a boolean to enable/disable requiring a checksum when receiving
* 受信時にチェックサムを必要とする有効/無効にするブール値
* the required minimum coverage (in bytes) of the checksum when receiving
* 受信時のチェックサムの必要最小限の補償（バイト）
When sending a message, no guarantees are given about the preservation of message boundaries to the peer; if message boundaries are needed, the receiving application at the peer must know about them beforehand (or the transport system cannot use TCP). Note that an application should already be able to hand over data before the transport system establishes a connection with a chosen transport protocol. Regarding the message that is being handed over, the following parameters can be used:
メッセージを送信するときは、ピアへのメッセージ境界の保存に関する保証は与えられません。メッセージ境界が必要な場合、ピアの受信側アプリケーションは事前にそれらについて知っている必要があります（またはトランスポートシステムはTCPを使用できません）。トランスポートシステムが選択されたトランスポートプロトコルとの接続を確立する前に、アプリケーションはすでにデータを手渡すことができるはずです。渡されているメッセージについては、以下のパラメータを使用できます。
Reliability: This parameter is used to convey a choice of: fully reliable with congestion control (not UDP), unreliable without congestion control, unreliable with congestion control (not UDP), and partially reliable with congestion control (see [RFC3758] and [RFC7496] for details on how to specify partial reliability) (not UDP). The latter two choices are optional for a transport system to offer and may result in full reliability. Note that applications sending unreliable data without congestion control should themselves perform congestion control in accordance with [RFC8085].
信頼性：このパラメータは、輻輳制御（UDPではなくUDPではなく）、輻輳制御のない、輻輳制御（UDPではなく）、輻輳制御との信頼性が低く、輻輳制御との間で完全に信頼性の低い、輻輳制御（UDP）、および輻輳制御との間に完全に信頼性があります（[RFC3758]と[RFC7496]を参照）。]部分的な信頼性を指定する方法については、（UDPではなく）。後者の2つの選択は、輸送システムが提供するためのオプションであり、完全な信頼性をもたらす可能性があります。輻輳制御なしで信頼性の低いデータを送信するアプリケーションは、[RFC8085]に従って輻輳制御を実行する必要があります。
Ordered (not UDP): This boolean lets an application choose between ordered message delivery (true) and possibly unordered, potentially faster message delivery (false).
順序付けられた（UDPではありません）：このブール値では、注文メッセージ配信（TRUE）と順序付けられていない潜在的に潜在的に潜在的に潜在的に潜在的に速く、潜在的に速く、潜在的に速いメッセージ配信（FALSE）を選択できます。
Bundle: This boolean expresses a preference for allowing to bundle messages (true) or not (false). No guarantees are given.
バンドル：このブール値は、メッセージをバンドルすることを可能にする（true）またはnot（false）を表現します。保証は与えられません。
DelAck: This boolean, if false, lets an application request that the peer not delay the acknowledgement for this message.
delack：このブール値は偽の場合、ピアがこのメッセージの確認応答を遅らせないことをアプリケーション要求します。
Fragment: This boolean expresses a preference for allowing to fragment messages (true) or not (false), at the IP level. No guarantees are given.
fragment：このブール値は、IPレベルでメッセージ（true）またはnot（false）をフラグメント化することを可能にするための好みを表します。保証は与えられません。
Idempotent (not UDP): This boolean expresses whether a message is idempotent (true) or not (false). Idempotent messages may arrive multiple times at the receiver (but they will arrive at least once). When data is idempotent, it can be used by the receiver immediately on a connection establishment attempt. Thus, if data is handed over before the transport system establishes a connection with a chosen transport protocol, stating that a message is idempotent facilitates transmitting it to the peer application particularly early.
iDempotent（UDPではなく）：このブール値は、メッセージがIDEmpotent（true）かどうかを表現します（false）。IDEmpotentメッセージは、受信者で複数回到着する可能性があります（ただし、それらは少なくとも1回到着します）。データがIDEmpotentの場合、接続確立の試みで直ちに受信機によって使用できます。したがって、トランスポートシステムが選択されたトランスポートプロトコルとの接続を確立する前にデータが手渡される場合、メッセージがIDEmpotentであることを述べると、特に早い段階でピアアプリケーションに送信することが容易になる。
An application can be notified of a failure to send a specific message. There is no guarantee of such notifications, i.e., send failures can also silently occur.
アプリケーションに特定のメッセージを送信しなかった場合に通知することができます。そのような通知の保証はありません、すなわち送信失敗も黙って発生する可能性がある。
A receiving application obtains an "Application-Framed Byte Stream" (AFra Byte Stream); this concept is further described in Section 5.1. In line with TCP's receiver semantics, an AFra Byte Stream is just a stream of bytes to the receiver. If message boundaries were specified by the sender, a receiver-side transport system implementing only the minimum set of Transport Services defined here will still not inform the receiving application about them (this limitation is only needed for transport systems that are implemented to directly use TCP).
受信側アプリケーションは、「アプリケーションフレームバイトストリーム」（AFRAバイトストリーム）を取得します。この概念はセクション5.1でさらに説明されています。TCPの受信機セマンティクスに沿って、AFRAバイトストリームは受信側へのバイトのストリームです。メッセージの境界が送信者によって指定された場合、ここで定義されている最小のトランスポートサービスのセットのみを実装する受信側転送システムは、それらについての受信アプリケーションに通知されません（この制限は直接TCPを使用するために実装されているトランスポートシステムにのみ必要です。）。
Different from TCP's semantics, if the sending application has allowed that messages are not fully reliably transferred, or delivered out of order, then such reordering or unreliability may be reflected per message in the arriving data. Messages will always stay intact, i.e., if an incomplete message is contained at the end of the arriving data block, this message is guaranteed to continue in the next arriving data block.
送信側アプリケーションが、メッセージが完全に確実に転送されていない、または順序から配信されていない場合、そのような並べ替えまたは信頼性が到着データのメッセージごとに反映されてもよい。メッセージは常に無傷のままであり、すなわち不完全なメッセージが到着データブロックの最後に含まれている場合、このメッセージは次の到着データブロックに続行することが保証される。
This document has no IANA actions.
この文書にはIANAの行動がありません。
Authentication, confidentiality protection, and integrity protection are identified as transport features by [RFC8095]. Often, these features are provided by a protocol or layer on top of the transport protocol; none of the full-featured standards-track transport protocols in [RFC8303], which this document is based upon, provide all of these transport features on its own. Therefore, they 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. The minimum requirements for a secure transport system are discussed in a separate document [RFC8922].
認証、機密保持保護、および完全性保護は、[RFC8095]によるトランスポート機能として識別されます。多くの場合、これらの機能はトランスポートプロトコルの上にプロトコルまたはレイヤーによって提供されます。このドキュメントに基づいている[RFC8303]のフル機能標準トラックトランスポートプロトコルのどれも、これらのトランスポート機能をすべて独自に提供していません。したがって、[RFC5925]と[RFC4895]のセキュリティ上の考慮事項が適用されるTCPとSCTPのネイティブ認証機能を除き、この文書では考慮されません。安全なトランスポートシステムの最小要件は別の文書[RFC8922]で説明されています。
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017, <https://www.rfc-editor.org/info/rfc8095>.
[RFC8095] Fairhurst、G.、Ed。、Trammell、B.、Ed。、およびM.Kuehlewind、ED。、「IETFトランスポートプロトコルと輻輳制御メカニズムによるサービス」、RFC 8095、DOI 10.17487 / RFC8095、2017年3月<https：//www.rfc-editor.org/info/rfc8095>。
[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of Transport Features Provided by IETF Transport Protocols", RFC 8303, DOI 10.17487/RFC8303, February 2018, <https://www.rfc-editor.org/info/rfc8303>.
[RFC8303] Welzl、M.、Tuexen、M.、N.Khademi、「IETF輸送プロトコルによる輸送機能の使用」、RFC 8303、DOI 10.17487 / RFC8303、2018年2月、<https：// www。rfc-editor.org/info/rfc8303>。
[RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey of the Interaction between Security Protocols and Transport Services", RFC 8922, DOI 10.17487/RFC8922, October 2020, <https://www.rfc-editor.org/info/rfc8922>.
[RFC8922] enghardt、T.、Pauly、T.、Perkins、C、Rose、K.、およびC.木材、「セキュリティプロトコルとトランスポートサービス間の相互作用の調査」、RFC 8922、DOI 10.17487 / RFC8922、2020年10月、<https://www.rfc-editor.org/info/rfc8922>。
[COBS] Cheshire, S. and M. Baker, "Consistent overhead byte stuffing", IEEE/ACM Transactions on Networking, Volume 7, Issue 2, DOI 10.1109/90.769765, April 1999, <https://doi.org/10.1109/90.769765>.
[COB]チェシャー、S.およびM. Baker、「一貫したオーバーヘッドバイト詰め」、ネットワーキング、第7号、発行2、DOI 10.1109 / 90.769765、1999年4月、<https：//doi.org/10.1109/ 90.769765>。
[POSIX] The Open Group, "IEEE Standard for Information Technology--Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7", (Revision of IEEE Std 1003.1-2008), IEEE Std 1003.1-2017, January 2018, <https://www.opengroup.org/onlinepubs/9699919799/ functions/contents.html>.
[POSIX]オープングループ「IEEE規格情報技術 - POSIX（R）」基本仕様、発行7 "、（IEEE STD 1003.1-2008の改訂）、IEEE STD 1003.1-2017、2018年1月、<https：//www.opengroup.org/onlinepubs/9699919799/関数/ contents.html>。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, <https://www.rfc-editor.org/info/rfc3758>.
[RFC3758] Stewart、R.、Ramalho、M.、XIE、Q.、Tuexen、M.、およびP. Conrad、「ストリーム制御伝送プロトコル（SCTP）部分信頼性延長」、RFC 3758、DOI 10.17487 / RFC3758、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.、およびE.RescoRA、「ストリーム制御伝送プロトコル（SCTP）」、RFC 4895、DOI 10.17487 / RFC4895、2007年8月、<HTTPS//www.rfc-editor.org/info/rfc4895>。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, <https://www.rfc-editor.org/info/rfc4987>.
[RFC4987] EDDY、W。、「TCP SYNフラッディング攻撃および一般的な軽減」、RFC 4987、DOI 10.17487 / RFC4987、2007年8月、<https：//www.rfc-editor.org/info/rfc4987>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A.、R.ボニカ、「TCP認証オプション」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<https://www.rfc-editor.org/info/ RFC5925>。
[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.およびA. Ford、 "Multipath TCP（MPTCP）アプリケーションインタフェースに関する考慮事項"、RFC 6897、DOI 10.17487 / RFC6897、2013年3月、<https://www.rfc-editor.org/info/rfc6897>。
[RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)", RFC 7305, DOI 10.17487/RFC7305, July 2014, <https://www.rfc-editor.org/info/rfc7305>.
[RFC7305]「IABワークショップからのIABワークショップからのIABワークショップからの報告」、RFC 7305、DOI 10.17487 / RFC7305、2014年7月、<https：//www.rfc-編集者。ORG / INFO / RFC7305>。
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[RFC7413] Cheng、Y.、Chu、J.、Radhakrishnan、S.、A. Jain、 "TCP Fast Open"、RFC 7413、DOI 10.17487 / RFC7413、2014年12月、<https：///www.rfc-編集者.ORG / INFO / RFC7413>。
[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.、およびS. Loreto、「部分信頼性のあるストリーム制御伝送プロトコル拡張の追加ポリシー」、RFC 7496、DOI 10.17487 / RFC7496、2015年4月、<HTTPS：//www.rfc-editor.org/info/rfc7496>。
[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.、および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.、およびR.SegGelmann、「ストリーム制御伝送プロトコルのためのストリームスケジューラおよびユーザメッセージインターリーブ」、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.およびT. Jones、「ユーザーデータグラムプロトコル（UDP）と軽量UDP（UDP-Lite）」、RFC 8304、DOI 10.17487 / RFC8304、2018年2月、<HTTPS：// WWW.rfc-editor.org / info / rfc8304>。
[RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, June 2019, <https://www.rfc-editor.org/info/rfc8622>.
[RFC8622] Bless、R.、「差別化サービス用の低稼働単価の行動（LE PHB）」、RFC 8622、DOI 10.17487 / RFC8622、2019年6月、<https：//www.rfc-editor.org/情報/ RFC8622>。
[SCTP-STREAM-1] Weinrank, F. and M. Tuexen, "Transparent Flow Mapping for NEAT", IFIP Networking 2017, Workshop on Future of Internet Transport (FIT 2017), June 2017.
[SCTP-STRIP-1] Weinrank、F.およびM.ティューセン、「ニートのための透明なフローマッピング」、IFIPネットワーキング2017、インターネット輸送の将来のワークショップ（FIT 2017）、2017年6月。
[SCTP-STREAM-2] Welzl, M., Niederbacher, F., and S. Gjessing, "Beneficial Transparent Deployment of SCTP: The Missing Pieces", IEEE GlobeCom 2011, DOI 10.1109/GLOCOM.2011.6133554, December 2011, <https://doi.org/10.1109/GLOCOM.2011.6133554>.
[SCTP-STRIP-2] Welzl、M.、Niederbacher、F.、およびS. Gjesing、「SCTPの有益な透明展開：不足しているピース」、IEEE GlobeCom 2011、DOI 10.1109 / GLOCOM.2011.6133554、2011年12月、<https：//doi.org/10.1109/glocom.2011.61335554>。
[TAPS-INTERFACE] Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Kuehlewind, M., Perkins, C., Tiesel, P. S., Wood, C. A., and T. Pauly, "An Abstract Application Layer Interface to Transport Services", Work in Progress, Internet-Draft, draft-ietf-taps-interface-09, 27 July 2020, <https://tools.ietf.org/html/draft-ietf-taps-interface-09>.
[TAPS-Interface] Trammell、B.、Welzl、M.、Enghardt、T.、FairHurst、G.、Kuehlewind、M.、Perkins、C、Tiesel、PS、Wood、CA、およびT. Pauly、 "抽象化サービスへの抽象的なアプリケーション層インタフェース2020年7月27日、<https://tools.ietf.org/html/draft-ietf.org/html/draft-ietf-taps-taps-Interface-09>。
[WWDC2015] Lakhera, P. and S. Cheshire, "Your App and Next Generation Networks", Apple Worldwide Developers Conference 2015, San Francisco, USA, June 2015, <https://developer.apple.com/videos/wwdc/2015/?id=719>.
[WWDC2015] Lakhera、P.およびS. Cheshire、「あなたのアプリと次世代ネットワーク」、Apple Worldwide開発者会議2015、サンフランシスコ、アメリカ、2015年6月、<https：//developer.apple.com/videos/wwdc/2015 /？ID = 719>。
In this description, transport features are presented following the nomenclature "CATEGORY.[SUBCATEGORY].FEATURENAME.PROTOCOL", equivalent to "pass 2" in [RFC8303]. We also sketch how functional or optimizing transport features can be implemented by a transport system. The "minimal set" derived in this document is meant to be implementable "one-sided" over TCP and, with limitations, UDP. Hence, for all transport features that are categorized as "functional" or "optimizing", and for which no matching TCP and/or UDP primitive exists in "pass 2" of [RFC8303], a brief discussion on how to implement them over TCP and/or UDP is included.
この説明では、命名法の「カテゴリ」の後に輸送機能が提示されています。[SubCategory] .Featurename.Protocol "、[RFC8303]の「パス2」に相当します。トランスポートシステムによって機能的または最適化することができるかまたは最適化する方法についてもスケッチします。この文書で導き出された「最小セット」は、TCPを介して「片面」、および制限事項、UDPを介して実装可能な「一方的」であることを意味しています。したがって、「機能的」または「最適化」として分類され、[RFC8303]の「パス2」に一致するTCPおよび/またはUDPプリミティブが存在しないすべてのトランスポート機能については、TCPを介してそれらを実装する方法に関する簡単な説明および/またはUDPが含まれています。
We designate some transport features as "automatable" on the basis of a broader decision that affects multiple transport features:
複数のトランスポート機能に影響を与えるより広い決定に基づいて、「自動化可能」として一部のトランスポート機能を指定します。
* Most transport features that are related to multi-streaming were designated as "automatable". This was done because the decision on whether or not to use multi-streaming does not depend on application-specific knowledge. This means that a connection that is exhibited to an application could be implemented by using a single stream of an SCTP association instead of mapping it to a complete SCTP association or TCP connection. This could be achieved by using more than one stream when an SCTP association is first established (CONNECT.SCTP parameter "outbound stream count"), maintaining an internal stream number, and using this stream number when sending data (SEND.SCTP parameter "stream number"). Closing or aborting a connection could then simply free the stream number for future use. This is discussed further in Section 5.2.
* マルチストリーミングに関連するほとんどのトランスポート機能は「自動化可能」と呼ばれていました。これは、マルチストリーミングを使用するかどうかの決定がアプリケーション固有の知識に依存しないためです。これは、アプリケーションに展示されている接続を、完全なSCTPアソシエーションまたはTCP接続にマッピングする代わりに、SCTP関連の単一のストリームを使用することによって実装できます。これは、SCTPアソシエーションが最初に確立されたとき（Connect.SCTPパラメータ "アウトバウンドストリームカウント"）、データを送信するとき（send.sctpパラメータ "ストリームを送信するときにこのストリーム番号を使用するときに、複数のストリームを使用することによって達成できます。数"）。接続を閉じるかまたは中止すると、将来の使用のためにストリーム番号を単に解放することができます。これについてはセクション5.2でさらに説明します。
* With the exception of "Disable MPTCP", all transport features that are related to using multiple paths or the choice of the network interface were designated as "automatable". For example, "Listen" could always listen on all available interfaces and "Connect" could use the default interface for the destination IP address.
* 「MPTCPを無効にする」を除いて、複数のパスを使用することに関連するすべてのトランスポート機能またはネットワークインターフェースの選択は「自動化可能」と呼ばれています。たとえば、「listen」は常に利用可能なすべてのインタフェースで聴取され、「connect」は宛先IPアドレスのデフォルトインターフェイスを使用できます。
Finally, in three cases, transport features are aggregated and/or slightly changed from [RFC8303] in the description below. These transport features are marked as "CHANGED FROM RFC 8303". These do not add any new functionality but just represent a simple refactoring step that helps to streamline the derivation process (e.g., by removing a choice of a parameter for the sake of applications that may not care about this choice). The corresponding transport features are automatable, and they are listed immediately below the "CHANGED FROM RFC 8303" transport feature.
最後に、3つのケースでは、以下の説明では[RFC8303]から輸送機能が集約されていてわずかに変化します。これらの輸送機能は「RFC 8303から変更された」とマークされています。これらは新しい機能を追加しませんが、派生プロセスを合理化するのに役立つ簡単なリファクタリングステップ（例えば、この選択を気にすることができないアプリケーションのためにパラメータの選択を削除することによって）。対応するトランスポート機能は自動化可能で、「RFC 8303」トランスポート機能から「変更された」の直下に記載されています。
ESTABLISHMENT:
確立：
* Connect
* 結ぶ
Protocols: TCP, SCTP, UDP(-Lite)
プロトコル：TCP、SCTP、UDP（-Lite）
Functional because the notion of a connection is often reflected in applications as an expectation to be able to communicate after a "Connect" succeeded, with a communication sequence relating to this transport feature that is defined by the application protocol.
接続の概念は、「接続」に成功した後に通信できることを期待としてアプリケーションに反映され、アプリケーションプロトコルによって定義されているこのトランスポート機能に関連する通信シーケンスがあることがよくあります。
Implementation: via CONNECT.TCP, CONNECT.SCTP or CONNECT.UDP(- Lite).
実装：Connect.TCP、Connect.SCTPまたはConnect.UDP（ - Lite）を介して。
* Specify which IP Options must always be used
* どのIPオプションを常に使用する必要があります
Protocols: TCP, UDP(-Lite)
プロトコル：TCP、UDP（-Lite）
Automatable because IP Options relate to knowledge about the network, not the application.
自動化可能なIPオプションは、アプリケーションではなくネットワークに関する知識に関連しています。
* Request multiple streams
* 複数のストリームを要求します
Protocols: SCTP
プロトコル：SCTP.
Automatable because using multi-streaming does not require application-specific knowledge (example implementations of using multi-streaming without involving the application are described in [SCTP-STREAM-1] and [SCTP-STREAM-2]).
マルチストリーミングを使用することは、アプリケーション固有の知識を必要としないため（アプリケーションを含まずにマルチストリーミングを使用する実装例は、[SCTP-STRIP-1]および[SCTP-STREAM-2]に記述されています）。
Implementation: see Section 5.2.
実装：セクション5.2を参照してください。
* Limit the number of inbound streams
* インバウンドストリームの数を制限します
Protocols: SCTP
プロトコル：SCTP.
Automatable because using multi-streaming does not require application-specific knowledge.
マルチストリーミングを使用すると、アプリケーション固有の知識が必要ないため自動化可能です。
Implementation: see Section 5.2.
実装：セクション5.2を参照してください。
* Specify number of attempts and/or timeout for the first establishment message
* 最初の確立メッセージの試行回数やタイムアウト数を指定する
Protocols: TCP, SCTP
プロトコル：TCP、SCTP
Functional because this is closely related to potentially assumed reliable data delivery for data that is sent before or during connection establishment.
これは、接続確立の前または連結期間中に送信されるデータのための潜在的に想定される信頼できるデータ配信に密接に関連しているので機能。
Implementation: using a parameter of CONNECT.TCP and CONNECT.SCTP.
実装：connect.tcpとconnect.sctpのパラメータを使用します。
Implementation over UDP: do nothing (this is irrelevant in the case of UDP because there, reliable data delivery is not assumed).
UDP上の実装：何もしない（これはUDPの場合、信頼できるデータ配信は想定されていません）。
* Obtain multiple sockets
* 複数のソケットを入手してください
Protocols: SCTP
プロトコル：SCTP.
Automatable because the non-parallel usage of multiple paths to communicate between the same end hosts relates to knowledge about the network, not the application.
自動的に同じエンドホスト間で通信する複数のパスの非並列使用は、アプリケーションではなくネットワークに関する知識に関連しています。
* Disable MPTCP
* MPTCPを無効にします
Protocols: MPTCP
プロトコル：MPTCP
Optimizing because the parallel usage of multiple paths to communicate between the same end hosts can improve performance. Whether or not to use this feature depends on knowledge about the network as well as application-specific knowledge (see Section 3.1 of [RFC6897]).
同じエンドホスト間で通信する複数のパスの並列使用量がパフォーマンスを向上させる可能性があるため、最適化。この機能を使用するかどうかは、ネットワークに関する知識とアプリケーション固有の知識に依存します（[RFC6897]のセクション3.1を参照）。
Implementation: via a boolean parameter in CONNECT.MPTCP.
実装：connect.mptcpのbooleanパラメータを介して。
Implementation over TCP: do nothing.
TCPを介した実装：何もしません。
Implementation over UDP: do nothing.
UDP上の実装：何もしません。
* Configure authentication
* 認証を設定します
Protocols: TCP, SCTP
プロトコル：TCP、SCTP
Functional because this has a direct influence on security.
これはセキュリティに直接的な影響を与えるので機能的です。
Implementation: via parameters in CONNECT.TCP and CONNECT.SCTP. With TCP, this allows configuring Master Key Tuples (MKTs) to authenticate complete segments (including the TCP IPv4 pseudoheader, TCP header, and TCP data). With SCTP, this allows specifying which chunk types must always be authenticated. Authenticating only certain chunk types creates a reduced level of security that is not supported by TCP; to be compatible, this should therefore only allow to authenticate all chunk types. Key material must be provided in a way that is compatible with both [RFC4895] and [RFC5925].
実装：connect.tcpとconnect.sctpのパラメータを介して。TCPでは、マスターキータプル（MKTS）を設定して完全なセグメントを認証することができます（TCP IPv4疑似ヘッダー、TCPヘッダー、およびTCPデータを含む）。SCTPを使用すると、これにより、どのチャンクタイプを常に認証する必要があるかを指定できます。特定のチャンクタイプのみを認証すると、TCPではサポートされていないセキュリティの削減されました。互換性があるために、これはすべてのチャンクタイプを認証することしか許可されません。キーマテリアルは、[RFC4895]と[RFC5925]の両方と互換性のある方法で提供する必要があります。
Implementation over UDP: not possible (UDP does not offer this functionality).
UDP上の実装：不可能（UDPはこの機能を提供しません）。
* Indicate (and/or obtain upon completion) an Adaptation Layer via an adaptation code point
* 適応コードポイントを介して適応レイヤを表示（および/または取得する）
Protocols: SCTP
プロトコル：SCTP.
Functional because it allows sending extra data for the sake of identifying an adaptation layer, which by itself is application specific.
それ自体がアプリケーション固有である適応層を識別するために追加のデータを送信することを可能にするので機能的。
Implementation: via a parameter in CONNECT.SCTP.
実装：connect.sctpのパラメータを介して。
Implementation over TCP: not possible. (TCP does not offer this functionality.)
TCPを介した実装：不可能です。（TCPはこの機能を提供しません。）
Implementation over UDP: not possible. (UDP does not offer this functionality.)
UDP上の実装：不可能です。（UDPはこの機能を提供しません。）
* Request to negotiate interleaving of user messages
* ユーザーメッセージのインターリーブを交渉するように要求します
Protocols: SCTP
プロトコル：SCTP.
Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable.
自動的に複数のストリームを使用する必要があるが、Connection.Stablishmentカテゴリに複数のストリームを要求するため、自動化可能です。
Implementation: controlled via a parameter in CONNECT.SCTP. One possible implementation is to always try to enable interleaving.
実装：connect.sctpのパラメータを介して制御されます。1つの可能な実装は常にインターリーブを可能にすることを試みることです。
* Hand over a message to reliably transfer (possibly multiple times) before connection establishment
* 接続確立の前に確実に転送するメッセージを手渡す（おそらく複数回）
Protocols: TCP
プロトコル：TCP.
Functional because this is closely tied to properties of the data that an application sends or expects to receive.
これは、アプリケーションが送信または受信を期待しているデータのプロパティに密接に関連しているためです。
Implementation: via a parameter in CONNECT.TCP.
実装：connect.tcpのパラメータを介して。
Implementation over UDP: not possible. (UDP does not provide reliability.)
UDP上の実装：不可能です。（UDPは信頼性を提供しません。）
* Hand over a message to reliably transfer during connection establishment
* 接続確立中に確実に転送するメッセージを手渡す
Protocols: SCTP
プロトコル：SCTP.
Functional because this can only work if the message is limited in size, making it closely tied to properties of the data that an application sends or expects to receive.
これはメッセージがサイズに制限されている場合にのみ機能できるので機能し、アプリケーションが送信または受信することを期待するデータのプロパティに密接に関連しているためです。
Implementation: via a parameter in CONNECT.SCTP.
実装：connect.sctpのパラメータを介して。
Implementation over TCP: transmit the message with the SYN packet, sacrificing the ability to identify message boundaries.
TCPを介した実装：メッセージをSYNパケットで送信し、メッセージの境界を識別する機能を犠牲にします。
Implementation over UDP: not possible. (UDP is unreliable.)
UDP上の実装：不可能です。（UDPは信頼できません。）
* Enable UDP encapsulation with a specified remote UDP port number
* 指定されたリモートUDPポート番号でUDPカプセル化を有効にする
Protocols: SCTP
プロトコル：SCTP.
Automatable because UDP encapsulation relates to knowledge about the network, not the application.
UDPカプセル化はアプリケーションではなくネットワークに関する知識に関連しているため自動化可能です。
AVAILABILITY:
可用性：
* Listen
* 聴く
Protocols: TCP, SCTP, UDP(-Lite)
プロトコル：TCP、SCTP、UDP（-Lite）
Functional because the notion of accepting connection requests is often reflected in applications as an expectation to be able to communicate after a "Listen" succeeded, with a communication sequence relating to this transport feature that is defined by the application protocol.
接続要求を受け入れるという概念は、アプリケーションプロトコルによって定義されているこのトランスポート機能に関連する通信シーケンスを持つ通信シーケンスを使用して、接続要求を受け入れることを期待としてアプリケーションに反映されることがよくあります。
CHANGED FROM RFC 8303. This differs from the 3 automatable transport features below in that it leaves the choice of interfaces for listening open.
RFC 8303から変更されました。これは、聴取用のインタフェースの選択を残すという点で、以下の3つの自動トランスポート機能とは異なります。
Implementation: by listening on all interfaces via LISTEN.TCP (not providing a local IP address) or LISTEN.SCTP (providing SCTP port number / address pairs for all local IP addresses). LISTEN.UDP(- Lite) supports both methods.
実装：listen.tcp（ローカルIPアドレスを提供していない）またはlisten.sctp（すべてのローカルIPアドレスのためのSCTPポート番号/アドレスペアを提供する）を介してすべてのインタフェースをリッスンすること。listen.udp（ - Lite）は両方の方法をサポートしています。
* Listen, 1 specified local interface
* listen、1指定されたローカルインタフェース
Protocols: TCP, SCTP, UDP(-Lite)
プロトコル：TCP、SCTP、UDP（-Lite）
Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application.
ローカルインタフェースに関する決定は、アプリケーションではなくネットワークとオペレーティングシステムに関する知識に関連しているため、自動化できます。
* Listen, N specified local interfaces
* listen、n指定されたローカルインターフェイス
Protocols: SCTP
プロトコル：SCTP.
Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application.
ローカルインタフェースに関する決定は、アプリケーションではなくネットワークとオペレーティングシステムに関する知識に関連しているため、自動化できます。
* Listen, all local interfaces
* Listen、すべてのローカルインタフェース
Protocols: TCP, SCTP, UDP(-Lite)
プロトコル：TCP、SCTP、UDP（-Lite）
Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application.
ローカルインタフェースに関する決定は、アプリケーションではなくネットワークとオペレーティングシステムに関する知識に関連しているため、自動化できます。
* Specify which IP Options must always be used
* どのIPオプションを常に使用する必要があります
Protocols: TCP, UDP(-Lite)
プロトコル：TCP、UDP（-Lite）
Automatable because IP Options relate to knowledge about the network, not the application.
自動化可能なIPオプションは、アプリケーションではなくネットワークに関する知識に関連しています。
* Disable MPTCP
* MPTCPを無効にします
Protocols: MPTCP
プロトコル：MPTCP
Optimizing because the parallel usage of multiple paths to communicate between the same end hosts can improve performance. Whether or not to use this feature depends on knowledge about the network as well as application-specific knowledge (see Section 3.1 of [RFC6897]).
同じエンドホスト間で通信する複数のパスの並列使用量がパフォーマンスを向上させる可能性があるため、最適化。この機能を使用するかどうかは、ネットワークに関する知識とアプリケーション固有の知識に依存します（[RFC6897]のセクション3.1を参照）。
Implementation: via a boolean parameter in LISTEN.MPTCP.
実装：listen.mptcpのbooleanパラメータを介して。
Implementation over TCP: do nothing.
TCPを介した実装：何もしません。
Implementation over UDP: do nothing.
UDP上の実装：何もしません。
* Configure authentication
* 認証を設定します
Protocols: TCP, SCTP
プロトコル：TCP、SCTP
Functional because this has a direct influence on security.
これはセキュリティに直接的な影響を与えるので機能的です。
Implementation: via parameters in LISTEN.TCP and LISTEN.SCTP.
実装：listen.tcpとlisten.sctpのパラメータを介して。
Implementation over TCP: with TCP, this allows configuring Master Key Tuples (MKTs) to authenticate complete segments (including the TCP IPv4 pseudoheader, TCP header, and TCP data). With SCTP, this allows specifying which chunk types must always be authenticated. Authenticating only certain chunk types creates a reduced level of security that is not supported by TCP; to be compatible, this should therefore only allow to authenticate all chunk types. Key material must be provided in a way that is compatible with both [RFC4895] and [RFC5925].
TCPを介した実装：TCPを使用すると、マスターキータプル（MKTS）を設定して完全なセグメントを認証します（TCP IPv4疑似ヘッダー、TCPヘッダー、およびTCPデータを含む）。SCTPを使用すると、これにより、どのチャンクタイプを常に認証する必要があるかを指定できます。特定のチャンクタイプのみを認証すると、TCPではサポートされていないセキュリティの削減されました。互換性があるために、これはすべてのチャンクタイプを認証することしか許可されません。キーマテリアルは、[RFC4895]と[RFC5925]の両方と互換性のある方法で提供する必要があります。
Implementation over UDP: not possible. (UDP does not offer authentication.)
UDP上の実装：不可能です。（UDPは認証を提供しません。）
* Obtain requested number of streams
* 要求されたストリーム数を取得します
Protocols: SCTP
プロトコル：SCTP.
Automatable because using multi-streaming does not require application-specific knowledge.
マルチストリーミングを使用すると、アプリケーション固有の知識が必要ないため自動化可能です。
Implementation: see Section 5.2.
実装：セクション5.2を参照してください。
* Limit the number of inbound streams
* インバウンドストリームの数を制限します
Protocols: SCTP
プロトコル：SCTP.
Automatable because using multi-streaming does not require application-specific knowledge.
マルチストリーミングを使用すると、アプリケーション固有の知識が必要ないため自動化可能です。
Implementation: see Section 5.2.
実装：セクション5.2を参照してください。
* Indicate (and/or obtain upon completion) an Adaptation Layer via an adaptation code point
* 適応コードポイントを介して適応レイヤを表示（および/または取得する）
Protocols: SCTP
プロトコル：SCTP.
Functional because it allows sending extra data for the sake of identifying an adaptation layer, which by itself is application specific.
それ自体がアプリケーション固有である適応層を識別するために追加のデータを送信することを可能にするので機能的。
Implementation: via a parameter in LISTEN.SCTP.
実装：listen.sctpのパラメータを介して。
Implementation over TCP: not possible. (TCP does not offer this functionality.)
TCPを介した実装：不可能です。（TCPはこの機能を提供しません。）
Implementation over UDP: not possible. (UDP does not offer this functionality.)
UDP上の実装：不可能です。（UDPはこの機能を提供しません。）
* Request to negotiate interleaving of user messages
* ユーザーメッセージのインターリーブを交渉するように要求します
Protocols: SCTP
プロトコル：SCTP.
Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable.
自動的に複数のストリームを使用する必要があるが、Connection.Stablishmentカテゴリに複数のストリームを要求するため、自動化可能です。
Implementation: via a parameter in LISTEN.SCTP.
実装：listen.sctpのパラメータを介して。
MAINTENANCE:
メンテナンス：
* Change timeout for aborting connection (using retransmit limit or time value)
* 接続を中止するためのタイムアウトを変更する（再送信制限または時間値を使用）
Protocols: TCP, SCTP
プロトコル：TCP、SCTP
Functional because this is closely related to potentially assumed reliable data delivery.
これは潜在的に信頼できるデータ配信に密接に関連しているためです。
Implementation: via CHANGE_TIMEOUT.TCP or CHANGE_TIMEOUT.SCTP.
実装：change_timeout.tcpまたはchange_timeout.sctpを介して。
Implementation over UDP: not possible. (UDP is unreliable and there is no connection timeout.)
UDP上の実装：不可能です。（UDPは信頼できず、接続タイムアウトはありません。）
* Suggest timeout to the peer
* ピアへのタイムアウトを提案します
Protocols: TCP
プロトコル：TCP.
Functional because this is closely related to potentially assumed reliable data delivery.
これは潜在的に信頼できるデータ配信に密接に関連しているためです。
Implementation: via CHANGE_TIMEOUT.TCP.
実装：via change_timeout.tcp。
Implementation over UDP: not possible. (UDP is unreliable and there is no connection timeout.)
UDP上の実装：不可能です。（UDPは信頼できず、接続タイムアウトはありません。）
* Disable Nagle algorithm
* Nagleアルゴリズムを無効にします
Protocols: TCP, SCTP
プロトコル：TCP、SCTP
Optimizing because this decision depends on knowledge about the size of future data blocks and the delay between them.
この決定が将来のデータブロックのサイズとそれらの間の遅延に関する知識に依存するため、最適化。
Implementation: via DISABLE_NAGLE.TCP and DISABLE_NAGLE.SCTP.
実装：DISABLE_NAGLE.TCPとDISABLE_NAGLE.SCTP。
Implementation over UDP: do nothing (UDP does not implement the Nagle algorithm).
UDP上の実装：何もしない（UDPはNagleアルゴリズムを実装しません）。
* Request an immediate heartbeat, returning success/failure
* 即時のハートビートを要求し、成功/失敗を返す
Protocols: SCTP
プロトコル：SCTP.
Automatable because this informs about network-specific knowledge.
これはネットワーク固有の知識について知らせるので自動的に可能です。
* Notification of Excessive Retransmissions (early warning below abortion threshold)
* 過度の再送信の通知（中絶しきい値以下の早期警告）
Protocols: TCP
プロトコル：TCP.
Optimizing because it is an early warning to the application, informing it of an impending functional event.
アプリケーションへの早期警告であるため、差し迫った機能イベントを知らせます。
Implementation: via ERROR.TCP.
実装：error.tcpを介して。
Implementation over UDP: do nothing (there is no abortion threshold).
UDP上の実装：何もしない（中絶しきい値はありません）。
* Add path
* パスを追加します
Protocols: MPTCP, SCTP
プロトコル：MPTCP、SCTP
MPTCP Parameters: source-IP; source-Port; destination-IP;
destination-Port
SCTP Parameters: local IP address
SCTPパラメータ：ローカルIPアドレス
Automatable because the choice of paths to communicate between the same end hosts relates to knowledge about the network, not the application.
同じエンドホスト間で通信するパスの選択は、アプリケーションではなくネットワークに関する知識に関連しています。
* Remove path
* パスを削除します
Protocols: MPTCP, SCTP
プロトコル：MPTCP、SCTP
MPTCP Parameters: source-IP; source-Port; destination-IP;
destination-Port
SCTP Parameters: local IP address
SCTPパラメータ：ローカルIPアドレス
Automatable because the choice of paths to communicate between the same end host relates to knowledge about the network, not the application.
同じエンドホスト間で通信するパスの選択は、アプリケーションではなくネットワークに関する知識に関連しているためです。
* Set primary path
* プライマリパスを設定します
Protocols: SCTP
プロトコル：SCTP.
Automatable because the choice of paths to communicate between the same end hosts relates to knowledge about the network, not the application.
同じエンドホスト間で通信するパスの選択は、アプリケーションではなくネットワークに関する知識に関連しています。
* Suggest primary path to the peer
* ピアへのプライマリパスを提案します
Protocols: SCTP
プロトコル：SCTP.
Automatable because the choice of paths to communicate between the same end hosts relates to knowledge about the network, not the application.
同じエンドホスト間で通信するパスの選択は、アプリケーションではなくネットワークに関する知識に関連しています。
* Configure Path Switchover
* パス切り替えを設定します
Protocols: SCTP
プロトコル：SCTP.
Automatable because the choice of paths to communicate between the same end hosts relates to knowledge about the network, not the application.
同じエンドホスト間で通信するパスの選択は、アプリケーションではなくネットワークに関する知識に関連しています。
* Obtain status (query or notification)
* ステータスを取得する（クエリまたは通知）
Protocols: SCTP, MPTCP
プロトコル：SCTP、MPTCP.
SCTP parameters: association connection state; destination
transport address list; destination transport address reachability
states; current local and peer receiver window size; current local
congestion window sizes; number of unacknowledged DATA chunks;
number of DATA chunks pending receipt; primary path; most recent
SRTT on primary path; RTO on primary path; SRTT and RTO on other
destination addresses; MTU per path; interleaving supported yes/no
MPTCP parameters: subflow-list (identified by source-IP; source-
Port; destination-IP; destination-Port)
Automatable because these parameters relate to knowledge about the network, not the application.
これらのパラメータはアプリケーションではなくネットワークに関する知識に関連しています。
* Specify DSCP field
* DSCPフィールドを指定します
Protocols: TCP, SCTP, UDP(-Lite)
プロトコル：TCP、SCTP、UDP（-Lite）
Optimizing because choosing a suitable DSCP value requires application-specific knowledge.
適切なDSCP値を選択するには、アプリケーション固有の知識が必要なため最適化します。
Implementation: via SET_DSCP.TCP / SET_DSCP.SCTP / SET_DSCP.UDP(- Lite).
実装：set_dscp.tcp / set_dscp.sctp / set_dscp.udp（ - Lite）。
* Notification of ICMP error message arrival
* ICMPエラーメッセージ到着の通知
Protocols: TCP, UDP(-Lite)
プロトコル：TCP、UDP（-Lite）
Optimizing because these messages can inform about success or failure of functional transport features (e.g., host unreachable relates to "Connect").
これらのメッセージは機能的輸送機能の成功または失敗について知らせる（例えば、ホスト到達不能）。
Implementation: via ERROR.TCP or ERROR.UDP(-Lite.)
実装：error.tcpまたはerror.udp（-lite）を介して
* Obtain information about interleaving support
* インターリーブサポートに関する情報を入手してください
Protocols: SCTP
プロトコル：SCTP.
Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable.
自動的に複数のストリームを使用する必要があるが、Connection.Stablishmentカテゴリに複数のストリームを要求するため、自動化可能です。
Implementation: via STATUS.SCTP.
実装：status.sctpを介して。
* Change authentication parameters
* 認証パラメータを変更します
Protocols: TCP, SCTP
プロトコル：TCP、SCTP
Functional because this has a direct influence on security.
これはセキュリティに直接的な影響を与えるので機能的です。
Implementation: via SET_AUTH.TCP and SET_AUTH.SCTP.
実装：set_auth.tcpとset_auth.sctpを介して。
Implementation over TCP: with SCTP, this allows adjusting key_id, key, and hmac_id. With TCP, this allows changing the preferred outgoing MKT (current_key) and the preferred incoming MKT (rnext_key), respectively, for a segment that is sent on the connection. Key material must be provided in a way that is compatible with both [RFC4895] and [RFC5925].
TCPを介した実装：SCTPを使用すると、これによりkey_id、key、およびhmac_idを調整できます。TCPでは、これにより、接続で送信されるセグメントに対して、それぞれ優先発信MKT（current_key）と優先着信MKT（RNEXT_KEY）を変更できます。キーマテリアルは、[RFC4895]と[RFC5925]の両方と互換性のある方法で提供する必要があります。
Implementation over UDP: not possible. (UDP does not offer authentication.)
UDP上の実装：不可能です。（UDPは認証を提供しません。）
* Obtain authentication information
* 認証情報を入手してください
Protocols: SCTP
プロトコル：SCTP.
Functional because authentication decisions may have been made by the peer, and this has an influence on the necessary application-level measures to provide a certain level of security.
認証の決定がピアによって行われた可能性があるため機能し、これは必要なレベルのセキュリティを提供するために必要なアプリケーションレベルの尺度に影響を与えます。
Implementation: via GET_AUTH.SCTP.
実装：get_auth.sctpを介して。
Implementation over TCP: with SCTP, this allows obtaining key_id and a chunk list. With TCP, this allows obtaining current_key and rnext_key from a previously received segment. Key material must be provided in a way that is compatible with both [RFC4895] and [RFC5925].
TCPの実装：SCTPを使用すると、これによりkey_idとチャンクリストを取得できます。TCPでは、これ以前に受信したセグメントからcurrent_keyとrnext_keyを取得できます。キーマテリアルは、[RFC4895]と[RFC5925]の両方と互換性のある方法で提供する必要があります。
Implementation over UDP: not possible. (UDP does not offer authentication.)
UDP上の実装：不可能です。（UDPは認証を提供しません。）
* Reset Stream
* ストリームをリセットします
Protocols: SCTP
プロトコル：SCTP.
Automatable because using multi-streaming does not require application-specific knowledge.
マルチストリーミングを使用すると、アプリケーション固有の知識が必要ないため自動化可能です。
Implementation: see Section 5.2.
実装：セクション5.2を参照してください。
* Notification of Stream Reset
* ストリームリセットの通知
Protocols: SCTP
プロトコル：SCTP.
Automatable because using multi-streaming does not require application-specific knowledge.
マルチストリーミングを使用すると、アプリケーション固有の知識が必要ないため自動化可能です。
Implementation: see Section 5.2.
実装：セクション5.2を参照してください。
* Reset Association
* 協会をリセットします
Protocols: SCTP
プロトコル：SCTP.
Automatable because deciding to reset an association does not require application-specific knowledge.
Automatable Associationのリセットを決定すると、アプリケーション固有の知識が必要ありません。
Implementation: via RESET_ASSOC.SCTP.
実装：reset_assoc.sctpを介して。
* Notification of Association Reset
* 関連リセットの通知
Protocols: SCTP
プロトコル：SCTP.
Automatable because this notification does not relate to application-specific knowledge.
この通知はアプリケーション固有の知識に関連しないため、自動化可能です。
* Add Streams
* ストリームを追加します
Protocols: SCTP
プロトコル：SCTP.
Automatable because using multi-streaming does not require application-specific knowledge.
マルチストリーミングを使用すると、アプリケーション固有の知識が必要ないため自動化可能です。
Implementation: see Section 5.2.
実装：セクション5.2を参照してください。
* Notification of Added Stream
* 追加されたストリームの通知
Protocols: SCTP
プロトコル：SCTP.
Automatable because using multi-streaming does not require application-specific knowledge.
マルチストリーミングを使用すると、アプリケーション固有の知識が必要ないため自動化可能です。
Implementation: see Section 5.2.
実装：セクション5.2を参照してください。
* Choose a scheduler to operate between streams of an association
* 関連付けのストリーム間で動作するスケジューラを選択してください
Protocols: SCTP
プロトコル：SCTP.
Optimizing because the scheduling decision requires application-specific knowledge. However, if a transport system would not use this, or wrongly configure it on its own, this would only affect the performance of data transfers; the outcome would still be correct within the "best effort" service model.
スケジューリングの決定にはアプリケーション固有の知識が必要なので最適化。ただし、トランスポートシステムがこれを使用しないか、またはそれを自分で誤って設定した場合、これはデータ転送のパフォーマンスにのみ影響します。結果はまだ「ベストエフォート」サービスモデル内で正しいです。
Implementation: using SET_STREAM_SCHEDULER.SCTP.
実装：set_stream_scheduler.sctpを使用します。
Implementation over TCP: do nothing (streams are not available in TCP, but no guarantee is given that this transport feature has any effect).
TCPの実装：何もしない（ストリームはTCPで利用できませんが、このトランスポート機能にはどのような効果があるという保証はありません）。
Implementation over UDP: do nothing (streams are not available in UDP, but no guarantee is given that this transport feature has any effect).
UDP上の実装：何もしない（ストリームはUDPで利用できませんが、このトランスポート機能にはどのような効果があることは保証はありません）。
* Configure priority or weight for a scheduler
* スケジューラの優先順位または重みを設定します
Protocols: SCTP
プロトコル：SCTP.
Optimizing because the priority or weight requires application-specific knowledge. However, if a transport system would not use this, or wrongly configure it on its own, this would only affect the performance of data transfers; the outcome would still be correct within the "best effort" service model.
優先順位または体重がアプリケーション固有の知識を必要とするため、最適化。ただし、トランスポートシステムがこれを使用しないか、またはそれを自分で誤って設定した場合、これはデータ転送のパフォーマンスにのみ影響します。結果はまだ「ベストエフォート」サービスモデル内で正しいです。
Implementation: using CONFIGURE_STREAM_SCHEDULER.SCTP.
実装：configure_stream_scheduler.sctpを使用します。
Implementation over TCP: do nothing (streams are not available in TCP, but no guarantee is given that this transport feature has any effect).
TCPの実装：何もしない（ストリームはTCPで利用できませんが、このトランスポート機能にはどのような効果があるという保証はありません）。
Implementation over UDP: do nothing (streams are not available in UDP, but no guarantee is given that this transport feature has any effect).
UDP上の実装：何もしない（ストリームはUDPで利用できませんが、このトランスポート機能にはどのような効果があることは保証はありません）。
* Configure send buffer size
* 送信バッファサイズを設定します
Protocols: SCTP
プロトコル：SCTP.
Automatable because this decision relates to knowledge about the network and the Operating System, not the application (see also the discussion in Section 5.4).
この決定は、アプリケーションではなくネットワークとオペレーティングシステムに関する知識に関連しているため、自動化可能です（セクション5.4の説明も参照）。
* Configure receive buffer (and rwnd) size
* 受信バッファ（およびRWND）のサイズを設定します
Protocols: SCTP
プロトコル：SCTP.
Automatable because this decision relates to knowledge about the network and the Operating System, not the application.
この決定はアプリケーションではなく、ネットワークとオペレーティングシステムに関する知識に関連しています。
* Configure message fragmentation
* メッセージの断片化を設定します
Protocols: SCTP
プロトコル：SCTP.
Automatable because this relates to knowledge about the network and the Operating System, not the application. Note that this SCTP feature does not control IP-level fragmentation, but decides on fragmentation of messages by SCTP, in the end system.
これはアプリケーションではなく、ネットワークとオペレーティングシステムに関する知識に関連しています。このSCTP機能はIPレベルの断片化を制御しないが、エンドシステムではSCTPによるメッセージの断片化を決定します。
Implementation: done by always enabling it with CONFIG_FRAGMENTATION.SCTP and auto-setting the fragmentation size based on network or Operating System conditions.
実装：常にconfig_fragmentation.stppを使用して有効にし、ネットワークまたはオペレーティングシステムの条件に基づいてフラグメンテーションサイズを自動設定します。
* Configure PMTUD
* PMTUDを設定します
Protocols: SCTP
プロトコル：SCTP.
Automatable because Path MTU Discovery relates to knowledge about the network, not the application.
PATH MTUディスカバリーはアプリケーションではなくネットワークに関する知識に関連しているため自動化可能です。
* Configure delayed SACK timer
* 遅延SACKタイマーを設定します
Protocols: SCTP
プロトコル：SCTP.
Automatable because the receiver-side decision to delay sending SACKs relates to knowledge about the network, not the application (it can be relevant for a sending application to request not to delay the SACK of a message, but this is a different transport feature).
自動的に袋を遅らせるための受信側の決定は、アプリケーションではなくネットワークに関する知識に関連しています（メッセージの袋を遅らせることはできませんが、これは異なるトランスポート機能です）ネットワークに関する知識に関連しています。
* Set Cookie life value
* Cookie Life Valueを設定します
Protocols: SCTP
プロトコル：SCTP.
Functional because it relates to security (possibly weakened by keeping a cookie very long) versus the time between connection establishment attempts. Knowledge about both issues can be application specific.
接続確立の試行間の時間に対するセキュリティ（クッキーを非常に長く保つことによって衰弱させる可能性がある）に関連するので機能的。両方の問題に関する知識はアプリケーション固有のものにすることができます。
Implementation over TCP: the closest specified TCP functionality is the cookie in TCP Fast Open; for this, [RFC7413] states that the server "can expire the cookie at any time to enhance security", and Section 4.1.2 of [RFC7413] describes an example implementation where updating the key on the server side causes the cookie to expire. Alternatively, for implementations that do not support TCP Fast Open, this transport feature could also affect the validity of SYN cookies (see Section 3.6 of [RFC4987]).
TCPを介した実装：最も近い指定されたTCP機能は、TCPのFast OpenのCookieです。このために、[RFC7413]はサーバーが「セキュリティを強化するためにいつでもクッキーを期限切れにすることができ」と述べています。[RFC7413]のセクション4.1.2では、サーバー側のキーを更新する例では、Cookieが期限切れになります。あるいは、TCPの高速オープンをサポートしていない実装では、このトランスポート機能もSYN Cookieの有効性に影響を与える可能性があります（[RFC4987]のセクション3.6を参照）。
Implementation over UDP: not possible. (UDP does not offer this functionality.)
UDP上の実装：不可能です。（UDPはこの機能を提供しません。）
* Set maximum burst
* 最大バーストを設定
Protocols: SCTP
プロトコル：SCTP.
Automatable because it relates to knowledge about the network, not the application.
自動的にはネットワークに関する知識に関連しているため、アプリケーションではありません。
* Configure size where messages are broken up for partial delivery
* 部分配信のためにメッセージが分割されているサイズを設定する
Protocols: SCTP
プロトコル：SCTP.
Functional because this is closely tied to properties of the data that an application sends or expects to receive.
これは、アプリケーションが送信または受信を期待しているデータのプロパティに密接に関連しているためです。
Implementation over TCP: not possible. (TCP does not offer identification of message boundaries.)
TCPを介した実装：不可能です。（TCPはメッセージ境界の識別を提供しません。）
Implementation over UDP: not possible. (UDP does not fragment messages.)
UDP上の実装：不可能です。（UDPはメッセージをフラグメント化しません。）
* Disable checksum when sending
* 送信時にチェックサムを無効にします
Protocols: UDP
プロトコル：UDP.
Functional because application-specific knowledge is necessary to decide whether it can be acceptable to lose data integrity with respect to random corruption.
アプリケーション固有の知識は、それがランダムな破損に関してデータの整合性を失うことが許容できるかどうかを決定するために必要なので、アプリケーション固有の知識が必要である。
Implementation: via SET_CHECKSUM_ENABLED.UDP.
実装：set_checksum_enabled.udp。
Implementation over TCP: do nothing (TCP does not offer to disable the checksum, but transmitting data with an intact checksum will not yield a semantically wrong result).
TCPの実装：何もしない（TCPはチェックサムを無効にしませんが、その無傷のチェックサムでデータを送信すると、意味的に間違った結果は生じません）。
* Disable checksum requirement when receiving
* 受信時にチェックサム要件を無効にします
Protocols: UDP
プロトコル：UDP.
Functional because application-specific knowledge is necessary to decide whether it can be acceptable to lose data integrity with respect to random corruption.
アプリケーション固有の知識は、それがランダムな破損に関してデータの整合性を失うことが許容できるかどうかを決定するために必要なので、アプリケーション固有の知識が必要である。
Implementation: via SET_CHECKSUM_REQUIRED.UDP.
実装：set_checksum_required.udp。
Implementation over TCP: do nothing (TCP does not offer to disable the checksum, but transmitting data with an intact checksum will not yield a semantically wrong result).
TCPの実装：何もしない（TCPはチェックサムを無効にしませんが、その無傷のチェックサムでデータを送信すると、意味的に間違った結果は生じません）。
* Specify checksum coverage used by the sender
* 送信者によって使用されるチェックサムカバレッジを指定します
Protocols: UDP-Lite
プロトコル：UDP-Lite
Functional because application-specific knowledge is necessary to decide for which parts of the data it can be acceptable to lose data integrity with respect to random corruption.
アプリケーション固有の知識は、データのどの部分がランダムな破損に関してデータの整合性を失うことが許容できるかを決定するために必要なので、アプリケーション固有の知識が必要です。
Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite.
実装：set_checksum_coverage.udp-liteを介して。
Implementation over TCP: do nothing (TCP does not offer to limit the checksum length, but transmitting data with an intact checksum will not yield a semantically wrong result).
TCPの実装：何もしない（TCPはチェックサム長を制限することを申し出ませんが、その無傷のチェックサムでデータを送信することは意味的に間違った結果をもたらされません）。
Implementation over UDP: if checksum coverage is set to cover payload data, do nothing. Else, either do nothing (transmitting data with an intact checksum will not yield a semantically wrong result), or use the transport feature "Disable checksum when sending".
UDP上の実装：チェックサムカバレッジがペイロードデータをカバーするように設定されている場合は、何もしません。そうでなければ、何もしない（無傷のチェックサムでデータを送信することは意味的に間違った結果は得られません）、またはトランスポート機能「送信時にチェックサムを無効にする」を使用します。
* Specify minimum checksum coverage required by receiver
* 受信者に必要な最小限のチェックサムカバレッジを指定してください
Protocols: UDP-Lite
プロトコル：UDP-Lite
Functional because application-specific knowledge is necessary to decide for which parts of the data it can be acceptable to lose data integrity with respect to random corruption.
アプリケーション固有の知識は、データのどの部分がランダムな破損に関してデータの整合性を失うことが許容できるかを決定するために必要なので、アプリケーション固有の知識が必要です。
Implementation: via SET_MIN_CHECKSUM_COVERAGE.UDP-Lite.
実装：set_min_checksum_coverage.udp-liteを介して。
Implementation over TCP: do nothing (TCP does not offer to limit the checksum length, but transmitting data with an intact checksum will not yield a semantically wrong result).
TCPの実装：何もしない（TCPはチェックサム長を制限することを申し出ませんが、その無傷のチェックサムでデータを送信することは意味的に間違った結果をもたらされません）。
Implementation over UDP: if checksum coverage is set to cover payload data, do nothing. Else, either do nothing (transmitting data with an intact checksum will not yield a semantically wrong result), or use the transport feature "Disable checksum requirement when receiving".
UDP上の実装：チェックサムカバレッジがペイロードデータをカバーするように設定されている場合は、何もしません。そうでなければ、何もしない（無傷のチェックサムでデータを送信することは意味的に間違った結果は得られません）、または[受信時にチェックサム要件を無効にする]を使用します。
* Specify DF field
* DFフィールドを指定します
Protocols: UDP(-Lite)
プロトコル：UDP（-Lite）
Optimizing because the DF field can be used to carry out Path MTU Discovery, which can lead an application to choose message sizes that can be transmitted more efficiently.
DFフィールドを使用してパスMTUディスカバリを実行できるため、アプリケーションがより効率的に送信できるメッセージサイズを選択することができるため、最適化。
Implementation: via MAINTENANCE.SET_DF.UDP(-Lite) and SEND_FAILURE.UDP(-Lite).
実装：maintenance.set_df.udp（-lite）とsend_failure.udp（-lite）を介して。
Implementation over TCP: do nothing (with TCP, the sending application is not in control of transport message sizes, making this functionality irrelevant).
TCPの実装：何もしない（TCPでは、送信アプリケーションはトランスポートメッセージサイズを制御していません。この機能は無関係にします）。
* Get max. transport-message size that may be sent using a non-fragmented IP packet from the configured interface
* マックスを取得します。設定されたインターフェイスから断片化されていないIPパケットを使用して送信されるトランスポートメッセージサイズ
Protocols: UDP(-Lite)
プロトコル：UDP（-Lite）
Optimizing because this can lead an application to choose message sizes that can be transmitted more efficiently.
これにより、アプリケーションがより効率的に送信できるメッセージサイズを選択するためにアプリケーションをリードする可能性があるため最適化されます。
Implementation over TCP: do nothing (this information is not available with TCP).
TCPの実装：何もしない（この情報はTCPでは利用できません）。
* Get max. transport-message size that may be received from the configured interface
* マックスを取得します。設定されたインターフェイスから受信できるトランスポートメッセージサイズ
Protocols: UDP(-Lite)
プロトコル：UDP（-Lite）
Optimizing because this can, for example, influence an application's memory management.
これは、例えばアプリケーションのメモリ管理に影響を与える可能性があるため、最適化します。
Implementation over TCP: do nothing (this information is not available with TCP).
TCPの実装：何もしない（この情報はTCPでは利用できません）。
* Specify TTL/Hop count field
* TTL / Hop Countフィールドを指定します
Protocols: UDP(-Lite)
プロトコル：UDP（-Lite）
Automatable because a transport system can use a large enough system default to avoid communication failures. Allowing an application to configure it differently can produce notifications of ICMP error message arrivals that yield information that only relates to knowledge about the network, not the application.
トランスポートシステムが通信障害を回避するためにデフォルトの大きなシステムのデフォルトを使用できるため、自動化可能です。アプリケーションを構成することで、アプリケーションではなくネットワークに関する知識にのみ関連する情報を生成するICMPエラーメッセージの到着の通知を生成できます。
* Obtain TTL/Hop count field
* TTL / Hop Countフィールドを入手してください
Protocols: UDP(-Lite)
プロトコル：UDP（-Lite）
Automatable because the TTL/Hop count field relates to knowledge about the network, not the application.
TTL / Hop Countフィールドはアプリケーションではなくネットワークに関する知識に関連しているため、自動化可能です。
* Specify ECN field
* ECNフィールドを指定してください
Protocols: UDP(-Lite)
プロトコル：UDP（-Lite）
Automatable because the ECN field relates to knowledge about the network, not the application.
ECNフィールドはアプリケーションではなくネットワークに関する知識に関連しているため、自動化できます。
* Obtain ECN field
* ECNフィールドを入手してください
Protocols: UDP(-Lite)
プロトコル：UDP（-Lite）
Optimizing because this information can be used by an application to better carry out congestion control (this is relevant when choosing a data transmission Transport Service that does not already do congestion control).
この情報は、アプリケーションによって輻輳制御を実行するためにアプリケーションによって使用される可能性があるため、最適化（まだ輻輳制御をしないデータ伝送トランスポートサービスを選択するときに関連があります）。
Implementation over TCP: do nothing (this information is not available with TCP).
TCPの実装：何もしない（この情報はTCPでは利用できません）。
* Specify IP Options
* IPオプションを指定します
Protocols: UDP(-Lite)
プロトコル：UDP（-Lite）
Automatable because IP Options relate to knowledge about the network, not the application.
自動化可能なIPオプションは、アプリケーションではなくネットワークに関する知識に関連しています。
* Obtain IP Options
* IPオプションを入手してください
Protocols: UDP(-Lite)
プロトコル：UDP（-Lite）
Automatable because IP Options relate to knowledge about the network, not the application.
自動化可能なIPオプションは、アプリケーションではなくネットワークに関する知識に関連しています。
* Enable and configure a "Low Extra Delay Background Transfer"
* 「低遅延バックグラウンド転送」を有効にして設定します。
Protocols: a protocol implementing the LEDBAT congestion control mechanism
プロトコル：LEDBAT輻輳制御メカニズムを実装するプロトコル
Optimizing because whether this feature is appropriate or not depends on application-specific knowledge. However, wrongly using this will only affect the speed of data transfers (albeit including other transfers that may compete with the transport system's transfer in the network), so it is still correct within the "best effort" service model.
この機能が適切かどうか、あるいはアプリケーション固有の知識に依存しているかどうかを最適化します。ただし、これを使用すると、データ転送の速度にのみ影響します（ネットワーク内でのトランスポートシステムの転送と競合する可能性がある他の転送を含むが）、「最良の努力」サービスモデル内でまだ正しいことです。
Implementation: via CONFIGURE.LEDBAT and/or SET_DSCP.TCP / SET_DSCP.SCTP / SET_DSCP.UDP(-Lite) [RFC8622].
実装：configure.ledbatおよび/またはset_dscp.tcp / set_dscp.sctp / set_dscp.udp（-lite）[RFC8622]。
Implementation over TCP: do nothing (TCP does not support LEDBAT congestion control, but not implementing this functionality will not yield a semantically wrong behavior).
TCPの実装：何もしない（TCPはLEDBATの輻輳制御をサポートしていませんが、この機能を実装していませんが、意味的に間違った動作にはなりません）。
Implementation over UDP: do nothing (UDP does not offer congestion control).
UDP上の実装：何もしない（UDPは輻輳制御を提供しません）。
TERMINATION:
終了：
* Close after reliably delivering all remaining data, causing an event informing the application on the other side
* 残りのすべてのデータを確実に配信した後に閉じて、他の側にアプリケーションに通知するイベントが発生します。
Protocols: TCP, SCTP
プロトコル：TCP、SCTP
Functional because the notion of a connection is often reflected in applications as an expectation to have all outstanding data delivered and no longer be able to communicate after a "Close" succeeded, with a communication sequence relating to this transport feature that is defined by the application protocol.
接続の概念は、すべての未処理のデータを提供することが期待としてアプリケーションに反映され、アプリケーションによって定義されているこのトランスポート機能に関連する通信シーケンスを持つことを期待としてアプリケーションに反映されます。プロトコル。
Implementation: via CLOSE.TCP and CLOSE.SCTP.
実装：ownly.tcpとclose.sctpを介して。
Implementation over UDP: not possible. (UDP is unreliable and hence does not know when all remaining data is delivered; it does also not offer to cause an event related to closing at the peer.)
UDP上の実装：不可能です。（UDPは信頼できないため、残りのすべてのデータが配信されている場合はわかりません。また、ピアでの終了に関連するイベントを提供することもできません。）
* Abort without delivering remaining data, causing an event informing the application on the other side
* 残りのデータを配信せずに中止され、アプリケーションに反対側にアプリケーションに通知するイベントが発生します。
Protocols: TCP, SCTP
プロトコル：TCP、SCTP
Functional because the notion of a connection is often reflected in applications as an expectation to potentially not have all outstanding data delivered and no longer be able to communicate after an "Abort" succeeded. On both sides of a connection, an application protocol may define a communication sequence relating to this transport feature.
接続の概念は、潜在的に配信されたすべての未処理のデータを持たず、「中止」の後に通信できなくなることを期待としてアプリケーションに反映されていることが多いため機能します。接続の両側に、アプリケーションプロトコルは、このトランスポート機能に関連する通信シーケンスを定義することができます。
Implementation: via ABORT.TCP and ABORT.SCTP.
実装：abort.tcpとabort.sctpを介して。
Implementation over UDP: not possible. (UDP does not offer to cause an event related to aborting at the peer.)
UDP上の実装：不可能です。（UDPは、ピアでの中止に関連するイベントを引き起こすことを申し出ません。）
* Abort without delivering remaining data, not causing an event informing the application on the other side
* 残りのデータを配信せずに中止し、アプリケーションに反対側にアプリケーションに知らせるイベントを引き起こしていません。
Protocols: UDP(-Lite)
プロトコル：UDP（-Lite）
Functional because the notion of a connection is often reflected in applications as an expectation to potentially not have all outstanding data delivered and no longer be able to communicate after an "Abort" succeeded. On both sides of a connection, an application protocol may define a communication sequence relating to this transport feature.
接続の概念は、潜在的に配信されたすべての未処理のデータを持たず、「中止」の後に通信できなくなることを期待としてアプリケーションに反映されていることが多いため機能します。接続の両側に、アプリケーションプロトコルは、このトランスポート機能に関連する通信シーケンスを定義することができます。
Implementation: via ABORT.UDP(-Lite).
実装：abort.udp（-lite）を介して。
Implementation over TCP: stop using the connection, wait for a timeout.
TCPの実装：接続の使用を中止し、タイムアウトを待ちます。
* Timeout event when data could not be delivered for too long
* データを長すぎるために配信できなかったタイムアウトイベント
Protocols: TCP, SCTP
プロトコル：TCP、SCTP
Functional because this notifies that potentially assumed reliable data delivery is no longer provided.
これは潜在的に想定される信頼できるデータ配信がもはや提供されなくなったことを通知するので機能的。
Implementation: via TIMEOUT.TCP and TIMEOUT.SCTP.
実装：timeout.tcpとtimeout.sctpをvia。
Implementation over UDP: do nothing (this event will not occur with UDP).
UDP上の実装：何もしない（このイベントはUDPでは発生しません）。
* Reliably transfer data, with congestion control
* 輻輳制御でデータを確実に転送します
Protocols: TCP, SCTP
プロトコル：TCP、SCTP
Functional because this is closely tied to properties of the data that an application sends or expects to receive.
これは、アプリケーションが送信または受信を期待しているデータのプロパティに密接に関連しているためです。
Implementation: via SEND.TCP and SEND.SCTP.
実装：send.tcpとsend.sctpを介して。
Implementation over UDP: not possible. (UDP is unreliable.)
UDP上の実装：不可能です。（UDPは信頼できません。）
* Reliably transfer a message, with congestion control
* 輻輳制御でメッセージを確実に転送します
Protocols: SCTP
プロトコル：SCTP.
Functional because this is closely tied to properties of the data that an application sends or expects to receive.
これは、アプリケーションが送信または受信を期待しているデータのプロパティに密接に関連しているためです。
Implementation: via SEND.SCTP.
実装：send.sctpを介して。
Implementation over TCP: via SEND.TCP. With SEND.TCP, message boundaries will not be identifiable by the receiver, because TCP provides a byte-stream service.
TCPを介した実装：send.tcpを介して。TCPはバイトストリームサービスを提供するため、Send.TCPでは、メッセージ境界は受信者によって識別できません。
Implementation over UDP: not possible. (UDP is unreliable.)
UDP上の実装：不可能です。（UDPは信頼できません。）
* Unreliably transfer a message
* メッセージを無関係に転送します
Protocols: SCTP, UDP(-Lite)
プロトコル：SCTP、UDP（ - ライト）
Optimizing because only applications know about the time criticality of their communication, and reliably transferring a message is never incorrect for the receiver of a potentially unreliable data transfer, it is just slower.
アプリケーションのみが通信の時期臨界度について知っておくことができ、信頼性の低いデータ転送の受信側にとって確実にメッセージを転送することは決して遅くなることはありません。
CHANGED FROM RFC 8303. This differs from the 2 automatable transport features below in that it leaves the choice of congestion control open.
RFC 8303から変更されました。
Implementation: via SEND.SCTP or SEND.UDP(-Lite).
実装：send.sctpまたはsend.udp（-lite）を介して。
Implementation over TCP: use SEND.TCP. With SEND.TCP, messages will be sent reliably, and message boundaries will not be identifiable by the receiver.
TCPの実装：send.tcpを使用してください。Send.TCPを使用すると、メッセージは確実に送信され、メッセージの境界は受信者によって識別できません。
* Unreliably transfer a message, with congestion control
* 輻輳制御を使用して、メッセージを無関係に転送します
Protocols: SCTP
プロトコル：SCTP.
Automatable because congestion control relates to knowledge about the network, not the application.
輻輳制御はネットワークに関する知識に関連しているため、アプリケーションではありません。
* Unreliably transfer a message, without congestion control
* 輻輳制御なしで、メッセージを無関係に転送します
Protocols: UDP(-Lite)
プロトコル：UDP（-Lite）
Automatable because congestion control relates to knowledge about the network, not the application.
輻輳制御はネットワークに関する知識に関連しているため、アプリケーションではありません。
* Configurable Message Reliability
* 設定可能なメッセージの信頼性
Protocols: SCTP
プロトコル：SCTP.
Optimizing because only applications know about the time criticality of their communication, and reliably transferring a message is never incorrect for the receiver of a potentially unreliable data transfer, it is just slower.
アプリケーションのみが通信の時期臨界度について知っておくことができ、信頼性の低いデータ転送の受信側にとって確実にメッセージを転送することは決して遅くなることはありません。
Implementation: via SEND.SCTP.
実装：send.sctpを介して。
Implementation over TCP: done by using SEND.TCP and ignoring this configuration. Based on the assumption of the best-effort service model, unnecessarily delivering data does not violate application expectations. Moreover, it is not possible to associate the requested reliability to a "message" in TCP anyway.
TCPを介した実装：Send.TCPを使用してこの構成を無視して行います。ベストエフォート型サービスモデルの仮定に基づいて、不必要にデータを配信することは申請期待に違反しません。また、要求された信頼性をTCPの「メッセージ」に関連付けることはできません。
Implementation over UDP: not possible. (UDP is unreliable.)
UDP上の実装：不可能です。（UDPは信頼できません。）
* Choice of stream
* ストリームの選択
Protocols: SCTP
プロトコル：SCTP.
Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable.
自動的に複数のストリームを使用する必要があるが、Connection.Stablishmentカテゴリに複数のストリームを要求するため、自動化可能です。
Implementation: see Section 5.2.
実装：セクション5.2を参照してください。
* Choice of path (destination address)
* パスの選択（宛先アドレス）
Protocols: SCTP
プロトコル：SCTP.
Automatable because it requires using multiple sockets, but obtaining multiple sockets in the CONNECTION.ESTABLISHMENT category is automatable.
自動的に複数のソケットを使用する必要があるが、Connection.Stablishmentカテゴリで複数のソケットを入手することは自動化可能です。
* Ordered message delivery (potentially slower than unordered)
* 注文されたメッセージ配信（順不同より遅く遅く）
Protocols: SCTP
プロトコル：SCTP.
Functional because this is closely tied to properties of the data that an application sends or expects to receive.
これは、アプリケーションが送信または受信を期待しているデータのプロパティに密接に関連しているためです。
Implementation: via SEND.SCTP.
実装：send.sctpを介して。
Implementation over TCP: done by using SEND.TCP. With SEND.TCP, messages will not be identifiable by the receiver.
TCPを介した実装：send.tcpを使用して行いました。send.tcpを使用すると、メッセージは受信者によって識別できません。
Implementation over UDP: not possible. (UDP does not offer any guarantees regarding ordering.)
UDP上の実装：不可能です。（UDPは注文に関する保証はありません。）
* Unordered message delivery (potentially faster than ordered)
* 順序付けられていないメッセージ配信（注文よりも潜在的に早く）
Protocols: SCTP, UDP(-Lite)
プロトコル：SCTP、UDP（ - ライト）
Functional because this is closely tied to properties of the data that an application sends or expects to receive.
これは、アプリケーションが送信または受信を期待しているデータのプロパティに密接に関連しているためです。
Implementation: via SEND.SCTP.
実装：send.sctpを介して。
Implementation over TCP: done by using SEND.TCP and always sending data ordered. Based on the assumption of the best-effort service model, ordered delivery may just be slower and does not violate application expectations. Moreover, it is not possible to associate the requested delivery order to a "message" in TCP anyway.
TCPを介した実装：send.tcpを使用して、常にデータの順序付きデータを送信します。ベストエフォート型サービスモデルの仮定に基づいて、順序付き配信は遅くなり、適用期待に違反しないようにします。さらに、要求された配送順序をTCPの「メッセージ」に関連付けることはできません。
* Request not to bundle messages
* バンドルメッセージを要求します
Protocols: SCTP
プロトコル：SCTP.
Optimizing because this decision depends on knowledge about the size of future data blocks and the delay between them.
この決定が将来のデータブロックのサイズとそれらの間の遅延に関する知識に依存するため、最適化。
Implementation: via SEND.SCTP.
実装：send.sctpを介して。
Implementation over TCP: done by using SEND.TCP and DISABLE_NAGLE.TCP to disable the Nagle algorithm when the request is made and enable it again when the request is no longer made. Note that this is not fully equivalent because it relates to the time of issuing the request rather than a specific message.
TCP over TCP：SEND.TCPとDISABLE_NAGLE.TCPを使用して、要求が行われたときにリクエストが行われたときに再び有効になったときにNAGLEアルゴリズムを無効にします。特定のメッセージではなくリクエストを発行する時間に関連するため、これは完全には同等ではないことに注意してください。
Implementation over UDP: do nothing (UDP never bundles messages).
UDP上の実装：何もしない（UDPはメッセージをバンドルしません）。
* Specifying a "payload protocol-id" (handed over as such by the receiver)
* "Payload Protocol-ID"の指定（受信者によってそのように渡される）
Protocols: SCTP
プロトコル：SCTP.
Functional because it allows sending extra application data with every message, for the sake of identification of data, which by itself is application specific.
機能がすべてのメッセージで追加のアプリケーションデータを送信することを可能にするデータの識別のために、それ自体がアプリケーション固有のものであるためです。
Implementation: SEND.SCTP.
実装：send.sctp。
Implementation over TCP: not possible. (This functionality is not available in TCP.)
TCPを介した実装：不可能です。（この機能はTCPでは利用できません。）
Implementation over UDP: not possible. (This functionality is not available in UDP.)
UDP上の実装：不可能です。（この機能はUDPでは利用できません。）
* Specifying a key id to be used to authenticate a message
* メッセージの認証に使用されるキーIDの指定
Protocols: SCTP
プロトコル：SCTP.
Functional because this has a direct influence on security.
これはセキュリティに直接的な影響を与えるので機能的です。
Implementation: via a parameter in SEND.SCTP.
実装：Send.SCTPのパラメータを介して。
Implementation over TCP: this could be emulated by using SET_AUTH.TCP before and after the message is sent. Note that this is not fully equivalent because it relates to the time of issuing the request rather than a specific message.
TCPを介した実装：これは、メッセージが送信される前後にset_auth.tcpを使用してエミュレートできます。特定のメッセージではなくリクエストを発行する時間に関連するため、これは完全には同等ではないことに注意してください。
Implementation over UDP: not possible. (UDP does not offer authentication.)
UDP上の実装：不可能です。（UDPは認証を提供しません。）
* Request not to delay the acknowledgement (SACK) of a message
* メッセージの確認応答（袋）を遅らせない要求
Protocols: SCTP
プロトコル：SCTP.
Optimizing because only an application knows for which message it wants to quickly be informed about success/failure of its delivery.
アプリケーションのみがどのメッセージですばやく通知するのかを知っているため、配信の成功/失敗について知っています。
Implementation over TCP: do nothing (TCP does not offer this functionality, but ignoring this request from the application will not yield a semantically wrong behavior).
TCPの実装：何もしません（TCPはこの機能を提供しませんが、この要求はこの要求を無視しますが、意味的に間違った動作にはなりません）。
Implementation over UDP: do nothing (UDP does not offer this functionality, but ignoring this request from the application will not yield a semantically wrong behavior).
UDP上の実装：何もしない（UDPはこの機能は提供されていませんが、アプリケーションからこの要求を無視すると、意味的に間違った動作が生じることはありません）。
* Receive data (with no message delimiting)
* データを受信する（メッセージの区切りなし）
Protocols: TCP
プロトコル：TCP.
Functional because a transport system must be able to send and receive data.
トランスポートシステムがデータを送受信できなければならないため、機能します。
Implementation: via RECEIVE.TCP.
実装：receive.tcpを介して。
Implementation over UDP: do nothing (UDP only works on messages; these can be handed over, the application can still ignore the message boundaries).
UDP上の実装：何もしない（UDPはメッセージに対してのみ機能します。これらを引き渡すことができ、アプリケーションはまだメッセージ境界を無視することができます）。
* Receive a message
* メッセージを受け取る
Protocols: SCTP, UDP(-Lite)
プロトコル：SCTP、UDP（ - ライト）
Functional because this is closely tied to properties of the data that an application sends or expects to receive.
これは、アプリケーションが送信または受信を期待しているデータのプロパティに密接に関連しているためです。
Implementation: via RECEIVE.SCTP and RECEIVE.UDP(-Lite).
実装：receive.sctpとreceive.udp（-lite）。
Implementation over TCP: not possible. (TCP does not support identification of message boundaries.)
TCPを介した実装：不可能です。（TCPはメッセージ境界の識別をサポートしていません。）
* Choice of stream to receive from
* から受けるためのストリームの選択
Protocols: SCTP
プロトコル：SCTP.
Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable.
自動的に複数のストリームを使用する必要があるが、Connection.Stablishmentカテゴリに複数のストリームを要求するため、自動化可能です。
Implementation: see Section 5.2.
実装：セクション5.2を参照してください。
* Information about partial message arrival
* 部分メッセージ到着に関する情報
Protocols: SCTP
プロトコル：SCTP.
Functional because this is closely tied to properties of the data that an application sends or expects to receive.
これは、アプリケーションが送信または受信を期待しているデータのプロパティに密接に関連しているためです。
Implementation: via RECEIVE.SCTP.
実装：receive.sctpを介して。
Implementation over TCP: do nothing (this information is not available with TCP).
TCPの実装：何もしない（この情報はTCPでは利用できません）。
Implementation over UDP: do nothing (this information is not available with UDP).
UDP上の実装：何もしない（この情報はUDPでは利用できません）。
This section describes sending failures that are associated with a specific call to in the "Sending Data" category (Appendix A.2.1).
このセクションでは、「データの送信データ」カテゴリ（付録A.2.1）での特定の呼び出しに関連付けられている障害の送信について説明します。
* Notification of send failures
* 送信失敗の通知
Protocols: SCTP, UDP(-Lite)
プロトコル：SCTP、UDP（ - ライト）
Functional because this notifies that potentially assumed reliable data delivery is no longer provided.
これは潜在的に想定される信頼できるデータ配信がもはや提供されなくなったことを通知するので機能的。
CHANGED FROM RFC 8303. This differs from the 2 automatable transport features below in that it does not distinguish between unsent and unacknowledged messages.
これは、未確認のメッセージと未確認のメッセージを区別しないという点で、これは2つの自動トランスポート機能とは異なります。
Implementation: via SENDFAILURE-EVENT.SCTP and SEND_FAILURE.UDP(- Lite).
実装：sendFailure-event.sctpとsend_failure.udp（ - Lite）を介して。
Implementation over TCP: do nothing (this notification is not available and will therefore not occur with TCP).
TCPの実装：何もしない（この通知は利用できず、したがってTCPでは発生しません）。
* Notification of an unsent (part of a) message
* 未送信の通知（a）メッセージ
Protocols: SCTP, UDP(-Lite)
プロトコル：SCTP、UDP（ - ライト）
Automatable because the distinction between unsent and unacknowledged does not relate to application-specific knowledge.
未確認と未確認の区別がアプリケーション固有の知識には関係がないため、自動化可能です。
* Notification of an unacknowledged (part of a) message
* 未確認の（a）メッセージの通知
Protocols: SCTP
プロトコル：SCTP.
Automatable because the distinction between unsent and unacknowledged does not relate to application-specific knowledge.
未確認と未確認の区別がアプリケーション固有の知識には関係がないため、自動化可能です。
* Notification that the stack has no more user data to send
* スタックに送信するユーザーデータがこれ以上ない通知
Protocols: SCTP
プロトコル：SCTP.
Optimizing because reacting to this notification requires the application to be involved, and ensuring that the stack does not run dry of data (for too long) can improve performance.
この通知に対応するには、アプリケーションが参加する必要があり、スタックがデータの乾燥していないことを確認します（長すぎる）ことで、パフォーマンスが向上する可能性があります。
Implementation over TCP: do nothing (see the discussion in Section 5.4).
TCPの実装：何もしない（セクション5.4の説明を参照）。
Implementation over UDP: do nothing (this notification is not available and will therefore not occur with UDP).
UDP上の実装：何もしない（この通知は利用できず、したがってUDPでは発生しません）。
* Notification to a receiver that a partial message delivery has been aborted
* 部分的なメッセージ配信が中止された受信者への通知
Protocols: SCTP
プロトコル：SCTP.
Functional because this is closely tied to properties of the data that an application sends or expects to receive.
これは、アプリケーションが送信または受信を期待しているデータのプロパティに密接に関連しているためです。
Implementation over TCP: do nothing (this notification is not available and will therefore not occur with TCP).
TCPの実装：何もしない（この通知は利用できず、したがってTCPでは発生しません）。
Implementation over UDP: do nothing (this notification is not available and will therefore not occur with UDP).
UDP上の実装：何もしない（この通知は利用できず、したがってUDPでは発生しません）。
Acknowledgements
謝辞
The authors would like to thank all the participants of the TAPS Working Group and the NEAT and MAMI research projects for valuable input to this document. We especially thank Michael Tüxen for help with connection establishment/teardown, Gorry Fairhurst for his suggestions regarding fragmentation and packet sizes, and Spencer Dawkins for his extremely detailed and constructive review. This work has received funding from the European Union's Horizon 2020 research and innovation program under grant agreement No. 644334 (NEAT).
著者らは、タップワーキンググループのすべての参加者とこの文書への貴重な入力のためのきちんとしたマミの研究プロジェクトに感謝します。私たちは特にMichaelTüxenに感謝します。この作品は、助成金協定No. 644334（きちんと）で、欧州連合のHorizo n 2020の研究とイノベーションプログラムからの資金を受けています。
Authors' Addresses
著者の住所
Michael Welzl University of Oslo PO Box 1080 Blindern N-0316 Oslo Norway
マイケルウェルズルオスロ大学POボックス1080ブルインバーニーN-0316オスロノルウェー
Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no
Stein Gjessing University of Oslo PO Box 1080 Blindern N-0316 Oslo Norway
Stein Gjessing Oslo大学PO BOX 1080 Blindnn N-0316オスロノルウェー
Phone: +47 22 85 24 44
Email: steing@ifi.uio.no