Some more comments on the proposed MP design
On protocol violations: quote: "If an endpoint receives MP frames from packets of other encryption levels, it MAY return MP_PROTOCOL_VIOLATION as a connection error and close the connection." I think it is important to use strict MUST on easily detectable protocol violations to ensure interop and security. Also, to my previous point on path sequence numbers as IV source: What is the motivation for using the same key on all paths? Is it considered a resource constraint to have more keys? Considering a server might have 10K+ connections, and perhaps 1.3 paths per connections (wild guess), it doesn’t seem to much of an overhead. In addition, having separate keys avoids the sync issues mentioned in the document. As it stands, failure on one active path can block key update. This sounds like an accidental or intentional attack vector, although I’m not sure that it is. On the document format: I think the discussion on application influence is good, but maybe isolate that discussion a bit. It seems that stream priorities are part of the MP design, which isn’t really the case, even if it is relevant to MP applications. On QoE: Maybe it is good to leave the interpretation open to applications, but it makes it more difficult to design a protocol layer on top. Is it the intention that, for example, a QUIC-MP video protocol is designed which then documents how to interpret QoE? If so, does this need to be in the MP protocol, or could it be in a control stream created by the app level protocol? In other words, I’m not sure wha the value is at the transport level if it doesn’t affect the transport layer directly (unless of course I am missing something). ACK_MP frame: If this is an extension to QUIC-v1 it makes sense (and this seems to be the case). If it is intended as a new protocol version, maybe replace the regular ACK frame to avoid protocol bloat? I can see the counter argument that a new frame ID makes it easier to reuse v1 implementations, but protocol bloat is a concern as well. The scheduling section has an example mentioning one of the two paths. I’m sure this a left-over since there could be more than two active paths as I understand. Path state: I do not understand this well enough, but I’m a bit concerned about one endpoint dictating the behaviour of the other regarding priorities etc. It seems like this could easily be abused, and perhaps this is also better done in an application level protocol? The text is not very clear about the client and the servers role in path negotiation. It seems that that it follows he QUIC-v1 async design due to relying on the v1 PATH packets. So presumably this also places constraints on who can send path state updates. If MP was to become more symmetric, I wonder if there is a natural evolution from here, or the proposed design is just digging the async design hole deeper, so to speak. Note that async MP is useful in its own right. Mikkel On 14 December 2020 at 10.38.58, Mikkel Fahnøe Jørgensen ([email protected]) wrote: Would it be practical to lift the 32-bit constraint on the CID sequence number? Even if it probably is enough for most use cases I find it unfortunate to introduce a new constraint here because if affects design decisions elsewhere in stack. For example, it could be required that a key is updated at least once in every 2^31 sequence numbers, or the IV could be hashed and use a sufficiently frequent key update. On 14 December 2020 at 07.14.07, Yanmei Liu ([email protected]) wrote: Hi all, Here is an updated version of the draft which was posted in the mailing list last Friday. Please check this link: https://tools.ietf.org/html/draft-liu-multipath-quic-01 Regarding the questions in the mailing list for the previous version: 1. We have fixed the IANA registry problem in the new version. Thanks Lucas for pointing out this problem. 2. We currently use Github for editing, and we prefer discussions on the mailing list, so we removed the Github link in this draft. This version merges our draft and Christian’s draft, and here are some of the key features: * Re-use as much as possible mechanisms of QUIC-v1, which has supported connection migration and path validation. * To avoid the risk of packets being dropped by middleboxes (which may only support QUIC-v1), use the same packet header formats as QUIC V1. * Endpoints need a Path Identifier for each different path which is used to track states of packets. As we want to keep the packet header formats unchanged [QUIC-TRANSPORT], Connection IDs (and the sequence number of Connection IDs) would be a good choice of Path Identifier. * For the convenience of packet loss detection and recovery, endpoints use a different packet number space for each Path Identifier. * Congestion Control, RTT measurements and PMTU discovery should be per-path (following [QUIC-TRANSPORT]) Thanks Jana and Kazuho for reviewing the proposal. We would like to know how people think about the draft, and all feedbacks and suggestions are welcome! Thanks, Yanmei ------------------------------------------------------------------ From: internet-drafts <[email protected]> Date: 2020年12月14日(星期一) 12:36 To：安勍(莳逸) <[email protected]>; "Ma, Yunfei" <[email protected]>; 刘彦梅(喵吉) <[email protected]>; Christian Huitema <[email protected]>; 李振宇 <[email protected]> Subject: New Version Notification for draft-liu-multipath-quic-01.txt A new version of I-D, draft-liu-multipath-quic-01.txt has been successfully submitted by Yanmei Liu and posted to the IETF repository. Name: draft-liu-multipath-quic Revision: 01 Title: Multipath Extension for QUIC Document date: 2020-12-14 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/archive/id/draft-liu-multipath-quic-01.txt Status: https://datatracker.ietf.org/doc/draft-liu-multipath-quic/ Htmlized: https://datatracker.ietf.org/doc/html/draft-liu-multipath-quic Htmlized: https://tools.ietf.org/html/draft-liu-multipath-quic-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-liu-multipath-quic-01 Abstract: This document specifies multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. The extension is compliant with the single-path QUIC design. The design principle is to support multipath by adding limited extension to [QUIC-TRANSPORT]. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat
