Internet Engineering Task Force (IETF) R. Stewart
Request for Comments: 8260 Netflix, Inc.
Category: Standards Track M. Tuexen
ISSN: 2070-1721 Muenster Univ. of Appl. Sciences
S. Loreto
Ericsson
R. Seggelmann
Metafinanz Informationssysteme GmbH
November 2017
Internet Engineering Task Force (IETF) R. Stewart
Request for Comments: 8260 Netflix, Inc.
Category: Standards Track M. Tuexen
ISSN: 2070-1721 Muenster Univ. of Appl. Sciences
S. Loreto
Ericsson
R. Seggelmann
Metafinanz Informationssysteme GmbH
November 2017
Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol
流控制传输协议的流调度器和用户消息交织
Abstract
摘要
The Stream Control Transmission Protocol (SCTP) is a message-oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head-of-line blocking at the sender. The interleaving of user messages is required for WebRTC data channels.
流控制传输协议（SCTP）是一种面向消息的传输协议，支持任意大的用户消息。本文档向SCTP添加了一个新块，用于承载有效负载数据。这允许发送方交错不同的用户消息，否则将导致发送方的行首阻塞。WebRTC数据通道需要用户消息的交错。
Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined in this document. A stream scheduler can choose to either implement, or not implement, user message interleaving.
每当允许SCTP发送方发送用户数据时，它可以从多个传出SCTP流中进行选择。本文档中定义了执行此选择的多种方法，称为流调度器。流调度器可以选择实现或不实现用户消息交错。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc8260.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8260.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
2. User Message Interleaving . . . . . . . . . . . . . . . . . . 6
2.1. The I-DATA Chunk Supporting User Message Interleaving . . 7
2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Negotiation . . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Sender-Side Considerations . . . . . . . . . . . . . 10
2.2.3. Receiver-Side Considerations . . . . . . . . . . . . 11
2.3. Interaction with Other SCTP Extensions . . . . . . . . . 11
2.3.1. SCTP Partial Reliability Extension . . . . . . . . . 11
2.3.2. SCTP Stream Reconfiguration Extension . . . . . . . . 13
3. Stream Schedulers . . . . . . . . . . . . . . . . . . . . . . 14
3.1. First-Come, First-Served Scheduler (SCTP_SS_FCFS) . . . . 14
3.2. Round-Robin Scheduler (SCTP_SS_RR) . . . . . . . . . . . 14
3.3. Round-Robin Scheduler per Packet (SCTP_SS_RR_PKT) . . . . 14
3.4. Priority-Based Scheduler (SCTP_SS_PRIO) . . . . . . . . . 14
3.5. Fair Capacity Scheduler (SCTP_SS_FC) . . . . . . . . . . 15
3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) . . . . . 15
4. Socket API Considerations . . . . . . . . . . . . . . . . . . 15
4.1. Exposure of the Stream Sequence Number (SSN) . . . . . . 15
4.2. SCTP_ASSOC_CHANGE Notification . . . . . . . . . . . . . 16
4.3. Socket Options . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. Enable or Disable the Support of User Message
Interleaving (SCTP_INTERLEAVING_SUPPORTED) . . . . . 16
4.3.2. Get or Set the Stream Scheduler
(SCTP_STREAM_SCHEDULER) . . . . . . . . . . . . . . . 17
4.3.3. Get or Set the Stream Scheduler Parameter
(SCTP_STREAM_SCHEDULER_VALUE) . . . . . . . . . . . . 18
4.4. Explicit EOR Marking . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
5.1. I-DATA Chunk . . . . . . . . . . . . . . . . . . . . . . 19
5.2. I-FORWARD-TSN Chunk . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
2. User Message Interleaving . . . . . . . . . . . . . . . . . . 6
2.1. The I-DATA Chunk Supporting User Message Interleaving . . 7
2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Negotiation . . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Sender-Side Considerations . . . . . . . . . . . . . 10
2.2.3. Receiver-Side Considerations . . . . . . . . . . . . 11
2.3. Interaction with Other SCTP Extensions . . . . . . . . . 11
2.3.1. SCTP Partial Reliability Extension . . . . . . . . . 11
2.3.2. SCTP Stream Reconfiguration Extension . . . . . . . . 13
3. Stream Schedulers . . . . . . . . . . . . . . . . . . . . . . 14
3.1. First-Come, First-Served Scheduler (SCTP_SS_FCFS) . . . . 14
3.2. Round-Robin Scheduler (SCTP_SS_RR) . . . . . . . . . . . 14
3.3. Round-Robin Scheduler per Packet (SCTP_SS_RR_PKT) . . . . 14
3.4. Priority-Based Scheduler (SCTP_SS_PRIO) . . . . . . . . . 14
3.5. Fair Capacity Scheduler (SCTP_SS_FC) . . . . . . . . . . 15
3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) . . . . . 15
4. Socket API Considerations . . . . . . . . . . . . . . . . . . 15
4.1. Exposure of the Stream Sequence Number (SSN) . . . . . . 15
4.2. SCTP_ASSOC_CHANGE Notification . . . . . . . . . . . . . 16
4.3. Socket Options . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. Enable or Disable the Support of User Message
Interleaving (SCTP_INTERLEAVING_SUPPORTED) . . . . . 16
4.3.2. Get or Set the Stream Scheduler
(SCTP_STREAM_SCHEDULER) . . . . . . . . . . . . . . . 17
4.3.3. Get or Set the Stream Scheduler Parameter
(SCTP_STREAM_SCHEDULER_VALUE) . . . . . . . . . . . . 18
4.4. Explicit EOR Marking . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
5.1. I-DATA Chunk . . . . . . . . . . . . . . . . . . . . . . 19
5.2. I-FORWARD-TSN Chunk . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
When SCTP [RFC4960] was initially designed, it was mainly envisioned for the transport of small signaling messages. Late in the design stage, it was decided to add support for fragmentation and reassembly of larger messages with the thought that someday signaling messages in the style of Session Initiation Protocol (SIP) [RFC3261] may also need to use SCTP, and a message that is a single Maximum Transmission Unit (MTU) would be too small. Unfortunately this design decision, though valid at the time, did not account for other applications that might send large messages over SCTP. The sending of such large messages over SCTP, as specified in [RFC4960], can result in a form of sender-side head-of-line blocking (e.g., when the transmission of a message is blocked from transmission because the sender has started the transmission of another, possibly large, message). This head-of-line blocking is caused by the use of the Transmission Sequence Number (TSN) for three different purposes:
当SCTP[RFC4960]最初设计时，它主要用于传输小型信令消息。在设计阶段后期，决定增加对更大消息的分段和重新组装的支持，考虑到有一天会话启动协议（SIP）[RFC3261]样式的信令消息可能也需要使用SCTP，并且作为单个最大传输单元（MTU）的消息将太小。不幸的是，这个设计决策虽然在当时是有效的，但没有考虑到其他可能通过SCTP发送大型消息的应用程序。按照[RFC4960]中的规定，通过SCTP发送如此大的消息可能会导致发送方端线路阻塞（例如，当一条消息的传输因发送方已开始传输另一条可能较大的消息而被阻止传输时）。这种线路头阻塞是由于将传输序列号（TSN）用于三种不同目的而造成的：
1. As an identifier for DATA chunks to provide a reliable transfer.
1. 作为数据块的标识符，以提供可靠的传输。
2. As an identifier for the sequence of fragments to allow reassembly.
2. 作为允许重新组装的片段序列的标识符。
3. As a sequence number allowing up to 2**16 - 1 Stream Sequence Numbers (SSNs) outstanding.
3. 作为一个序列号，最多允许2**16-1个流序列号（SSN）未完成。
The protocol requires all fragments of a user message to have consecutive TSNs. This document allows an SCTP sender to interleave different user messages.
该协议要求用户消息的所有片段都具有连续的TSN。此文档允许SCTP发送方交错不同的用户消息。
This document also defines several stream schedulers for general SCTP associations allowing different relative stream treatments. The stream schedulers may behave differently depending on whether or not user message interleaving has been negotiated for the association.
本文档还为通用SCTP关联定义了几个流调度器，允许不同的相对流处理。流调度器的行为可能不同，这取决于是否已为关联协商用户消息交错。
Figure 1 illustrates the behavior of a round-robin stream scheduler using DATA chunks when three streams with the Stream Identifiers (SIDs) 0, 1, and 2 are used. Each queue for SID 0 and SID 2 contains a single user message requiring three chunks. The queue for SID 1 contains three user messages each requiring a single chunk. It is shown how these user messages are encapsulated in chunks using TSN 0 to TSN 8. Please note that the use of such a scheduler implies late
图1说明了当使用三个具有流标识符（SID）0、1和2的流时，使用数据块的循环流调度器的行为。SID 0和SID 2的每个队列都包含一条需要三个数据块的用户消息。SID 1的队列包含三条用户消息，每条消息都需要一个块。本文展示了如何使用TSN 0到TSN 8将这些用户消息封装在块中。请注意，使用这样的调度程序意味着延迟
TSN assignment, but it can be used with an implementation that is compliant with [RFC4960] and that does not support user message interleaving. Late TSN assignment means that the sender generates chunks from user messages and assigns the TSN as late as possible in the process of sending the user messages.
TSN分配，但可与符合[RFC4960]且不支持用户消息交错的实现一起使用。延迟TSN分配意味着发送方从用户消息生成块，并在发送用户消息的过程中尽可能晚地分配TSN。
+---+---+---+
| 0/0 |-+
+---+---+---+ |
| +---+---+---+---+---+---+---+---+---+
+---+---+---+ +->|1/2|1/1|2/0|2/0|2/0|1/0|0/0|0/0|0/0|
|1/2|1/1|1/0|--->|---|---|---|---|---|---|---|---|---|
+---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| +---+---+---+---+---+---+---+---+---+
+---+---+---+ |
| 2/0 |-+
+---+---+---+
+-------+
+-------+ |SID/SSN|
|SID/SSN| |-------|
+-------+ | TSN |
+-------+
+---+---+---+
| 0/0 |-+
+---+---+---+ |
| +---+---+---+---+---+---+---+---+---+
+---+---+---+ +->|1/2|1/1|2/0|2/0|2/0|1/0|0/0|0/0|0/0|
|1/2|1/1|1/0|--->|---|---|---|---|---|---|---|---|---|
+---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| +---+---+---+---+---+---+---+---+---+
+---+---+---+ |
| 2/0 |-+
+---+---+---+
+-------+
+-------+ |SID/SSN|
|SID/SSN| |-------|
+-------+ | TSN |
+-------+
Figure 1: Round-Robin Scheduler without User Message Interleaving
图1：无用户消息交错的循环调度程序
This document describes a new chunk carrying payload data called I-DATA. This chunk incorporates the properties of the current SCTP DATA chunk, all the flags and fields except the Stream Sequence Number (SSN), and also adds two new fields in its chunk header -- the Fragment Sequence Number (FSN) and the Message Identifier (MID). The FSN is only used for reassembling all fragments that have the same MID and the same ordering property. The TSN is only used for the reliable transfer in combination with Selective Acknowledgment (SACK) chunks.
本文档描述了一个新的块，它承载名为I-data的有效负载数据。此块包含当前SCTP数据块的属性、除流序列号（SSN）之外的所有标志和字段，并在其块头中添加两个新字段——片段序列号（FSN）和消息标识符（MID）。FSN仅用于重新组装具有相同MID和相同排序属性的所有片段。TSN仅与选择性确认（SACK）块一起用于可靠传输。
In addition, the MID is also used for ensuring ordered delivery instead of using the stream sequence number (the I-DATA chunk omits an SSN).
此外，MID还用于确保有序交付，而不是使用流序列号（I-DATA区块省略SSN）。
Figure 2 illustrates the behavior of an interleaving round-robin stream scheduler using I-DATA chunks.
图2说明了使用I-DATA块的交错循环流调度器的行为。
+---+---+---+
| 0/0 |-+
+---+---+---+ |
| +-----+-----+-----+-----+-----+-----+-----+-----+-----+
+---+---+---+ +->|2/0/2|1/2/0|0/0/2|2/0/1|1/1/0|0/0/1|2/0/0|1/0/0|0/0/0|
|1/2|1/1|1/0|--->|-----|-----|-----|-----|-----|-----|-----|-----|-----|
+---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| +-----+-----+-----+-----+-----+-----+-----+-----+-----+
+---+---+---+ |
| 2/0 |-+
+---+---+---+
+-----------+
+-------+ |SID/MID/FSN|
|SID/MID| |-----------|
+-------+ | TSN |
+-----------+
+---+---+---+
| 0/0 |-+
+---+---+---+ |
| +-----+-----+-----+-----+-----+-----+-----+-----+-----+
+---+---+---+ +->|2/0/2|1/2/0|0/0/2|2/0/1|1/1/0|0/0/1|2/0/0|1/0/0|0/0/0|
|1/2|1/1|1/0|--->|-----|-----|-----|-----|-----|-----|-----|-----|-----|
+---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| +-----+-----+-----+-----+-----+-----+-----+-----+-----+
+---+---+---+ |
| 2/0 |-+
+---+---+---+
+-----------+
+-------+ |SID/MID/FSN|
|SID/MID| |-----------|
+-------+ | TSN |
+-----------+
Figure 2: Round-Robin Scheduler with User Message Interleaving
图2：具有用户消息交错的循环调度程序
The support of the I-DATA chunk is negotiated during the association setup using the Supported Extensions Parameter, as defined in [RFC5061]. If I-DATA support has been negotiated for an association, I-DATA chunks are used for all user messages. DATA chunks are not permitted when I-DATA support has been negotiated. It should be noted that an SCTP implementation supporting I-DATA chunks needs to allow the coexistence of associations using DATA chunks and associations using I-DATA chunks.
在关联设置期间，使用[RFC5061]中定义的Supported Extensions参数协商I-DATA区块的支持。如果已经为关联协商了I-DATA支持，则I-DATA块将用于所有用户消息。协商I-DATA支持时，不允许使用数据块。应该注意，支持I-DATA块的SCTP实现需要允许使用数据块的关联和使用I-DATA块的关联共存。
In Section 2, this document specifies the user message interleaving by defining the I-DATA chunk, the procedures to use it, and its interactions with other SCTP extensions. Section 3 defines multiple stream schedulers, and Section 4 describes an extension to the socket API for using the mechanism specified in this document.
在第2节中，本文档通过定义I-DATA块、使用过程及其与其他SCTP扩展的交互来指定用户消息交错。第3节定义了多个流调度器，第4节描述了套接字API的扩展，以使用本文档中指定的机制。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The protocol mechanisms described in this document allow the interleaving of user messages sent on different streams. They do not support the interleaving of multiple messages (ordered or unordered) sent on the same stream.
本文档中描述的协议机制允许在不同流上发送的用户消息交错。它们不支持在同一流上发送的多条消息（有序或无序）的交错。
The interleaving of user messages is required for WebRTC data channels, as specified in [DATA-CHAN].
如[data-CHAN]中所述，WebRTC数据通道需要交错用户消息。
An SCTP implementation supporting user message interleaving is REQUIRED to support the coexistence of associations using DATA chunks and associations using I-DATA chunks. If an SCTP implementation supports user message interleaving and the Partial Reliability extension described in [RFC3758] or the Stream Reconfiguration Extension described in [RFC6525], it is REQUIRED to implement the corresponding changes specified in Section 2.3.
需要支持用户消息交织的SCTP实现来支持使用数据块的关联和使用I-DATA块的关联共存。如果SCTP实现支持[RFC3758]中描述的用户消息交织和部分可靠性扩展或[RFC6525]中描述的流重新配置扩展，则需要实现第2.3节中规定的相应更改。
The following Figure 3 shows the new I-DATA chunk allowing user message interleaving.
下图3显示了允许用户消息交错的新I-DATA块。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 64 | Res |I|U|B|E| Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier / Fragment Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 64 | Res |I|U|B|E| Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier / Fragment Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: I-DATA Chunk Format
图3:I-DATA区块格式
The only differences between the I-DATA chunk in Figure 3 and the DATA chunk defined in [RFC4960] and [RFC7053] are the addition of the new Message Identifier (MID) and the new Fragment Sequence Number (FSN) and the removal of the Stream Sequence Number (SSN). The Payload Protocol Identifier (PPID), which is already defined for DATA chunks in [RFC4960], and the new FSN are stored at the same location of the packet using the B bit to determine which value is stored at the location. The length of the I-DATA chunk header is 20 bytes, which is 4 bytes more than the length of the DATA chunk header defined in [RFC4960] and [RFC7053].
图3中的I-DATA区块与[RFC4960]和[RFC7053]中定义的数据区块之间的唯一区别在于添加了新的消息标识符（MID）和新的片段序列号（FSN）以及删除了流序列号（SSN）。有效负载协议标识符（PPID）（已为[RFC4960]中的数据块定义）和新FSN使用B位存储在数据包的同一位置，以确定在该位置存储的值。I数据块头的长度为20字节，比[RFC4960]和[RFC7053]中定义的数据块头的长度多4字节。
The old fields are:
旧字段为：
Res: 4 bits These bits are reserved. They MUST be set to 0 by the sender and MUST be ignored by the receiver.
Res:4位这些位是保留的。发送方必须将它们设置为0，接收方必须忽略它们。
I bit: 1 bit The (I)mmediate Bit, if set, indicates that the receiver SHOULD NOT delay the sending of the corresponding SACK chunk. Same as the I bit for DATA chunks, as specified in [RFC7053].
I位：1位（I）mmediate位，如果设置，则表示接收器不应延迟相应SACK块的发送。与[RFC7053]中指定的数据块的I位相同。
U bit: 1 bit The (U)nordered bit, if set, indicates the user message is unordered. Same as the U bit for DATA chunks, as specified in [RFC4960].
U位：1位（U）未排序位，如果设置，则表示用户消息未排序。与[RFC4960]中指定的数据块的U位相同。
B bit: 1 bit The (B)eginning fragment bit, if set, indicates the first fragment of a user message. Same as the B bit for DATA chunks, as specified in [RFC4960].
B位：1位（B）开始片段位，如果设置，则表示用户消息的第一个片段。与[RFC4960]中指定的数据块的B位相同。
E bit: 1 bit The (E)nding fragment bit, if set, indicates the last fragment of a user message. Same as the E bit for DATA chunks, as specified in [RFC4960].
E位：1位（E）nding片段位，如果设置，则表示用户消息的最后一个片段。与[RFC4960]中指定的数据块的E位相同。
Length: 16 bits (unsigned integer) This field indicates the length in bytes of the DATA chunk from the beginning of the Type field to the end of the User Data field, excluding any padding. Similar to the Length for DATA chunks, as specified in [RFC4960].
长度：16位（无符号整数）此字段表示数据块从类型字段开始到用户数据字段结束的长度（字节），不包括任何填充。类似于[RFC4960]中指定的数据块的长度。
TSN: 32 bits (unsigned integer) This value represents the TSN for this I-DATA chunk. Same as the TSN for DATA chunks, as specified in [RFC4960].
TSN:32位（无符号整数）此值表示此I数据块的TSN。与[RFC4960]中指定的数据块的TSN相同。
Stream Identifier: 16 bits (unsigned integer) Identifies the stream to which the user data belongs. Same as the Stream Identifier for DATA chunks, as specified in [RFC4960].
流标识符：16位（无符号整数）标识用户数据所属的流。与[RFC4960]中指定的数据块的流标识符相同。
The new fields are:
新字段包括：
Reserved: 16 bits (unsigned integer) This field is reserved. It MUST be set to 0 by the sender and MUST be ignored by the receiver.
保留：16位（无符号整数）此字段为保留字段。发送方必须将其设置为0，接收方必须将其忽略。
Message Identifier (MID): 32 bits (unsigned integer) The MID is the same for all fragments of a user message; it is used to determine which fragments (enumerated by the FSN) belong to the same user message. For ordered user messages, the MID is also used by the SCTP receiver to deliver the user messages in the correct order to the upper layer (similar to the SSN of the DATA chunk defined in [RFC4960]). The sender uses two counters for each outgoing stream: one for ordered messages and one for unordered messages. All of these counters are independent and initially 0. They are incremented by 1 for each user message. Please note that the serial number arithmetic defined in [RFC1982] using SERIAL_BITS = 32 applies. Therefore, the sender MUST NOT have more than 2**31 - 1 ordered messages for each outgoing stream in flight and MUST NOT have more than 2**31 - 1 unordered messages for each outgoing stream in flight. A message is considered in flight if at least one of its I-DATA chunks is not acknowledged in a way that cannot be reneged (i.e., not acknowledged by the cumulative TSN Ack). Please note that the MID is in "network byte order", a.k.a. Big Endian.
消息标识符（MID）：32位（无符号整数）用户消息的所有片段的MID都相同；它用于确定哪些片段（由FSN枚举）属于同一用户消息。对于有序用户消息，SCTP接收器还使用MID将用户消息以正确的顺序传递到上层（类似于[RFC4960]中定义的数据块的SSN）。发送方对每个传出流使用两个计数器：一个用于有序消息，另一个用于无序消息。所有这些计数器都是独立的，最初为0。对于每个用户消息，它们将递增1。请注意，[RFC1982]中使用串行位=32定义的序列号算法适用。因此，对于飞行中的每个传出流，发送方不得有超过2**31-1条有序消息，对于飞行中的每个传出流，发送方不得有超过2**31-1条无序消息。如果消息中至少有一个I-DATA块未以无法拒绝的方式得到确认（即，累积TSN Ack未确认），则消息被视为正在传输中。请注意，MID是“网络字节顺序”，也称为Big-Endian。
Payload Protocol Identifier (PPID) / Fragment Sequence Number (FSN): 32 bits (unsigned integer) If the B bit is set, this field contains the PPID of the user message. Note that in this case, this field is not touched by an SCTP implementation; therefore, its byte order is not necessarily in network byte order. The upper layer is responsible for any byte order conversions to this field, similar to the PPID of DATA chunks. In this case, the FSN is implicitly considered to be 0. If the B bit is not set, this field contains the FSN. The FSN is used to enumerate all fragments of a single user message, starting from 0 and incremented by 1. The last fragment of a message MUST have the E bit set. Note that the FSN MAY wrap completely multiple times, thus allowing arbitrarily large user messages. For the FSN, the serial number arithmetic defined in [RFC1982] applies with SERIAL_BITS = 32. Therefore, a sender MUST NOT have more than 2**31 - 1 fragments of a single user message in flight. A fragment is considered in flight if it is not acknowledged in a way that cannot be reneged. Please note that the FSN is in "network byte order", a.k.a. Big Endian.
有效负载协议标识符（PPID）/片段序列号（FSN）：32位（无符号整数）。如果设置了B位，则此字段包含用户消息的PPID。注意，在这种情况下，SCTP实现不会触及该字段；因此，其字节顺序不一定是网络字节顺序。上层负责到该字段的任何字节顺序转换，类似于数据块的PPID。在这种情况下，FSN被隐式地认为是0。如果未设置B位，则此字段包含FSN。FSN用于枚举单个用户消息的所有片段，从0开始，递增1。消息的最后一个片段必须设置E位。注意，FSN可以完全包装多次，从而允许任意大的用户消息。对于FSN，[RFC1982]中定义的序列号算法适用于串行位=32。因此，发送方在传输中的单个用户消息片段不得超过2**31-1。如果未以不可否认的方式确认碎片，则认为碎片处于飞行状态。请注意，FSN是“网络字节顺序”，也称为Big-Endian。
This subsection describes how the support of the I-DATA chunk is negotiated and how the I-DATA chunk is used by the sender and receiver.
本小节描述如何协商对I-DATA块的支持，以及发送方和接收方如何使用I-DATA块。
The handling of the I bit for the I-DATA chunk corresponds to the handling of the I bit for the DATA chunk described in [RFC7053].
I数据块的I位处理对应于[RFC7053]中描述的数据块的I位处理。
An SCTP endpoint indicates user message interleaving support by listing the I-DATA chunk within the Supported Extensions Parameter, as defined in [RFC5061]. User message interleaving has been negotiated for an association if both endpoints have indicated I-DATA support.
SCTP端点通过在[RFC5061]中定义的Supported Extensions参数中列出I-DATA块来指示用户消息交错支持。如果两个端点都表示支持I-DATA，则已为关联协商用户消息交错。
If user message interleaving support has been negotiated for an association, I-DATA chunks MUST be used for all user messages and DATA chunks MUST NOT be used. If user message interleaving support has not been negotiated for an association, DATA chunks MUST be used for all user messages and I-DATA chunks MUST NOT be used.
如果为关联协商了用户消息交错支持，则所有用户消息都必须使用I-DATA块，并且不能使用数据块。如果尚未为关联协商用户消息交错支持，则必须对所有用户消息使用数据块，并且不得使用I-DATA块。
An endpoint implementing the socket API specified in [RFC6458] MUST NOT indicate user message interleaving support unless the user has requested its use (e.g., via the socket API; see Section 4.3). This constraint is made since the usage of this chunk requires that the application is capable of handling interleaved messages upon reception within an association. This is not the default choice within the socket API (see the SCTP_FRAGMENT_INTERLEAVE socket option in Section 8.1.20 of [RFC6458]); thus, the user MUST indicate to the SCTP implementation its support for receiving completely interleaved messages.
实现[RFC6458]中规定的套接字API的端点不得表示用户消息交错支持，除非用户已请求使用（例如，通过套接字API；参见第4.3节）。由于使用此区块要求应用程序能够在关联内接收时处理交错消息，因此产生了此约束。这不是套接字API中的默认选项（请参阅[RFC6458]第8.1.20节中的SCTP_片段_交错套接字选项）；因此，用户必须向SCTP实现指示其对接收完全交织消息的支持。
Note that stacks that do not implement [RFC6458] may use other methods to indicate interleaved message support and thus indicate the support of user message interleaving. The crucial point is that the SCTP stack MUST know that the application can handle interleaved messages before indicating the I-DATA support.
注意，不实现[RFC6458]的堆栈可以使用其他方法来指示交错消息支持，从而指示用户消息交错的支持。关键的一点是，SCTP堆栈必须知道，在指示I-DATA支持之前，应用程序可以处理交错消息。
The sender-side usage of the I-DATA chunk is quite simple. Instead of using the TSN for fragmentation purposes, the sender uses the new FSN field to indicate which fragment number is being sent. The first fragment MUST have the B bit set. The last fragment MUST have the E bit set. All other fragments MUST NOT have the B or E bit set. All other properties of the existing SCTP DATA chunk also apply to the I-DATA chunk, i.e., congestion control as well as receiver window conditions MUST be observed, as defined in [RFC4960].
I-DATA块的发送方端用法非常简单。发送方使用新的FSN字段来指示正在发送的片段号，而不是将TSN用于碎片目的。第一个片段必须设置B位。最后一个片段必须设置E位。所有其他片段不得设置B或E位。现有SCTP数据块的所有其他属性也适用于I数据块，即必须遵守[RFC4960]中定义的拥塞控制和接收器窗口条件。
Note that the usage of this chunk implies the late assignment of the actual TSN to any chunk being sent. Each I-DATA chunk uses a single TSN. This way messages from other streams may be interleaved with the fragmented message. Please note that this is the only form of interleaving support. For example, it is not possible to interleave multiple ordered or unordered user messages from the same stream.
请注意，此区块的使用意味着将实际TSN延迟分配给正在发送的任何区块。每个I-DATA块使用一个TSN。这样，来自其他流的消息可以与分段消息交错。请注意，这是交错支持的唯一形式。例如，不可能交错来自同一流的多个有序或无序用户消息。
The sender MUST NOT process (move user data into I-DATA chunks and assign a TSN to it) more than one user message in any given stream at any time. At any time, a sender MAY process multiple user messages, each of them on different streams.
发送方在任何时候都不得在任何给定流中处理（将用户数据移动到I-data块中并为其分配TSN）多个用户消息。在任何时候，发送方都可以处理多个用户消息，每个消息都在不同的流上。
The sender MUST assign TSNs to I-DATA chunks in a way that the receiver can make progress. One way to achieve this is to assign a higher TSN to the later fragments of a user message and send out the I-DATA chunks such that the TSNs are in sequence.
发送方必须以接收方能够取得进展的方式将TSN分配给I-DATA块。实现这一点的一种方法是将更高的TSN分配给用户消息的后续片段，并发送I数据块，以便TSN按顺序排列。
Upon reception of an SCTP packet containing an I-DATA chunk whose user message needs to be reassembled, the receiver MUST first use the SID to identify the stream, consider the U bit to determine if it is part of an ordered or unordered message, find the user message identified by the MID, and use the FSN for reassembly of the message and not the TSN. The receiver MUST NOT make any assumption about the TSN assignments of the sender. Note that a non-fragmented message is indicated by the fact that both the E and B bits are set. A message (either ordered or unordered) whose E and B bits are not both set may be identified as being fragmented.
在接收包含需要重新组装用户信息的I数据块的SCTP分组时，接收方必须首先使用SID来识别流，考虑U比特来确定它是有序消息还是无序消息的一部分，找到由MID标识的用户消息，并使用FSN重新组装消息，而不是TSN。接收方不得对发送方的TSN分配做出任何假设。注意，非分段消息由E位和B位都已设置的事实表示。E位和B位未同时设置的消息（有序或无序）可能被标识为分段消息。
If I-DATA support has been negotiated for an association, the reception of a DATA chunk is a violation of the above rules and therefore the receiver of the DATA chunk MUST abort the association by sending an ABORT chunk. The ABORT chunk MAY include the 'Protocol Violation' error cause. The same applies if I-DATA support has not been negotiated for an association and an I-DATA chunk is received.
如果已为关联协商I-DATA支持，则数据块的接收违反上述规则，因此数据块的接收方必须通过发送中止块中止关联。中止区块可能包括“协议冲突”错误原因。如果尚未为关联协商I-DATA支持，并且收到I-DATA区块，则同样适用。
The usage of the I-DATA chunk might interfere with other SCTP extensions. Future SCTP extensions MUST describe if and how they interfere with the usage of I-DATA chunks. For the SCTP extensions already defined when this document was published, the details are given in the following subsections.
I-DATA块的使用可能会干扰其他SCTP扩展。未来的SCTP扩展必须描述它们是否以及如何干扰I-DATA块的使用。对于本文档发布时已经定义的SCTP扩展，以下小节给出了详细信息。
When the SCTP extension defined in [RFC3758] is used in combination with the user message interleaving extension, the new I-FORWARD-TSN chunk MUST be used instead of the FORWARD-TSN chunk. The difference between the FORWARD-TSN and the I-FORWARD-TSN chunk is that the 16-bit Stream Sequence Number (SSN) has been replaced by the 32-bit Message Identifier (MID), and the largest skipped MID can also be
当[RFC3758]中定义的SCTP扩展与用户消息交织扩展结合使用时，必须使用新的I-FORWARD-TSN块而不是FORWARD-TSN块。FORWARD-TSN和I-FORWARD-TSN区块之间的区别在于，16位流序列号（SSN）已被32位消息标识符（MID）替换，并且还可以删除最大的跳过MID
provided for unordered messages. Therefore, the principle applied to ordered messages when using FORWARD-TSN chunks is applied to ordered and unordered messages when using I-FORWARD-TSN chunks.
为无序消息提供。因此，使用FORWARD-TSN区块时适用于有序消息的原则适用于使用I-FORWARD-TSN区块时的有序和无序消息。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 194 | Flags = 0x00 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Cumulative TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | Reserved |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | Reserved |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 194 | Flags = 0x00 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Cumulative TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | Reserved |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | Reserved |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: I-FORWARD-TSN Chunk Format
图4:I-FORWARD-TSN块格式
The old fields are:
旧字段为：
Flags: 8 bits (unsigned integer) These bits are reserved. They MUST be set to 0 by the sender and MUST be ignored by the receiver. Same as the Flags for FORWARD TSN chunks, as specified in [RFC3758].
标志：8位（无符号整数）这些位是保留的。发送方必须将它们设置为0，接收方必须忽略它们。与[RFC3758]中指定的前向TSN块的标志相同。
Length: 16 bits (unsigned integer) This field holds the length of the chunk. Similar to the Length for FORWARD TSN chunks, as specified in [RFC3758].
长度：16位（无符号整数）此字段保存块的长度。类似于[RFC3758]中规定的前向TSN块的长度。
New Cumulative TSN: 32 bits (unsigned integer) This indicates the New Cumulative TSN to the data receiver. Same as the New Cumulative TSN for FORWARD TSN chunks, as specified in [RFC3758].
新累积TSN:32位（无符号整数）这表示数据接收器的新累积TSN。与[RFC3758]中指定的前向TSN块的新累积TSN相同。
The new fields are:
新字段包括：
Stream Identifier (SID): 16 bits (unsigned integer) This field holds the stream number this entry refers to.
流标识符（SID）：16位（无符号整数），此字段保存此项所指的流编号。
Reserved: 15 bits This field is reserved. It MUST be set to 0 by the sender and MUST be ignored by the receiver.
保留：15位此字段保留。发送方必须将其设置为0，接收方必须将其忽略。
U bit: 1 bit The U bit specifies if the Message Identifier of this entry refers to unordered messages (U bit is set) or ordered messages (U bit is not set).
U位：1位U位指定此条目的消息标识符是指无序消息（设置了U位）还是有序消息（未设置U位）。
Message Identifier (MID): 32 bits (unsigned integer) This field holds the largest Message Identifier for ordered or unordered messages indicated by the U bit that was skipped for the stream specified by the Stream Identifier. For ordered messages, this is similar to the FORWARD-TSN chunk, just replacing the 16-bit SSN by the 32-bit MID.
消息标识符（MID）：32位（无符号整数）此字段保存由U位指示的有序或无序消息的最大消息标识符，U位是由流标识符指定的流跳过的。对于有序消息，这类似于FORWARD-TSN块，只是将16位SSN替换为32位MID。
Support for the I-FORWARD-TSN chunk is negotiated during the SCTP association setup via the Supported Extensions Parameter, as defined in [RFC5061]. The partial reliability extension is negotiated and can be used in combination with user message interleaving only if both endpoints indicated their support of user message interleaving and the I-FORWARD-TSN chunk.
在SCTP关联设置期间，通过[RFC5061]中定义的Supported Extensions参数协商对I-FORWARD-TSN区块的支持。仅当两个端点都表示支持用户消息交织和I-FORWARD-TSN块时，才协商部分可靠性扩展，并可与用户消息交织结合使用。
The FORWARD-TSN chunk MUST be used in combination with the DATA chunk and MUST NOT be used in combination with the I-DATA chunk. The I-FORWARD-TSN chunk MUST be used in combination with the I-DATA chunk and MUST NOT be used in combination with the DATA chunk.
FORWARD-TSN区块必须与数据区块结合使用，不得与I-DATA区块结合使用。I-FORWARD-TSN区块必须与I-DATA区块结合使用，不得与数据区块结合使用。
If I-FORWARD-TSN support has been negotiated for an association, the reception of a FORWARD-TSN chunk is a violation of the above rules and therefore the receiver of the FORWARD-TSN chunk MUST abort the association by sending an ABORT chunk. The ABORT chunk MAY include the 'Protocol Violation' error cause. The same applies if I-FORWARD-TSN support has not been negotiated for an association and a FORWARD-TSN chunk is received.
如果已为关联协商I-FORWARD-TSN支持，则接收FORWARD-TSN区块违反上述规则，因此FORWARD-TSN区块的接收方必须通过发送中止区块中止关联。中止区块可能包括“协议冲突”错误原因。如果尚未为关联协商I-FORWARD-TSN支持，并且收到FORWARD-TSN区块，则同样适用。
When an association resets the SSN using the SCTP extension defined in [RFC6525], the two counters (one for the ordered messages, one for the unordered messages) used for the MIDs MUST be reset to 0.
当关联使用[RFC6525]中定义的SCTP扩展重置SSN时，用于MID的两个计数器（一个用于有序消息，一个用于无序消息）必须重置为0。
Since most schedulers, especially all schedulers supporting user message interleaving, require late TSN assignment, it should be noted that the implementation of [RFC6525] needs to handle this.
由于大多数调度器，尤其是支持用户消息交织的所有调度器，需要延迟TSN分配，因此应该注意的是，[RFC6525]的实现需要处理这个问题。
This section defines several stream schedulers. The stream schedulers may behave differently depending on whether or not user message interleaving has been negotiated for the association. An implementation MAY implement any subset of them. If the implementation is used for WebRTC data channels, as specified in [DATA-CHAN], it MUST implement the Weighted Fair Queueing Scheduler defined in Section 3.6.
本节定义了几个流调度程序。流调度器的行为可能不同，这取决于是否已为关联协商用户消息交错。一个实现可以实现它们的任何子集。如果按照[data-CHAN]中的规定，实施用于WebRTC数据通道，则必须实施第3.6节中定义的加权公平排队调度器。
The selection of the stream scheduler is done at the sender side. There is no mechanism provided for signaling the stream scheduler being used to the receiver side or even for letting the receiver side influence the selection of the stream scheduler used at the sender side.
流调度程序的选择在发送方完成。没有提供用于向接收方发送正在使用的流调度器的信令的机制，或者甚至不用于让接收方影响在发送方使用的流调度器的选择的机制。
The simple first-come, first-served scheduler of user messages is used. It just passes through the messages in the order in which they have been delivered by the application. No modification of the order is done at all. The usage of user message interleaving does not affect the sending of the chunks, except that I-DATA chunks are used instead of DATA chunks.
使用简单的先到先得的用户消息调度程序。它只是按照应用程序传递消息的顺序传递消息。根本不修改订单。用户消息交错的使用不会影响块的发送，除非使用I-DATA块而不是数据块。
When not interleaving user messages, this scheduler provides a fair scheduling based on the number of user messages by cycling around non-empty stream queues. When interleaving user messages, this scheduler provides a fair scheduling based on the number of I-DATA chunks by cycling around non-empty stream queues.
当不交错用户消息时，此调度器通过在非空流队列中循环，根据用户消息的数量提供公平的调度。当交织用户消息时，该调度器通过在非空流队列中循环，根据I-DATA块的数量提供公平的调度。
This is a round-robin scheduler, which only switches streams when starting to fill a new packet. It bundles only DATA or I-DATA chunks referring to the same stream in a packet. This scheduler minimizes head-of-line blocking when a packet is lost because only a single stream is affected.
这是一个循环调度程序，它仅在开始填充新数据包时切换流。它只绑定数据或I-DATA块，这些块引用数据包中的同一个流。当数据包丢失时，该调度器将行首阻塞最小化，因为只有一个流受到影响。
Scheduling of user messages with strict priorities is used. The priority is configurable per outgoing SCTP stream. Streams having a higher priority will be scheduled first and when multiple streams have the same priority, the scheduling between them is implementation
使用具有严格优先级的用户消息调度。优先级可配置为每个传出SCTP流。具有较高优先级的流将首先被调度，当多个流具有相同优先级时，它们之间的调度将被实现
dependent. When the scheduler interleaves user messages, the sending of large, lower-priority user messages will not delay the sending of higher-priority user messages.
依靠的当调度程序交错用户消息时，发送较大的、低优先级的用户消息不会延迟发送高优先级的用户消息。
A fair capacity distribution between the streams is used. This scheduler considers the lengths of the messages of each stream and schedules them in a specific way to maintain an equal capacity for all streams. The details are implementation dependent. interleaving user messages allows for a better realization of the fair capacity usage.
在流之间使用公平的容量分配。该调度器考虑每个流的消息长度，并以特定的方式对其进行调度，以保持所有流的容量相等。细节取决于实现。交错用户消息允许更好地实现公平容量使用。
A Weighted Fair Queueing scheduler between the streams is used. The weight is configurable per outgoing SCTP stream. This scheduler considers the lengths of the messages of each stream and schedules them in a specific way to use the capacity according to the given weights. If the weight of stream S1 is n times the weight of stream S2, the scheduler should assign to stream S1 n times the capacity it assigns to stream S2. The details are implementation dependent. Interleaving user messages allows for a better realization of the capacity usage according to the given weights.
在流之间使用加权公平排队调度器。每个传出SCTP流的权重是可配置的。该调度器考虑每个流的消息长度，并根据给定的权重以特定的方式对其进行调度以使用容量。如果流S1的权重是流S2权重的n倍，则调度器应将其分配给流S2的容量的n倍分配给流S1。细节取决于实现。交织用户消息允许根据给定的权重更好地实现容量使用。
This scheduler, in combination with user message interleaving, is used for WebRTC data channels, as specified in [DATA-CHAN].
如[data-CHAN]中所述，此调度器与用户消息交错一起用于WebRTC数据通道。
This section describes how the socket API defined in [RFC6458] is extended to allow applications to use the extension described in this document.
本节介绍如何扩展[RFC6458]中定义的套接字API，以允许应用程序使用本文档中描述的扩展。
Please note that this section is informational only.
请注意，本节仅供参考。
The socket API defined in [RFC6458] defines several structures in which the SSN of a received user message is exposed to the application. The list of these structures includes:
[RFC6458]中定义的套接字API定义了几个结构，其中接收到的用户消息的SSN向应用程序公开。这些结构的清单包括：
struct sctp_sndrcvinfo Specified in Section 5.3.2 of [RFC6458] and marked as deprecated.
[RFC6458]第5.3.2节规定的结构sctp_sndrcvinfo，并标记为已弃用。
struct sctp_extrcvinfo Specified in Section 5.3.3 of [RFC6458] and marked as deprecated.
[RFC6458]第5.3.3节中规定的结构sctp_EXTRACVINFO，并标记为已弃用。
struct sctp_rcvinfo Specified in Section 5.3.5 of [RFC6458].
[RFC6458]第5.3.5节中规定的结构sctp_rcvinfo。
If user message interleaving is used, the lower-order 16 bits of the MID are used as the SSN when filling out these structures.
如果使用用户消息交织，则在填充这些结构时，MID的低阶16位用作SSN。
When an SCTP_ASSOC_CHANGE notification (specified in Section 6.1.1 of [RFC6458]) is delivered indicating a sac_state of SCTP_COMM_UP or SCTP_RESTART for an SCTP association where both peers support the I-DATA chunk, SCTP_ASSOC_SUPPORTS_INTERLEAVING should be listed in the sac_info field.
当发送SCTP_ASSOC_变更通知（在[RFC6458]第6.1.1节中规定）时，指示SCTP_通信或SCTP_重启的sac_状态，其中两个对等方都支持I数据块，则应在sac_信息字段中列出SCTP_ASSOC_支持交织。
+-----------------------------+-------------------------+-----+-----+
| Option Name | Data Type | Get | Set |
+-----------------------------+-------------------------+-----+-----+
| SCTP_INTERLEAVING_SUPPORTED | struct sctp_assoc_value | X | X |
| SCTP_STREAM_SCHEDULER | struct sctp_assoc_value | X | X |
| SCTP_STREAM_SCHEDULER_VALUE | struct | X | X |
| | sctp_stream_value | | |
+-----------------------------+-------------------------+-----+-----+
+-----------------------------+-------------------------+-----+-----+
| Option Name | Data Type | Get | Set |
+-----------------------------+-------------------------+-----+-----+
| SCTP_INTERLEAVING_SUPPORTED | struct sctp_assoc_value | X | X |
| SCTP_STREAM_SCHEDULER | struct sctp_assoc_value | X | X |
| SCTP_STREAM_SCHEDULER_VALUE | struct | X | X |
| | sctp_stream_value | | |
+-----------------------------+-------------------------+-----+-----+
4.3.1. Enable or Disable the Support of User Message Interleaving (SCTP_INTERLEAVING_SUPPORTED)
4.3.1. 启用或禁用对用户消息交织的支持（支持SCTP\U交织）
This socket option allows the enabling or disabling of the negotiation of user message interleaving support for future associations. For existing associations, it allows for querying whether or not user message interleaving support was negotiated on a particular association.
此套接字选项允许启用或禁用用户消息交错支持的协商，以支持将来的关联。对于现有关联，它允许查询是否在特定关联上协商用户消息交错支持。
This socket option uses IPPROTO_SCTP as its level and SCTP_INTERLEAVING_SUPPORTED as its name. It can be used with getsockopt() and setsockopt(). The socket option value uses the following structure defined in [RFC6458]:
此套接字选项使用IPPROTO_SCTP作为其级别，使用SCTP_INTERLEAVING_SUPPORTED作为其名称。它可以与getsockopt（）和setsockopt（）一起使用。套接字选项值使用[RFC6458]中定义的以下结构：
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, this parameter indicates upon which association the user is performing an action. The special sctp_assoc_t SCTP_FUTURE_ASSOC can also be used; it is an error to use SCTP_{CURRENT|ALL}_ASSOC in assoc_id.
assoc_id：对于一对一样式的套接字，此参数被忽略。对于一对多样式套接字，此参数指示用户执行操作的关联。也可使用特殊的sctp_assoc_t sctp_FUTURE_assoc；在ASSOC_id中使用SCTP_u{CURRENT | ALL}ASSOC是一个错误。
assoc_value: A non-zero value encodes the enabling of user message interleaving, whereas a value of zero encodes the disabling of user message interleaving.
assoc_值：非零值编码启用用户消息交错，而零值编码禁用用户消息交错。
sctp_opt_info() needs to be extended to support SCTP_INTERLEAVING_SUPPORTED.
需要扩展sctp_opt_info（），以支持支持sctp_交错。
An application using user message interleaving should also set the fragment interleave level to 2 by using the SCTP_FRAGMENT_INTERLEAVE socket option specified in Section 8.1.20 of [RFC6458]. This allows the interleaving of user messages from different streams. Please note that it does not allow the interleaving of user messages (ordered or unordered) on the same stream. Failure to set this option can possibly lead to application deadlock. Some implementations might therefore put some restrictions on setting combinations of these values. Setting the interleaving level to at least 2 before enabling the negotiation of user message interleaving should work on all platforms. Since the default fragment interleave level is not 2, user message interleaving is disabled per default.
使用用户消息交织的应用程序还应使用[RFC6458]第8.1.20节中指定的SCTP_fragment_交织套接字选项，将片段交织级别设置为2。这允许来自不同流的用户消息交错。请注意，它不允许在同一流上交错用户消息（有序或无序）。未能设置此选项可能会导致应用程序死锁。因此，一些实现可能会对设置这些值的组合设置一些限制。在启用用户消息交织协商之前，将交织级别设置为至少2应该适用于所有平台。由于默认的片段交错级别不是2，因此根据默认值禁用用户消息交错。
A stream scheduler can be selected with the SCTP_STREAM_SCHEDULER option for setsockopt(). The struct sctp_assoc_value is used to specify the association for which the scheduler should be changed and the value of the desired algorithm.
可以使用setsockopt（）的SCTP_stream_调度程序选项选择流调度程序。struct sctp_assoc_值用于指定应更改调度程序的关联以及所需算法的值。
The definition of struct sctp_assoc_value is the same as in [RFC6458]:
struct sctp_assoc_value的定义与[RFC6458]中的定义相同：
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
assoc_id: Holds the identifier of the association for which the scheduler should be changed. The special SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter is ignored for one-to-one style sockets.
assoc_id：保存应更改其计划程序的关联的标识符。也可以使用特殊的SCTP{FUTURE | CURRENT | ALL}{u ASSOC。对于一对一样式的套接字，将忽略此参数。
assoc_value: This specifies which scheduler is used. The following constants can be used:
assoc_值：指定使用哪个计划程序。可以使用以下常量：
SCTP_SS_DEFAULT: The default scheduler used by the SCTP implementation. Typical values are SCTP_SS_FCFS or SCTP_SS_RR.
SCTP_SS_DEFAULT：SCTP实现使用的默认调度程序。典型值为SCTP_SS_FCFS或SCTP_SS_RR。
SCTP_SS_FCFS: Use the scheduler specified in Section 3.1.
SCTP_SS_FCFS：使用第3.1节中指定的调度程序。
SCTP_SS_RR: Use the scheduler specified in Section 3.2.
SCTP_SS_RR：使用第3.2节中指定的调度程序。
SCTP_SS_RR_PKT: Use the scheduler specified in Section 3.3.
SCTP_SS_RR_PKT：使用第3.3节中指定的调度程序。
SCTP_SS_PRIO: Use the scheduler specified in Section 3.4. The priority can be assigned with the sctp_stream_value struct. The higher the assigned value, the lower the priority. That is, the default value 0 is the highest priority, and therefore the default scheduling will be used if no priorities have been assigned.
SCTP_SS_PRIO：使用第3.4节中指定的调度程序。优先级可以通过sctp_stream_value结构来分配。分配的值越高，优先级越低。也就是说，默认值0是最高优先级，因此，如果未分配优先级，将使用默认调度。
SCTP_SS_FB: Use the scheduler specified in Section 3.5.
SCTP_SS_FB：使用第3.5节中指定的调度程序。
SCTP_SS_WFQ: Use the scheduler specified in Section 3.6. The weight can be assigned with the sctp_stream_value struct.
SCTP_SS_WFQ：使用第3.6节中指定的调度程序。可以使用sctp_stream_value结构指定权重。
sctp_opt_info() needs to be extended to support SCTP_STREAM_SCHEDULER.
sctp_opt_info（）需要扩展以支持sctp_STREAM_调度程序。
4.3.3. Get or Set the Stream Scheduler Parameter (SCTP_STREAM_SCHEDULER_VALUE)
4.3.3. 获取或设置流计划程序参数（SCTP\u流计划程序\u值）
Some schedulers require additional information to be set for individual streams as shown in the following table:
某些调度程序需要为各个流设置附加信息，如下表所示：
+-----------------+-----------------+
| Name | Per-Stream Info |
+-----------------+-----------------+
| SCTP_SS_DEFAULT | n/a |
| SCTP_SS_FCFS | no |
| SCTP_SS_RR | no |
| SCTP_SS_RR_PKT | no |
| SCTP_SS_PRIO | yes |
| SCTP_SS_FB | no |
| SCTP_SS_WFQ | yes |
+-----------------+-----------------+
+-----------------+-----------------+
| Name | Per-Stream Info |
+-----------------+-----------------+
| SCTP_SS_DEFAULT | n/a |
| SCTP_SS_FCFS | no |
| SCTP_SS_RR | no |
| SCTP_SS_RR_PKT | no |
| SCTP_SS_PRIO | yes |
| SCTP_SS_FB | no |
| SCTP_SS_WFQ | yes |
+-----------------+-----------------+
This is achieved with the SCTP_STREAM_SCHEDULER_VALUE option and the corresponding struct sctp_stream_value. The definition of struct sctp_stream_value is as follows:
这是通过SCTP_STREAM_SCHEDULER_VALUE选项和相应的struct SCTP_STREAM_VALUE实现的。struct sctp_stream_value的定义如下：
struct sctp_stream_value {
sctp_assoc_t assoc_id;
uint16_t stream_id;
uint16_t stream_value;
};
struct sctp_stream_value {
sctp_assoc_t assoc_id;
uint16_t stream_id;
uint16_t stream_value;
};
assoc_id: Holds the identifier of the association for which the scheduler should be changed. The special SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter is ignored for one-to-one style sockets.
assoc_id：保存应更改其计划程序的关联的标识符。也可以使用特殊的SCTP{FUTURE | CURRENT | ALL}{u ASSOC。对于一对一样式的套接字，将忽略此参数。
stream_id: Holds the identifier of the stream for which additional information has to be provided.
stream_id：保存必须为其提供附加信息的流的标识符。
stream_value: The meaning of this field depends on the scheduler specified. It is ignored when the scheduler does not need additional information.
stream_value：此字段的含义取决于指定的调度程序。当计划程序不需要其他信息时，它将被忽略。
sctp_opt_info() needs to be extended to support SCTP_STREAM_SCHEDULER_VALUE.
需要扩展sctp_opt_info（），以支持sctp_STREAM_SCHEDULER_值。
Using explicit End of Record (EOR) marking for an SCTP association supporting user message interleaving allows the user to interleave the sending of user messages on different streams.
使用支持用户消息交织的SCTP关联的显式记录结束（EOR）标记允许用户在不同流上交织用户消息的发送。
Two new chunk types have been assigned by IANA.
IANA分配了两种新的块类型。
IANA has assigned the chunk type for this chunk from the pool of chunks with the upper two bits set to '01'. This appears in the "Chunk Types" registry for SCTP as follows:
IANA已从区块池中为该区块分配区块类型，上部两位设置为“01”。这将出现在SCTP的“块类型”注册表中，如下所示：
+----------+--------------------------------------------+-----------+
| ID Value | Chunk Type | Reference |
+----------+--------------------------------------------+-----------+
| 64 | Payload Data supporting Interleaving | RFC 8260 |
| | (I-DATA) | |
+----------+--------------------------------------------+-----------+
+----------+--------------------------------------------+-----------+
| ID Value | Chunk Type | Reference |
+----------+--------------------------------------------+-----------+
| 64 | Payload Data supporting Interleaving | RFC 8260 |
| | (I-DATA) | |
+----------+--------------------------------------------+-----------+
The registration table (as defined in [RFC6096]) for the chunk flags of this chunk type is initially as follows:
此块类型的块标志的注册表（如[RFC6096]中所定义）最初如下所示：
+------------------+-----------------+-----------+
| Chunk Flag Value | Chunk Flag Name | Reference |
+------------------+-----------------+-----------+
| 0x01 | E bit | RFC 8260 |
| 0x02 | B bit | RFC 8260 |
| 0x04 | U bit | RFC 8260 |
| 0x08 | I bit | RFC 8260 |
| 0x10 | Unassigned | |
| 0x20 | Unassigned | |
| 0x40 | Unassigned | |
| 0x80 | Unassigned | |
+------------------+-----------------+-----------+
+------------------+-----------------+-----------+
| Chunk Flag Value | Chunk Flag Name | Reference |
+------------------+-----------------+-----------+
| 0x01 | E bit | RFC 8260 |
| 0x02 | B bit | RFC 8260 |
| 0x04 | U bit | RFC 8260 |
| 0x08 | I bit | RFC 8260 |
| 0x10 | Unassigned | |
| 0x20 | Unassigned | |
| 0x40 | Unassigned | |
| 0x80 | Unassigned | |
+------------------+-----------------+-----------+
IANA has assigned the chunk type for this chunk from the pool of chunks with the upper two bits set to '11'. This appears in the "Chunk Types" registry for SCTP as follows:
IANA已从区块池中为该区块分配区块类型，上部两位设置为“11”。这将出现在SCTP的“块类型”注册表中，如下所示：
+----------+---------------+-----------+
| ID Value | Chunk Type | Reference |
+----------+---------------+-----------+
| 194 | I-FORWARD-TSN | RFC 8260 |
+----------+---------------+-----------+
+----------+---------------+-----------+
| ID Value | Chunk Type | Reference |
+----------+---------------+-----------+
| 194 | I-FORWARD-TSN | RFC 8260 |
+----------+---------------+-----------+
The registration table (as defined in [RFC6096]) for the chunk flags of this chunk type is initially empty.
此块类型的块标志的注册表（如[RFC6096]中定义）最初为空。
This document does not add any additional security considerations in addition to the ones given in [RFC4960] and [RFC6458].
除[RFC4960]和[RFC6458]中给出的安全注意事项外，本文档未添加任何其他安全注意事项。
It should be noted that the application has to consent that it is willing to do the more complex reassembly support required for user message interleaving. When doing so, an application has to provide a reassembly buffer for each incoming stream. It has to protect itself against these buffers taking too many resources. If user message interleaving is not used, only a single reassembly buffer needs to be provided for each association. But the application has to protect itself for excessive resource usages there too.
应该注意的是，应用程序必须同意它愿意执行用户消息交错所需的更复杂的重组支持。这样做时，应用程序必须为每个传入流提供重新组装缓冲区。它必须保护自己不受这些缓冲区占用太多资源的影响。如果不使用用户消息交错，则只需要为每个关联提供一个重组缓冲区。但应用程序也必须保护自己，以防过度使用资源。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, <https://www.rfc-editor.org/info/rfc1982>.
[RFC1982]Elz，R.和R.Bush，“序列号算术”，RFC 1982，DOI 10.17487/RFC1982，1996年8月<https://www.rfc-editor.org/info/rfc1982>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[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年5月<https://www.rfc-editor.org/info/rfc3758>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 4960，DOI 10.17487/RFC4960，2007年9月<https://www.rfc-editor.org/info/rfc4960>.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/RFC5061, September 2007, <https://www.rfc-editor.org/info/rfc5061>.
[RFC5061]Stewart，R.，Xie，Q.，Tuexen，M.，Maruyama，S.，和M.Kozuka，“流控制传输协议（SCTP）动态地址重新配置”，RFC 5061，DOI 10.17487/RFC5061，2007年9月<https://www.rfc-editor.org/info/rfc5061>.
[RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission Protocol (SCTP) Chunk Flags Registration", RFC 6096, DOI 10.17487/RFC6096, January 2011, <https://www.rfc-editor.org/info/rfc6096>.
[RFC6096]Tuexen，M.和R.Stewart，“流控制传输协议（SCTP）块标志注册”，RFC 6096，DOI 10.17487/RFC6096，2011年1月<https://www.rfc-editor.org/info/rfc6096>.
[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, DOI 10.17487/RFC6525, February 2012, <https://www.rfc-editor.org/info/rfc6525>.
[RFC6525]Stewart，R.，Tuexen，M.，和P.Lei，“流控制传输协议（SCTP）流重新配置”，RFC 6525，DOI 10.17487/RFC6525，2012年2月<https://www.rfc-editor.org/info/rfc6525>.
[RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, <https://www.rfc-editor.org/info/rfc7053>.
[RFC7053]Tuexen，M.，Ruengeler，I.，和R.Stewart，“流控制传输协议的SACK-立即扩展”，RFC 7053，DOI 10.17487/RFC7053，2013年11月<https://www.rfc-editor.org/info/rfc7053>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[DATA-CHAN] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", Work in Progress, draft-ietf-rtcweb-data-channel-13, January 2015.
[DATA-CHAN]Jesup，R.，Loreto，S.，和M.Tuexen，“WebRTC数据通道”，正在进行的工作，草稿-ietf-rtcweb-DATA-channel-13，2015年1月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<https://www.rfc-editor.org/info/rfc3261>.
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/RFC6458, December 2011, <https://www.rfc-editor.org/info/rfc6458>.
[RFC6458]Stewart，R.，Tuexen，M.，Poon，K.，Lei，P.，和V.Yasevich，“流控制传输协议（SCTP）的套接字API扩展”，RFC 6458，DOI 10.17487/RFC6458，2011年12月<https://www.rfc-editor.org/info/rfc6458>.
Acknowledgments
致谢
The authors wish to thank Benoit Claise, Julian Cordes, Spencer Dawkins, Gorry Fairhurst, Lennart Grahl, Christer Holmberg, Mirja Kuehlewind, Marcelo Ricardo Leitner, Karen E. Egede Nielsen, Maksim Proshin, Eric Rescorla, Irene Ruengeler, Felix Weinrank, Michael Welzl, Magnus Westerlund, and Lixia Zhang for their invaluable comments.
作者希望感谢贝努伊特·克莱斯、朱利安·科尔德斯、斯宾塞·道金斯、戈里·费尔赫斯特、伦纳德·格拉尔、克里斯特·霍姆伯格、米尔贾·库勒温德、马塞洛·里卡多·莱特纳、卡伦·E·埃格德·尼尔森、马克西姆·普罗申、埃里克·雷索拉、艾琳·朗格勒、费利克斯·温兰克、迈克尔·韦尔兹尔、马格纳斯·韦斯特伦德和张丽霞的宝贵评论。
This work has received funding from the European Union's Horizon 2020 research and innovation program under grant agreement No. 644334 (NEAT). The views expressed are solely those of the authors.
这项工作已获得欧盟地平线2020研究和创新计划的资助，资助协议编号为644334（NEAT）。所表达的观点仅为作者的观点。
Authors' Addresses
作者地址
Randall R. Stewart Netflix, Inc. Chapin, SC 29036 United States of America
Randall R.Stewart Netflix，Inc.Chapin，SC 29036美利坚合众国
Email: randall@lakerest.net
Email: randall@lakerest.net
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 48565 Steinfurt Germany
米迦勒TuxEN明斯特应用科学大学StugWaldStasSE 39 48565斯坦福特德国
Email: tuexen@fh-muenster.de
Email: tuexen@fh-muenster.de
Salvatore Loreto Ericsson Torshamnsgatan 21 164 80 Stockholm Sweden
萨尔瓦托雷·洛雷托·爱立信托尔沙姆斯加坦21 164 80瑞典斯德哥尔摩
Email: Salvatore.Loreto@ericsson.com
Email: Salvatore.Loreto@ericsson.com
Robin Seggelmann Metafinanz Informationssysteme GmbH Leopoldstrasse 146 80804 Muenchen Germany
Robin Seggelmann Metafinanz Information System GmbH Leopoldstrasse 146 80804德国慕尼黑
Email: rfc@robin-seggelmann.com
Email: rfc@robin-seggelmann.com