Internet Engineering Task Force (IETF) M. Scharf
Request for Comments: 6897 Alcatel-Lucent Bell Labs
Category: Informational A. Ford
ISSN: 2070-1721 Cisco
March 2013
Internet Engineering Task Force (IETF) M. Scharf
Request for Comments: 6897 Alcatel-Lucent Bell Labs
Category: Informational A. Ford
ISSN: 2070-1721 Cisco
March 2013
Multipath TCP (MPTCP) Application Interface Considerations
多路径TCP（MPTCP）应用程序接口注意事项
Abstract
摘要
Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface that is a simple extension of TCP's interface for MPTCP-aware applications.
多路径TCP（MPTCP）增加了在常规TCP会话中使用多条路径的能力。尽管它被设计为与应用程序完全向后兼容，但数据传输与常规TCP不同，并且应用程序可能希望利用几个额外的自由度。本文档总结了MPTCP可能对应用程序产生的影响，如性能变化。此外，还讨论了MPTCP与非MPTCP感知应用程序的兼容性问题。最后，本文描述了一个基本的应用程序接口，它是TCP接口的简单扩展，用于MPTCP感知应用程序。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6897.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6897.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Comparison of MPTCP and Regular TCP .............................5
3.1. Effect on Performance ......................................5
3.1.1. Throughput ..........................................5
3.1.2. Delay ...............................................6
3.1.3. Resilience ..........................................7
3.2. Potential Problems .........................................8
3.2.1. Impact of Middleboxes ...............................8
3.2.2. Dealing with Multiple Addresses inside
Applications ........................................9
3.2.3. Security Implications ..............................10
4. Operation of MPTCP with Legacy Applications ....................10
4.1. Overview of the MPTCP Network Stack .......................10
4.2. Address Issues ............................................11
4.2.1. Specification of Addresses by Applications .........11
4.2.2. Querying of Addresses by Applications ..............12
4.3. MPTCP Connection Management ...............................13
4.3.1. Reaction to Close Call by Application ..............13
4.3.2. Other Connection Management Functions ..............13
4.4. Socket Option Issues ......................................13
4.4.1. General Guideline ..................................13
4.4.2. Disabling of the Nagle Algorithm ...................13
4.4.3. Buffer Sizing ......................................14
4.4.4. Other Socket Options ...............................14
4.5. Default Enabling of MPTCP .................................14
4.6. Summary of Advice to Application Developers ...............15
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Comparison of MPTCP and Regular TCP .............................5
3.1. Effect on Performance ......................................5
3.1.1. Throughput ..........................................5
3.1.2. Delay ...............................................6
3.1.3. Resilience ..........................................7
3.2. Potential Problems .........................................8
3.2.1. Impact of Middleboxes ...............................8
3.2.2. Dealing with Multiple Addresses inside
Applications ........................................9
3.2.3. Security Implications ..............................10
4. Operation of MPTCP with Legacy Applications ....................10
4.1. Overview of the MPTCP Network Stack .......................10
4.2. Address Issues ............................................11
4.2.1. Specification of Addresses by Applications .........11
4.2.2. Querying of Addresses by Applications ..............12
4.3. MPTCP Connection Management ...............................13
4.3.1. Reaction to Close Call by Application ..............13
4.3.2. Other Connection Management Functions ..............13
4.4. Socket Option Issues ......................................13
4.4.1. General Guideline ..................................13
4.4.2. Disabling of the Nagle Algorithm ...................13
4.4.3. Buffer Sizing ......................................14
4.4.4. Other Socket Options ...............................14
4.5. Default Enabling of MPTCP .................................14
4.6. Summary of Advice to Application Developers ...............15
5. Basic API for MPTCP-Aware Applications .........................15
5.1. Design Considerations .....................................15
5.2. Requirements on the Basic MPTCP API .......................16
5.3. Sockets Interface Extensions by the Basic MPTCP API .......17
5.3.1. Overview ...........................................17
5.3.2. Enabling and Disabling of MPTCP ....................19
5.3.3. Binding MPTCP to Specified Addresses ...............19
5.3.4. Querying the MPTCP Subflow Addresses ...............20
5.3.5. Getting a Unique Connection Identifier .............20
6. Other Compatibility Issues .....................................21
6.1. Usage of TLS over MPTCP ...................................21
6.2. Usage of the SCTP Sockets API .............................21
6.3. Incompatibilities with Other Multihoming Solutions ........21
6.4. Interactions with DNS .....................................22
7. Security Considerations ........................................22
8. Conclusion .....................................................23
9. Acknowledgments ................................................23
10. References ....................................................24
10.1. Normative References .....................................24
10.2. Informative References ...................................24
Appendix A. Requirements on a Future Advanced MPTCP API ...........26
A.1. Design Considerations ......................................26
A.2. MPTCP Usage Scenarios and Application Requirements .........27
A.3. Potential Requirements on an Advanced MPTCP API ............29
A.4. Integration with the SCTP Sockets API ......................30
5. Basic API for MPTCP-Aware Applications .........................15
5.1. Design Considerations .....................................15
5.2. Requirements on the Basic MPTCP API .......................16
5.3. Sockets Interface Extensions by the Basic MPTCP API .......17
5.3.1. Overview ...........................................17
5.3.2. Enabling and Disabling of MPTCP ....................19
5.3.3. Binding MPTCP to Specified Addresses ...............19
5.3.4. Querying the MPTCP Subflow Addresses ...............20
5.3.5. Getting a Unique Connection Identifier .............20
6. Other Compatibility Issues .....................................21
6.1. Usage of TLS over MPTCP ...................................21
6.2. Usage of the SCTP Sockets API .............................21
6.3. Incompatibilities with Other Multihoming Solutions ........21
6.4. Interactions with DNS .....................................22
7. Security Considerations ........................................22
8. Conclusion .....................................................23
9. Acknowledgments ................................................23
10. References ....................................................24
10.1. Normative References .....................................24
10.2. Informative References ...................................24
Appendix A. Requirements on a Future Advanced MPTCP API ...........26
A.1. Design Considerations ......................................26
A.2. MPTCP Usage Scenarios and Application Requirements .........27
A.3. Potential Requirements on an Advanced MPTCP API ............29
A.4. Integration with the SCTP Sockets API ......................30
Multipath TCP adds the capability of using multiple paths to a regular TCP session [1]. The motivations for this extension include increasing throughput, overall resource utilization, and resilience to network failure, and these motivations are discussed, along with high-level design decisions, as part of the multipath TCP architecture [4]. MPTCP [5] offers the same reliable, in-order, byte-stream transport as TCP and is designed to be backward compatible with both applications and the network layer. It requires support inside the network stack of both endpoints.
多路径TCP为常规TCP会话添加了使用多条路径的功能[1]。此扩展的动机包括提高吞吐量、总体资源利用率和网络故障恢复能力，这些动机与高层设计决策一起讨论，作为多路径TCP体系结构的一部分[4]。MPTCP[5]提供了与TCP相同的可靠、有序的字节流传输，并设计为与应用程序和网络层向后兼容。它需要两个端点的网络堆栈内部的支持。
This document first presents the effects that MPTCP may have on applications, such as performance changes compared to regular TCP. Second, it defines the interoperation of MPTCP and applications that are unaware of the multipath transport. MPTCP is designed to be usable without any application changes, but some compatibility issues have to be taken into account. Third, this memo specifies a basic Application Programming Interface (API) for MPTCP-aware applications. The API presented here is an extension to the regular TCP API to
本文档首先介绍MPTCP可能对应用程序产生的影响，例如与常规TCP相比的性能变化。其次，它定义了MPTCP和不知道多路径传输的应用程序的互操作。MPTCP被设计为无需任何应用程序更改即可使用，但必须考虑一些兼容性问题。第三，本备忘录指定了MPTCP感知应用程序的基本应用程序编程接口（API）。这里提供的API是对常规TCP API的扩展，用于
allow an MPTCP-aware application the equivalent level of control and access to information of an MPTCP connection that would be possible with the standard TCP API on a regular TCP connection.
允许MPTCP感知应用程序具有与常规TCP连接上的标准TCP API相同的MPTCP连接信息控制和访问级别。
The de facto standard API for TCP/IP applications is the "sockets" interface [8]. This document provides an abstract definition of MPTCP-specific extensions to this interface. These are operations that can be used by an application to get or set additional MPTCP-specific information on a socket, in order to provide an equivalent level of information and control over MPTCP as exists for an application using regular TCP. It is up to the applications, high-level programming languages, or libraries to decide whether to use these optional extensions. For instance, an application may want to turn on or off the MPTCP mechanism for certain data transfers or limit its use to certain interfaces. The abstract specification is in line with the Portable Operating System Interface (POSIX) standard [8] as much as possible.
TCP/IP应用程序的实际标准API是“套接字”接口[8]。本文档提供了此接口的MPTCP特定扩展的抽象定义。应用程序可以使用这些操作在套接字上获取或设置额外的MPTCP特定信息，以便提供与使用常规TCP的应用程序相同的MPTCP信息和控制级别。由应用程序、高级编程语言或库决定是否使用这些可选扩展。例如，应用程序可能希望为某些数据传输打开或关闭MPTCP机制，或将其使用限制在某些接口上。抽象规范尽可能符合便携式操作系统接口（POSIX）标准[8]。
An advanced API for MPTCP is outside the scope of this document. Such an advanced API could offer a more fine-grained control over multipath transport functions and policies. The appendix includes a brief, non-compulsory list of potential features of such an advanced API.
MPTCP的高级API不在本文档范围内。这种高级API可以提供对多路径传输功能和策略的更细粒度控制。附录中包含了此类高级API潜在功能的简要非强制性列表。
There can be interactions or incompatibilities of MPTCP with other APIs or sockets interface extensions, which are discussed later in this document. Some network stack implementations, especially on mobile devices, have centralized connection managers or other higher-level APIs to solve multi-interface issues, as surveyed in [15]. Their interaction with MPTCP is outside the scope of this document.
MPTCP可能与其他API或套接字接口扩展存在交互或不兼容，本文稍后将对此进行讨论。一些网络堆栈实现，特别是在移动设备上，具有集中式连接管理器或其他更高级别的API来解决多接口问题，如[15]中所述。他们与MPTCP的互动超出了本文件的范围。
The target readers of this document are application developers whose software may benefit significantly from MPTCP. This document also provides the necessary information for developers of MPTCP to implement the API in a TCP/IP network stack.
本文档的目标读者是应用程序开发人员，他们的软件可能会从MPTCP中受益匪浅。本文档还为MPTCP开发人员在TCP/IP网络堆栈中实现API提供了必要的信息。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[3]中所述进行解释。
This document uses the MPTCP terminology introduced in [5].
本文件使用了[5]中介绍的MPTCP术语。
Concerning the API towards applications, the following terms are distinguished:
关于API应用程序，区分以下术语：
o Legacy API: The interface towards TCP that is currently used by applications. This document explains the effect of MPTCP for such applications, as well as resulting issues.
o 遗留API：应用程序当前使用的TCP接口。本文档解释了MPTCP对此类应用的影响，以及由此产生的问题。
o Basic API: A simple extension of TCP's interface for applications that are aware of MPTCP. This document abstractly describes this interface, which provides access to multipath address information and a level of control equivalent to regular TCP.
o 基本API：TCP接口的简单扩展，适用于了解MPTCP的应用程序。本文档对该接口进行了抽象描述，该接口提供了对多路径地址信息的访问以及与常规TCP相当的控制级别。
o Advanced API: An API that offers more fine-grained control over the behavior of MPTCP. Its specification is outside the scope of this document.
o 高级API：对MPTCP的行为提供更细粒度控制的API。其规格不在本文件范围内。
This section discusses the effect of MPTCP on performance as seen by an application, in comparison to what may be expected from the use of regular TCP.
本节讨论应用程序所看到的MPTCP对性能的影响，并与常规TCP的使用进行比较。
One of the key goals of adding multipath capability to TCP is to improve the performance of a transport connection by load distribution over separate subflows across potentially disjoint paths. Furthermore, it is an explicit goal of MPTCP that it provides a connection that performs at least as well as one using single-path TCP. A corresponding congestion control algorithm is described in [7]. The following sections summarize the performance effect of MPTCP as seen by an application.
向TCP添加多路径功能的关键目标之一是通过在可能不相交的路径上的独立子流上分配负载来提高传输连接的性能。此外，MPTCP的一个明确目标是，它提供的连接的性能至少与使用单路径TCP的连接一样好。[7]中描述了相应的拥塞控制算法。以下各节总结了应用程序对MPTCP的性能影响。
The most obvious performance improvement that can be expected from the use of MPTCP is an increase in throughput, since MPTCP will pool more than one path (where available) between two endpoints. This will usually provide as great or greater bandwidth for an application, even though exceptions may exist, e.g., due to differences in the congestion control dynamics. For instance, if a new subflow is started, the short-term throughput can be smaller than the theoretical optimum. If there are shared bottlenecks between the flows, then the congestion control algorithms will in most cases ensure that load is evenly spread amongst regular and multipath TCP sessions, so that no end user receives worse performance than if all were using single-path TCP. There are some known corner cases in which an upgrade to MPTCP can affect other users [21].
使用MPTCP可以预期的最明显的性能改进是吞吐量的增加，因为MPTCP将在两个端点之间共享多个路径（如果可用）。这通常会为应用程序提供相同或更大的带宽，即使可能存在例外情况，例如，由于拥塞控制动态的差异。例如，如果启动新的子流，短期吞吐量可能小于理论最佳吞吐量。如果流之间存在共享瓶颈，那么在大多数情况下，拥塞控制算法将确保负载均匀分布在常规和多路径TCP会话中，这样最终用户的性能就不会比全部使用单路径TCP时差。在一些已知的情况下，升级到MPTCP可能会影响其他用户[21]。
This performance increase additionally means that an MPTCP session could achieve throughput that is greater than the capacity of a single interface on the device. If any applications make assumptions about interfaces due to throughput, they must take this into account (although an MPTCP implementation must always respect an application's request for a particular interface).
这种性能的提高还意味着MPTCP会话可以实现比设备上单个接口的容量更大的吞吐量。如果任何应用程序由于吞吐量而对接口做出假设，它们必须考虑到这一点（尽管MPTCP实现必须始终尊重应用程序对特定接口的请求）。
Furthermore, the flexibility of MPTCP to add and remove subflows as paths change availability could lead to a greater variation, and more frequent change, in connection bandwidth. Applications that adapt to available bandwidth (such as video and audio streaming) may need to adjust some of their assumptions to most effectively take this into account.
此外，MPTCP在路径可用性发生变化时添加和删除子流的灵活性可能会导致连接带宽发生更大的变化和更频繁的变化。适应可用带宽（如视频和音频流）的应用程序可能需要调整一些假设，以便最有效地考虑到这一点。
The transport of MPTCP signaling information results in a small overhead. The use of MPTCP instead of a single TCP connection therefore results in a smaller goodput. Also, if multiple subflows share a same bottleneck, this overhead slightly reduces the capacity that is available for data transport. Yet, this potential reduction of throughput will be negligible in many usage scenarios, and the protocol contains optimizations in its design so that this overhead is minimal.
MPTCP信令信息的传输会导致较小的开销。因此，使用MPTCP而不是单个TCP连接将导致较小的goodput。此外，如果多个子流共享同一瓶颈，则此开销会略微降低数据传输的可用容量。然而，在许多使用场景中，吞吐量的这种潜在降低可以忽略不计，并且协议在其设计中包含了优化，因此这种开销是最小的。
The benefits of MPTCP regarding throughput and resilience may come at some cost regarding data delivery delay and delay jitter.
MPTCP在吞吐量和恢复能力方面的优势可能以数据传输延迟和延迟抖动为代价。
If the delays on the constituent subflows of an MPTCP connection differ, the jitter perceivable to an application may appear higher as the data are spread across the subflows. Although MPTCP will ensure in-order delivery to the application, the data delivery could be more bursty than may be usual with single-path TCP, in particular on highly asymmetric paths.
如果MPTCP连接的组成子流上的延迟不同，则当数据分布在子流上时，应用程序可感知的抖动可能会更高。尽管MPTCP将确保按顺序向应用程序交付数据，但数据交付可能比单路径TCP的通常情况更具突发性，尤其是在高度不对称的路径上。
Applications with high real-time requirements might be affected by such a scenario. One possible remedy is to disable MPTCP for such jitter-sensitive applications, either by using the basic API defined in this document, or by other means, such as system policies.
具有高实时性要求的应用程序可能会受到此类场景的影响。一种可能的补救方法是，通过使用本文档中定义的基本API，或通过其他方式（如系统策略），禁用此类抖动敏感应用程序的MPTCP。
However, the actual delay and jitter of data transport over MPTCP depend on the scheduling and congestion control algorithms used for sending data, as well as the heuristics to establish and shut down subflows. A sender can implement strategies to minimize the delay jitter seen by applications, but this requires an accurate estimation of the path characteristics. If the scheduling decisions are suboptimal or if assumptions about the path characteristics turn out to be wrong, delay jitter may be increased and affect delay-sensitive
然而，MPTCP上数据传输的实际延迟和抖动取决于用于发送数据的调度和拥塞控制算法，以及建立和关闭子流的启发式方法。发送方可以实现最小化应用程序看到的延迟抖动的策略，但这需要准确估计路径特性。如果调度决策是次优的，或者如果关于路径特性的假设被证明是错误的，那么延迟抖动可能会增加并影响延迟敏感度
applications. In general, for a delay-sensitive application, it would be desirable to select an appropriate congestion control algorithm for its traffic needs.
应用。一般来说，对于延迟敏感的应用程序，需要根据其流量需求选择合适的拥塞控制算法。
Alternatively, MPTCP could be used in high-reliability, rather than high-throughput, modes of operation, such as by mirroring traffic on subflows, or by only using additional subflows for hot standby. These methods of traffic scheduling would not cause delay variation in the same way. These additional modes, and the selection of alternative scheduling algorithms, would need to be indicated by an advanced API, the specification of which requires further analysis and is outside the scope of this document.
或者，MPTCP可以用于高可靠性而不是高吞吐量的操作模式，例如通过在子流上镜像流量，或者仅使用额外的子流进行热备用。这些流量调度方法不会以相同的方式引起延迟变化。这些附加模式以及备选调度算法的选择需要通过高级API进行说明，高级API的规范需要进一步分析，不在本文档的范围内。
If data transport on one subflow fails, the retransmissions inside MPTCP could affect the delivery delay to the application. Yet, without MPTCP that data or the whole connection might have been lost, and other reliability mechanisms (e.g., application-level recovery) would likely have an even larger delay impact.
如果一个子流上的数据传输失败，MPTCP内的重新传输可能会影响应用程序的传递延迟。然而，如果没有MPTCP，数据或整个连接可能会丢失，而其他可靠性机制（例如，应用程序级恢复）可能会产生更大的延迟影响。
In addition, applications that make round-trip time (RTT) estimates at the application level may have some issues. Whilst the average delay calculated will be accurate, whether this is useful for an application will depend on what it requires this information for. If a new application wishes to derive such information, it should consider how multiple subflows may affect its measurements and thus how it may wish to respond. In such a case, an application may wish to express its scheduling preferences, as described later in this document.
此外，在应用程序级别进行往返时间（RTT）估计的应用程序可能存在一些问题。虽然计算的平均延迟是准确的，但这对应用程序是否有用将取决于它需要这些信息的目的。如果一个新的应用程序希望得到这样的信息，它应该考虑多个子流可能如何影响其测量结果，以及它可能希望如何响应。在这种情况下，应用程序可能希望表达其调度首选项，如本文档后面所述。
Another performance improvement through the use of MPTCP is better resilience. The use of multiple subflows simultaneously means that if one should fail, all traffic will move to the remaining subflow(s), and additionally any lost packets can be retransmitted on these subflows.
通过使用MPTCP的另一个性能改进是更好的恢复能力。同时使用多个子流意味着，如果其中一个子流出现故障，所有流量将移动到剩余的子流，此外，任何丢失的数据包都可以在这些子流上重新传输。
As one special case, MPTCP can be used with only one active subflow at a given point in time. In that case, resilience compared to single-path TCP is improved. MPTCP also supports make-before-break and break-before-make handovers between subflows. In both cases, the MPTCP connection can survive an unavailability or change of an IP address (e.g., due to shutdown of an interface or handover). MPTCP closes or resets the MPTCP connection separately from the individual subflows, as described in [5].
作为一种特殊情况，MPTCP在给定时间点只能与一个活动子流一起使用。在这种情况下，与单路径TCP相比，恢复能力得到了提高。MPTCP还支持子流之间的先接通后断和先断后接通切换。在这两种情况下，MPTCP连接都可以在IP地址不可用或更改（例如，由于接口关闭或切换）后继续存在。MPTCP关闭或重置MPTCP连接，与各个子流分开，如[5]所述。
Subflow failure may be caused by issues within the network, which an application would be unaware of, or interface failure on the node.
子流故障可能由网络内的问题（应用程序可能不知道）或节点上的接口故障引起。
An application may, under certain circumstances, be in a position to be aware of such failure (e.g., by radio signal strength, or simply an interface enabled flag), and so must not make assumptions of an MPTCP flow's stability based on this. An MPTCP implementation must never override an application's request for a given interface, however, so the cases where this issue may be applicable are limited.
在某些情况下，应用程序可能会意识到此类故障（例如，通过无线电信号强度，或仅通过接口启用标志），因此不得基于此假设MPTCP流的稳定性。然而，MPTCP实现决不能覆盖应用程序对给定接口的请求，因此此问题可能适用的情况是有限的。
MPTCP has been designed to pass through the majority of middleboxes. Empirical evidence suggests that new TCP options can successfully be used on most paths in the Internet [22]. Nevertheless, some middleboxes may still refuse to pass MPTCP messages due to the presence of TCP options, or they may strip TCP options. If this is the case, MPTCP falls back to regular TCP. Although this will not create a problem for the application (its communication will be set up either way), there may be additional (and indeed, user-perceivable) delay while the first handshake fails. Therefore, an alternative approach could be to try both MPTCP and regular TCP connection attempts at the same time and respond to whichever replies first, in a fashion similar to the "Happy Eyeballs" mechanism for IPv6 [16]. One could also apply a shorter timeout on the MPTCP attempt and thus reduce the setup delay if fallback to regular TCP is needed.
MPTCP设计用于通过大多数中间盒。经验证据表明，新的TCP选项可以成功地用于互联网中的大多数路径[22]。尽管如此，由于存在TCP选项，一些中间盒可能仍然拒绝传递MPTCP消息，或者它们可能会剥夺TCP选项。如果是这种情况，MPTCP将返回到常规TCP。虽然这不会给应用程序带来问题（它的通信将以任何方式设置），但在第一次握手失败时，可能会有额外的（实际上，用户可感知的）延迟。因此，另一种方法可以是同时尝试MPTCP和常规TCP连接尝试，并以类似于IPv6的“快乐眼球”机制的方式对最先做出的响应进行响应[16]。还可以在MPTCP尝试时应用较短的超时，从而在需要回退到常规TCP时减少设置延迟。
An MPTCP implementation can learn the rate of MPTCP connection attempt successes or failures to particular hosts or networks, and on particular interfaces, and could therefore learn heuristics of when and when not to use MPTCP. A detailed discussion of the various fallback mechanisms, for failures occurring at different points in the connection, is presented in [5]. It must be emphasized that all such heuristics could also fail, and learning can be difficult in certain environments, e.g., if the host is mobile.
MPTCP实现可以了解特定主机或网络以及特定接口上MPTCP连接尝试成功或失败的速率，因此可以了解何时和何时不使用MPTCP的启发式方法。[5]中详细讨论了连接中不同点发生故障时的各种回退机制。必须强调的是，所有这些启发式方法也可能失败，并且在某些环境中学习可能很困难，例如，如果主机是移动的。
There may also be middleboxes that transparently change the length of content. If such middleboxes are present, MPTCP's reassembly of the byte stream in the receiver is difficult. Still, MPTCP can detect such middleboxes and then fall back to regular TCP. An overview of the impact of middleboxes is presented in [4], and MPTCP's mechanisms to work around these issues are presented and discussed in [5].
也可能有透明地改变内容长度的中间盒。如果存在这样的中间盒，MPTCP很难在接收器中重新组装字节流。不过，MPTCP可以检测到这样的中间盒，然后退回到常规TCP。[4]概述了中间箱的影响，并在[5]中介绍和讨论了MPTCP解决这些问题的机制。
MPTCP can also have other unexpected implications. For instance, intrusion detection systems could be triggered. A full analysis of MPTCP's impact on such middleboxes is for further study after deployment experiments.
MPTCP还可能产生其他意想不到的影响。例如，可以触发入侵检测系统。充分分析MPTCP对此类中间盒的影响，以便在部署实验后进一步研究。
In regular TCP, there is a one-to-one mapping of the sockets interface to a flow through a network. Since MPTCP can make use of multiple subflows, applications cannot implicitly rely on this one-to-one mapping any more.
在常规TCP中，套接字接口与通过网络的流之间存在一对一的映射。由于MPTCP可以使用多个子流，因此应用程序不能再隐式地依赖于此一对一映射。
Whilst this doesn't matter for most applications, some applications may need to adapt to the presence of multiple addresses, because implicit assumptions are outdated. In this section, selected examples for resulting issues are discussed. The question of whether such implicit assumptions matter is an application-level decision, and this document only provides general guidance and a basic API to retrieve relevant information.
虽然这对大多数应用程序来说并不重要，但一些应用程序可能需要适应多个地址的存在，因为隐式假设已经过时。在本节中，将讨论所产生问题的选定示例。此类隐含假设是否重要的问题是应用程序级决策，本文档仅提供一般指导和检索相关信息的基本API。
A few applications require the transport to be along a single path; they can disable the use of MPTCP as described later in this document. Examples include monitoring tools that want to measure the available bandwidth on a path, or routing protocols such as BGP that require the use of a specific link.
少数应用要求传输沿单一路径进行；如本文档后面所述，他们可以禁用MPTCP的使用。示例包括希望测量路径上可用带宽的监视工具，或需要使用特定链路的路由协议（如BGP）。
Certain applications store the IP addresses of TCP connections, e.g., by logging mechanisms. Such logging mechanisms will continue to work with MPTCP, but two important aspects have to be mentioned: First, if the application is not aware of MPTCP, it will use the existing interface to the network stack. This implies that an MPTCP-unaware application will track the IP addresses of the first subflow only. IP addresses used by follow-up subflows will be ignored. Second, an MPTCP-aware application can use the basic API described in this document to monitor the IP addresses of all subflows, e.g., for logging mechanisms. If an MPTCP connection uses several subflows, this will possibly imply that data structures have to be adapted and that the amount of data that has to be logged and stored per connection will increase.
某些应用程序存储TCP连接的IP地址，例如通过日志机制。这种日志机制将继续与MPTCP一起工作，但必须提到两个重要方面：首先，如果应用程序不知道MPTCP，它将使用网络堆栈的现有接口。这意味着不知道MPTCP的应用程序将只跟踪第一个子流的IP地址。后续子流使用的IP地址将被忽略。其次，支持MPTCP的应用程序可以使用本文档中描述的基本API来监控所有子流的IP地址，例如日志机制。如果MPTCP连接使用多个子流，这可能意味着必须调整数据结构，并且每个连接必须记录和存储的数据量将增加。
An MPTCP implementation may choose to maintain an MPTCP connection even if the IP address of the original subflow is no longer allocated to a host, depending on the policy concerning the first subflow (fate-sharing; see Section 4.2.2). In this case, the IP address exposed to an MPTCP-unaware application can differ from the addresses actually being used by MPTCP. It is even possible that the IP address gets assigned to another host during the lifetime of an MPTCP connection. As further discussed below, this could be an issue if the IP addresses are exchanged by applications, e.g., inside the application protocol. This issue can be addressed by enabling fate-sharing, at the cost of resilience, because the MPTCP connection then cannot close the initial subflow.
MPTCP实现可以选择维护MPTCP连接，即使原始子流的IP地址不再分配给主机，这取决于关于第一个子流的策略（命运共享；参见第4.2.2节）。在这种情况下，公开给MPTCP应用程序的IP地址可能与MPTCP实际使用的地址不同。甚至有可能在MPTCP连接的生存期内将IP地址分配给另一台主机。如下文进一步讨论的，如果IP地址由应用程序（例如，在应用程序协议内）交换，则这可能是一个问题。这个问题可以通过启用命运共享来解决，代价是恢复能力，因为MPTCP连接无法关闭初始子流。
The support for multiple IP addresses within one MPTCP connection can result in additional security vulnerabilities, such as possibilities for attackers to hijack connections. The protocol design of MPTCP minimizes this risk. An attacker on one of the paths can cause harm, but this is hardly an additional security risk compared to single-path TCP, which is vulnerable to man-in-the-middle attacks as well. A detailed threat analysis of MPTCP is published in [6].
在一个MPTCP连接中支持多个IP地址可能会导致额外的安全漏洞，例如攻击者劫持连接的可能性。MPTCP的协议设计将这种风险降至最低。其中一条路径上的攻击者可能会造成伤害，但与易受中间人攻击的单路径TCP相比，这几乎不是额外的安全风险。MPTCP的详细威胁分析发表在[6]中。
Impact on Transport Layer Security (TLS) is discussed in Section 6.1.
第6.1节讨论了对传输层安全性（TLS）的影响。
MPTCP is an extension of TCP, but it is designed to be backward compatible for legacy (MPTCP-unaware) applications. TCP interacts with other parts of the network stack via different interfaces. The de facto standard API between TCP and applications is the sockets interface. The position of MPTCP in the protocol stack is illustrated in Figure 1.
MPTCP是TCP的一个扩展，但它被设计为向后兼容遗留（MPTCP）应用程序。TCP通过不同的接口与网络堆栈的其他部分进行交互。TCP和应用程序之间事实上的标准API是套接字接口。MPTCP在协议栈中的位置如图1所示。
+-------------------------------+
| Application |
+-------------------------------+
^ |
~~~~~~~~~~|~Sockets Interface|~~~~~~~~~
| v
+-------------------------------+
| MPTCP |
+ - - - - - - - + - - - - - - - +
| Subflow (TCP) | Subflow (TCP) |
+-------------------------------+
| IP | IP |
+-------------------------------+
+-------------------------------+
| Application |
+-------------------------------+
^ |
~~~~~~~~~~|~Sockets Interface|~~~~~~~~~
| v
+-------------------------------+
| MPTCP |
+ - - - - - - - + - - - - - - - +
| Subflow (TCP) | Subflow (TCP) |
+-------------------------------+
| IP | IP |
+-------------------------------+
Figure 1: MPTCP Protocol Stack
图1:MPTCP协议栈
In general, MPTCP can affect all interfaces that make assumptions about the coupling of a TCP connection to a single IP address and TCP port pair, to one socket endpoint, to one network interface, or to a given path through the network.
通常，MPTCP会影响所有接口，这些接口假设TCP连接与单个IP地址和TCP端口对、一个套接字端点、一个网络接口或网络中的给定路径耦合。
This means that there are two classes of applications:
这意味着有两类应用程序：
o Legacy applications: These applications are unaware of MPTCP and use the existing API towards TCP without any changes. This is the default case.
o 遗留应用程序：这些应用程序不知道MPTCP，并且在不做任何更改的情况下使用现有的TCP API。这是默认情况。
o MPTCP-aware applications: These applications indicate support for an enhanced MPTCP interface. This document specifies a minimum set of API extensions for such applications.
o 支持MPTCP的应用程序：这些应用程序表示支持增强的MPTCP接口。本文档为此类应用程序指定了一组最少的API扩展。
In the following sections, it is discussed to what extent MPTCP affects legacy applications using the existing sockets API. The existing sockets API implies that applications deal with data structures that store, amongst others, the IP addresses and TCP port numbers of a TCP connection. A design objective of MPTCP is that legacy applications can continue to use the established sockets API without any changes. However, in MPTCP there is a one-to-many mapping between the socket endpoint and the subflows. This has several subtle implications for legacy applications using sockets API functions.
在以下部分中，将讨论MPTCP在多大程度上影响使用现有套接字API的遗留应用程序。现有的套接字API意味着应用程序处理的数据结构存储TCP连接的IP地址和TCP端口号。MPTCP的一个设计目标是，遗留应用程序可以继续使用已建立的套接字API，而无需进行任何更改。但是，在MPTCP中，套接字端点和子流之间存在一对多映射。这对使用套接字API函数的遗留应用程序有几个微妙的影响。
During binding, an application can either select a specific address or bind to INADDR_ANY. Furthermore, on some systems other socket options (e.g., SO_BINDTODEVICE) can be used to bind to a specific interface. If an application uses a specific address or binds to a specific interface, then MPTCP MUST respect this and not interfere in the application's choices. The binding to a specific address or interface implies that the application is not aware of MPTCP and will disable the use of MPTCP on this connection. An application that wishes to bind to a specific set of addresses with MPTCP must use multipath-aware calls to achieve this (as described in Section 5.3.3).
在绑定过程中，应用程序可以选择特定地址，也可以绑定到INADDR\ U ANY。此外，在某些系统上，可以使用其他套接字选项（例如，SO_BINDTODEVICE）绑定到特定接口。如果应用程序使用特定地址或绑定到特定接口，则MPTCP必须遵守这一点，并且不得干扰应用程序的选择。绑定到特定地址或接口意味着应用程序不知道MPTCP，并将禁止在此连接上使用MPTCP。希望使用MPTCP绑定到特定地址集的应用程序必须使用多路径感知调用来实现这一点（如第5.3.3节所述）。
If an application binds to INADDR_ANY, it is assumed that the application does not care which addresses are used locally. In this case, a local policy MAY allow MPTCP to automatically set up multiple subflows on such a connection.
如果应用程序绑定到INADDR_ANY，则假定该应用程序不关心本地使用的地址。在这种情况下，本地策略可能允许MPTCP在这种连接上自动设置多个子流。
The basic sockets API of MPTCP-aware applications allows the expression of further preferences in an MPTCP-compatible way (e.g., binding to a subset of interfaces only).
MPTCP感知应用程序的基本套接字API允许以MPTCP兼容的方式表达进一步的首选项（例如，仅绑定到接口子集）。
Applications can use the getpeername() or getsockname() functions in order to retrieve the IP address of the peer or of the local socket. These functions can be used for various purposes, including security mechanisms, geo-location, or interface checks. The sockets API was designed with an assumption that a socket is using just one address, and since this address is visible to the application, the application may assume that the information provided by the functions is the same during the lifetime of a connection. However, in MPTCP, unlike in TCP, there is a one-to-many mapping of a connection to subflows, and subflows can be added and removed while the connection continues to exist. Since the subflow addresses can change, MPTCP cannot expose addresses by getpeername() or getsockname() that are both valid and constant during the connection's lifetime.
应用程序可以使用getpeername（）或getsockname（）函数来检索对等方或本地套接字的IP地址。这些功能可用于各种目的，包括安全机制、地理位置或接口检查。sockets API的设计假设套接字仅使用一个地址，并且由于该地址对应用程序可见，应用程序可能会假设函数提供的信息在连接的生命周期内是相同的。但是，在MPTCP中，与TCP不同的是，连接与子流之间存在一对多映射，并且可以在连接继续存在时添加和删除子流。由于子流地址可以更改，因此MPTCP无法通过getpeername（）或getsockname（）公开连接生存期内有效且恒定的地址。
This problem is addressed as follows: If used by a legacy application, the MPTCP stack MUST always return the addresses and port numbers of the first subflow of an MPTCP connection, in all circumstances, even if that particular subflow is no longer in use.
此问题的解决方法如下：如果由遗留应用程序使用，MPTCP堆栈必须始终返回MPTCP连接的第一个子流的地址和端口号，在任何情况下，即使该特定子流不再使用。
As the addresses may not be valid any more if the first subflow is closed, the MPTCP stack MAY close the whole MPTCP connection if the first subflow is closed (i.e., fate-sharing between the initial subflow and the MPTCP connection as a whole). This fate-sharing avoids the reuse of the pair of IP addresses and ports while an MPTCP connection is still in progress, but at the cost of reducing the utility of MPTCP if IP addresses of the first subflow are not available any more (e.g., mobility events). Whether to close the whole MPTCP connection by default SHOULD be controlled by a local policy. Further experiments are needed to investigate its implications.
由于如果第一子流关闭，则地址可能不再有效，因此如果第一子流关闭，则MPTCP堆栈可能会关闭整个MPTCP连接（即，初始子流和MPTCP连接作为一个整体之间的命运共享）。当MPTCP连接仍在进行时，这种命运共享避免了对IP地址和端口的重用，但是如果第一子流的IP地址不再可用（例如，移动事件），则以降低MPTCP的效用为代价。默认情况下是否关闭整个MPTCP连接应由本地策略控制。需要进一步的实验来研究它的含义。
The functions getpeername() and getsockname() SHOULD also always return the addresses of the first subflow if the socket is used by an MPTCP-aware application, in order to be consistent with MPTCP-unaware applications, and, e.g., also with the Stream Control Transmission Protocol (SCTP). Instead of getpeername() or getsockname(), MPTCP-aware applications can use new API calls, described in Section 5.3, in order to retrieve the full list of address pairs for the subflows in use.
如果MPTCP感知应用程序使用套接字，则函数getpeername（）和getsockname（）也应始终返回第一个子流的地址，以便与MPTCP感知应用程序一致，例如与流控制传输协议（SCTP）一致。与getpeername（）或getsockname（）不同，支持MPTCP的应用程序可以使用第5.3节所述的新API调用来检索正在使用的子流的完整地址对列表。
As described in [5], MPTCP distinguishes between the closing of subflows (by TCP FIN) and closing the whole MPTCP connection (by Data FIN).
如[5]所述，MPTCP区分关闭子流（通过TCP FIN）和关闭整个MPTCP连接（通过数据FIN）。
When an application closes a socket, e.g., by calling the close() function, this indicates that the application has no more data to send, like for single-path TCP. MPTCP will then close the MPTCP connection via Data FIN messages. This is completely transparent for an application.
当应用程序关闭套接字（例如，通过调用close（）函数）时，这表示应用程序没有更多的数据要发送，如单路径TCP。然后，MPTCP将通过数据FIN消息关闭MPTCP连接。这对于应用程序来说是完全透明的。
In summary, the semantics of the close() interface for applications are not changed compared to TCP.
总之，与TCP相比，应用程序close（）接口的语义没有改变。
In general, an MPTCP connection is maintained separately from individual subflows. MPTCP therefore has internal mechanisms to establish, close, or reset the MPTCP connection [5]. These mechanisms provide equivalent functions like single-path TCP and can be mapped accordingly. Therefore, these MPTCP internals do not affect the application interface.
通常，MPTCP连接与各个子流分开维护。因此，MPTCP具有建立、关闭或重置MPTCP连接的内部机制[5]。这些机制提供了类似于单路径TCP的等效功能，并且可以相应地进行映射。因此，这些MPTCP内部不会影响应用程序接口。
The existing sockets API includes options that modify the behavior of sockets and their underlying communications protocols. Various socket options exist on the socket, TCP, and IP level. The value of an option can usually be set by the setsockopt() system function. The getsockopt() function gets information. In general, the existing sockets interface functions cannot configure each MPTCP subflow individually. In order to be backward compatible, existing APIs therefore SHOULD apply to all subflows within one connection, as far as possible.
现有的套接字API包括修改套接字行为及其底层通信协议的选项。套接字、TCP和IP级别上存在各种套接字选项。选项的值通常可以通过setsockopt（）系统函数设置。函数的作用是：获取信息。通常，现有套接字接口函数无法单独配置每个MPTCP子流。因此，为了向后兼容，现有API应尽可能应用于一个连接内的所有子流。
One commonly used TCP socket option (TCP_NODELAY) disables the Nagle algorithm as described in [2]. This option is also specified in the POSIX standard [8]. Applications can use this option in combination with MPTCP in exactly the same way. It then SHOULD disable the Nagle algorithm for the MPTCP connection, i.e., all subflows.
一个常用的TCP套接字选项（TCP_NODELAY）禁用了Nagle算法，如[2]所述。POSIX标准[8]中也指定了此选项。应用程序可以以完全相同的方式将此选项与MPTCP结合使用。然后应禁用MPTCP连接的Nagle算法，即所有子流。
In addition, the MPTCP protocol instance MAY use a different path scheduler algorithm if TCP_NODELAY is present. For instance, it could use an algorithm that is optimized for latency-sensitive traffic (for instance, only transmitting on one path). Specific algorithms are outside the scope of this document.
此外，如果存在TCP_节点延迟，MPTCP协议实例可以使用不同的路径调度器算法。例如，它可以使用针对延迟敏感流量（例如，仅在一条路径上传输）进行优化的算法。具体算法不在本文件范围内。
Applications can explicitly configure send and receive buffer sizes via the sockets API (SO_SNDBUF, SO_RCVBUF). These socket options can also be used in combination with MPTCP and then affect the buffer size of the MPTCP connection. However, when defining buffer sizes, application programmers should take into account that the transport over several subflows requires a certain amount of buffer for resequencing in the receiver. MPTCP may also require more storage space in the sender, in particular, if retransmissions are sent over more than one path. In addition, very small send buffers may prevent MPTCP from efficiently scheduling data over different subflows. Therefore, it does not make sense to use MPTCP in combination with small send or receive buffers.
应用程序可以通过sockets API（SO_SNDBUF，SO_RCVBUF）显式配置发送和接收缓冲区大小。这些套接字选项也可以与MPTCP结合使用，然后影响MPTCP连接的缓冲区大小。但是，在定义缓冲区大小时，应用程序程序员应该考虑到，通过几个子流的传输需要一定数量的缓冲区，以便在接收器中重新排序。MPTCP还可能需要发送方中更多的存储空间，特别是在通过多条路径发送重传的情况下。此外，非常小的发送缓冲区可能会阻止MPTCP在不同的子流上高效地调度数据。因此，将MPTCP与小型发送或接收缓冲区结合使用是没有意义的。
An MPTCP implementation MAY set a lower bound for send and receive buffers and treat a small buffer size request as an implicit request not to use MPTCP.
MPTCP实现可以为发送和接收缓冲区设置下限，并将较小的缓冲区大小请求视为不使用MPTCP的隐式请求。
TCP features the ability to send "Urgent" data, but its use is not recommended in general, and specifically not with MPTCP [4].
TCP具有发送“紧急”数据的功能，但一般不建议使用它，尤其不建议与MPTCP一起使用[4]。
Some network stacks may provide additional implementation-specific socket options or interfaces that affect TCP's behavior. In such cases, implementers must ensure that these options do not interfere with the MPTCP interface.
某些网络堆栈可能提供影响TCP行为的其他特定于实现的套接字选项或接口。在这种情况下，实现者必须确保这些选项不会干扰MPTCP接口。
It is up to a local policy at the end system whether a network stack should automatically enable MPTCP for sockets even if there is no explicit sign of MPTCP awareness of the corresponding application. Such a choice may be under the control of the user through system preferences.
即使没有相应应用程序的MPTCP感知的明确迹象，网络堆栈是否应自动为套接字启用MPTCP仍取决于终端系统的本地策略。这样的选择可以由用户通过系统偏好来控制。
The enabling of MPTCP, either by application or by system defaults, does not necessarily mean that MPTCP will always be used. Both endpoints must support MPTCP, and there must be multiple addresses at at least one endpoint, for MPTCP to be used. Even if those requirements are met, however, MPTCP may not be immediately used on a
通过应用程序或系统默认值启用MPTCP并不一定意味着将始终使用MPTCP。两个端点都必须支持MPTCP，并且必须有多个地址（至少有一个端点），才能使用MPTCP。然而，即使这些要求得到满足，MPTCP也可能不会立即用于某个特定的应用程序
connection. It may make sense for multiple paths to be brought into operation only after a given period of time, or if the connection is saturated.
联系只有在给定的一段时间后，或者如果连接饱和，多条路径才能投入运行，这可能是有意义的。
o Using the default MPTCP configuration: Like TCP, MPTCP is designed to be efficient and robust in the default configuration. Application developers should not explicitly configure TCP (or MPTCP) features unless this is really needed.
o 使用默认的MPTCP配置：与TCP一样，MPTCP在默认配置中被设计为高效和健壮的。除非确实需要，否则应用程序开发人员不应该显式配置TCP（或MPTCP）功能。
o Socket buffer dimensioning: Multipath transport requires larger buffers in the receiver for resequencing, as already explained. Applications should use reasonable buffer sizes (such as the operating system default values) in order to fully benefit from MPTCP. A full discussion of buffer sizing issues is given in [5].
o 套接字缓冲区尺寸：如前所述，多路径传输要求接收器中有更大的缓冲区用于重新排序。应用程序应使用合理的缓冲区大小（如操作系统默认值），以便充分受益于MPTCP。[5]中对缓冲区大小问题进行了全面讨论。
o Facilitating stack-internal heuristics: The path management and data scheduling by MPTCP is realized by stack-internal algorithms that may implicitly try to self-optimize their behavior according to assumed application needs. For instance, an MPTCP implementation may use heuristics to determine whether an application requires delay-sensitive or bulk data transport, using, for instance, port numbers, the TCP_NODELAY socket options, or the application's read/write patterns as input parameters. An application developer can facilitate the operation of such heuristics by avoiding atypical interface use cases. For instance, for long bulk data transfers, it does not make sense to enable the TCP_NODELAY socket option, nor is it reasonable to use many small socket send() calls each with small amounts of data only.
o 促进堆栈内部启发式：MPTCP的路径管理和数据调度是通过堆栈内部算法实现的，这些算法可以根据假定的应用程序需求隐式地尝试自我优化其行为。例如，MPTCP实现可以使用启发式来确定应用程序是否需要延迟敏感或批量数据传输，例如使用端口号、TCP_节点延迟套接字选项或应用程序的读/写模式作为输入参数。应用程序开发人员可以通过避免非典型接口用例来促进此类启发式操作。例如，对于长批量数据传输，启用TCP_NODELAY socket选项是没有意义的，使用许多小socket send（）调用（每个调用只包含少量数据）也是不合理的。
While applications can use MPTCP with the unmodified sockets API, multipath transport results in many degrees of freedom. MPTCP manages the data transport over different subflows automatically. By default, this is transparent to the application, but an application could use an additional API to interface with the MPTCP layer and to control important aspects of the MPTCP implementation's behavior.
虽然应用程序可以将MPTCP与未修改的套接字API一起使用，但多路径传输会带来许多自由度。MPTCP自动管理不同子流上的数据传输。默认情况下，这对应用程序是透明的，但应用程序可以使用附加的API与MPTCP层接口，并控制MPTCP实现行为的重要方面。
This document describes a basic MPTCP API. The API contains a minimum set of functions that provide an equivalent level of control and information as exists for regular TCP. It maintains backward compatibility with legacy applications.
本文档描述了一个基本的MPTCPAPI。API包含一组最小的函数，这些函数提供与常规TCP相同的控制和信息级别。它保持了与遗留应用程序的向后兼容性。
An advanced MPTCP API is outside the scope of this document. The basic API does not allow a sender or a receiver to express preferences about the management of paths or the scheduling of data, even if this can have a significant performance impact and if an MPTCP implementation could benefit from additional guidance by applications. A list of potential further API extensions is provided in the appendix. The specification of such an advanced API is for further study and may partly be implementation-specific.
高级MPTCP API不在本文档范围内。基本API不允许发送方或接收方表达有关路径管理或数据调度的首选项，即使这可能会对性能产生重大影响，并且MPTCP实现可以从应用程序的附加指导中受益。附录中提供了可能进一步扩展API的列表。这种高级API的规范用于进一步研究，部分可能是特定于实现的。
MPTCP mainly affects the sending of data. But a receiver may also have preferences about data transfer choices, and it may have performance requirements as well. Yet, the configuration of such preferences is outside of the scope of the basic API.
MPTCP主要影响数据的发送。但是，接收器也可能有关于数据传输选择的偏好，并且可能有性能要求。然而，这些首选项的配置超出了基本API的范围。
Because of the importance of the sockets interface there are several fundamental design objectives for the basic interface between MPTCP and applications:
由于套接字接口的重要性，MPTCP和应用程序之间的基本接口有几个基本设计目标：
o Consistency with existing sockets APIs must be maintained as far as possible. In order to support the large base of applications using the original API, a legacy application must be able to continue to use standard sockets interface functions when run on a system supporting MPTCP. Also, MPTCP-aware applications should be able to access the socket without any major changes.
o 必须尽可能保持与现有套接字API的一致性。为了支持大量使用原始API的应用程序，传统应用程序在支持MPTCP的系统上运行时必须能够继续使用标准套接字接口函数。此外，支持MPTCP的应用程序应该能够访问套接字，而无需进行任何重大更改。
o Sockets API extensions must be minimized and independent of an implementation.
o 套接字API扩展必须最小化，并且独立于实现。
o The interface should handle both IPv4 and IPv6.
o 该接口应同时处理IPv4和IPv6。
The following is a list of the core requirements for the basic API:
以下是基本API的核心要求列表：
REQ1: Turn on/off MPTCP: An application should be able to request to turn on or turn off the usage of MPTCP. This means that an application should be able to explicitly request the use of MPTCP if this is possible. Applications should also be able to request not to enable MPTCP and to use regular TCP transport instead. This can be implicit in many cases, since MPTCP must be disabled by the use of binding to a specific address. MPTCP may also be enabled if an application uses a dedicated multipath address family (such as AF_MULTIPATH [20]).
请求1：打开/关闭MPTCP：应用程序应该能够请求打开或关闭MPTCP的使用。这意味着如果可能，应用程序应该能够显式请求使用MPTCP。应用程序还应该能够请求不启用MPTCP，而是使用常规TCP传输。这在许多情况下可能是隐式的，因为必须通过使用绑定到特定地址来禁用MPTCP。如果应用程序使用专用多路径地址系列（如AF_multipath[20]），则也可以启用MPTCP。
REQ2: An application should be able to restrict MPTCP to binding to a given set of addresses.
请求2：应用程序应该能够将MPTCP限制为绑定到给定的一组地址。
REQ3: An application should be able to obtain information on the pairs of addresses used by the MPTCP subflows.
请求3：应用程序应该能够获取MPTCP子流使用的地址对的信息。
REQ4: An application should be able to extract a unique identifier for the connection (per endpoint).
请求4：应用程序应该能够提取连接的唯一标识符（每个端点）。
The first requirement is the most important one, since some applications could benefit a lot from MPTCP, but there are also cases in which it hardly makes sense. The existing sockets API provides similar mechanisms to enable or disable advanced TCP features. The second requirement corresponds to the binding of addresses with the bind() socket call, or, e.g., explicit device bindings with a SO_BINDTODEVICE option. The third requirement ensures that there is an equivalent to getpeername() or getsockname() that is able to deal with more than one subflow. Finally, it should be possible for the application to retrieve a unique connection identifier (local to the endpoint on which it is running) for the MPTCP connection. This replaces the (address, port) pair for a connection identifier in single-path TCP, which is no longer static in MPTCP.
第一个要求是最重要的，因为一些应用程序可以从MPTCP中受益匪浅，但也有一些情况下它几乎没有意义。现有的套接字API提供了类似的机制来启用或禁用高级TCP功能。第二个要求对应于使用bind（）套接字调用绑定地址，或者，例如，使用SO_BINDTODEVICE选项进行显式设备绑定。第三个要求确保有一个等价于getpeername（）或getsockname（）的程序能够处理多个子流。最后，应用程序应该可以检索MPTCP连接的唯一连接标识符（运行它的端点的本地）。这将替换单路径TCP中连接标识符的（地址、端口）对，而单路径TCP在MPTCP中不再是静态的。
An application can continue to use getpeername() or getsockname() in addition to the basic MPTCP API. Both functions return the corresponding addresses of the first subflow, as already explained.
除了基本的MPTCP API之外，应用程序还可以继续使用getpeername（）或getsockname（）。如前所述，这两个函数都返回第一个子流的相应地址。
The abstract, basic MPTCP API consists of a set of new values that are associated with an MPTCP socket. Such values may be used for changing properties of an MPTCP connection or retrieving information. These values could be accessed by new symbols on existing calls such as setsockopt() and getsockopt() or could be implemented as entirely new function calls. This implementation decision is out of scope for this document. The following list presents symbolic names for these MPTCP socket settings.
抽象的基本MPTCPAPI由一组与MPTCP套接字关联的新值组成。这些值可用于更改MPTCP连接的属性或检索信息。这些值可以通过现有调用（如setsockopt（）和getsockopt（）上的新符号访问，也可以作为全新的函数调用实现。本实施决策超出了本文件的范围。下表显示了这些MPTCP套接字设置的符号名称。
o TCP_MULTIPATH_ENABLE: Enable/disable MPTCP
o TCP\u多路径\u启用：启用/禁用MPTCP
o TCP_MULTIPATH_ADD: Bind MPTCP to a set of given local addresses, or add a set of new local addresses to an existing MPTCP connection
o TCP_MULTIPATH_ADD：将MPTCP绑定到一组给定的本地地址，或向现有MPTCP连接添加一组新的本地地址
o TCP_MULTIPATH_REMOVE: Remove a local address from an MPTCP connection
o TCP_MULTIPATH_REMOVE：从MPTCP连接中删除本地地址
o TCP_MULTIPATH_SUBFLOWS: Get the pairs of addresses currently used by the MPTCP subflows
o TCP_多路径_子流：获取MPTCP子流当前使用的地址对
o TCP_MULTIPATH_CONNID: Get the local connection identifier for this MPTCP connection
o TCP\u MULTIPATH\u CONNID:获取此MPTCP连接的本地连接标识符
Table 1 shows a list of the abstract socket operations for the basic configuration of MPTCP. The first column gives the symbolic name of the operation. The second and third columns indicate whether the operation provides values to be read ("Get") or takes values to configure ("Set"). The fourth column lists the type of data associated with this operation. The data types are listed for information only. In addition to IP addresses, an application MAY also indicate TCP port numbers, as further detailed below.
表1显示了MPTCP基本配置的抽象套接字操作列表。第一列给出操作的符号名称。第二列和第三列指示操作是提供要读取的值（“Get”）还是获取要配置的值（“Set”）。第四列列出了与此操作关联的数据类型。列出的数据类型仅供参考。除IP地址外，应用程序还可以指示TCP端口号，如下所述。
+------------------------+-----+-----+------------------------------+
| Name | Get | Set | Data type |
+------------------------+-----+-----+------------------------------+
| TCP_MULTIPATH_ENABLE | o | o | boolean |
| TCP_MULTIPATH_ADD | | o | list of addresses |
| | | | (and ports) |
| TCP_MULTIPATH_REMOVE | | o | list of addresses |
| | | | (and ports) |
| TCP_MULTIPATH_SUBFLOWS | o | | list of pairs of addresses |
| | | | (and ports) |
| TCP_MULTIPATH_CONNID | o | | integer |
+------------------------+-----+-----+------------------------------+
+------------------------+-----+-----+------------------------------+
| Name | Get | Set | Data type |
+------------------------+-----+-----+------------------------------+
| TCP_MULTIPATH_ENABLE | o | o | boolean |
| TCP_MULTIPATH_ADD | | o | list of addresses |
| | | | (and ports) |
| TCP_MULTIPATH_REMOVE | | o | list of addresses |
| | | | (and ports) |
| TCP_MULTIPATH_SUBFLOWS | o | | list of pairs of addresses |
| | | | (and ports) |
| TCP_MULTIPATH_CONNID | o | | integer |
+------------------------+-----+-----+------------------------------+
Table 1: MPTCP Socket Operations
表1:MPTCP套接字操作
There are restrictions on when these new socket operations can be used:
使用这些新套接字操作的时间有限制：
o TCP_MULTIPATH_ENABLE: This value should only be set before the establishment of a TCP connection. Its value should only be read after the establishment of a connection.
o TCP_MULTIPATH_ENABLE：仅应在建立TCP连接之前设置此值。它的值只能在建立连接后读取。
o TCP_MULTIPATH_ADD: This operation can be applied both before connection setup and during a connection. If used before, it controls the local addresses that an MPTCP connection can use. In the latter case, it allows MPTCP to use an additional local address, if there has been a restriction before connection setup.
o TCP_MULTIPATH_ADD：此操作可在连接设置之前和连接期间应用。如果以前使用过，它控制MPTCP连接可以使用的本地地址。在后一种情况下，它允许MPTCP使用额外的本地地址，如果在连接设置之前有限制的话。
o TCP_MULTIPATH_REMOVE: This operation can be applied both before connection setup and during a connection. In both cases, it removes an address from the list of local addresses that may be used by subflows.
o TCP_MULTIPATH_REMOVE：此操作可在连接设置之前和连接期间应用。在这两种情况下，它都会从子流可能使用的本地地址列表中删除一个地址。
o TCP_MULTIPATH_SUBFLOWS: This value is read-only and can only be used after connection setup.
o TCP_多路径_子流：此值为只读，只能在连接设置后使用。
o TCP_MULTIPATH_CONNID: This value is read-only and should only be used after connection setup.
o TCP_MULTIPATH_CONNID:此值为只读，仅应在连接设置后使用。
An application can explicitly indicate multipath capability by setting TCP_MULTIPATH_ENABLE to the value "true". In this case, the MPTCP implementation SHOULD try to negotiate MPTCP for that connection. Note that multipath transport will not necessarily be enabled, as it requires support at both end systems, no middleboxes on the path that would prevent any additional signaling, and at least one endpoint with multiple addresses.
应用程序可以通过将TCP_multipath_ENABLE设置为值“true”来明确指示多路径能力。在这种情况下，MPTCP实现应该尝试协商该连接的MPTCP。请注意，不一定启用多路径传输，因为它需要两端系统的支持，路径上没有阻止任何附加信令的中间盒，以及至少一个具有多个地址的端点。
Building on the backward compatibility specified in Section 4.2.1, if an application enables MPTCP but binds to a specific address or interface, MPTCP MUST be enabled, but MPTCP MUST respect the application's choice and only use addresses that are explicitly provided by the application. Note that it would be possible for an application to use the legacy bindings and then expand on them by using TCP_MULTIPATH_ADD. Note also that it is possible for more than one local address to be initially available to MPTCP in this case, if an application has bound to a specific interface with multiple addresses.
基于第4.2.1节中规定的向后兼容性，如果应用程序启用MPTCP但绑定到特定地址或接口，则必须启用MPTCP，但MPTCP必须尊重应用程序的选择，并且仅使用应用程序明确提供的地址。请注意，应用程序可以使用遗留绑定，然后使用TCP_MULTIPATH_ADD对其进行扩展。还请注意，在这种情况下，如果应用程序已绑定到具有多个地址的特定接口，则MPTCP最初可以使用多个本地地址。
An application can disable MPTCP by setting TCP_MULTIPATH_ENABLE to a value of "false". In that case, MPTCP MUST NOT be used on that connection.
应用程序可以通过将TCP_MULTIPATH_ENABLE设置为“false”值来禁用MPTCP。在这种情况下，不得在该连接上使用MPTCP。
After connection establishment, an application can get the value of TCP_MULTIPATH_ENABLE. A value of "false" then means lack of MPTCP support. A value of "true" means that MPTCP is supported.
建立连接后，应用程序可以获得TCP_MULTIPATH_ENABLE的值。值为“false”则表示缺少MPTCP支持。值“true”表示支持MPTCP。
Before connection establishment, an application can use the TCP_MULTIPATH_ADD function to indicate a set of local IP addresses that MPTCP may bind to. The parameter of the function is a list of addresses in a corresponding data structure. By extension, this operation will also control the list of addresses that can be advertised to the peer via MPTCP signaling.
在建立连接之前，应用程序可以使用TCP_MULTIPATH_ADD函数来指示MPTCP可以绑定到的一组本地IP地址。函数的参数是相应数据结构中的地址列表。通过扩展，该操作还将控制可通过MPTCP信令向对等方通告的地址列表。
If an application binds to a specific address or interface, it is not required to use the TCP_MULTIPATH_ADD operation for that address. As explained in Section 5.3.2, MPTCP MUST only use the explicitly specified addresses in that case.
如果应用程序绑定到特定地址或接口，则不需要对该地址使用TCP\u MULTIPATH\u ADD操作。如第5.3.2节所述，在这种情况下，MPTCP只能使用明确指定的地址。
An application MAY also indicate a TCP port number that, if specified, MPTCP MUST attempt to bind to. The port number MAY be different than the one used by existing subflows. If no port number is provided by the application, the port number is automatically selected by the MPTCP implementation, and it is RECOMMENDED that it is the same across all subflows.
应用程序还可以指示MPTCP必须尝试绑定的TCP端口号（如果指定）。端口号可能与现有子流使用的端口号不同。如果应用程序未提供端口号，则MPTCP实现会自动选择端口号，建议所有子流的端口号相同。
This operation can also be used to modify the address list in use during the lifetime of an MPTCP connection. In this case, it is used to indicate a set of additional local addresses that the MPTCP connection can make use of and that can be signaled to the peer. It should be noted that this signal is only a hint, and an MPTCP implementation MAY select only a subset of the addresses.
此操作还可用于修改MPTCP连接生存期内使用的地址列表。在这种情况下，它用于指示MPTCP连接可以使用并且可以用信号通知对等方的一组附加本地地址。应该注意，该信号只是一个提示，MPTCP实现可能只选择地址的子集。
The TCP_MULTIPATH_REMOVE operation can be used to remove a local address, or a set of local addresses, from an MPTCP connection. MPTCP MUST close any corresponding subflows (i.e., those using the local address that is no longer present) and signal the removal of the address to the peer. If alternative paths are available using the supplied address list but MPTCP is not currently using them, an MPTCP implementation SHOULD establish alternative subflows before undertaking the address removal.
TCP_MULTIPATH_REMOVE操作可用于从MPTCP连接中删除本地地址或一组本地地址。MPTCP必须关闭任何相应的子流（即使用不再存在的本地地址的子流），并向对等方发出删除地址的信号。如果使用提供的地址列表可以使用替代路径，但MPTCP当前未使用它们，则MPTCP实现应在执行地址删除之前建立替代子流。
It should be remembered that these operations SHOULD support both IPv4 and IPv6 addresses, potentially in the same call.
应该记住，这些操作应该支持IPv4和IPv6地址，可能在同一个呼叫中。
An application can get a list of the addresses used by the currently established subflows in an MPTCP connection by means of the read-only TCP_MULTIPATH_SUBFLOWS operation.
应用程序可以通过只读TCP_MULTIPATH_子流操作获取MPTCP连接中当前建立的子流使用的地址列表。
The return value is a list of pairs of tuples of IP address and TCP port number. In one pair, the first tuple refers to the local IP address and the local TCP port, and the second one to the remote IP address and remote TCP port used by the subflow. The list MUST only include established subflows. Both addresses in each pair MUST be either IPv4 or IPv6.
返回值是IP地址和TCP端口号的元组对的列表。在一对中，第一个元组表示本地IP地址和本地TCP端口，第二个元组表示子流使用的远程IP地址和远程TCP端口。该列表必须仅包括已建立的子流。每对中的两个地址都必须是IPv4或IPv6。
An application that wants a unique identifier for the connection, analogous to an (address, port) pair in regular TCP, can query the TCP_MULTIPATH_CONNID value to get a local connection identifier for the MPTCP connection.
需要连接的唯一标识符（类似于常规TCP中的（地址、端口）对）的应用程序可以查询TCP_MULTIPATH_CONNID值以获取MPTCP连接的本地连接标识符。
This SHOULD be an integer number and SHOULD be locally unique (e.g., the MPTCP token).
这应该是一个整数，并且应该是本地唯一的（例如，MPTCP令牌）。
Transport Layer Security (TLS) [17] may be used over MPTCP's basic API. When TLS compares any addresses used by MPTCP against names or addresses present in X.509 certificates [18] [19], it MUST only compare them with the address that MPTCP used to start the initial subflow as presented to TLS. The addresses used for subsequent subflows need not to be compared against any TLS certificate information. Finer-grained control would require an advanced API or proactive subflow management via the basic API.
传输层安全性（TLS）[17]可通过MPTCP的基本API使用。当TLS将MPTCP使用的任何地址与X.509证书[18][19]中的名称或地址进行比较时，它只能将它们与MPTCP用于启动初始子流的地址进行比较，如向TLS提供的那样。用于后续子流的地址无需与任何TLS证书信息进行比较。更细粒度的控制需要高级API或通过基本API进行主动子流管理。
For dealing with multihoming, several sockets API extensions have been defined for SCTP [13]. As MPTCP realizes multipath transport from and to multihomed end systems, some of these interface function calls are actually applicable to MPTCP in a similar way.
为了处理多宿主，已经为SCTP定义了几个套接字API扩展[13]。由于MPTCP实现了从多宿终端系统到多宿终端系统的多路径传输，其中一些接口函数调用实际上以类似的方式适用于MPTCP。
API developers may wish to integrate SCTP and MPTCP calls to provide a consistent interface to the application. Yet, it must be emphasized that the transport service provided by MPTCP is different than that of SCTP, and this is why not all SCTP API functions can be mapped directly to MPTCP. Furthermore, a network stack implementing MPTCP does not necessarily support SCTP and its specific sockets interface extensions. This is why the basic API of MPTCP defines additional socket options only, which are a backward-compatible extension of TCP's application interface. Integration with the SCTP API is outside the scope of the basic API.
API开发人员可能希望集成SCTP和MPTCP调用，以便为应用程序提供一致的接口。然而，必须强调的是，MPTCP提供的传输服务不同于SCTP，这就是为什么并非所有SCTP API函数都可以直接映射到MPTCP的原因。此外，实现MPTCP的网络堆栈不一定支持SCTP及其特定套接字接口扩展。这就是MPTCP的基本API仅定义附加套接字选项的原因，这些选项是TCP应用程序接口的向后兼容扩展。与SCTP API的集成超出了基本API的范围。
The use of MPTCP can interact with various related sockets API extensions. The use of a multihoming shim layer conflicts with multipath transport such as MPTCP or SCTP [11]. Care should be taken that the use of MPTCP not conflict with the overlapping features of other APIs:
MPTCP的使用可以与各种相关的套接字API扩展交互。使用多归属垫片层与多路径传输（如MPTCP或SCTP）冲突[11]。应注意，MPTCP的使用不得与其他API的重叠功能冲突：
o SHIM API [11]: This API specifies sockets API extensions for the multihoming shim layer.
o SHIM API[11]：此API指定多宿主垫片层的套接字API扩展。
o HIP API [12]: The Host Identity Protocol (HIP) also results in a new API.
o HIPAPI[12]：主机标识协议（HIP）也会产生一个新的API。
o API for Mobile IPv6 [10]: For Mobile IPv6, a significantly extended sockets API exists as well (in addition to API extensions for IPv6 [9]).
o 移动IPv6的API[10]：对于移动IPv6，还存在显著扩展的套接字API（除了IPv6的API扩展[9]）。
In order to avoid any conflict, multiaddressed MPTCP SHOULD NOT be enabled if a network stack uses SHIM6, HIP, or Mobile IPv6. Furthermore, applications should not try to use both the MPTCP API and another multihoming or mobility layer API.
为了避免任何冲突，如果网络堆栈使用SHIM6、HIP或移动IPv6，则不应启用多寻址MPTCP。此外，应用程序不应尝试同时使用MPTCP API和另一个多主或移动层API。
It is possible, however, that some of the MPTCP functionality, such as congestion control, could be used in a SHIM6 or HIP environment. Such operation is for further study.
然而，一些MPTCP功能（如拥塞控制）可能会在SHIM6或HIP环境中使用。此类操作有待进一步研究。
In multihomed or multiaddressed environments, there are various issues that are not specific to MPTCP but have to be considered as well. These problems are summarized in [14].
在多址或多址环境中，有各种问题不是MPTCP特有的，但也必须加以考虑。这些问题总结在[14]中。
Specifically, there can be interactions with DNS. Whilst it is expected that an application will iterate over the list of addresses returned from a call such as getaddrinfo(), MPTCP itself MUST NOT make any assumptions about multiple A or AAAA records from the same DNS query referring to the same host, as it is possible that multiple addresses refer to multiple servers for load-balancing purposes.
具体来说，可以与DNS进行交互。虽然预计应用程序将迭代从调用（如getaddrinfo（））返回的地址列表，但MPTCP本身不得对来自同一DNS查询的引用同一主机的多个a或AAAA记录作出任何假设，因为出于负载平衡的目的，多个地址可能引用多个服务器。
This document first defines the behavior of the standard TCP/IP API for MPTCP-unaware applications. In general, enabling MPTCP has some security implications for applications, which are introduced in Section 5.3.3, and these threats are further detailed in [6]. The protocol specification of MPTCP [5] defines several mechanisms to protect MPTCP against those attacks.
本文档首先定义了MPTCP应用程序的标准TCP/IP API的行为。一般来说，启用MPTCP会对应用程序产生一些安全影响，这些影响将在第5.3.3节中介绍，这些威胁将在[6]中进一步详细说明。MPTCP[5]的协议规范定义了几种机制来保护MPTCP免受这些攻击。
The syntax and semantics of the API for MPTCP-unaware applications does not change. However, assumptions that non-MPTCP-aware applications may make on the data retrieved by the backward-compatible API are discussed in Section 4.2.2. System administrators may wish to disable MPTCP for certain applications that signal addresses, or make security decisions (e.g., opening firewall holes), based on responses to such queries.
MPTCP应用程序API的语法和语义不变。然而，第4.2.2节讨论了非MPTCP感知应用程序可能对向后兼容API检索的数据做出的假设。系统管理员可能希望对某些发送地址信号的应用程序禁用MPTCP，或根据对此类查询的响应做出安全决策（例如打开防火墙漏洞）。
In addition, the basic MPTCP API for MPTCP-aware applications defines functions that provide an equivalent level of control and information as exists for regular TCP. This document does not mandate a specific implementation of the basic MPTCP API. The implementation should be designed not to affect memory management assumptions in existing code. Implementors should take into account that data structures will be more complex than for standard TCP, e.g., when multiple
此外，MPTCP感知应用程序的基本MPTCPAPI定义了提供与常规TCP相同级别的控制和信息的函数。本文件不强制要求具体实施基本MPTCP API。实现的设计不应影响现有代码中的内存管理假设。实现者应该考虑到数据结构将比标准TCP更复杂，例如，当多个
subflow addresses have to be stored. When dealing with such data structures, care is needed not to add security vulnerabilities to applications.
必须存储子流地址。在处理此类数据结构时，需要注意不要给应用程序添加安全漏洞。
New functions enable adding and removing local addresses from an MPTCP connection (TCP_MULTIPATH_ADD and TCP_MULTIPATH_REMOVE). These functions don't add security threats if the MPTCP stack verifies that the addresses provided by the application are indeed available as source addresses for subflows.
新函数支持从MPTCP连接添加和删除本地地址（TCP_MULTIPATH_ADD和TCP_MULTIPATH_REMOVE）。如果MPTCP堆栈验证应用程序提供的地址确实可用作子流的源地址，则这些函数不会添加安全威胁。
However, applications should use the TCP_MULTIPATH_ADD function with care, as new subflows might get established to those addresses. Furthermore, it could result in some form of information leakage since MPTCP might advertise those addresses to the other connection endpoint, which could learn IP addresses of interfaces that are not visible otherwise.
但是，应用程序应谨慎使用TCP_MULTIPATH_ADD函数，因为这些地址可能会建立新的子流。此外，它可能会导致某种形式的信息泄漏，因为MPTCP可能会将这些地址通告给另一个连接端点，而另一个端点可能会了解其他情况下不可见的接口的IP地址。
Use of different addresses should not be assumed to lead to use of different paths, especially for security purposes.
不应假设使用不同的地址会导致使用不同的路径，尤其是出于安全目的。
MPTCP-aware applications should also take care when querying and using information about the addresses used by subflows (TCP_MULTIPATH_SUBFLOWS). As MPTCP can dynamically open and close subflows, a list of addresses queried once can get outdated during the lifetime of an MPTCP connection. Then, the list may contain invalid entries, i.e., addresses that are not used any more or that might not even be assigned to that host any more. Applications that want to ensure that MPTCP only uses a certain set of addresses should explicitly bind to those addresses.
MPTCP感知应用程序在查询和使用有关子流（TCP_多路径_子流）所使用地址的信息时也应小心。由于MPTCP可以动态打开和关闭子流，因此在MPTCP连接的生存期内，一次查询的地址列表可能会过时。然后，该列表可能包含无效条目，即不再使用或甚至可能不再分配给该主机的地址。要确保MPTCP只使用某一组地址的应用程序应显式绑定到这些地址。
One specific example is the use TLS on top of MPTCP. Corresponding guidance can be found in Section 6.1.
一个具体的例子是在MPTCP之上使用TLS。相关指南见第6.1节。
This document discusses MPTCP's implications and its performance impact on applications. In addition, it specifies a basic MPTCP API. For legacy applications, it is ensured that the existing sockets API continues to work. MPTCP-aware applications can use the basic MPTCP API that provides some control over the transport layer equivalent to regular TCP.
本文档讨论MPTCP的含义及其对应用程序的性能影响。此外，它还指定了一个基本的MPTCPAPI。对于遗留应用程序，可以确保现有套接字API继续工作。支持MPTCP的应用程序可以使用基本的MPTCPAPI，该API提供对传输层的某种控制，相当于常规TCP。
The authors sincerely thank the following people for their helpful comments and reviews of the document: Philip Eardley, Lavkesh Lahngir, John Leslie, Costin Raiciu, Michael Tuexen, and Javier Ubillos.
作者真诚地感谢以下人士对本文件的有益评论和评论：菲利普·埃尔德利、拉夫克什·拉恩吉尔、约翰·莱斯利、科斯汀·雷丘、迈克尔·图克森和哈维尔·乌比略斯。
Michael Scharf is supported by the German-Lab project (http://www.german-lab.de/) funded by the German Federal Ministry of Education and Research (BMBF). Alan Ford was previously supported by Roke Manor Research and by Trilogy (http://www.trilogy-project.org/), a research project (ICT-216372) partially funded by the European Community under its Seventh Framework Program.
Michael Scharf得到了德国实验室项目的支持(http://www.german-lab.de/)由德国联邦教育和研究部（BMBF）资助。艾伦·福特此前得到了罗克庄园研究院和三部曲的支持(http://www.trilogy-project.org/)，一个研究项目（ICT-216372），部分由欧洲共同体根据其第七个框架计划资助。
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[1] 《传输控制协议》，标准7，RFC 793，1981年9月。
[2] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[2] Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011.
[4] Ford，A.，Raiciu，C.，Handley，M.，Barre，S.，和J.Iyengar，“多路径TCP开发的架构指南”，RFC 61822011年3月。
[5] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013.
[5] Ford，A.，Raiciu，C.，Handley，M.，和O.Bonaventure，“具有多个地址的多路径操作的TCP扩展”，RFC 68242013年1月。
[6] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, March 2011.
[6] Bagnulo，M.，“具有多个地址的多路径操作的TCP扩展的威胁分析”，RFC 61812011年3月。
[7] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, October 2011.
[7] Raiciu，C.，Handley，M.，和D.Wischik，“多路径传输协议的耦合拥塞控制”，RFC 6356，2011年10月。
[8] "IEEE Standard for Information Technology -- Portable Operating System Interface (POSIX) Base Specifications, Issue 7", IEEE Std. 1003.1-2008, 2008.
[8] “IEEE信息技术标准——便携式操作系统接口（POSIX）基本规范，第7期”，IEEE标准1003.1-2008，2008年。
[9] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
[9] Stevens，W.，Thomas，M.，Nordmark，E.，和T.Jinmei，“IPv6的高级套接字应用程序接口（API）”，RFC 3542，2003年5月。
[10] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for Mobile IPv6", RFC 4584, July 2006.
[10] Chakrabarti，S.和E.Nordmark，“移动IPv6套接字API的扩展”，RFC 4584，2006年7月。
[11] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Sockets Application Program Interface (API) for Multihoming Shim", RFC 6316, July 2011.
[11] Komu，M.，Bagnulo，M.，Slavov，K.，和S.Sugimoto，“多主垫片的套接字应用程序接口（API）”，RFC 63161011年7月。
[12] Komu, M. and T. Henderson, "Basic Socket Interface Extensions for the Host Identity Protocol (HIP)", RFC 6317, July 2011.
[12] Komu，M.和T.Henderson，“主机标识协议（HIP）的基本套接字接口扩展”，RFC 63172011年7月。
[13] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, December 2011.
[13] Stewart，R.，Tuexen，M.，Poon，K.，Lei，P.，和V.Yasevich，“流控制传输协议（SCTP）的套接字API扩展”，RFC 6458，2011年12月。
[14] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011.
[14] Blanchet，M.和P.Seite，“多接口和供应域问题陈述”，RFC 6418，2011年11月。
[15] Wasserman, M. and P. Seite, "Current Practices for Multiple-Interface Hosts", RFC 6419, November 2011.
[15] Wasserman，M.和P.Seite，“多接口主机的当前实践”，RFC 6419，2011年11月。
[16] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.
[16] Wing，D.和A.Yourtchenko，“快乐眼球：双堆栈主机的成功”，RFC 65552012年4月。
[17] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[17] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[18] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[18] Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[19] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[19] Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务身份”，RFC 61252011年3月。
[20] Sarolahti, P., "Multi-address Interface in the Socket API", Work in Progress, March 2010.
[20] Sarolahti，P.，“套接字API中的多地址接口”，正在进行的工作，2010年3月。
[21] Khalili, R., Gast, N., Popovic, M., and J. Le Boudec, "Performance Issues with MPTCP", Work in Progress, February 2013.
[21] R.Khalili、N.Gast、M.Popovic和J.Le Boudec，“MPTCP的绩效问题”，正在进行的工作，2013年2月。
[22] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M., and H. Tokuda, "Is it Still Possible to Extend TCP?", Proc. ACM Internet Measurement Conference (IMC), November 2011.
[22] 本田，M.，西田，Y.，雷丘，C.，格林豪尔，A.，汉德利，M.，和H.德田，“仍然有可能扩展TCP吗？”，Proc。ACM互联网测量会议（IMC），2011年11月。
Multipath transport results in many degrees of freedom. The basic MPTCP API only defines a minimum set of the API extensions for the interface between the MPTCP layer and applications, which does not offer much control of the MPTCP implementation's behavior. A future, advanced API could address further features of MPTCP and provide more control.
多径传输导致多个自由度。基本的MPTCPAPI只为MPTCP层和应用程序之间的接口定义了一组最小的API扩展，这并不能对MPTCP实现的行为提供太多的控制。未来的高级API可以解决MPTCP的更多特性，并提供更多的控制。
Applications that use TCP may have different requirements on the transport layer. While developers have become used to the characteristics of regular TCP, new opportunities created by MPTCP could allow the service provided to be optimized further. An advanced API could enable MPTCP-aware applications to specify preferences and control certain aspects of the behavior, in addition to the simple control provided by the basic interface. An advanced API could also address aspects that are completely out of scope of the basic API, for example, the question of whether a receiving application could influence the sending policy. A better integration with TLS could be another relevant objective (cf. Section 6.1) that requires further work.
使用TCP的应用程序可能对传输层有不同的要求。虽然开发人员已经习惯了常规TCP的特性，但MPTCP创造的新机会可以使提供的服务得到进一步优化。除了基本接口提供的简单控制之外，高级API还可以使MPTCP感知应用程序能够指定首选项并控制行为的某些方面。高级API还可以解决完全超出基本API范围的方面，例如，接收应用程序是否会影响发送策略的问题。与TLS更好的集成可能是另一个相关目标（参见第6.1节），需要进一步工作。
Furthermore, an advanced MPTCP API could be part of a new overall interface between the network stack and applications that addresses other issues as well, such as the split between identifiers and locators. An API that does not use IP addresses (but instead uses, e.g., the connectbyname() function) would be useful for numerous purposes, independent of MPTCP.
此外，高级MPTCPAPI可以是网络堆栈和应用程序之间新的整体接口的一部分，该接口还可以解决其他问题，例如标识符和定位器之间的分离。不使用IP地址（而是使用，例如，connectbyname（）函数）的API可用于多种用途，与MPTCP无关。
It has also been suggested that a separate address family called AF_MULTIPATH [20] be used. This separate address family could be used to exchange multiple addresses between an application and the standard sockets API, but it would be a more fundamental change compared to the basic API described in this document.
也有人建议使用一个称为AF_MULTIPATH[20]的单独地址族。这个单独的地址族可用于在应用程序和标准套接字API之间交换多个地址，但与本文档中描述的基本API相比，这将是一个更根本的更改。
This appendix documents a list of potential usage scenarios and requirements for the advanced API. The specification and implementation of a corresponding API are outside the scope of this document.
本附录记录了高级API的潜在使用场景和要求列表。相应API的规范和实现不在本文档的范围内。
There are different MPTCP usage scenarios. An application that wishes to transmit bulk data will want MPTCP to provide a high-throughput service immediately, through creating and maximizing utilization of all available subflows. This is the default MPTCP use case.
有不同的MPTCP使用场景。希望传输大容量数据的应用程序希望MPTCP通过创建并最大限度地利用所有可用子流，立即提供高吞吐量服务。这是默认的MPTCP用例。
But at the other extreme, there are applications that are highly interactive but require only a small amount of throughput, and these are optimally served by low latency and jitter stability. In such a situation, it would be preferable for the traffic to use only the lowest-latency subflow (assuming it has sufficient capacity), maybe with one or two additional subflows for resilience and recovery purposes. The key challenge for such a strategy is that the delay on a path may fluctuate significantly and that just always selecting the path with the smallest delay might result in instability.
但在另一个极端，有些应用程序具有高度的交互性，但只需要少量的吞吐量，这些应用程序的最佳服务方式是低延迟和抖动稳定性。在这种情况下，业务流最好仅使用最低延迟子流（假设其具有足够的容量），出于恢复和恢复目的，可能还有一个或两个附加子流。这种策略的关键挑战是，路径上的延迟可能会显著波动，而总是选择延迟最小的路径可能会导致不稳定。
The choice between bulk data transport and latency-sensitive transport affects the scheduler in terms of whether traffic should be, by default, sent on one subflow or across several subflows. Even if the total bandwidth required is less than that available on an individual path, it is desirable to spread this load to reduce stress on potential bottlenecks, and this is why this method should be the default for bulk data transport. However, that may not be optimal for applications that require latency/jitter stability.
批量数据传输和延迟敏感传输之间的选择会影响调度程序，因为默认情况下，流量应该在一个子流上发送还是跨多个子流发送。即使所需的总带宽小于单个路径上的可用带宽，也希望分散此负载以减少对潜在瓶颈的压力，这就是为什么此方法应为批量数据传输的默认方法。但是，对于需要延迟/抖动稳定性的应用程序来说，这可能不是最佳选择。
In the case of the latter option, a further question arises: Should additional subflows be used whenever the primary subflow is overloaded, or only when the primary path fails (hot standby)? In other words, is latency stability or bandwidth more important to the application? This results in two different options: Firstly, there is the single path that can overflow into an additional subflow; and secondly, there is the single path with hot standby, whereby an application may want an alternative backup subflow in order to improve resilience. In case data delivery on the first subflow fails, the data transport could immediately be continued on the second subflow, which is idle otherwise.
在后一个选项的情况下，会出现另一个问题：当主子流过载时，还是仅当主路径出现故障时（热备用），才应使用附加子流？换句话说，延迟稳定性或带宽对应用程序更重要吗？这导致了两种不同的选择：首先，有一条路径可以溢出到额外的子流中；其次，还有热备用的单路径，因此应用程序可能需要备用备份子流以提高恢复能力。如果第一个子流上的数据传输失败，则可以立即在第二个子流上继续数据传输，否则第二个子流将处于空闲状态。
Yet another complication is introduced with the potential that MPTCP introduces for changes in available bandwidth as the number of available subflows changes. Such jitter in bandwidth may prove confusing for some applications, such as video or audio streaming, that dynamically adapt codecs based on available bandwidth. Such applications may prefer MPTCP to attempt to provide a consistent bandwidth as far as is possible and avoid maximizing the use of all subflows.
随着可用子流数量的变化，MPTCP可能会带来可用带宽的变化，这又带来了另一个复杂性。这种带宽抖动可能会让一些应用程序感到困惑，例如视频或音频流，这些应用程序根据可用带宽动态调整编解码器。此类应用程序可能希望MPTCP尽可能提供一致的带宽，并避免最大限度地使用所有子流。
A further, mostly orthogonal question is whether data should be duplicated over the different subflows, in particular if there is spare capacity. This could improve both the timeliness and reliability of data delivery.
另一个主要是正交的问题是，是否应在不同的子流上复制数据，特别是在存在备用容量的情况下。这可以提高数据交付的及时性和可靠性。
In summary, there are at least three possible performance objectives for multipath transport:
总之，多路径传输至少有三个可能的性能目标：
1. High bandwidth
1. 高带宽
2. Low latency and jitter stability
2. 低延迟和抖动稳定性
3. High reliability
3. 高可靠性
These are not necessarily disjoint, since there are also broadband interactive applications that require both high-speed bulk data traffic and a low latency and jitter.
这些不一定是不相交的，因为也有宽带交互应用程序需要高速大容量数据流量和低延迟和抖动。
In an advanced API, applications could provide high-level guidance to the MPTCP implementation concerning these performance requirements, for instance, which requirement is considered to be the most important. The MPTCP stack would then use internal mechanisms to fulfill this abstract indication of a desired service, as far as possible. This would affect the assignment of data (including retransmissions) to existing subflows (e.g., 'use all in parallel', 'use as overflow', 'hot standby', 'duplicate traffic') as well as the decisions regarding when to set up additional subflows to which addresses. In both cases, different policies can exist, which can be expected to be implementation-specific.
在高级API中，应用程序可以为MPTCP实现提供有关这些性能要求的高级指导，例如，哪个要求被认为是最重要的。然后，MPTCP堆栈将尽可能使用内部机制来实现所需服务的抽象指示。这将影响将数据（包括重传）分配到现有子流（例如，“并行使用所有”、“用作溢出”、“热备用”、“重复通信”）以及关于何时设置附加子流的决定。在这两种情况下，可能存在不同的政策，这些政策可能是针对具体实施的。
Therefore, an advanced API could provide a mechanism for how applications can specify their high-level requirements in an implementation-independent way. One possibility would be to select one "application profile" out of a number of choices that characterize typical applications. Yet, as applications today do not have to inform TCP about their communication requirements, it requires further studies as to whether such an approach would be realistic.
因此，高级API可以提供一种机制，用于应用程序如何以独立于实现的方式指定其高级需求。一种可能性是，从一系列描述典型应用的选项中选择一个“应用程序配置文件”。然而，由于当今的应用程序不必将其通信需求告知TCP，因此需要进一步研究这种方法是否可行。
Of course, independent of an advanced API, such functionality could also partly be achieved by MPTCP-internal heuristics that infer some application preferences, e.g., from existing socket options, such as TCP_NODELAY. Whether this would be reliable, and indeed appropriate, is for further study.
当然，独立于高级API，这种功能也可以部分地通过MPTCP内部试探法来实现，该试探法可以推断一些应用程序偏好，例如，从现有套接字选项（如TCP_NODELAY）中推断。这是否可靠，是否恰当，有待进一步研究。
The following is a list of potential requirements for an advanced MPTCP API beyond the features of the basic API. It is included here for information only:
以下是高级MPTCP API的潜在需求列表，超出了基本API的功能。此处包含的内容仅供参考：
REQ5: An application should be able to establish MPTCP connections without using IP addresses as locators.
要求5：应用程序应该能够建立MPTCP连接，而不使用IP地址作为定位器。
REQ6: An application should be able to obtain usage information and statistics about all subflows (e.g., ratio of traffic sent via this subflow).
请求6：应用程序应能够获取所有子流的使用信息和统计信息（例如，通过该子流发送的流量比率）。
REQ7: An application should be able to request a change in the number of subflows in use, thus triggering removal or addition of subflows. An even finer control granularity would be a request for the establishment of a specific subflow to a provided destination or a request for the termination of a specified, existing subflow.
请求7：应用程序应该能够请求更改正在使用的子流的数量，从而触发子流的删除或添加。更精细的控制粒度将是请求建立到所提供目的地的特定子流，或者请求终止指定的现有子流。
REQ8: An application should be able to inform the MPTCP implementation about its high-level performance requirements, e.g., in the form of a profile.
需求8：应用程序应该能够以概要文件的形式通知MPTCP实现其高级性能需求。
REQ9: An application should be able to indicate communication characteristics, e.g., the expected amount of data to be sent, the expected duration of the connection, or the expected rate at which data is provided. Applications may in some cases be able to forecast such properties. If so, such information could be an additional input parameter for heuristics inside the MPTCP implementation, which could be useful, for example, to decide when to set up additional subflows.
请求9：应用程序应能够指示通信特性，例如，要发送的预期数据量、连接的预期持续时间或提供数据的预期速率。在某些情况下，应用程序可能能够预测此类属性。如果是这样的话，这些信息可能是MPTCP实现内部启发式的一个额外输入参数，例如，这可能有助于决定何时设置额外的子流。
REQ10: An application should be able to control the automatic establishment/termination of subflows. This would imply a selection among different heuristics of the path manager, e.g., 'try as soon as possible', 'wait until there is a bunch of data', etc.
请求10：应用程序应能够控制子流的自动建立/终止。这意味着在路径管理器的不同启发式中进行选择，例如，“尽快尝试”、“等待直到有一堆数据”等。
REQ11: An application should be able to set preferred subflows or subflow usage policies. This would result in a selection among different configurations of the multipath scheduler. For instance, an application might want to use certain subflows as backup only.
请求11：应用程序应能够设置首选子流或子流使用策略。这将导致在多路径调度器的不同配置之间进行选择。例如，应用程序可能希望仅将某些子流用作备份。
REQ12: An application should be able to control the level of redundancy by telling whether segments should be sent on more than one path in parallel.
REQ12：应用程序应能够通过告知是否应在多条路径上并行发送段来控制冗余级别。
REQ13: An application should be able to control the use of fate-sharing of the MPTCP connection and the initial subflow, e.g., to overwrite system policies.
REQ13：应用程序应该能够控制MPTCP连接和初始子流的命运共享的使用，例如覆盖系统策略。
REQ14: An application should be able to register for callbacks to be informed of changes to subflows on an MPTCP connection. This "push" interface would allow the application to make timely logging and configuration changes, if required, and would avoid frequent polling of information.
REQ14：应用程序应该能够注册回调，以便在MPTCP连接上通知子流的更改。此“推送”接口允许应用程序在需要时及时进行日志记录和配置更改，并避免频繁轮询信息。
An advanced API fulfilling these requirements would allow application developers to more specifically configure MPTCP. It could avoid suboptimal decisions of internal, implicit heuristics. However, it is unclear whether all of these requirements would have a significant benefit to applications, since they are going above and beyond what the existing API to regular TCP provides.
满足这些要求的高级API将允许应用程序开发人员更具体地配置MPTCP。它可以避免内部隐式启发式的次优决策。然而，目前尚不清楚所有这些需求是否会对应用程序产生重大的好处，因为它们超出了常规TCP的现有API所提供的范围。
A subset of these functions might also be implemented system-wide or by other configuration mechanisms. These implementation details are left for further study.
这些功能的一个子集也可以在系统范围内或通过其他配置机制实现。这些实现细节留待进一步研究。
The advanced API may also integrate or use the SCTP sockets API. The following functions that are defined for SCTP have functionality similar to the basic MPTCP API:
高级API还可以集成或使用SCTP套接字API。为SCTP定义的以下函数具有与基本MPTCP API类似的功能：
o sctp_bindx()
o sctp_bindx（）
o sctp_connectx()
o sctp_connectx（）
o sctp_getladdrs()
o sctp_getladdrs（）
o sctp_getpaddrs()
o sctp_getpaddrs（）
o sctp_freeladdrs()
o sctp_freeladrs（）
o sctp_freepaddrs()
o sctp_freepaddrs（）
The syntax and semantics of these functions are described in [13].
[13]中描述了这些函数的语法和语义。
A potential objective for the advanced API is to provide a consistent MPTCP and SCTP interface to the application. This is left for further study.
高级API的一个潜在目标是为应用程序提供一致的MPTCP和SCTP接口。这有待进一步研究。
Authors' Addresses
作者地址
Michael Scharf Alcatel-Lucent Bell Labs Lorenzstrasse 10 70435 Stuttgart Germany
Michael Scharf Alcatel-Lucent Bell实验室Lorenzstrasse 10 70435德国斯图加特
EMail: michael.scharf@alcatel-lucent.com
EMail: michael.scharf@alcatel-lucent.com
Alan Ford Cisco Ruscombe Business Park Ruscombe, Berkshire RG10 9NN UK
艾伦·福特思科罗斯科姆商业园罗斯科姆，伯克希尔RG10 9NN英国
EMail: alanford@cisco.com
EMail: alanford@cisco.com