QUIC 的多路径扩展
抽象
本文档指定了 QUIC 协议的多路径扩展，以支持同时使用单个连接的多个路径。
讨论场地
在作为 RFC 发布之前，应删除此注释。
对本文档的讨论在 QUIC 工作组邮件列表 （quic@ietf.org）， 存档于quic.
此草案的来源和问题跟踪器可在以下位置找到https://github.com/mirjak/draft-lmbdhk-quic-multipath.
本备忘录的状态
本互联网草案的提交完全符合 BCP 78 和 BCP 79 的规定。
互联网草稿是互联网工程任务的工作文档 力 （IETF）。请注意，其他组也可能分发工作 作为互联网草稿的文档。当前的互联网草案列表是 在Active Internet-Drafts.
互联网草稿是有效期最长为六个月的草稿文件 并可能被其他文档更新、替换或过时 时间。使用互联网草稿作为参考是不合适的 材料或引用它们，而不是作为“正在进行的工作”。
本互联网草案将于 2022 年 4 月 28 日到期。
版权声明
版权所有 （c） 2021 IETF Trust 和被确定为 文档作者。保留所有权利。
本文档受 BCP 78 和 IETF Trust 的法律约束 与 IETF 文件相关的规定 (Trust Legal Provisions (TLP) – IETF Trust） 自 本文件的发布。请查看这些文件 仔细，因为他们描述了您的权利和限制 尊重本文件。从中提取的代码组件 文档必须包含简化的 BSD 许可证文本，如 信托法律条款的第 4.e 节，并且没有提供 简化 BSD 许可证中所述的保修。
1. 引言
本文档指定了对 QUIC v1 的扩展[QUIC-传输]允许同时使用单个连接的多个路径。
该提案基于几个基本设计点：
- 尽可能多地重用 QUIC-v1 机制。具体而言，该提案使用为 QUIC v1 指定的路径验证，旨在尽可能多地重用 QUIC 的连接迁移。
- 使用与 QUIC v1 相同的数据包标头格式，以避免数据包被中间盒丢弃的风险（可能仅支持 QUIC v1）
- 拥塞控制、RTT 测量和 PMTU 发现应按路径进行（以下[QUIC-传输])
- 路径由源和目标 IP 地址以及源和目标端口的 4 元组确定。因此，每个 4 元组最多可以有一个活动路径/连接 ID。
第 9 节中指定的路径管理[QUIC-传输]实现多个目标：它指示对等方通过新的首选路径切换发送，并允许对等方释放与旧路径关联的资源。多路径需要对该机制进行几项更改：
- 允许在多个路径上同时传输非探测帧。
- 继续使用现有路径，即使已在另一条路径上接收到非探测帧。
- 管理已放弃的路径的删除。
因此，此扩展指定了与第 9 节中路径管理规范的背离[QUIC-传输]因此，需要使用新的传输参数在两个端点之间进行协商，如第 2 节中指定的那样。
此提案支持协商对所有路径使用一个数据包编号空间或对每个路径使用单独的数据包编号空间。虽然单独的数据包编号空间允许更高效的 ACK 编码，尤其是当路径具有高度不同的延迟时，但这种方法需要使用连接 ID。因此，在高度受限的网络中，使用单个数字空间可能是有益的，因为这些网络无法从标头中公开连接 ID 中受益。虽然此版本文档中的规范支持这两种方法，但最终发布 QUIC 多路径扩展的目的是选择一个选项以避免不兼容。在最终公布之前，需要更多的评估和实施经验来选择一种方法。关于优缺点的一些讨论可以在这里找到： https://github.com/mirjak/draft-lmbdhk-quic-multipath/blob/master/presentations/PacketNumberSpace_s.pdf
正如此版本草案中当前定义的那样，使用多个数据包编号空间需要使用连接 ID 是双向的。当今的部署通常只在将数据包从客户端发送到服务器时使用目标连接 ID，因为这解决了迁移的最重要用例，例如 NAT 重新绑定或移动事件。需要进一步的讨论和工作来评估当连接 ID 仅存在于一个方向时，是否也支持使用多个数据包编号空间。
此提案不包括地址发现和管理。假定设置或拆除路径的地址和实际决策过程由使用 QUIC 多路径扩展的应用程序处理。此外，该提案仅指定了一个简单的基本数据包调度算法，以便提供一些基本的实现指导。然而，更先进的算法以及增强当前路径状态信令的潜在扩展有望成为未来的工作。
1.1. 约定和定义
关键词“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应”、 本文档中的“推荐”、“不推荐”、“可能”和“可选”均应解释为 如 BCP 14 中所述[RFC2119] [RFC8174]当且仅当它们出现在所有 大写字母，如下所示。
我们假设读者熟悉[QUIC-传输]. 此外，我们还定义了以下术语：
- 路径标识符（路径 ID）：用于标识 QUIC 连接中的路径的标识符 在端点上。路径标识符用于多路径控制帧（等PATH_ABANDON帧） 确定路径。默认情况下，它被定义为目标连接 ID 的序列号 用于在该特定路径上发送数据包，但可以使用替代定义 如果该连接 ID 的长度为零。
- 数据包编号空间标识符（PN Space ID）：用于区分数据包的标识符 不同路径的数字空格。它用于 1-RTT 数据包和 ACK_MP 帧。每个节点 维护它提供给对等方的每个 CID 的“已接收数据包”列表， 用于确认使用该 CID 接收的数据包。
路径标识符和数据包号空间标识符之间的区别在于，路径标识符 在多路径控制帧中用于标识路径，并使用数据包编号空间标识符 在 1-RTT 数据包和 ACK_MP 帧中，以区分不同路径的数据包编号空间。 两个标识符具有相同的值，即连接 ID 的序列号，如果 使用非零连接 ID。如果连接 ID 长度为零，则数据包编号空间 标识符为 0，而路径标识符在路径建立时选择。
2. 握手协商和传输参数
此扩展定义了一个新的传输参数，用于协商多路径扩展的使用 在连接握手期间，如[QUIC-传输].新的传输参数为 定义如下：
- 名称：enable_multipath（待定 - 实验使用0xbabf）
- 值：0（默认值）表示禁用。终结点在值字段中使用 2 位来协商一个或多个 PN 空间，客户端和服务器的可用选项值列在表 1 中：
| 客户端选项 | 定义 | 允许的服务器响应 |
|---|---|---|
| 0x0 | 不支持多路径 | 0x0 |
| 0x1 | 仅支持一个 PN 空间用于多路径 | 0x0或0x1 |
| 0x2 | 仅支持多路径的多个 PN 空间 | 0x0或0x2 |
| 0x3 | 支持一个PN空间和多个PN空间 | 0x0、0x1或0x2 |
如果对等体不携带 enable_multipath 传输参数，则表示对等体不携带 支持多路径，端点必须回退到[QUIC-传输]使用单一路径，不得使用 本文档中定义的任何框架或机制。如果终结点收到传输参数的意外值 “enable_multipath”，它必须将其视为 MP_CONNECTION_ERROR 类型的连接错误 并关闭连接。
请注意，传输参数“active_connection_id_limit”[QUIC-传输]限制可用数量 连接 ID，并限制并发路径数。对于 QUIC 多路径扩展，当 QUIC 标头中未公开任何连接 ID 时，此限制甚至适用。
3. 路径设置和删除
完成握手后，终端节点已同意启用多路径功能，并可以开始使用多路径。本文档不讨论客户端何时决定启动新路径。我们将这种讨论委托给单独的文件。
该提案增加了一个用于路径管理的多路径控制框架：
- PATH_ABANDON帧，供接收方放弃路径 第 10.1 节
所有新帧都以 1-RTT 数据包的形式发送[QUIC-传输].
3.1. 路径启动
协商多路径选项时，想要使用其他选项的客户端 path 必须首先使用 PATH_CHALLENGE 和 PATH_RESPONSE 启动地址验证过程 第 8 节中描述的框架[QUIC-传输].后 在新路径上接收来自客户端的数据包时，服务器可以 反过来，尝试使用相同的机制验证这些路径。
如果验证成功，客户端可以在新路径上发送非探测的 1-RTT 数据包。在 与第 9 节中的规范形成鲜明对比[QUIC-传输]这 服务器不得假设在新的 path 指示尝试迁移到该路径。取而代之的是服务器 应将已接收非探测数据包的新路径视为 可用于传输。
3.2. 路径关闭
每个终结点管理可用于传输的路径集。 在连接中的任何时间，每个端点都可以决定放弃以下路径之一， 例如，以下：本地连接的变化或 本地首选项。终结点放弃路径后，对等方将 该路径上不再接收任何非探测数据包。
想要关闭路径的端点不应依赖于隐式信号，如空闲时间或数据包丢失， 但应该使用显式请求通过发送PATH_ABANDON帧来终止路径（参见第 10.1 节）。
3.2.1. 使用 PATH_ABANDON 帧关闭路径
两个端点，即客户端和服务器，都可以通过发送PATH_ABANDON帧（参见第 10.1 节）来关闭路径，该帧 放弃具有相应路径标识符的路径。标记路径后 作为“放弃”，表示可以释放与路径相关的资源，例如使用的连接 ID。 但是，与通过该路径传递的数据相关的信息不应立即发布 因为仍然可以接收确认或其他帧，这些帧也可能触发另一条路径上的数据重新传输。
发送PATH_ABANDON帧的端点应将路径视为放弃，当 确认包含PATH_ABANDON帧的数据包。释放路径的资源时， 终结点应为路径上使用的连接 ID（如果有）发送RETIRE_CONNECTION_ID帧。
PATH_ABANDON帧的接收方不应立即释放其资源，而应释放其资源 等待收到已用连接 ID 或 3 个 RTO 的RETIRE_CONNECTION_ID帧。
通常，客户端应使用PATH_ABANDON帧向服务器指示 该路径条件已更改，使得该路径不再可用或将不再可用，例如，在万一 移动事件。因此，PATH_ABANDON帧向接收对等体指示发送方 不打算再在该路径上发送任何数据包，但也建议接收方不要 数据包应向任一方向发送。PATH_ABANDON帧的接收器也可以 发送一个PATH_ABANDON帧，以表明它自己愿意不再在此路径上发送任何数据包。
如果使用连接 ID，则可以在任何路径上发送PATH_ABANDON帧，而不仅仅是 打算关闭。因此，即使该路径上的连接是 已经坏了。如果未使用连接 ID，并且必须在路径上发送PATH_ABANDON帧 也就是说，包含PATH_ABANDON帧的数据包或 无法再接收包含 PATH_ABANDON 帧的 ACK 的数据包，并且终端节点 可能需要依靠空闲超时来关闭路径，如第 3.2.3 节中所述。
可重新传输的帧，这些帧之前已在废弃路径上发送并被视为丢失， 应该在不同的路径上重新传输。
如果为 QUIC 连接的唯一活动路径接收到PATH_ABANDON帧，则接收 peer 应该发送一个CONNECTION_CLOSE帧并进入关闭状态。如果客户端 收到最后一个打开路径的PATH_ABANDON帧，如果出现以下情况，它可能会尝试打开新路径 可用，并且仅在路径验证失败或帧CONNECTION_CLOSE时启动连接关闭 从服务器接收。同样，服务器可以等待一个短暂的、有限的时间，例如一个 RTO 如果在发送CONNECTION_CLOSE帧之前在新路径上接收到路径探测数据包。
3.2.2. RETIRE_CONNECTION_ID帧的影响
接收RETIRE_CONNECTION_ID帧会导致端点丢弃与 该连接 ID。如果对等方使用连接 ID 来标识从对等方到 此终结点，资源包括用于发送确认的已接收数据包列表。 对等方可以决定继续使用以前的相同 IP 地址和 UDP 端口发送数据 与连接 ID 关联，但执行此操作时必须使用其他连接 ID。
3.2.3. 空闲超时
[QUIC-传输]如果连接保持空闲时间过长，则允许关闭连接。 多路径 QUIC 中的连接空闲超时定义为“在任何路径上均未收到数据包 空闲超时的持续时间“。当只有一个路径可用时，服务器必须遵循 中的规格[QUIC-传输].
当多条路径是 可用时，服务器应监视非探测数据包的到达 在可用路径上。服务器应停止在路径上发送流量 在最后 3 条路径中未收到非探测数据包 RTT，但如果该规则会取消所有可用的资格，则可以忽略该规则 路径。服务器可以释放与以下路径关联的资源 在足够长的时间内没有收到非探测数据包 路径空闲延迟，但应该只释放最后一个资源 在空闲期间未收到任何流量时的可用路径 超时，如第 10.1 节中所述[QUIC-传输]. 这意味着，如果所有路径在空闲超时期间保持空闲状态，则连接 隐式关闭。
服务器实现需要选择子路径空闲超时作为交易 在保持资源（如连接 ID）处于使用状态之间关闭 时间过长或必须立即重新建立路径 在客户端对路径放弃的虚假估计之后。
3.3. 路径状态
图 1 显示了端点路径可能具有的状态。
o
| PATH_CHALLENGE sent/received on new path
v
+------------+ Path validation abandoned
| Validating |----------------------------------+
+------------+ |
| |
| PATH_RESPONSE received |
| |
v Associated CID have been retired |
+------------+ Path's idle timeout |
| Active |----------------------------------+
+------------+ |
| |
| PATH_ABANDONED sent/received |
v |
+------------+ |
| Closing | |
+------------+ |
| |
| Associated CID have been retired |
| Path's idle timeout |
v |
+------------+ |
| Closed |<---------------------------------+
+------------+
在非最终状态下，主机必须跟踪以下信息。
- 关联的 4 元组：元组（源 IP、源端口、目标 IP、目标端口） endhost 用于通过路径发送数据包。
- 关联的目标连接 ID：用于通过路径发送数据包的连接 ID。
如果在连接上使用多个数据包编号空间，则主机还必须跟踪以下信息。
- 路径数据包编号空间：终端维护一个单独的数据包编号，用于通过此路径发送和接收数据包。 中所述的数据包号注意事项[QUIC-传输]在给定路径内应用。
在“活动”状态下，主机还必须跟踪以下信息。
- 关联的源连接 ID：用于通过路径接收数据包的连接 ID。
处于“正在验证”状态的路径执行路径验证，如[QUIC-传输]. 终端主机不应在处于“正在验证”状态的路径上发送非探测帧，因为它无法保证数据包 实际上会到达对等方。
终端主机可以使用处于“活动”状态的所有路径，前提是拥塞控制和流量控制当前允许在路径上发送新数据。
在“关闭”状态下，终端主机不应再在此路径上发送数据包，因为无法保证 对等方仍然可以将数据包映射到连接。终端主机应等待确认PATH_ABANDONED 在将路径移动到“已关闭”状态之前进行帧，以确保路径的正常终止。
当路径达到“已关闭”状态时，endhost 将释放该路径的所有关联资源。 因此，终端主机无法再在此路径上发送或接收数据包。
4. 拥堵控制
发送方必须管理每条路径的拥塞状态，并且不得在给定路径上发送超过该路径上的拥塞控制所允许的数据。这已经是[QUIC-传输].
当多路径 QUIC 连接使用两条或多条路径时，无法保证这些路径是完全脱节的。当两条（或多条路径）共享同一瓶颈时，使用标准拥塞控制方案可能会导致带宽分配不公平，因为多路径连接比竞争的单路径连接获得更多的带宽。多路径 TCP 使用 LIA 拥塞控制方案[RFC6356]来解决这个问题。该方案可以立即适应多路径 QUIC。已经为多路径TCP提出了其他耦合拥塞控制方案，例如[奥利亚].
5. 计算路径 RTT
确认延迟是两个单向延迟的总和，即延迟 在数据包发送路径上以及所选返回路径上的延迟 致谢。当不同的路径有不同的 特征，这可能会导致确认延迟有所不同 广泛。例如，考虑使用两个 地面路径，每个方向的延迟为 50 毫秒，并且 地球静止卫星路径，两者的延迟均为 300 毫秒 方向。确认延迟将取决于组合 用于数据包传输和 ACK 传输的路径， 如表2所示。
| ACK路径\数据路径 | 地球的 | 卫星 |
|---|---|---|
| 地球的 | 100毫秒 | 350毫秒 |
| 卫星 | 350毫秒 | 600毫秒 |
使用 中指定的默认算法[QUIC-恢复]将导致 在次优性能下，计算平均 RTT 和标准 不同时延测量的一系列偏差 组合路径。同时，早期的测试表明它是 希望通过最短的路径发送 ACK，因为较短的路径 ACK 延迟可实现更紧密的控制环路和更好的性能。 测试还表明，发送 ACK 的副本是可取的 在多条路径上，如果路径突然丢失，则保持鲁棒性。
早期的实现通过使用 时间戳，如[QUIC-时间戳].当时间戳 存在，实现可以估计传输延迟 在每条单向路径上，然后可以使用这些单向延迟来获得更多 高效实施恢复和拥塞控制 算法。
如果时间戳不可用，实现可以估计一个 使用统计技术的方式延迟。例如，在示例中 如表1所示，实现可以使用“同路径” 测量以估计地面路径的单向延迟 每个方向约50ms，卫星路径约50ms。 300毫秒然后可以使用进一步的测量来维持估计值 的单向延迟变化，使用类似于卡尔曼滤波的逻辑。 但统计处理容易出错，并且使用时间戳 提供更可靠的测量。
6. 数据包调度
常规 QUIC 连接上 QUIC 数据包的传输受以下因素的约束 来自应用程序和拥塞控制方案的数据到达。QUIC公司 只有当至少一个路径的拥塞窗口打开时，才能发送数据包。
多路径 QUIC 实现还需要包含一个数据包调度程序，该调度程序决定： 在拥塞窗口打开的路径中，下一个 QUIC 数据包所经过的路径 将被发送。许多因素会影响这些算法的定义，并且 它们的确切定义超出了本文档的范围。各种数据包调度程序已被 提出并实施，特别是针对多路径TCP。配套草稿[I-D.bonaventure-iccrg-调度器]提供多种通用 数据包调度程序，具体取决于应用程序目标。
7. 数据包号空间和连接ID的使用
如果数据包标头中存在连接 ID（非零长度），则连接 ID 用于标识路径。 如果不存在连接 ID，则 4 元组标识路径。 握手（和多路径协商）期间使用的初始路径的路径 ID 为 0，因此 所有 0-RTT 数据包也使用路径 ID 0 进行跟踪和处理。 对于 1-RTT 数据包，路径 ID 是 数据包标头中存在的目标连接 ID，如第 5.1.1 节中所定义 之[QUIC-传输]，如果连接 ID 长度为零，则为 0。
如果使用非零长度的连接 ID，则终结点必须在不同的路径上使用不同的连接 ID。 尽管如此，接收方仍可能会观察到在不同的 4 元组上使用的相同连接 ID 例如，由于 NAT 重新绑定。在这种情况下，接收器将按照 第 9.3 节[QUIC-传输].
初始数据包和握手数据包的确认必须使用 ACK 帧进行传输，如[QUIC-传输]. ACK 帧，如[QUIC-传输]，不携带路径标识符。如果出于任何原因 ACK 帧是 在 1-RTT 数据包中接收 当多路径协商的状态不明确时，它们必须解释为确认 在路径 0 上发送的数据包。
7.1. 使用一个数据包号空间
如果协商多路径选项以对所有路径使用一个数据包编号空间，则数据包序列号将从 公用号码空间，例如，可以在一条路径上发送数据包号 N，在另一条路径上发送数据包号 N+1。
ACK 帧报告到目前为止已接收的数据包数，而不考虑接收数据包的路径。 这意味着发送方需要在发送的数据包号和 发送这些数据包的路径。这对于实现每条路径的拥塞控制是必需的。
确认数据包时，必须更新路径的拥塞控制状态 最初发送确认数据包的位置。 RTT 是根据该数据包传输和 它的第一个确认（参见第 5 节），用于更新发送路径的 RTT 统计信息。
此外，损失检测必须进行调整，以允许不同的 RTT 不同的路径。例如，计时器计算应考虑 account 发送数据包的路径的 RTT。检测 基于数据包编号，应将给定的数据包编号与 该路径接收的最高数据包编号。
7.2. 使用多个数据包编号空间
如果启用了值为 2 的多路径选项，则每个路径都有自己的数据包编号空间，用于传输 1-RTT 数据包，并使用第 10.2 节中指定的新 ACK 帧格式。 与 QUIC v1 ACK 帧相比，MP_ACK 帧还包含数据包编号空间标识符 （PN Space ID）。 PN 空间 ID 用于区分不同路径的数据包编号空间，仅派生自目标连接 ID 的序列号。 因此，可以根据每个数据包中的目标连接 ID 来识别 1-RTT 数据包的数据包编号空间。
一旦完成值为 2 的多路径支持协商， 端点应使用 ACK_MP 帧而不是 ACK 帧来确认路径 0 上的 1-RTT 数据包， 以及握手结束后确认的 0-RTT 数据包。
以后[QUIC-传输]，每个端点都使用 NEW_CONNECTION_ID 帧来颁发可用的连接 ID 到达它。在终结点通过启动路径验证添加新路径之前，它必须检查是否至少有一个未使用的路径 连接 ID 可用于每一端。
如果传输参数 “active_connection_id_limit” 协商为 N， 服务器提供了 N 个连接 ID，并且客户端已经在主动使用 N 个路径， 达到限制。如果客户端想要启动新路径，则必须停用 既定路径之一。
ACK_MP帧第 10.2 节可以通过不同的路径或识别的相同路径返回 通过路径标识符，基于发送ACK_MP帧的不同策略。
使用多个数据包编号空间需要更改 AEAD 应用于数据包的方式 保护，如第 7.2.1 节所述，以及更严格的密钥约束 更新，如第 7.2.2 节所述。
7.2.1. QUIC 多路径的数据包保护
QUIC v1 的数据包保护指定为 第 5 节[QUIC-红绿灯].一般原则 QUIC 多路径的数据包保护不会更改。无需更改即可进行设置 数据包保护密钥、初始密钥、标头保护、使用 0-RTT 密钥、接收 无序保护数据包、接收受保护数据包、 或重试数据包完整性。但是，使用多个 1-RTT 数据包的编号空间需要更改 AEAD 使用情况。
第 5.3 节[QUIC-红绿灯]指定 AEAD 的用法，特别是 nonce，N，由数据包保护 IV 与数据包编号组合而成。如果 使用多个数据包编号空间，仅数据包编号即可 不保证随机数的唯一性。
为了保证 None 的唯一性，随机数 N 的计算公式为 将数据包保护 IV 与数据包编号相结合 和路径标识符。
1-RTT 数据包的路径 ID 是 之[QUIC-传输]，如果连接 ID 长度为零，则为零。 《公约》第19条[QUIC-传输]将连接 ID 序列号编码为可变长度整数， 允许值最大为 2^62-1;在此规范中，范围小于 2^32-1 在更新数据包保护密钥之前，必须使用值。
要计算随机数，则为 96 位 path-and-packet-number 由字节顺序排列的 32 位连接 ID 序列号组成， 两个零位，以及按网络字节顺序重建的 QUIC 数据包编号的 62 位。 如果 IV 大于 96 位，则路径和数据包编号将用零填充到 IV的大小。填充数据包编号和 IV 的独占 OR 构成 AEAD 随机数。
例如，假设 IV 值为 ，连接 ID 序列 number 为 ，数据包编号为 ，随机数将设置为 。6b26114b9cba2b63a9e8dd4f3aead6b2611489cba2b63a9e873e2
7.2.2. QUIC Multipath 的密钥更新
QUIC v1 的关键阶段位更新过程在[QUIC-红绿灯].密钥更新的一般原则在此没有改变 规范。在 QUIC v1 之后，关键相位用于指示哪个 数据包保护密钥用于保护数据包。关键阶段位为 切换以发出每个后续密钥更新的信号。由于网络延迟， 受旧密钥保护的数据包可能比数据包晚到达 使用新密钥进行保护。因此，终端节点需要保留旧数据包 键允许处理这些延迟的数据包，并且必须区分 在新密钥和旧密钥之间。在 QUIC V1 中，这是使用数据包完成的 数字，以便规则变得简单：如果数据包编号为 低于任何数据包编号的帧当前密钥阶段。
在不同路径上使用多个数据包编号空间时， 启动密钥更新过程时需要小心，因为路径不同 使用不同的数据包编号空间，但共享一个 钥匙。在一个路径上启动密钥更新时，数据包将发送到另一个路径 需要知道转换何时完成。否则，可能会 其他路径使用旧密钥发送数据包，但跳过发送 当前关键阶段，并直接跳转到下一个关键阶段发送数据包。 发生这种情况时，因为终端只能保留两组数据包 保护密钥与 1 位关键相位，其他路径不能 区分应该使用哪个密钥来解码接收到的数据包，从而产生什么结果 在密钥轮换同步问题中。
要解决此类同步问题，如果密钥更新是 在一条路径上初始化，发送方应发送至少一个带有新 键在所有活动路径上。此外，一个 终端节点不得启动后续密钥更新，直到具有 每条路径上都已确认当前密钥。
遵循第 5.4 节[QUIC-红绿灯]，关键相位位受到保护，因此 同时发送多个具有关键相位翻转的数据包应该 不会导致可链接性问题。
8. 示例
8.1. 路径建立
图 2 说明了使用多个数据包编号空间建立新路径的示例。
Client Server
(Exchanges start on default path)
1-RTT[]: NEW_CONNECTION_ID[C1, Seq=1] -->
<-- 1-RTT[]: NEW_CONNECTION_ID[S1, Seq=1]
<-- 1-RTT[]: NEW_CONNECTION_ID[S2, Seq=2]
...
(starts new path)
1-RTT[0]: DCID=S2, PATH_CHALLENGE[X] -->
Checks AEAD using nonce(CID sequence 2, PN 0)
<-- 1-RTT[0]: DCID=C1, PATH_RESPONSE[X], PATH_CHALLENGE[Y],
ACK_MP[Seq=2,PN=0]
Checks AEAD using nonce(CID sequence 1, PN 0)
1-RTT[1]: DCID=S2, PATH_RESPONSE[Y],
ACK_MP[Seq=1, PN=0], ... -->
在图 2 中，端点首先交换新的可用连接 ID 使用NEW_CONNECTION_ID框架。在此示例中，客户端提供一个连接 ID（序列号为 1 的 C1）， 服务器提供两个连接 ID（S1 的序列号为 1，S2 的序列号为 2）。
在客户端通过在该路径上发送具有PATH_CHALLENGE帧的数据包来打开新路径之前， 它必须检查。每端是否有未使用的连接 ID。 在此示例中，客户端选择连接 ID S2 作为新路径中的目标连接 ID。
如果客户端已使用所有分配的 CID，则应该停用那些 不再使用，并且服务器应该提供替换，如[QUIC-传输]. 通常，需要再提供一个当前正在使用的连接 ID，以允许新路径 或迁移。
8.2. 路径关闭
在此示例中，客户端检测到网络环境变化（客户端的 4G/Wi-Fi 已关闭， Wi-Fi 信号衰减到阈值，或者 RTT 质量或丢失率 变得更糟）并希望关闭初始路径。
在图 3 中，服务器的 1-RTT 数据包使用序列号为 1 的 DCID C1 作为第一条路径;客户端的 1-RTT 数据包使用 DCID S2，其序列号为 2。对于第二条路径， 服务器的 1-RTT 数据包使用 DCID C2，其序列号为 2;这 客户端的 1-RTT 数据包使用 CID S3，其序列号为 3。请注意， 两条路径使用不同的数据包编号空间。
客户端通过发送 ID 为 1 的路径启动路径闭包 具有PATH_ABANDON帧的数据包。当服务器收到PATH_ABANDON 帧，它还会在下一个数据包中发送PATH_ABANDON帧。之后 可以使用RETIRE_CONNECTION_ID停用两个方向的连接 ID 框架。
Client Server
(client tells server to abandon a path)
1-RTT[X]: DCID=S2 PATH_ABANDON[path_id=1]->
(server tells client to abandon a path)
<-1-RTT[Y]: DCID=C1 PATH_ABANDON[path_id=2], ACK_MP[Seq=2, PN=X]
(client abandons the path that it is using)
1-RTT[U]: DCID=S3 RETIRE_CONNECTION_ID[2], ACK_MP[Seq=1, PN=Y] ->
(server abandons the path that it is using)
<- 1-RTT[V]: DCID=C2 RETIRE_CONNECTION_ID[1], ACK_MP[Seq=3, PN=U]
10. 新框架
所有新帧只能以 1-RTT 数据包的形式发送，并且不得使用其他加密级别。
如果终端节点从其他加密级别的数据包接收特定于多路径的帧，则必须返回 MP_PROTOCOL_VIOLATION为连接错误并关闭连接。
10.1. PATH_ABANDON框架
PATH_ABANDON 帧通知对等方放弃 路径。更复杂的路径管理可以 通过额外的扩展（例如，PATH_STATUS帧[I-D.liu-多路径-quic]).
PATH_ABANDON帧的格式如图 4 所示。
PATH_ABANDON Frame {
Type (i) = TBD-03 (experiments use 0xbaba05),
Path Identifier (..),
Error Code (i),
Reason Phrase Length (i),
Reason Phrase (..),
}
PATH_ABANDON帧包含以下字段：
Path Identifier：路径的标识符，其格式如图 5 所示。
-
标识符类型：将“标识符类型”字段设置为指示路径标识符的类型。
- 类型 0：在以下情况下，请参阅控制帧的发送方使用的连接标识符 通过指定路径发送数据。如果此连接，则应使用此方法 标识符的长度为非零。如果此连接标识符，则不得使用此方法 长度为零。
- 类型 1：参考控制帧的接收器在以下情况下使用的连接标识符 通过指定路径发送数据。如果此连接，则不得使用此方法 标识符长度为零。
- 类型 2：引用发送或接收控制帧的路径。
- 路径标识符内容：指定路径标识符的可变长度整数。如果标识符类型为 2， 路径标识符内容必须为空。
注意：如果PATH_ABANDON帧的接收方在该路径上使用非零长度的连接ID， 端点应将类型 0x00 用于控制帧中的路径标识符。如果接收机的PATH_ABANDON帧 使用长度为零的连接 ID，但对等方在该路径（端点）上使用非长度为零的连接 ID 应将 type 0x01 用作路径标识符。如果两个终结点都在该路径上使用 0 长度连接 ID， 端点应仅使用 0x02 类型作为路径标识符。
错误代码：
一个可变长度整数，指示放弃此路径的原因。
原因短语长度：
一个可变长度整数，指定原因短语的长度（以字节为单位）。 由于 PATH_ABANDON 帧不能在数据包之间拆分，因此任何限制 on 数据包大小也会因原因短语而限制可用空间。
原因短语：
闭合的其他诊断信息。如果出现以下情况，则长度可以为零 发件人选择不提供超出“错误代码”值的详细信息。 这应该是 UTF-8 编码的字符串[RFC3629]，虽然框架 不携带有助于理解的信息，例如语言标签 由创建文本的实体以外的任何实体提供。
应确认PATH_ABANDON帧。如果数据包包含 PATH_ABANDON 帧被认为是丢失的，对等体应该重复它。
如果标识符类型为 0x00 或 0x01，则可以在任何路径上发送PATH_ABANDON帧， 而不仅仅是由“路径标识符内容”字段标识的路径。如果 标识符类型 如果0x02，则PATH_ABANDON帧只能在路径上发送 这是打算放弃的。
10.2. ACK_MP框架
ACK_MP框架（TBD-00 和 TBD-01 型;实验使用 0xbaba00..0xbaba01） 是 ACK 框架的扩展，由[QUIC-传输].它用于 使用多个时确认在不同路径上发送的数据包 数据包编号空间。如果帧类型为 TBD-01，则ACK_MP帧还包含 在连接上接收的具有关联 ECN 标记的 QUIC 数据包的总和 到这一点。
ACK_MP帧的格式如图 6 所示。
ACK_MP Frame {
Type (i) = TBD-00..TBD-01 (experiments use 0xbaba00..0xbaba01),
Packet Number Space Identifier (i),
Largest Acknowledged (i),
ACK Delay (i),
ACK Range Count (i),
First ACK Range (i),
ACK Range (..) ...,
[ECN Counts (..)],
}
与 中指定的 ACK 帧相比[QUIC-传输]，则添加以下字段。
Packet Number Space Identifier：路径包号空间的标识符，即 ACK_MP帧确认的 1-RTT 数据包的目标连接 ID。如果端点收到 长度为零的连接 ID 的 1-RTT 数据包，它应在ACK_MP帧中使用数据包编号空间标识符 0。 如果终端收到具有不存在的数据包编号空间 ID 的ACK_MP帧，则必须处理此帧 作为 MP_PROTOCOL_VIOLATION 类型的连接错误，然后关闭连接。
使用单个数据包编号空间时，终端主机不得发送ACK_MP帧。 如果终端主机在协商单个数据包编号空间时接收到ACK_MP帧，则必须处理 这是 MP_PROTOCOL_VIOLATION 类型的连接错误，并关闭连接。
11. 错误代码
多路径 QUIC 传输错误代码是 62 位无符号整数，其后列[QUIC-传输].
本节列出了定义的多路径 QUIC 传输错误代码，这些错误代码可以是 用于具有0x1c类型的CONNECTION_CLOSE框架。这些错误适用于整个连接。
MP_PROTOCOL_VIOLATION（实验使用0xba01）：端点检测到协议符合性错误 这没有被更具体的错误代码所涵盖。
12. IANA 注意事项
本文档定义了一个新的传输参数，用于协商为 QUIC 启用多个路径， 以及两种新的框架类型。该草案定义了实验的临时值，但我们希望 IANA 能够 如果草稿获得批准，则分配短值。
表 3 中的以下条目应添加到“QUIC 传输参数”注册表中 在“QUIC协议”标题下。
| 价值 | 参数名称。 | 规范 |
|---|---|---|
| 待定（实验使用0xbabf） | enable_multipath | 第2节 |
表 4 中定义的以下帧类型应添加到“QUIC 帧类型”注册表中 在“QUIC协议”标题下。
| 价值 | 框架名称 | 规范 |
|---|---|---|
| TBD-00 - TBD-01（实验使用0xbaba00-0xbaba01） | ACK_MP | 第 10.2 节 |
| TBD-02 （实验使用0xbaba05） | PATH_ABANDON | 第 10.1 节 |
表 5 中定义的以下传输错误代码应添加到“QUIC 传输错误代码”中 注册表在“QUIC协议”标题下。
| 价值 | 法典 | 描述 | 规范 |
|---|---|---|---|
| 待定（实验使用0xba01） | MP_PROTOCOL_VIOLATION | 多路径协议冲突 | 第11节 |
16. 参考资料
16.1. 规范性参考文献
[QUIC-TLS]
汤姆森，M.，编辑。和S.特纳，编辑。,“使用 TLS 保护 QUIC”,RFC 9001的,DOI： 10.17487/RFC9001， 五月 2021，<Information on RFC 9001 » RFC Editor>.
[QUIC-运输]
艾扬格，J.，编辑。和M.汤姆森，编辑。,“QUIC：基于UDP的多路复用安全传输”,RFC 9000的,DOI： 10.17487/RFC9000， 五月 2021，<Information on RFC 9000 » RFC Editor>.
[RFC2119]
布拉德纳，S.,“RFC中用于指示需求级别的关键字”,BCP 14 （英语）,RFC 2119的,DOI： 10.17487/RFC2119， 三月 1997，<Information on RFC 2119 » RFC Editor>.
[RFC3629]
耶尔格，F.,“UTF-8，ISO 10646 的转换格式”,性病 63,RFC 3629的,DOI： 10.17487/RFC3629， 十一月 2003，<Information on RFC 3629 » RFC Editor>.
[RFC8174]
莱巴，B.,“RFC 2119 关键字中大写与小写的歧义”,BCP 14 （英语）,RFC 8174 中,DOI： 10.17487/RFC8174， 五月 2017，<Information on RFC 8174 » RFC Editor>.
16.2. 信息参考
[I-D.bonaventure-iccrg-调度程序]
博纳文图尔，O.,皮罗，M.,康宁克，Q.D.,贝尔茨，M.,帕施，C.和M. 修正,“多路径调度程序”,工作进行中,互联网草稿，draft-bonaventure-iccrg-schedulers-02， 25 10月 2021，<https://www.ietf.org/archive/id/draft-bonaventure-iccrg-schedulers-02.txt>.
[I-D.liu-多路径-quic]
刘彦,马，Y.,惠特玛，C.,安，Q。和李志强,“QUIC 的多路径扩展”,工作进行中,互联网草稿，draft-liu-multipath-quic-04， 5 九月 2021，<https://www.ietf.org/archive/id/draft-liu-multipath-quic-04.txt>.
[奥利娅]
哈利利，R.,加斯特，N.,波波维奇，M.,Upadhyay，美国和J.-Y.勒布德克,“MPTCP 不是帕累托最优的：性能问题和可能的解决方案”,第八届新兴网络实验与技术国际会议论文集，ACM，2012 年。
[QUIC-不变量]
汤姆森，M.,“QUIC 的版本无关属性”,RFC 8999的,DOI： 10.17487/RFC8999， 五月 2021，<Information on RFC 8999 » RFC Editor>.
[QUIC-恢复]
艾扬格，J.，编辑。和I.斯威特，编辑。,“QUIC 丢失检测和拥塞控制”,RFC 9002的,DOI： 10.17487/RFC9002， 五月 2021，<Information on RFC 9002 » RFC Editor>.
[QUIC-时间戳]
惠特玛，C.,“用于测量单向延迟的 Quic 时间戳”,工作进行中,互联网草稿，draft-huitema-quic-ts-06， 12 九月 2021，<https://www.ietf.org/archive/id/draft-huitema-quic-ts-06.txt>.
[RFC6356]
雷丘，C.,汉德利，M.和D.维希克,“多路径传输协议的耦合拥塞控制”,RFC 6356的,DOI： 10.17487/RFC6356， 十月 2011，<Information on RFC 6356 » RFC Editor>.
4053
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
