Internet Engineering Task Force (IETF) A. Ford
Request for Comments: 6182 Roke Manor Research
Category: Informational C. Raiciu
ISSN: 2070-1721 M. Handley
University College London
S. Barre
Universite catholique de Louvain
J. Iyengar
Franklin and Marshall College
March 2011
Internet Engineering Task Force (IETF) A. Ford
Request for Comments: 6182 Roke Manor Research
Category: Informational C. Raiciu
ISSN: 2070-1721 M. Handley
University College London
S. Barre
Universite catholique de Louvain
J. Iyengar
Franklin and Marshall College
March 2011
Architectural Guidelines for Multipath TCP Development
多路径TCP开发的体系结构指南
Abstract
摘要
Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput.
主机通常通过多条路径连接，但TCP将每个传输连接的通信限制为一条路径。如果这些多条路径能够同时使用，网络中的资源使用将更加高效。这将通过提高对网络故障的恢复能力和更高的吞吐量来增强用户体验。
This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of a Multipath TCP (MPTCP). This document lists certain high-level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements.
本文档概述了开发多路径传输协议的体系结构指南，并参考了在开发多路径TCP（MPTCP）过程中这些体系结构组件是如何结合在一起的。本文件列出了某些高层设计决策，这些决策为基于这些体系结构要求的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/rfc6182.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6182.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 ....................................................4
1.1. Requirements Language ......................................5
1.2. Terminology ................................................5
1.3. Reference Scenario .........................................6
2. Goals ...........................................................6
2.1. Functional Goals ...........................................6
2.2. Compatibility Goals ........................................7
2.2.1. Application Compatibility ...........................7
2.2.2. Network Compatibility ...............................8
2.2.3. Compatibility with Other Network Users .............10
2.3. Security Goals ............................................10
2.4. Related Protocols .........................................10
3. An Architectural Basis for Multipath TCP .......................11
4. A Functional Decomposition of MPTCP ............................12
5. High-Level Design Decisions ....................................14
5.1. Sequence Numbering ........................................14
5.2. Reliability and Retransmissions ...........................15
5.3. Buffers ...................................................17
5.4. Signaling .................................................18
5.5. Path Management ...........................................19
5.6. Connection Identification .................................20
5.7. Congestion Control ........................................21
5.8. Security ..................................................21
6. Software Interactions ..........................................23
6.1. Interactions with Applications ............................23
6.2. Interactions with Management Systems ......................23
7. Interactions with Middleboxes ..................................23
8. Contributors ...................................................25
9. Acknowledgements ...............................................25
10. Security Considerations .......................................26
11. References ....................................................26
11.1. Normative References .....................................26
11.2. Informative References ...................................26
1. Introduction ....................................................4
1.1. Requirements Language ......................................5
1.2. Terminology ................................................5
1.3. Reference Scenario .........................................6
2. Goals ...........................................................6
2.1. Functional Goals ...........................................6
2.2. Compatibility Goals ........................................7
2.2.1. Application Compatibility ...........................7
2.2.2. Network Compatibility ...............................8
2.2.3. Compatibility with Other Network Users .............10
2.3. Security Goals ............................................10
2.4. Related Protocols .........................................10
3. An Architectural Basis for Multipath TCP .......................11
4. A Functional Decomposition of MPTCP ............................12
5. High-Level Design Decisions ....................................14
5.1. Sequence Numbering ........................................14
5.2. Reliability and Retransmissions ...........................15
5.3. Buffers ...................................................17
5.4. Signaling .................................................18
5.5. Path Management ...........................................19
5.6. Connection Identification .................................20
5.7. Congestion Control ........................................21
5.8. Security ..................................................21
6. Software Interactions ..........................................23
6.1. Interactions with Applications ............................23
6.2. Interactions with Management Systems ......................23
7. Interactions with Middleboxes ..................................23
8. Contributors ...................................................25
9. Acknowledgements ...............................................25
10. Security Considerations .......................................26
11. References ....................................................26
11.1. Normative References .....................................26
11.2. Informative References ...................................26
As the Internet evolves, demands on Internet resources are ever-increasing, but often these resources (in particular, bandwidth) cannot be fully utilized due to protocol constraints both on the end-systems and within the network. If these resources could be used concurrently, end user experience could be greatly improved. Such enhancements would also reduce the necessary expenditure on network infrastructure that would otherwise be needed to create an equivalent improvement in user experience. By the application of resource pooling [3], these available resources can be 'pooled' such that they appear as a single logical resource to the user.
随着互联网的发展，对互联网资源的需求不断增加，但由于终端系统和网络内的协议限制，这些资源（特别是带宽）往往无法充分利用。如果这些资源可以同时使用，最终用户体验将大大改善。这些改进还将减少网络基础设施方面的必要支出，否则就需要这些基础设施来改善用户体验。通过应用资源池[3]，这些可用资源可以被“池化”，以便它们在用户看来是单个逻辑资源。
Multipath transport aims to realize some of the goals of resource pooling by simultaneously making use of multiple disjoint (or partially disjoint) paths across a network. The two key benefits of multipath transport are the following:
多径传输的目的是通过在网络上同时使用多条不相交（或部分不相交）的路径来实现资源池的一些目标。多路径传输的两个主要好处如下：
o To increase the resilience of the connectivity by providing multiple paths, protecting end hosts from the failure of one.
o 通过提供多条路径提高连接的恢复能力，保护终端主机免受一条路径故障的影响。
o To increase the efficiency of the resource usage, and thus increase the network capacity available to end hosts.
o 提高资源使用效率，从而增加终端主机可用的网络容量。
Multipath TCP is a modified version of TCP [1] that implements a multipath transport and achieves these goals by pooling multiple paths within a transport connection, transparently to the application. Multipath TCP is primarily concerned with utilizing multiple paths end-to-end, where one or both of the end hosts are multihomed. It may also have applications where multiple paths exist within the network and can be manipulated by an end host, such as using different port numbers with Equal Cost MultiPath (ECMP) [4].
多路径TCP是TCP[1]的一个修改版本，它实现了多路径传输，并通过在传输连接中共享多条路径来实现这些目标，对应用程序来说是透明的。多路径TCP主要涉及端到端利用多条路径，其中一个或两个终端主机是多址的。它还可能具有网络中存在多条路径且可由终端主机操纵的应用，例如使用不同端口号的等成本多路径（ECMP）[4]。
MPTCP, defined in [5], is a specific protocol that instantiates the Multipath TCP concept. This document looks both at general architectural principles for a Multipath TCP fulfilling the goals described in Section 2, as well as the key design decisions behind MPTCP, which are detailed in Section 5.
在[5]中定义的MPTCP是一种具体的协议，它实例化了多路径TCP概念。本文档既介绍了实现第2节所述目标的多路径TCP的一般架构原则，也介绍了MPTCP背后的关键设计决策，详见第5节。
Although multihoming and multipath functions are not new to transport protocols (Stream Control Transmission Protocol (SCTP) [6] being a notable example), MPTCP aims to gain wide-scale deployment by recognizing the importance of application and network compatibility goals. These goals, discussed in detail in Section 2, relate to the appearance of MPTCP to the network (so non-MPTCP-aware entities see it as TCP) and to the application (through providing a service equivalent to TCP for non-MPTCP-aware applications).
虽然多归属和多路径功能对于传输协议（流控制传输协议（SCTP）[6]是一个显著的例子）并不陌生，但MPTCP旨在通过认识到应用程序和网络兼容性目标的重要性来实现大规模部署。第2节详细讨论了这些目标，它们与MPTCP在网络中的出现（因此非MPTCP感知实体将其视为TCP）和应用程序（通过为非MPTCP感知应用程序提供与TCP等效的服务）有关。
This document has three key purposes: (i) it describes goals for a multipath transport -- goals that MPTCP is designed to meet; (ii) it lays out an architectural basis for MPTCP's design -- a discussion that applies to other multipath transports as well; and (iii) it discusses and documents high-level design decisions made in MPTCP's development, and considers their implications.
本文档有三个主要目的：（i）它描述了多路径传输的目标——MPTCP设计要达到的目标；（ii）它为MPTCP的设计奠定了架构基础——这一讨论也适用于其他多路径传输；（iii）讨论并记录MPTCP开发过程中做出的高层设计决策，并考虑其影响。
Companion documents to this architectural overview are those that provide details of the protocol extensions [5], congestion control algorithms [7], and application-level considerations [8]. Put together, these components specify a complete Multipath TCP design. Note that specific components are replaceable in accordance with the layer and functional decompositions discussed in this document.
本体系结构概述的配套文档提供了协议扩展[5]、拥塞控制算法[7]和应用程序级注意事项[8]的详细信息。这些组件共同指定了一个完整的多路径TCP设计。请注意，根据本文档中讨论的层和功能分解，特定组件是可更换的。
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 RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
Regular/Single-Path TCP: The standard version of TCP [1] in use today, operating between a single pair of IP addresses and ports.
常规/单路径TCP：目前使用的TCP[1]的标准版本，在一对IP地址和端口之间运行。
Multipath TCP: A modified version of the TCP protocol that supports the simultaneous use of multiple paths between hosts.
多路径TCP：TCP协议的修改版本，支持主机之间同时使用多条路径。
Path: A sequence of links between a sender and a receiver, defined in this context by a source and destination address pair.
路径：发送方和接收方之间的一系列链接，在此上下文中由源地址对和目标地址对定义。
Host: An end host either initiating or terminating a Multipath TCP connection.
主机：启动或终止多路径TCP连接的终端主机。
MPTCP: The proposed protocol extensions specified in [5] to provide a Multipath TCP implementation.
MPTCP：在[5]中指定的提议的协议扩展，用于提供多路径TCP实现。
Subflow: A flow of TCP segments operating over an individual path, which forms part of a larger Multipath TCP connection.
子流：在单个路径上运行的TCP段流，它构成较大的多路径TCP连接的一部分。
(Multipath TCP) Connection: A set of one or more subflows combined to provide a single Multipath TCP service to an application at a host.
（多路径TCP）连接：一组由一个或多个子流组成的连接，用于向主机上的应用程序提供单个多路径TCP服务。
The diagram shown in Figure 1 illustrates a typical usage scenario for Multipath TCP. Two hosts, A and B, are communicating with each other. These hosts are multihomed and multi-addressed, providing two disjoint connections to the Internet. The addresses on each host are referred to as A1, A2, B1, and B2. There are therefore up to four different paths between the two hosts: A1-B1, A1-B2, A2-B1, A2-B2.
图1所示的图表说明了多路径TCP的典型使用场景。两台主机A和B正在相互通信。这些主机是多址和多址的，提供两个到Internet的不相交连接。每个主机上的地址称为A1、A2、B1和B2。因此，两台主机之间最多有四条不同的路径：A1-B1、A1-B2、A2-B1、A2-B2。
+------+ __________ +------+
| |A1 ______ ( ) ______ B1| |
| Host |--/ ( ) \--| Host |
| | ( Internet ) | |
| A |--\______( )______/--| B |
| |A2 (__________) B2| |
+------+ +------+
+------+ __________ +------+
| |A1 ______ ( ) ______ B1| |
| Host |--/ ( ) \--| Host |
| | ( Internet ) | |
| A |--\______( )______/--| B |
| |A2 (__________) B2| |
+------+ +------+
Figure 1: Simple Multipath TCP Usage Scenario
图1：简单的多路径TCP使用场景
The scenario could have any number of addresses (1 or more) on each host, as long as the number of paths available between the two hosts is 2 or more (i.e., num_addr(A) * num_addr(B) > 1). The paths created by these address combinations through the Internet need not be entirely disjoint -- potential fairness issues introduced by shared bottlenecks need to be handled by the Multipath TCP congestion controller. Furthermore, the paths through the Internet often do not provide a pure end-to-end service, and instead may be affected by middleboxes such as NATs and firewalls.
只要两台主机之间可用的路径数为2或更多（即num_addr（A）*num_addr（B）>1），该场景中的每台主机上可以有任意数量的地址（1或更多）。这些地址组合通过Internet创建的路径不必完全不相交——共享瓶颈带来的潜在公平性问题需要由多路径TCP拥塞控制器处理。此外，通过Internet的路径通常不提供纯端到端服务，而是可能受到NAT和防火墙等中间盒的影响。
This section outlines primary goals that Multipath TCP aims to meet. These are broadly broken down into the following: functional goals, which steer services and features that Multipath TCP must provide, and compatibility goals, which determine how Multipath TCP should appear to entities that interact with it.
本节概述了多路径TCP要达到的主要目标。这些目标大致可分为以下几个方面：功能目标，用于指导多路径TCP必须提供的服务和功能；兼容性目标，用于确定多路径TCP对与其交互的实体的显示方式。
In supporting the use of multiple paths, Multipath TCP has the following two functional goals.
为了支持多路径的使用，多路径TCP有以下两个功能目标。
o Improve Throughput: Multipath TCP MUST support the concurrent use of multiple paths. To meet the minimum performance incentives for deployment, a Multipath TCP connection over multiple paths SHOULD achieve no worse throughput than a single TCP connection over the best constituent path.
o 提高吞吐量：多路径TCP必须支持多路径的并发使用。为了满足部署的最低性能激励，多路径上的多路径TCP连接的吞吐量不应低于最佳组成路径上的单个TCP连接。
o Improve Resilience: Multipath TCP MUST support the use of multiple paths interchangeably for resilience purposes, by permitting segments to be sent and re-sent on any available path. It follows that, in the worst case, the protocol MUST be no less resilient than regular single-path TCP.
o 提高恢复能力：多路径TCP必须通过允许在任何可用路径上发送和重新发送段，支持为恢复能力目的互换使用多条路径。因此，在最坏的情况下，协议的弹性必须不低于常规单路径TCP。
As distribution of traffic among available paths and responses to congestion are done in accordance with resource pooling principles [3], a secondary effect of meeting these goals is that widespread use of Multipath TCP over the Internet should improve overall network utility by shifting load away from congested bottlenecks and by taking advantage of spare capacity wherever possible.
由于可用路径之间的流量分配和拥塞响应是根据资源池原则进行的[3]，实现这些目标的第二个效果是，在互联网上广泛使用多路径TCP可以通过将负载从拥挤的瓶颈转移出去并尽可能利用备用容量来提高整体网络利用率。
Furthermore, Multipath TCP SHOULD feature automatic negotiation of its use. A host supporting Multipath TCP that requires the other host to do so too must be able to detect reliably whether this host does in fact support the required extensions, using them if so, and otherwise automatically falling back to single-path TCP.
此外，多路径TCP应具有自动协商其使用的功能。支持多路径TCP的主机需要另一台主机也这样做，该主机必须能够可靠地检测该主机是否确实支持所需的扩展，如果支持，则使用它们，否则会自动退回到单路径TCP。
In addition to the functional goals listed above, a Multipath TCP must meet a number of compatibility goals in order to support deployment in today's Internet. These goals fall into the following categories.
除了上面列出的功能目标外，多路径TCP还必须满足许多兼容性目标，以支持在当今互联网上的部署。这些目标分为以下几类。
Application compatibility refers to the appearance of Multipath TCP to the application both in terms of the API that can be used and the expected service model that is provided.
应用程序兼容性是指应用程序在可使用的API和提供的预期服务模型方面出现多路径TCP。
Multipath TCP MUST follow the same service model as TCP [1]: in-order, reliable, and byte-oriented delivery. Furthermore, a Multipath TCP connection SHOULD provide the application with no worse throughput or resilience than it would expect from running a single TCP connection over any one of its available paths. A Multipath TCP may not, however, be able to provide the same level of consistency of throughput and latency as a single TCP connection. These, and other, application considerations are discussed in detail in [8].
多路径TCP必须遵循与TCP[1]相同的服务模型：以便有序、可靠和面向字节的交付。此外，多路径TCP连接应该为应用程序提供的吞吐量或恢复能力不会比在其任何一条可用路径上运行单个TCP连接所期望的更差。但是，多路径TCP可能无法提供与单个TCP连接相同级别的吞吐量和延迟一致性。[8]中详细讨论了这些以及其他应用注意事项。
A multipath-capable equivalent of TCP MUST retain some level of backward compatibility with existing TCP APIs, so that existing applications can use the newer transport merely by upgrading the operating systems of the end hosts. This does not preclude the use of an advanced API to permit multipath-aware applications to specify
具有多路径功能的等效TCP必须与现有TCP API保持一定程度的向后兼容性，以便现有应用程序只需升级终端主机的操作系统即可使用较新的传输。这并不排除使用高级API来允许多路径感知应用程序指定
preferences, nor for users to configure their systems in a different way from the default, for example switching on or off the automatic use of multipath extensions.
也不允许用户以与默认设置不同的方式配置其系统，例如打开或关闭多路径扩展的自动使用。
It is possible for regular TCP sessions today to survive brief breaks in connectivity by retaining state at end hosts before a timeout occurs. It would be desirable to support similar session continuity in MPTCP; however, the circumstances could be different. Whilst in regular TCP the IP addresses will remain constant across the break in connectivity, in MPTCP a different interface may appear. It is desirable (but not mandated) to support this kind of "break-before-make" session continuity. This places constraints on security mechanisms, however, as discussed in Section 5.8. Timeouts for this function would be locally configured.
通过在超时发生之前保持终端主机的状态，现在的常规TCP会话可以在连接短暂中断后生存。最好在MPTCP中支持类似的会话连续性；然而，情况可能有所不同。虽然在常规TCP中，IP地址将在中断连接期间保持不变，但在MPTCP中，可能会出现不同的接口。支持这种“先断后补”的会话连续性是可取的（但不是强制性的）。然而，正如第5.8节所讨论的，这对安全机制造成了限制。此功能的超时将在本地配置。
In the traditional Internet architecture, network devices operate at the network layer and lower layers, with the layers above the network layer instantiated only at the end hosts. While this architecture, shown in Figure 2, was initially largely adhered to, this layering no longer reflects the "ground truth" in the Internet with the proliferation of middleboxes [9]. Middleboxes routinely interpose on the transport layer; sometimes even completely terminating transport connections, thus leaving the application layer as the first real end-to-end layer, as shown in Figure 3.
在传统的Internet架构中，网络设备在网络层和较低层运行，网络层之上的层仅在终端主机上实例化。虽然这种架构（如图2所示）最初在很大程度上得到了遵守，但随着中间包的激增，这种分层不再反映互联网中的“基本事实”[9]。中间盒通常插在传输层上；有时甚至完全终止传输连接，从而将应用程序层作为第一个真正的端到端层，如图3所示。
+-------------+ +-------------+
| Application |<------------ end-to-end ------------->| Application |
+-------------+ +-------------+
| Transport |<------------ end-to-end ------------->| Transport |
+-------------+ +-------------+ +-------------+ +-------------+
| Network |<->| Network |<->| Network |<->| Network |
+-------------+ +-------------+ +-------------+ +-------------+
End Host Router Router End Host
+-------------+ +-------------+
| Application |<------------ end-to-end ------------->| Application |
+-------------+ +-------------+
| Transport |<------------ end-to-end ------------->| Transport |
+-------------+ +-------------+ +-------------+ +-------------+
| Network |<->| Network |<->| Network |<->| Network |
+-------------+ +-------------+ +-------------+ +-------------+
End Host Router Router End Host
Figure 2: Traditional Internet Architecture
图2：传统互联网架构
+-------------+ +-------------+
| Application |<------------ end-to-end ------------->| Application |
+-------------+ +-------------+ +-------------+
| Transport |<------------------->| Transport |<->| Transport |
+-------------+ +-------------+ +-------------+ +-------------+
| Network |<->| Network |<->| Network |<->| Network |
+-------------+ +-------------+ +-------------+ +-------------+
Firewall,
End Host Router NAT, or Proxy End Host
+-------------+ +-------------+
| Application |<------------ end-to-end ------------->| Application |
+-------------+ +-------------+ +-------------+
| Transport |<------------------->| Transport |<->| Transport |
+-------------+ +-------------+ +-------------+ +-------------+
| Network |<->| Network |<->| Network |<->| Network |
+-------------+ +-------------+ +-------------+ +-------------+
Firewall,
End Host Router NAT, or Proxy End Host
Figure 3: Internet Reality
图3：互联网现实
Middleboxes that interpose on the transport layer result in loss of "fate-sharing" [10], that is, they often hold "hard" state that, when lost or corrupted, results in loss or corruption of the end-to-end transport connection.
插入传输层的中间盒会导致“命运共享”的丢失[10]，也就是说，它们通常保持“硬”状态，当丢失或损坏时，会导致端到端传输连接的丢失或损坏。
The network compatibility goal requires that the multipath extension to TCP retain compatibility with the Internet as it exists today, including making reasonable efforts to be able to traverse predominant middleboxes such as firewalls, NATs, and performance-enhancing proxies [9]. This requirement comes from recognizing middleboxes as a significant deployment bottleneck for any transport that is not TCP or UDP, and constrains Multipath TCP to appear as TCP does on the wire and to use established TCP extensions where necessary. To ensure "end-to-endness" of the transport, Multipath TCP MUST preserve fate-sharing without making any assumptions about middlebox behavior.
网络兼容性目标要求TCP的多路径扩展保持与当前互联网的兼容性，包括做出合理的努力，以便能够穿越主要的中间盒，如防火墙、NAT和性能增强代理[9]。这一要求来自于将中间盒视为任何非TCP或UDP传输的重要部署瓶颈，并限制多路径TCP与TCP在线路上的表现相同，并在必要时使用已建立的TCP扩展。为了确保传输的“端到端”，多路径TCP必须保持命运共享，而不必对中间盒行为进行任何假设。
A detailed analysis of middlebox behavior and the impact on the Multipath TCP architecture is presented in Section 7. In addition, network compatibility must be retained to the extent that Multipath TCP MUST fall back to regular TCP if there are insurmountable incompatibilities for the multipath extension on a path.
第7节详细分析了中间盒行为及其对多路径TCP体系结构的影响。此外，如果路径上的多路径扩展存在无法克服的不兼容性，则必须保持网络兼容性，使多路径TCP必须退回到常规TCP。
Middleboxes may also cause some TCP features to be able to exist on one subflow but not another. Typically, these will be at the subflow level (such as selective acknowledgment (SACK) [11]) and thus do not affect the connection-level behavior. In the future, any proposed TCP connection-level extensions should consider how they can coexist with MPTCP.
中间盒还可能导致某些TCP功能能够存在于一个子流上，而不能存在于另一个子流上。通常，这些将处于子流级别（例如选择性确认（SACK）[11]），因此不会影响连接级别的行为。在未来，任何建议的TCP连接级别扩展都应该考虑它们如何与MPTCP共存。
The modifications to support Multipath TCP remain at the transport layer, although some knowledge of the underlying network layer is required. Multipath TCP SHOULD work with IPv4 and IPv6 interchangeably, i.e., one connection may operate over both IPv4 and IPv6 networks.
支持多路径TCP的修改仍停留在传输层，尽管需要对底层网络层有所了解。多路径TCP应可与IPv4和IPv6互换使用，即一个连接可在IPv4和IPv6网络上运行。
As a corollary to both network and application compatibility, the architecture must enable new Multipath TCP flows to coexist gracefully with existing single-path TCP flows, competing for bandwidth neither unduly aggressively nor unduly timidly (unless low-precedence operation is specifically requested by the application, such as with LEDBAT). The use of multiple paths MUST NOT unduly harm users using single-path TCP at shared bottlenecks, beyond the impact that would occur from another single-path TCP flow. Multiple Multipath TCP flows on a shared bottleneck MUST share bandwidth between each other with similar fairness to that which occurs at a shared bottleneck with single-path TCP.
作为网络和应用程序兼容性的必然结果，该体系结构必须使新的多路径TCP流能够与现有的单路径TCP流优雅地共存，既不过度激烈地竞争带宽，也不过度怯懦地竞争带宽（除非应用程序特别要求低优先级操作，例如使用LEDBAT）。在共享瓶颈处使用单路径TCP时，使用多条路径不得对用户造成不适当的伤害，超出另一条单路径TCP流可能产生的影响。共享瓶颈上的多个多路径TCP流必须在彼此之间共享带宽，其公平性与使用单路径TCP的共享瓶颈上发生的公平性相似。
The extension of TCP with multipath capabilities will bring with it a number of new threats, analyzed in detail in [12]. The security goal for Multipath TCP is to provide a service no less secure than regular, single-path TCP. This will be achieved through a combination of existing TCP security mechanisms (potentially modified to align with the Multipath TCP extensions) and of protection against the new multipath threats identified. The design decisions derived from this goal are presented in Section 5.8.
具有多路径功能的TCP扩展将带来许多新的威胁，详细分析见[12]。多路径TCP的安全目标是提供一种安全性不低于常规单路径TCP的服务。这将通过结合现有的TCP安全机制（可能进行修改以与多路径TCP扩展保持一致）和针对已识别的新多路径威胁的保护来实现。第5.8节介绍了由此目标得出的设计决策。
There are several similarities between SCTP [6] and MPTCP, in that both can make use of multiple addresses at end hosts to give some multipath capability. In SCTP, the primary use case is to support redundancy and mobility for multihomed hosts (i.e., a single path will change one of its end host addresses); the simultaneous use of multiple paths is not supported. Extensions are proposed to support simultaneous multipath transport [13], but these are yet to be standardized. By far the most widely used stream-based transport protocol is, however, TCP [1], and SCTP does not meet the network and application compatibility goals specified in Section 2.2. For network compatibility, there are issues with various middleboxes (especially NATs) that are unaware of SCTP and consequently end up blocking it. For application compatibility, applications need to actively choose to use SCTP, and with the deployment issues, very few choose to do so. MPTCP's compatibility goals are in part based on these observations of SCTP's deployment issues.
SCTP[6]和MPTCP之间有一些相似之处，都可以利用终端主机上的多个地址来提供某种多路径能力。在SCTP中，主要用例是支持多宿主机的冗余和移动性（即，单个路径将更改其一个终端主机地址）；不支持同时使用多个路径。提出了支持同时多路径传输的扩展[13]，但这些扩展尚未标准化。然而，到目前为止，最广泛使用的基于流的传输协议是TCP[1]，SCTP不符合第2.2节中规定的网络和应用程序兼容性目标。对于网络兼容性，各种中间盒（尤其是NAT）都存在问题，它们不知道SCTP，因此最终会阻止SCTP。对于应用程序兼容性，应用程序需要主动选择使用SCTP，并且由于部署问题，很少有人选择这样做。MPTCP的兼容性目标部分基于对SCTP部署问题的观察。
This section presents one possible transport architecture that the authors believe can effectively support the goals for Multipath TCP. The new Internet model described here is based on ideas proposed earlier in Tng ("Transport next-generation") [14]. While by no means the only possible architecture supporting multipath transport, Tng incorporates many lessons learned from previous transport research and development practice, and offers a strong starting point from which to consider the extant Internet architecture and its bearing on the design of any new Internet transports or transport extensions.
本节介绍了一种可能的传输架构，作者认为该架构可以有效支持多路径TCP的目标。这里描述的新互联网模型基于Tng（“下一代交通”）中早些时候提出的想法[14]。虽然Tng绝不是支持多径传输的唯一可能架构，但它结合了从以前的传输研究和开发实践中吸取的许多经验教训，并提供了一个强大的起点，从中考虑现存的Internet架构及其对任何新的互联网传输或传输扩展的设计的影响。
+------------------+
| Application |
+------------------+ ^ Application-oriented transport
| | | functions (Semantic Layer)
+ - - Transport - -+ ----------------------------------
| | | Network-oriented transport
+------------------+ v functions (Flow+Endpoint Layer)
| Network |
+------------------+
Existing Layers Tng Decomposition
+------------------+
| Application |
+------------------+ ^ Application-oriented transport
| | | functions (Semantic Layer)
+ - - Transport - -+ ----------------------------------
| | | Network-oriented transport
+------------------+ v functions (Flow+Endpoint Layer)
| Network |
+------------------+
Existing Layers Tng Decomposition
Figure 4: Decomposition of Transport Functions
图4：运输功能的分解
Tng loosely splits the transport layer into "application-oriented" and "network-oriented" layers, as shown in Figure 4. The application-oriented "Semantic" layer implements functions driven primarily by concerns of supporting and protecting the application's end-to-end communication, while the network-oriented "Flow+Endpoint" layer implements functions such as endpoint identification (using port numbers) and congestion control. These network-oriented functions, while traditionally located in the ostensibly "end-to-end" Transport layer, have proven in practice to be of great concern to network operators and the middleboxes they deploy in the network to enforce network usage policies [15] [16] or optimize communication performance [17]. Figure 5 shows how middleboxes interact with different layers in this decomposed model of the transport layer: the application-oriented layer operates end-to-end, while the network-oriented layer operates "segment-by-segment" and can be interposed upon by middleboxes.
Tng将传输层松散地划分为“面向应用程序”层和“面向网络”层，如图4所示。面向应用程序的“语义”层主要实现支持和保护应用程序端到端通信的功能，而面向网络的“流+端点”层实现端点识别（使用端口号）和拥塞控制等功能。这些面向网络的功能虽然传统上位于表面上的“端到端”传输层，但在实践中已经证明，它们是网络运营商及其在网络中部署的用于实施网络使用策略[15][16]或优化通信性能[17]的中间盒非常关心的问题。图5显示了在这个传输层的分解模型中，中间盒如何与不同的层交互：面向应用程序的层端到端运行，而面向网络的层“逐段”运行，可以由中间盒插入。
+-------------+ +-------------+
| Application |<------------ end-to-end ------------->| Application |
+-------------+ +-------------+
| Semantic |<------------ end-to-end ------------->| Semantic |
+-------------+ +-------------+ +-------------+ +-------------+
|Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint|
+-------------+ +-------------+ +-------------+ +-------------+
| Network |<->| Network |<->| Network |<->| Network |
+-------------+ +-------------+ +-------------+ +-------------+
Firewall Performance
End Host or NAT Enhancing Proxy End Host
+-------------+ +-------------+
| Application |<------------ end-to-end ------------->| Application |
+-------------+ +-------------+
| Semantic |<------------ end-to-end ------------->| Semantic |
+-------------+ +-------------+ +-------------+ +-------------+
|Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint|
+-------------+ +-------------+ +-------------+ +-------------+
| Network |<->| Network |<->| Network |<->| Network |
+-------------+ +-------------+ +-------------+ +-------------+
Firewall Performance
End Host or NAT Enhancing Proxy End Host
Figure 5: Middleboxes in the New Internet Model
图5：新互联网模型中的中间盒
MPTCP's architectural design follows Tng's decomposition as shown in Figure 6. MPTCP, which provides application compatibility through the preservation of TCP-like semantics of global ordering of application data and reliability, is an instantiation of the "application-oriented" Semantic layer; whereas the subflow TCP component, which provides network compatibility by appearing and behaving as a TCP flow in the network, is an instantiation of the "network-oriented" Flow+Endpoint layer.
MPTCP的架构设计遵循Tng的分解，如图6所示。MPTCP是“面向应用程序”语义层的一个实例，它通过保存应用程序数据全局排序和可靠性的类似TCP的语义来提供应用程序兼容性；而子流TCP组件是“面向网络”的流+端点层的一个实例，它通过在网络中作为TCP流出现和行为来提供网络兼容性。
+--------------------------+ +-------------------------------+
| Application | | Application |
+--------------------------+ +-------------------------------+
| Semantic | | MPTCP |
|------------+-------------| + - - - - - - - + - - - - - - - +
| Flow+Endpt | Flow+Endpt | | Subflow (TCP) | Subflow (TCP) |
+------------+-------------+ +---------------+---------------+
| Network | Network | | IP | IP |
+------------+-------------+ +---------------+---------------+
+--------------------------+ +-------------------------------+
| Application | | Application |
+--------------------------+ +-------------------------------+
| Semantic | | MPTCP |
|------------+-------------| + - - - - - - - + - - - - - - - +
| Flow+Endpt | Flow+Endpt | | Subflow (TCP) | Subflow (TCP) |
+------------+-------------+ +---------------+---------------+
| Network | Network | | IP | IP |
+------------+-------------+ +---------------+---------------+
Figure 6: Relationship between Tng (Left) and MPTCP (Right)
图6:Tng（左）和MPTCP（右）之间的关系
As a protocol extension to TCP, MPTCP thus explicitly acknowledges middleboxes in its design, and specifies a protocol that operates at two scales: the MPTCP component operates end-to-end, while it allows the TCP component to operate segment-by-segment.
作为TCP的协议扩展，MPTCP因此在其设计中明确承认了中间盒，并指定了一个以两种规模运行的协议：MPTCP组件端到端运行，而它允许TCP组件逐段运行。
The previous two sections have discussed the goals for a Multipath TCP design, and provided a basis for decomposing the functions of a transport protocol in order to better understand the form a solution should take. This section builds upon this analysis by presenting the functional components that are used within the MPTCP design.
前两节讨论了多路径TCP设计的目标，并为分解传输协议的功能提供了基础，以便更好地理解解决方案应采取的形式。本节以该分析为基础，介绍MPTCP设计中使用的功能组件。
MPTCP makes use of (what appear to the network to be) standard TCP sessions, termed "subflows", to provide the underlying transport per path, and as such these retain the network compatibility desired. MPTCP-specific information is carried in a TCP-compatible manner, although this mechanism is separate from the actual information being transferred so could evolve in future revisions. Figure 7 illustrates the layered architecture.
MPTCP利用（在网络看来是）标准TCP会话（称为“子流”）来提供每个路径的底层传输，因此这些会话保持了所需的网络兼容性。MPTCP特定信息以TCP兼容的方式传输，尽管该机制与传输的实际信息不同，因此可能会在未来的版本中演变。图7说明了分层体系结构。
+-------------------------------+
| Application |
+---------------+ +-------------------------------+
| Application | | MPTCP |
+---------------+ + - - - - - - - + - - - - - - - +
| TCP | | Subflow (TCP) | Subflow (TCP) |
+---------------+ +-------------------------------+
| IP | | IP | IP |
+---------------+ +-------------------------------+
+-------------------------------+
| Application |
+---------------+ +-------------------------------+
| Application | | MPTCP |
+---------------+ + - - - - - - - + - - - - - - - +
| TCP | | Subflow (TCP) | Subflow (TCP) |
+---------------+ +-------------------------------+
| IP | | IP | IP |
+---------------+ +-------------------------------+
Figure 7: Comparison of Standard TCP and MPTCP Protocol Stacks
图7：标准TCP和MPTCP协议栈的比较
Situated below the application, the MPTCP extension in turn manages multiple TCP subflows below it. In order to do this, it must implement the following functions:
MPTCP扩展位于应用程序下方，它依次管理其下方的多个TCP子流。为此，它必须实现以下功能：
o Path Management: This is the function to detect and use multiple paths between two hosts. MPTCP uses the presence of multiple IP addresses at one or both of the hosts as an indicator of this. The path management features of the MPTCP protocol are the mechanisms to signal alternative addresses to hosts, and mechanisms to set up new subflows joined to an existing MPTCP connection.
o 路径管理：该功能用于检测和使用两台主机之间的多条路径。MPTCP使用一个或两个主机上存在多个IP地址作为这一情况的指示器。MPTCP协议的路径管理功能包括向主机发送替代地址信号的机制，以及建立连接到现有MPTCP连接的新子流的机制。
o Packet Scheduling: This function breaks the byte stream received from the application into segments to be transmitted on one of the available subflows. The MPTCP design makes use of a data sequence mapping, associating segments sent on different subflows to a connection-level sequence numbering, thus allowing segments sent on different subflows to be correctly re-ordered at the receiver. The packet scheduler is dependent upon information about the availability of paths exposed by the path management component, and then makes use of the subflows to transmit queued segments. This function is also responsible for connection-level re-ordering on receipt of packets from the TCP subflows, according to the attached data sequence mappings.
o 数据包调度：此函数将从应用程序接收的字节流分成若干段，在其中一个可用子流上传输。MPTCP设计利用数据序列映射，将在不同子流上发送的段关联到连接级序列编号，从而允许在不同子流上发送的段在接收器处正确重新排序。包调度器依赖于关于路径管理组件公开的路径的可用性的信息，然后利用子流来传输排队段。此函数还负责根据附加的数据序列映射，在从TCP子流接收数据包时重新排序连接级别。
o Subflow (single-path TCP) Interface: A subflow component takes segments from the packet-scheduling component and transmits them over the specified path, ensuring detectable delivery to the host.
o 子流（单路径TCP）接口：子流组件从数据包调度组件获取数据段，并通过指定的路径进行传输，确保可检测到主机的传输。
MPTCP uses TCP underneath for network compatibility; TCP ensures in-order, reliable delivery. TCP adds its own sequence numbers to the segments; these are used to detect and retransmit lost packets at the subflow layer. On receipt, the subflow passes its reassembled data to the packet scheduling component for connection-level reassembly; the data sequence mapping from the sender's packet scheduling component allows re-ordering of the entire byte stream.
MPTCP在底层使用TCP实现网络兼容性；TCP确保有序、可靠的交付。TCP将自己的序列号添加到段中；这些用于在子流层检测和重新传输丢失的数据包。在接收时，子流将其重新组装的数据传递给分组调度组件以进行连接级重新组装；来自发送方的数据包调度组件的数据序列映射允许对整个字节流进行重新排序。
o Congestion Control: This function coordinates congestion control across the subflows. As specified, this congestion control algorithm MUST ensure that an MPTCP connection does not unfairly take more bandwidth than a single path TCP flow would take at a shared bottleneck. An algorithm to support this is specified in [7].
o 拥塞控制：此功能协调子流之间的拥塞控制。如前所述，此拥塞控制算法必须确保MPTCP连接不会不公平地占用比共享瓶颈处的单路径TCP流更多的带宽。[7]中规定了支持此功能的算法。
These functions fit together as follows. The path management looks after the discovery (and if necessary, initialization) of multiple paths between two hosts. The packet scheduler then receives a stream of data from the application destined for the network, and undertakes the necessary operations on it (such as segmenting the data into connection-level segments, and adding a connection-level sequence number) before sending it on to a subflow. The subflow then adds its own sequence number, ACKs, and passes them to network. The receiving subflow re-orders data (if necessary) and passes it to the packet scheduling component, which performs connection level re-ordering, and sends the data stream to the application. Finally, the congestion control component exists as part of the packet scheduling, in order to schedule which segments should be sent at what rate on which subflow.
这些功能组合如下。路径管理负责两台主机之间多条路径的发现（如有必要，还负责初始化）。然后，分组调度器从目的地为网络的应用程序接收数据流，并在将其发送到子流之前对其进行必要的操作（例如，将数据分段为连接级段，并添加连接级序列号）。然后，子流添加自己的序列号ACK，并将其传递给网络。接收子流对数据重新排序（如有必要）并将其传递给分组调度组件，分组调度组件执行连接级重新排序，并将数据流发送给应用程序。最后，拥塞控制组件作为分组调度的一部分存在，以便调度应该以什么速率在哪个子流上发送哪些段。
There is seemingly a wide range of choices when designing a multipath extension to TCP. However, the goals as discussed earlier in this document constrain the possible solutions, leaving relative little choice in many areas. This section outlines high-level design choices that draw from the architectural basis discussed earlier in Section 3, which the design of MPTCP [5] takes into account.
在设计TCP的多路径扩展时，似乎有很多选择。然而，本文档前面讨论的目标限制了可能的解决方案，在许多领域几乎没有选择。本节概述了从第3节前面讨论的体系结构基础中得出的高层设计选择，MPTCP[5]的设计考虑了这些基础。
MPTCP uses two levels of sequence spaces: a connection-level sequence number and another sequence number for each subflow. This permits connection-level segmentation and reassembly and retransmission of the same part of connection-level sequence space on different subflow-level sequence space.
MPTCP使用两级序列空间：连接级序列号和每个子流的另一个序列号。这允许连接级分段以及在不同的子流级序列空间上重新组装和重传连接级序列空间的相同部分。
The alternative approach would be to use a single connection-level sequence number, which gets sent on multiple subflows. This has two problems: first, the individual subflows will appear to the network as TCP sessions with gaps in the sequence space; this in turn may upset certain middleboxes such as intrusion detection systems, or certain transparent proxies, and would thus go against the network compatibility goal. Second, the sender would not be able to attribute packet losses or receptions to the correct path when the same segment is sent on multiple paths (i.e., in the case of retransmissions).
另一种方法是使用单个连接级别序列号，该序列号在多个子流上发送。这有两个问题：首先，单个子流将在网络中显示为TCP会话，在序列空间中有间隙；这反过来可能会打乱某些中间盒，如入侵检测系统或某些透明代理，从而违反网络兼容性目标。其次，当同一段在多条路径上发送时（即，在重传的情况下），发送方将无法将分组丢失或接收归因于正确的路径。
The sender must be able to tell the receiver how to reassemble the data, for delivery to the application. In order to achieve this, the receiver must determine how subflow-level data (carrying subflow sequence numbers) maps at the connection level. This is referred to as the "data sequence mapping". This mapping can be represented as a tuple of (data sequence number, subflow sequence number, length), i.e., for a given number of bytes (the length), the subflow sequence space beginning at the given sequence number maps to the connection-level sequence space (beginning at the given data sequence number). This information could conceivably have various sources.
发送方必须能够告诉接收方如何重新组装数据，以便将数据交付给应用程序。为了实现这一点，接收器必须确定子流级数据（携带子流序列号）在连接级的映射方式。这被称为“数据序列映射”。该映射可以表示为（数据序列号、子流序列号、长度）的元组，即对于给定数量的字节（长度），从给定序列号开始的子流序列空间映射到连接级序列空间（从给定数据序列号开始）。可以想象，这些信息可能有各种来源。
One option to signal the data sequence mapping would be to use existing fields in the TCP segment (such as subflow sequence number, length) and add only the data sequence number to each segment, for instance, as a TCP option. This would be vulnerable, however, to middleboxes that re-segment or assemble data, since there is no specified behavior for coalescing TCP options. If one signaled (data sequence number, length), this would still be vulnerable to middleboxes that coalesce segments and do not understand MPTCP signaling so do not correctly rewrite the options.
向数据序列映射发送信号的一个选项是使用TCP段中的现有字段（如子流序列号、长度），并仅向每个段添加数据序列号，例如，作为TCP选项。但是，由于没有指定合并TCP选项的行为，因此对于重新分段或组装数据的中间盒来说，这很容易受到攻击。如果有一个信令（数据序列号、长度），这仍然容易受到合并段的中间盒的攻击，并且不理解MPTCP信令，因此不能正确重写选项。
Because of these potential issues, the design decision taken in the MPTCP protocol is that whenever a mapping for subflow data needs to be conveyed to the other host, all three pieces of data (data seq, subflow seq, length) must be sent. To reduce the overhead, it would be permissible for the mapping to be sent periodically and cover more than a single segment. Further experimentation is required to determine what tradeoffs exist regarding the frequency at which mappings should be sent. It could also be excluded entirely in the case of a connection before more than one subflow is used, where the data-level and subflow-level sequence space is the same.
由于这些潜在问题，MPTCP协议中的设计决策是，每当需要将子流数据的映射传送到另一台主机时，必须发送所有三段数据（数据顺序、子流顺序、长度）。为了减少开销，允许定期发送映射并覆盖多个段。需要进行进一步的实验，以确定在发送映射的频率方面存在哪些折衷。在使用多个子流之前进行连接的情况下，如果数据级别和子流级别序列空间相同，也可以将其完全排除在外。
MPTCP features acknowledgements at connection-level as well as subflow-level acknowledgements, in order to provide a robust service to the application.
MPTCP具有连接级别和子流级别的确认功能，以便为应用程序提供健壮的服务。
Under normal behavior, MPTCP could use the data sequence mapping and subflow ACKs to decide when a connection-level segment was received. The transmission of TCP ACKs for a subflow are handled entirely at the subflow level, in order to maintain TCP semantics and trigger subflow-level retransmissions. This has certain implications on end-to-end semantics. It would mean that once a segment is ACKed at the subflow level, it cannot be discarded in the re-order buffer at the connection level. Secondly, unlike in standard TCP, a receiver cannot simply drop out-of-order segments if needed (for instance, due to memory pressure). Under certain circumstances, it may be desirable to drop segments after acknowledgement on the subflow but before delivery to the application, and this can be facilitated by a connection-level acknowledgement.
在正常行为下，MPTCP可以使用数据序列映射和子流确认来确定何时接收到连接级段。子流的TCP确认传输完全在子流级别处理，以维护TCP语义并触发子流级别的重新传输。这对端到端语义有一定的影响。这意味着，一旦在子流级别对段进行了确认，就不能在连接级别的重新排序缓冲区中丢弃该段。其次，与标准TCP不同，如果需要（例如，由于内存压力），接收器不能简单地丢失顺序错误的段。在某些情况下，可能希望在子流上的确认之后但在交付到应用程序之前丢弃段，并且这可以通过连接级确认来促进。
Furthermore, it is possible to conceive of some cases where connection-level acknowledgements could improve robustness. Consider a subflow traversing a transparent proxy: if the proxy ACKs a segment and then crashes, the sender will not retransmit the lost segment on another subflow, as it thinks the segment has been received. The connection grinds to a halt despite having other working subflows, and the sender would be unable to determine the cause of the problem. An example situation where this may occur would be mobility between wireless access points, each of which operates a transport-level proxy. Finally, as an optimization, it may be feasible for a connection-level acknowledgement to be transmitted over the shortest Round-Trip Time (RTT) path, potentially reducing send buffer requirements (see Section 5.3).
此外，还可以设想一些情况，其中连接级别的确认可以提高健壮性。考虑一个遍历透明代理的子流：如果代理插入一个片段，然后崩溃，则发送者不会在另一个子流上重传丢失的片段，因为它认为已经接收了该片段。尽管有其他工作子流，但连接仍会停止，发送方将无法确定问题的原因。可能发生这种情况的示例情况是无线接入点之间的移动性，每个无线接入点都操作传输级代理。最后，作为一种优化，在最短往返时间（RTT）路径上传输连接级确认可能是可行的，这可能会降低发送缓冲区要求（见第5.3节）。
Therefore, to provide a fully robust multipath TCP solution given the above constraints, MPTCP for use on the public Internet MUST feature explicit connection-level acknowledgements, in addition to subflow-level acknowledgements. A connection-level acknowledgement would only be required in order to signal when the receive window moves forward; the heuristics for using such a signal are discussed in more detail in the protocol specification [5].
因此，为了在上述约束条件下提供完全健壮的多路径TCP解决方案，在公共Internet上使用的MPTCP必须具有明确的连接级别确认，以及子流级别确认。只有在接收窗口向前移动时发出信号时，才需要连接级确认；协议规范[5]更详细地讨论了使用此类信号的启发式方法。
Regarding retransmissions, it MUST be possible for a segment to be retransmitted on a different subflow from that on which it was originally sent. This is one of MPTCP's core goals, in order to maintain integrity during temporary or permanent subflow failure, and this is enabled by the dual sequence number space.
关于重传，必须能够在与最初发送的子流不同的子流上重传段。这是MPTCP的核心目标之一，以便在临时或永久子流故障期间保持完整性，这是由双序列号空间实现的。
The scheduling of retransmissions will have significant impact on MPTCP user experience. The current MPTCP specification suggests that data outstanding on subflows that have timed out should be rescheduled for transmission on different subflows. This behavior
重传调度将对MPTCP用户体验产生重大影响。当前的MPTCP规范建议，已超时的子流上未完成的数据应重新安排在不同的子流上传输。这种行为
aims to minimize disruption when a path breaks, and uses the first timeout as indicators. More conservative versions would be to use second or third timeouts for the same segment.
旨在最大限度地减少路径中断时的中断，并使用第一个超时作为指示器。更保守的版本是对同一段使用第二次或第三次超时。
Typically, fast retransmit on an individual subflow will not trigger retransmission on another subflow, although this may still be desirable in certain cases, for instance, to reduce the receive buffer requirements. However, in all cases with retransmissions on different subflows, the lost segments SHOULD still be sent on the path that lost them. This is currently believed to be necessary to maintain subflow integrity, as per the network compatibility goal. By doing this, some efficiency is lost, and it is unclear at this point what the optimal retransmit strategy is.
通常，在单个子流上的快速重传不会触发在另一个子流上的重传，尽管这在某些情况下可能仍然是可取的，例如，为了减少接收缓冲区需求。但是，在不同子流上进行重传的所有情况下，丢失的段仍应在丢失它们的路径上发送。根据网络兼容性目标，目前认为这对于保持子流完整性是必要的。这样做会损失一些效率，目前还不清楚最佳的重传策略是什么。
Large-scale experiments are therefore required in order to determine the most appropriate retransmission strategy, and recommendations will be refined once more information is available.
因此，需要进行大规模实验，以确定最合适的重传策略，一旦获得更多信息，将改进建议。
To ensure in-order delivery, MPTCP must use a connection level receive buffer, where segments are placed until they are in order and can be read by the application.
为了确保按顺序交付，MPTCP必须使用连接级别的接收缓冲区，在该缓冲区中，段被放置到有序的位置，并且可以被应用程序读取。
In regular, single-path TCP, it is usually recommended to set the receive buffer to 2*BDP (Bandwidth-Delay Product, i.e., BDP = BW*RTT, where BW = Bandwidth and RTT = Round-Trip Time). One BDP allows supporting reordering of segments by the network. The other BDP allows the connection to continue during fast retransmit: when a segment is fast retransmitted, the receiver must be able to store incoming data during one more RTT.
在常规的单路径TCP中，通常建议将接收缓冲区设置为2*BDP（带宽延迟乘积，即BDP=BW*RTT，其中BW=带宽，RTT=往返时间）。一个BDP允许通过网络对段进行重新排序。另一个BDP允许在快速重传期间继续连接：当一个段被快速重传时，接收器必须能够在一个或多个RTT期间存储传入数据。
For MPTCP, the story is a bit more complicated. The ultimate goal is that a subflow packet loss or subflow failure should not affect the throughput of other working subflows; the receiver should have enough buffering to store all data until the missing segment is re-transmitted and reaches the destination.
对于MPTCP来说，这个故事有点复杂。最终目标是，子流数据包丢失或子流故障不应影响其他工作子流的吞吐量；接收器应有足够的缓冲来存储所有数据，直到丢失的数据段被重新传输并到达目的地。
The worst-case scenario would be when the subflow with the highest RTT/RTO (Round-Trip Time or Retransmission TimeOut) experiences a timeout; in that case, the receiver has to buffer data from all subflows for the duration of the RTO. Thus, the smallest connection-level receive buffer that would be needed to avoid stalling with subflow failures is sum(BW_i)*RTO_max, where BW_i = Bandwidth for each subflow and RTO_max is the largest RTO across all subflows.
最坏的情况是，具有最高RTT/RTO（往返时间或重传超时）的子流经历超时；在这种情况下，接收器必须在RTO期间缓冲来自所有子流的数据。因此，避免因子流故障而暂停所需的最小连接级接收缓冲区是sum（BW_i）*RTO_max，其中BW_i=每个子流的带宽，RTO_max是所有子流中最大的RTO。
This is an order of magnitude more than the receive buffer required for a single connection, and is probably too expensive for practical purposes. A more sensible requirement is to avoid stalls in the absence of timeouts. Therefore, the RECOMMENDED receive buffer is 2*sum(BW_i)*RTT_max, where RTT_max is the largest RTT across all subflows. This buffer sizing ensures subflows do not stall when fast retransmit is triggered on any subflow.
这比单个连接所需的接收缓冲区大一个数量级，并且对于实际用途来说可能过于昂贵。一个更合理的要求是避免在没有暂停的情况下出现摊位。因此，建议的接收缓冲区是2*sum（BW_i）*RTT_max，其中RTT_max是所有子流中最大的RTT。此缓冲区大小可确保在任何子流上触发快速重新传输时，子流不会停止。
The resulting buffer size should be small enough for practical use. However, there may be extreme cases where fast, high throughput paths (e.g., 100 Mb/s, 10 ms RTT) are used in conjunction with slow paths (e.g., 1 Mb/s, 1000 ms RTT). In that case, the required receive buffer would be 12.5 MB, which is likely too big. In extreme cases such as this example, it may be prudent to only use some of the fastest available paths for the MPTCP connection, potentially using the slow path(s) for backup only.
产生的缓冲区大小应足够小，以供实际使用。然而，在某些极端情况下，快速、高吞吐量路径（例如100 Mb/s、10 ms RTT）与慢速路径（例如1 Mb/s、1000 ms RTT）结合使用。在这种情况下，所需的接收缓冲区将为12.5 MB，这可能太大了。在本例等极端情况下，可能需要谨慎地为MPTCP连接仅使用一些最快的可用路径，可能仅将慢路径用于备份。
Send Buffer: The RECOMMENDED send buffer is the same size as the recommended receive buffer, i.e., 2*sum(BW_i)*RTT_max. This is because the sender must locally store the segments sent but unacknowledged by the connection level ACK. The send buffer size matters particularly for hosts that maintain a large number of ongoing connections. If the required send buffer is too large, a host can choose to only send data on the fast subflows, using the slow subflows only in cases of failure.
发送缓冲区：建议的发送缓冲区与建议的接收缓冲区大小相同，即2*sum（BW_i）*RTT_max。这是因为发送方必须本地存储发送但未被连接级别确认的段。发送缓冲区的大小对于维护大量正在进行的连接的主机尤其重要。如果所需的发送缓冲区太大，主机可以选择仅在快速子流上发送数据，仅在发生故障时使用慢速子流。
Since MPTCP uses TCP as its subflow transport mechanism, an MPTCP connection will also begin as a single TCP connection. Nevertheless, it must signal to the peer that it supports MPTCP and wishes to use it on this connection. As such, a TCP option will be used to transmit this information, since this is the established mechanism for indicating additional functionality on a TCP session.
由于MPTCP使用TCP作为其子流传输机制，因此MPTCP连接也将作为单个TCP连接开始。然而，它必须向对等方发出信号，表示它支持MPTCP并希望在此连接上使用它。因此，TCP选项将用于传输此信息，因为这是用于指示TCP会话上附加功能的既定机制。
In addition, further signaling is required during the operation of an MPTCP session, such as that for reassembly across multiple subflows, and for informing the other host about other available IP addresses.
此外，在MPTCP会话的操作期间需要进一步的信令，例如用于跨多个子流重新组装的信令，以及用于将其他可用IP地址通知另一主机的信令。
The MPTCP protocol design will use TCP options for this additional signaling. This has been chosen as the mechanism most fitting in with the goals as specified in Section 2. With this mechanism, the signaling required to operate MPTCP is transported separately from the data, allowing it to be created and processed separately from the data stream, and retaining architectural compatibility with network entities.
MPTCP协议设计将使用TCP选项进行此附加信令。这被选为最符合第2节规定目标的机制。使用该机制，操作MPTCP所需的信令与数据分开传输，允许与数据流分开创建和处理，并保持与网络实体的架构兼容性。
This decision is the consensus of the Working Group (following detailed discussions at IETF78), and the main reasons for this are as follows:
该决定是工作组的共识（在IETF78上进行详细讨论后），其主要原因如下：
o TCP options are the traditional signaling method for TCP;
o TCP选项是TCP的传统信令方法；
o A TCP option on a SYN is the most compatible way for an end host to signal it is MPTCP capable;
o SYN上的TCP选项是终端主机发出MPTCP功能信号的最兼容方式；
o If connection-level ACKs are signaled in the payload, then they may suffer from packet loss and may be congestion-controlled, which may affect the data throughput in the forward direction and could lead to head-of-line blocking;
o 如果在有效载荷中用信号通知连接级ack，则它们可能遭受分组丢失，并且可能受到拥塞控制，这可能会影响正向上的数据吞吐量，并可能导致线首阻塞；
o Middleboxes, such as NAT traversal helpers, can easily parse TCP options, e.g., to rewrite addresses.
o 诸如NAT遍历助手之类的中间盒可以轻松解析TCP选项，例如重写地址。
On the other hand, the main drawbacks of TCP options compared to TLV encoding in the payload are the following:
另一方面，与有效负载中的TLV编码相比，TCP选项的主要缺点如下：
o There is limited space for signaling messages;
o 信令消息的空间有限；
o A middlebox may, potentially, drop a packet with an unknown option;
o 中间盒可以潜在地丢弃具有未知选项的分组；
o The transport of control information in options is not necessarily reliable.
o 选项中控制信息的传输不一定可靠。
The detailed design of MPTCP alleviates these issues as far as possible by carefully considering the size of MPTCP options and seamlessly falling back to regular TCP on the loss of control data.
MPTCP的详细设计通过仔细考虑MPTCP选项的大小，并在控制数据丢失时无缝地返回到常规TCP，尽可能地缓解了这些问题。
Both option and payload encoding may interfere with offloading of TCP processing to high-speed network interface cards, such as segmentation, checksumming, and reassembly. For network cards supporting MPTCP, signaling in TCP options should simplify offloading due to the separate handling of MPTCP signaling and data.
选项和有效负载编码都可能会干扰将TCP处理卸载到高速网络接口卡，例如分段、校验和和重新组装。对于支持MPTCP的网卡，由于MPTCP信令和数据的单独处理，TCP选项中的信令应简化卸载。
Currently, the network does not expose path diversity between pairs of IP addresses. In order to achieve path diversity from today's IP networks, in the typical case, MPTCP uses multiple addresses at one or both hosts to infer different paths across the network. It is expected that these paths, whilst not necessarily entirely non-overlapping, will be sufficiently disjoint to allow multipath to
目前，网络不公开IP地址对之间的路径多样性。为了实现当今IP网络的路径多样性，在典型情况下，MPTCP使用一台或两台主机上的多个地址来推断网络中的不同路径。预计这些路径虽然不一定完全不重叠，但将充分不相交以允许多径传播
achieve improved throughput and robustness. The use of multiple IP addresses is a simple mechanism that requires no additional features in the network.
实现更高的吞吐量和健壮性。使用多个IP地址是一种简单的机制，不需要网络中的其他功能。
Multiple different (source, destination) address pairs will thus be used as path selectors in most cases. However, each path will be identified by a standard five-tuple (i.e., source address, destination address, source port, destination port, protocol), which can allow the extension of MPTCP to use ports as well as addresses as path selectors. This will allow hosts to use port-based load balancing with MPTCP, for example, if the network routes different ports over different paths (which may be the case with technologies such as Equal Cost MultiPath (ECMP) routing [4]). It should be noted, however, that ISPs often undertake traffic engineering in order to optimize resource utilization within their networks, and care should be taken (by both ISPs and developers) that MPTCP using broadly similar paths does not adversely interfere with this.
因此，在大多数情况下，多个不同的（源、目标）地址对将用作路径选择器。但是，每个路径将由一个标准的五元组（即源地址、目标地址、源端口、目标端口、协议）标识，该元组允许MPTCP的扩展使用端口以及地址作为路径选择器。这将允许主机在MPTCP中使用基于端口的负载平衡，例如，如果网络通过不同的路径路由不同的端口（这可能与等成本多路径（ECMP）路由[4]等技术有关）。然而，应注意的是，ISP通常会进行流量工程，以优化其网络内的资源利用率，并且（ISP和开发商）应注意，使用大致相似路径的MPTCP不会对这一点产生不利影响。
For an increased chance of successfully setting up additional subflows (such as when one end is behind a firewall, NAT, or other restrictive middlebox), either host SHOULD be able to add new subflows to an MPTCP connection. MPTCP MUST be able to handle paths that appear and disappear during the lifetime of a connection (for example, through the activation of an additional network interface).
为了增加成功设置其他子流的机会（例如，当一端位于防火墙、NAT或其他限制性中间盒之后），任一主机都应该能够向MPTCP连接添加新的子流。MPTCP必须能够处理在连接生命周期内出现和消失的路径（例如，通过激活附加网络接口）。
The path management is a separate function from the packet scheduling, subflow interface, and congestion control functions of MPTCP, as documented in Section 4. As such, it would be feasible to replace this IP-address-based design with an alternative path selection mechanism in the future, with no significant changes to the other functional components.
路径管理是与MPTCP的数据包调度、子流接口和拥塞控制功能分离的功能，如第4节所述。因此，将来用替代路径选择机制取代这种基于IP地址的设计是可行的，而不会对其他功能组件进行重大更改。
Since an MPTCP connection may not be bound to a traditional 5-tuple (source address and port, destination address and port, protocol number) for the entirety of its existence, it is desirable to provide a new mechanism for connection identification. This will be useful for MPTCP-aware applications and for the MPTCP implementation (and MPTCP-aware middleboxes) to have a unique identifier with which to associate the multiple subflows.
由于MPTCP连接在其存在的整个过程中可能不会绑定到传统的5元组（源地址和端口、目标地址和端口、协议号），因此需要提供一种新的连接标识机制。这对于支持MPTCP的应用程序和MPTCP实现（以及支持MPTCP的中间盒）具有唯一标识符（可与多个子流关联）非常有用。
Therefore, each MPTCP connection requires a connection identifier at each host, which is locally unique within that host. In many ways, this is analogous to an ephemeral port number in regular TCP. The manifestation and purpose of such an identifier is out of the scope of this architecture document.
因此，每个MPTCP连接在每个主机上都需要一个连接标识符，该标识符在该主机中是本地唯一的。在许多方面，这类似于常规TCP中的临时端口号。此类标识符的表现形式和用途不在本架构（architecture）文档的范围内。
Non-MPTCP-aware applications will not, however, have access to this identifier and in such cases an MPTCP connection will be identified by the 5-tuple of the first TCP subflow. It is out of the scope of this document, however, to define the behavior of the MPTCP implementation if the first TCP subflow later fails. If there are MPTCP-unaware applications that make assumptions about continued existence of the initial address pair, their behavior could be disrupted by carrying on regardless. It is expected that this is a very small, possibly negligible, set of applications, however. MPTCP MUST NOT be used for applications that request to bind to a specific address or interface, since such applications are making a deliberate choice of path in use.
但是，不支持MPTCP的应用程序将无法访问此标识符，在这种情况下，MPTCP连接将由第一个TCP子流的5元组标识。但是，如果第一个TCP子流随后失败，则定义MPTCP实现的行为超出了本文档的范围。如果有一些MPTCP不知道的应用程序假设初始地址对继续存在，则它们的行为可能会因继续执行而中断。然而，预计这是一个非常小的、可能可以忽略不计的应用程序集。MPTCP不得用于请求绑定到特定地址或接口的应用程序，因为此类应用程序正在故意选择使用的路径。
Since the requirements of applications are not clear at this stage, however, it is as yet unconfirmed whether carrying on in the event of the loss of the initial address pair would be a damaging assumption to make. This behavior will be an implementation-specific solution, and as such it is expected to be chosen by implementors once more research has been undertaken to determine its impact.
然而，由于申请的要求在现阶段尚不明确，因此尚未确认在丢失初始地址对的情况下继续进行是否会是一种有害的假设。这种行为将是一种特定于实现的解决方案，因此，一旦进行了进一步的研究以确定其影响，实现者将选择这种行为。
As discussed in network-layer compatibility requirements Section 2.2.3, there are three goals for the congestion control algorithms used by an MPTCP implementation: improve throughput (at least as well as a single-path TCP connection would perform); do no harm to other network users (do not take up more capacity on any one path than if it was a single path flow using only that route -- this is particularly relevant for shared bottlenecks); and balance congestion by moving traffic away from the most congested paths. To achieve these goals, the congestion control algorithms on each subflow must be coupled in some way. A proposal for a suitable congestion control algorithm is given in [7].
如网络层兼容性要求第2.2.3节所述，MPTCP实现使用的拥塞控制算法有三个目标：提高吞吐量（至少与单路径TCP连接的性能一样）；不要伤害其他网络用户（不要在任何一条路径上占用比仅使用该路径的单路径流更多的容量——这与共享瓶颈特别相关）；并通过将交通从最拥挤的路径移开来平衡拥堵。为了实现这些目标，每个子流上的拥塞控制算法必须以某种方式耦合。[7]中给出了一种合适的拥塞控制算法的建议。
A detailed threat analysis for Multipath TCP is presented in a separate document [12]. That document focuses on flooding attacks and hijacking attacks that can be launched against a Multipath TCP connection.
多路径TCP的详细威胁分析见单独的文件[12]。该文档重点介绍了可针对多路径TCP连接发起的洪水攻击和劫持攻击。
The basic security goal of Multipath TCP, as introduced in Section 2.3, can be stated as: "provide a solution that is no worse than standard TCP".
如第2.3节所述，多路径TCP的基本安全目标可以表述为：“提供不比标准TCP差的解决方案”。
From the threat analysis, and with this goal in mind, three key security requirements can be identified. A multi-addressed Multipath TCP SHOULD be able to do the following:
通过威胁分析，并牢记这一目标，可以确定三个关键的安全需求。多寻址多路径TCP应能够执行以下操作：
o Provide a mechanism to confirm that the parties in a subflow handshake are the same as in the original connection setup (e.g., require use of a key exchanged in the initial handshake in the subflow handshake, to limit the scope for hijacking attacks).
o 提供一种机制，以确认子流握手中的各方与原始连接设置中的各方相同（例如，要求在子流握手中使用初始握手中交换的密钥，以限制劫持攻击的范围）。
o Provide verification that the peer can receive traffic at a new address before adding it (i.e., verify that the address belongs to the other host, to prevent flooding attacks).
o 在添加新地址之前，验证对等方是否可以在新地址接收流量（即，验证该地址是否属于其他主机，以防止泛洪攻击）。
o Provide replay protection, i.e., ensure that a request to add/ remove a subflow is 'fresh'.
o 提供重播保护，即确保添加/删除子流的请求是“新的”。
Additional mechanisms have been deployed as part of standard TCP stacks to provide resistance to Denial-of-Service (DoS) attacks. For example, there are various mechanisms to protect against TCP reset attacks [18], and Multipath TCP should continue to support similar protection. In addition, TCP SYN Cookies [19] were developed to allow a TCP server to defer the creation of session state in the SYN_RCVD state, and remain stateless until the ESTABLISHED state had been reached. Multipath TCP should, ideally, continue to provide such functionality and, at a minimum, avoid significant computational burden prior to reaching the ESTABLISHED state (of the Multipath TCP connection as a whole).
作为标准TCP协议栈的一部分，还部署了其他机制，以抵抗拒绝服务（DoS）攻击。例如，有各种机制可以防止TCP重置攻击[18]，多路径TCP应该继续支持类似的保护。此外，TCP SYN Cookie[19]的开发允许TCP服务器延迟在SYN_RCVD状态下创建会话状态，并保持无状态，直到达到已建立的状态。理想情况下，多路径TCP应继续提供此类功能，并至少在达到（多路径TCP连接作为一个整体）已建立状态之前避免大量计算负担。
It should be noted that aspects of the Multipath TCP design space place constraints on the security solution:
应该注意的是，多路径TCP设计空间的各个方面对安全解决方案提出了限制：
o The use of TCP options significantly limits the amount of information that can be carried in the handshake.
o TCP选项的使用大大限制了握手中可以携带的信息量。
o The need to work through middleboxes results in the need to handle mutability of packets.
o 通过中间盒工作的需要导致需要处理数据包的易变性。
o The desire to support a 'break-before-make' (as well as a 'make-before-break') approach to adding subflows (within a limited time period) implies that a host cannot rely on using a pre-existing subflow to support the addition of a new one.
o 希望支持“先断后通”（以及“先通后断”）的方法来添加子流（在有限的时间段内），这意味着主机不能依赖使用预先存在的子流来支持添加新的子流。
The MPTCP protocol will be designed with these security requirements in mind, and the protocol specification [5] will document how these are met.
MPTCP协议的设计将考虑这些安全要求，协议规范[5]将记录如何满足这些要求。
In the case of applications that have used an existing API call to bind to a specific address or interface, the MPTCP extension MUST NOT be used. This is because the applications are indicating a clear choice of path to use and thus will have expectations of behavior that must be maintained, in order to adhere to the application compatibility goals.
对于使用现有API调用绑定到特定地址或接口的应用程序，不得使用MPTCP扩展。这是因为应用程序指明了一个明确的使用路径选择，因此，为了遵守应用程序兼容性目标，必须保持对行为的预期。
Interactions with applications are presented in [8] -- including, but not limited to, performances changes that may be expected, semantic changes, and new features that may be requested through an enhanced API.
[8]中介绍了与应用程序的交互，包括但不限于预期的性能更改、语义更改以及通过增强API请求的新功能。
TCP features the ability to send "Urgent" data, the delivery of which to the application may or may not be out-of-band. The use of this feature is not recommended due to security implications and implementation differences [20]. MPTCP requires contiguous data to support its data sequence mapping over multiple segments, and therefore the Urgent pointer cannot interrupt an existing mapping. An MPTCP implementation MAY choose to support sending Urgent data, and if it does, it SHOULD send the Urgent data on the soonest available unassigned subflow sequence space. Incoming Urgent data SHOULD be mapped to connection-level sequence space and delivered to the application analogous to Urgent data in regular TCP.
TCP具有发送“紧急”数据的功能，向应用程序发送的数据可能在带外，也可能不在带外。由于安全影响和实现差异，不建议使用此功能[20]。MPTCP需要连续数据来支持其在多个段上的数据序列映射，因此紧急指针不能中断现有映射。MPTCP实现可以选择支持发送紧急数据，如果支持，则应在最快可用的未分配子流序列空间上发送紧急数据。传入的紧急数据应映射到连接级别的序列空间，并发送到应用程序，类似于常规TCP中的紧急数据。
To enable interactions between TCP and network management systems, the TCP [21] and TCP Extended Statistics (ESTATS) [22] MIBs have been defined. MPTCP should share these MIBs for aspects that are designed to be transparent to the application.
为了实现TCP和网络管理系统之间的交互，定义了TCP[21]和TCP扩展统计（ESTATS）[22]MIB。MPTCP应该为应用程序透明的方面共享这些MIB。
It is anticipated that an MPTCP MIB will be defined in the future, once experience of experimental MPTCP deployments is gathered. This MIB would provide access to MPTCP-specific properties such as whether MPTCP is enabled and the number and properties of the individual paths in use.
一旦收集到实验性MPTCP部署的经验，预计未来将定义MPTCP MIB。此MIB将提供对MPTCP特定属性的访问，例如是否启用MPTCP以及正在使用的各个路径的数量和属性。
As discussed in Section 2.2, it is a goal of MPTCP to be deployable today and thus compatible with the majority of middleboxes. This section summarizes the issues that may arise with NATs, firewalls, proxies, intrusion detection systems, and other middleboxes that, if not considered in the protocol design, may hinder its deployment.
如第2.2节所述，MPTCP的目标是今天可以部署，从而与大多数中间盒兼容。本节总结了NAT、防火墙、代理、入侵检测系统和其他中间件可能出现的问题，如果在协议设计中未考虑这些问题，可能会阻碍其部署。
This section is intended primarily as a description of options and considerations only. Protocol-specific solutions to these issues will be given in the companion documents.
本节主要用于描述选项和注意事项。这些问题的特定协议解决方案将在配套文件中给出。
Multipath TCP will be deployed in a network that no longer provides just basic datagram delivery. A myriad of middleboxes are deployed to optimize various perceived problems with the Internet protocols: NATs primarily address IP address space shortage [15], Performance Enhancing Proxies (PEPs) optimize TCP for different link characteristics [17], firewalls [16] and intrusion detection systems try to block malicious content from reaching a host, and traffic normalizers [23] ensure a consistent view of the traffic stream to Intrusion Detection Systems (IDS) and hosts.
多路径TCP将部署在不再只提供基本数据报传递的网络中。部署了无数的中间件来优化互联网协议的各种感知问题：NAT主要解决IP地址空间不足[15]，性能增强代理（PEP）针对不同的链路特征优化TCP[17]，防火墙[16]和入侵检测系统试图阻止恶意内容到达主机，流量规范化器[23]确保入侵检测系统（IDS）和主机的流量流的一致视图。
All these middleboxes optimize current applications at the expense of future applications. In effect, future applications will often need to behave in a similar fashion to existing ones, in order to increase the chances of successful deployment. Further, the precise behavior of all these middleboxes is not clearly specified, and implementation errors make matters worse, raising the bar for the deployment of new technologies.
所有这些中间盒都以牺牲未来应用程序为代价优化当前应用程序。实际上，未来的应用程序通常需要以与现有应用程序类似的方式运行，以增加成功部署的机会。此外，所有这些中间盒的精确行为都没有明确规定，而实现错误使情况变得更糟，从而提高了部署新技术的门槛。
The following list of middlebox classes documents behavior that could impact the use of MPTCP. This list is used in [5] to describe the features of the MPTCP protocol that are used to mitigate the impact of these middlebox behaviors.
以下middlebox类列表记录了可能影响MPTCP使用的行为。[5]中使用此列表来描述MPTCP协议的功能，这些功能用于减轻这些中间箱行为的影响。
o NATs: Network Address Translators decouple the host's local IP address (and, in the case of NAPTs, port) with that which is seen in the wider Internet when the packets are transmitted through a NAT. This adds complexity, and reduces the chances of success, when signaling IP addresses.
o NAT：当数据包通过NAT传输时，网络地址转换器将主机的本地IP地址（在NAPTs的情况下，还有端口）与更广泛的Internet中的IP地址解耦。这增加了发送IP地址信号时的复杂性，并降低了成功的机会。
o PEPs: Performance Enhancing Proxies, which aim to improve the performance of protocols over low-performance (e.g., high-latency or high-error-rate) links. As such, they may "split" a TCP connection and behavior such as proactive ACKing may occur, and therefore it is no longer guaranteed that one host is communicating directly with another. PEPs, firewalls, or other middleboxes may also change the declared receive window size.
o PEPs：性能增强代理，旨在提高协议在低性能（例如，高延迟或高错误率）链路上的性能。因此，它们可能会“分割”TCP连接，并可能发生主动确认等行为，因此不再保证一台主机与另一台主机直接通信。PEP、防火墙或其他中间盒也可能更改声明的接收窗口大小。
o Traffic Normalizers: These aim to eliminate ambiguities and potential attacks at the network level, and amongst other things, are unlikely to permit holes in TCP-level sequence space (which has an impact on MPTCP's retransmission and subflow sequence numbering design choices).
o 流量规范化器：这些规范化器旨在消除网络级别的歧义和潜在攻击，除其他外，不太可能允许TCP级别的序列空间出现漏洞（这会影响MPTCP的重传和子流序列编号设计选择）。
o Firewalls: on top of preventing incoming connections, firewalls may also attempt additional protection such as sequence number randomization (so a sender cannot reliably know what TCP sequence number the receiver will see).
o 防火墙：除了防止传入连接之外，防火墙还可能尝试额外的保护，例如序列号随机化（因此发送方无法可靠地知道接收方将看到的TCP序列号）。
o IDSs: Intrusion Detection Systems may look for traffic patterns to protect a network and may have false positives with MPTCP and drop the connections during normal operation. Future MPTCP-aware middleboxes will require the ability to correlate the various paths in use.
o IDSs：入侵检测系统可能会寻找流量模式来保护网络，可能会对MPTCP产生误报，并在正常操作期间中断连接。未来支持MPTCP的中间盒需要能够关联使用中的各种路径。
o Content-Aware Firewalls: Some middleboxes may actively change data in packets, such as rewriting URIs in HTTP traffic.
o 内容感知防火墙：一些中间包可能会主动更改数据包中的数据，例如在HTTP流量中重写URI。
In addition, all classes of middleboxes may affect TCP traffic in the following ways:
此外，所有类别的中间盒都可能通过以下方式影响TCP流量：
o TCP Options: some middleboxes may drop packets with unknown TCP options or strip those options from the packets.
o TCP选项：某些中间盒可能会丢弃具有未知TCP选项的数据包，或者从数据包中删除这些选项。
o Segmentation and Coalescing: middleboxes (or even something as close to the end host as TCP Segmentation Offloading (TSO) on a Network Interface Card (NIC)) may change the packet boundaries from those that the sender intended. It may do this by splitting packets or coalescing them together. This leads to two major impacts: where a packet boundary will be cannot be guaranteed and what a middlebox will do with TCP options in these cases (they may be repeated, dropped, or sent only once) cannot be said for sure.
o 分段和合并：中间盒（甚至像网络接口卡（NIC）上的TCP分段卸载（TSO）一样靠近终端主机）可能会改变发送方预期的数据包边界。它可以通过拆分数据包或将它们合并在一起来实现这一点。这导致了两个主要影响：无法保证数据包边界的位置，以及在这些情况下（它们可能会重复、丢弃或只发送一次）中间盒将如何处理TCP选项，这些都无法确定。
The authors would like to acknowledge the contributions of Andrew McDonald and Bryan Ford to this document.
作者要感谢安德鲁·麦克唐纳和布莱恩·福特对本文件的贡献。
The authors would also like to thank the following people for detailed reviews: Olivier Bonaventure, Gorry Fairhurst, Iljitsch van Beijnum, Philip Eardley, Michael Scharf, Lars Eggert, Cullen Jennings, Joel Halpern, Juergen Quittek, Alexey Melnikov, David Harrington, Jari Arkko, and Stewart Bryant.
作者还要感谢以下人士的详细评论：奥利维尔·博纳文图尔、戈里·费尔赫斯特、伊尔吉奇·范·贝伊南、菲利普·埃尔德利、迈克尔·沙夫、拉尔斯·艾格特、卡伦·詹宁斯、乔尔·哈尔彭、尤尔根·奎特克、阿列克谢·梅尔尼科夫、大卫·哈林顿、贾里·阿尔科和斯图尔特·布莱恩特。
Alan Ford, Costin Raiciu, Mark Handley, and Sebastien Barre are supported by Trilogy (http://www.trilogy-project.org), a research project (ICT-216372) partially funded by the European Community under its Seventh Framework Program. The views expressed here are those of the author(s) only. The European Commission is not liable for any use that may be made of the information in this document.
艾伦·福特、科斯汀·雷丘、马克·汉德利和塞巴斯蒂安·巴尔都得到了三部曲的支持(http://www.trilogy-project.org)，一个研究项目（ICT-216372），部分由欧洲共同体根据其第七个框架计划资助。此处表达的观点仅为作者的观点。欧盟委员会对可能使用本文件中的信息不承担任何责任。
This informational document provides an architectural overview for Multipath TCP and so does not, in itself, raise any security issues. A separate threat analysis [12] lists threats that can exist with a Multipath TCP. However, a protocol based on the architecture in this document will have a number of security requirements. The high-level goals for such a protocol are identified in Section 2.3, whilst Section 5.8 provides more detailed discussion of security requirements and design decisions which are applied in the MPTCP protocol design [5].
本信息性文档提供了多路径TCP的体系结构概述，因此本身不会引起任何安全问题。单独的威胁分析[12]列出了多路径TCP可能存在的威胁。然而，基于本文档中架构的协议将有许多安全要求。第2.3节确定了此类协议的高级别目标，而第5.8节提供了MPTCP协议设计中应用的安全要求和设计决策的更详细讨论[5]。
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[1] 《传输控制协议》，标准7，RFC 793，1981年9月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Wischik, D., Handley, M., and M. Bagnulo Braun, "The Resource Pooling Principle", ACM SIGCOMM CCR vol. 38 num. 5, pp. 47-52, October 2008, <http://ccr.sigcomm.org/online/files/p47-handleyA4.pdf>.
[3] Wischik，D.，Handley，M.和M.Bagnulo Braun，“资源池原则”，ACM SIGCOMM CCR第38卷第5期，第47-52页，2008年10月<http://ccr.sigcomm.org/online/files/p47-handleyA4.pdf>.
[4] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, November 2000.
[4] Hopps，C.，“等成本多路径算法的分析”，RFC 2992，2000年11月。
[5] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", Work in Progress, March 2011.
[5] Ford，A.，Raiciu，C.，Handley，M.，和O.Bonaventure，“具有多个地址的多路径操作的TCP扩展”，正在进行的工作，2011年3月。
[6] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[6] Stewart，R.，“流控制传输协议”，RFC 4960，2007年9月。
[7] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", Work in Progress, March 2011.
[7] Raiciu，C.，Handley，M.，和D.Wischik，“多路径传输协议的耦合拥塞控制”，正在进行的工作，2011年3月。
[8] Scharf, M. and A. Ford, "MPTCP Application Interface Considerations", Work in Progress, March 2011.
[8] Scharf，M.和A.Ford，“MPTCP应用程序接口注意事项”，正在进行的工作，2011年3月。
[9] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[9] Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 3234，2002年2月。
[10] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[10] Carpenter，B.，“互联网透明度”，RFC 27752000年2月。
[11] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[11] Mathis，M.，Mahdavi，J.，Floyd，S.，和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[12] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, March 2011.
[12] Bagnulo，M.，“具有多个地址的多路径操作的TCP扩展的威胁分析”，RFC 61812011年3月。
[13] Becke, M., Dreibholz, T., Iyengar, J., Natarajan, P., and M. Tuexen, "Load Sharing for the Stream Control Transmission Protocol (SCTP)", Work in Progress, December 2010.
[13] Becke，M.，Dreibholz，T.，Iyengar，J.，Natarajan，P.，和M.Tuexen，“流控制传输协议（SCTP）的负载共享”，正在进行的工作，2010年12月。
[14] Ford, B. and J. Iyengar, "Breaking Up the Transport Logjam", ACM HotNets, October 2008.
[14] Ford，B.和J.Iyengar，“打破交通僵局”，ACM HotNets，2008年10月。
[15] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[15] Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[16] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[16] 弗里德，N.，“互联网防火墙的行为和要求”，RFC 2979，2000年10月。
[17] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
[17] Border，J.，Kojo，M.，Griner，J.，黑山，G.，和Z.Shelby，“旨在缓解链路相关降级的性能增强代理”，RFC 31352001年6月。
[18] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
[18] Ramaiah，A.，Stewart，R.，和M.Dalal，“提高TCP对窗口盲攻击的鲁棒性”，RFC 59612010年8月。
[19] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[19] Eddy，W.“TCP SYN洪泛攻击和常见缓解措施”，RFC 4987，2007年8月。
[20] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, January 2011.
[20] Gont，F.和A.Yourtchenko，“关于TCP紧急机制的实施”，RFC 6093，2011年1月。
[21] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005.
[21] Raghunarayan，R.，“传输控制协议（TCP）的管理信息库”，RFC4022，2005年3月。
[22] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP Extended Statistics MIB", RFC 4898, May 2007.
[22] Mathis，M.，Heffner，J.和R.Raghunarayan，“TCP扩展统计MIB”，RFC 4898，2007年5月。
[23] Handley, M., Paxson, V., and C. Kreibich, "Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics", Usenix Security 2001, 2001, <http:// www.usenix.org/events/sec01/full_papers/handley/handley.pdf>.
[23] Handley，M.，Paxson，V.，和C.Kreibich，“网络入侵检测：规避、流量规范化和端到端协议语义”，Usenix Security 2001，2001，<http://www.Usenix.org/events/sec01/full_papers/Handley/Handley.pdf>。
Authors' Addresses
作者地址
Alan Ford Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN UK Phone: +44 1794 833 465 EMail: alan.ford@roke.co.uk
Alan Ford Roke Manor Research Old Salisbury Lane Romsey，Hampshire SO51 0ZN英国电话：+44 1794 833 465电子邮件：Alan。ford@roke.co.uk
Costin Raiciu University College London Gower Street London WC1E 6BT UK EMail: c.raiciu@cs.ucl.ac.uk
Costin Raiciu大学学院伦敦高尔街伦敦WC1E 6BT英国电子邮件：c。raiciu@cs.ucl.ac.uk
Mark Handley University College London Gower Street London WC1E 6BT UK EMail: m.handley@cs.ucl.ac.uk
马克·汉德利大学学院伦敦高尔街伦敦WC1E 6BT英国电子邮件：m。handley@cs.ucl.ac.uk
Sebastien Barre Universite catholique de Louvain Pl. Ste Barbe, 2 Louvain-la-Neuve 1348 Belgium Phone: +32 10 47 91 03 EMail: sebastien.barre@uclouvain.be
Sebastien Barre Universite catholique de Louvain Pl.Ste Barbe，2 Louvain la Neuve 1348比利时电话：+32 10 47 91 03电子邮件：Sebastien。barre@uclouvain.be
Janardhan Iyengar Franklin and Marshall College Mathematics and Computer Science PO Box 3003 Lancaster, PA 17604-3003 USA Phone: 717-358-4774 EMail: jiyengar@fandm.edu
Janardhan Iyengar Franklin和Marshall学院数学和计算机科学邮箱3003宾夕法尼亚州兰开斯特17604-3003美国电话：717-358-4774电子邮件：jiyengar@fandm.edu