Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt

[Mikkel Fahnøe Jørgensen <[e-mail]>]

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 ([e-mail])
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 ([e-mail])
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 <[e-mail]>
Date: 2020年12月14日(星期一) 12:36

To：安勍(莳逸) <[e-mail]>; "Ma, Yunfei"
<[e-mail]>; 刘彦梅(喵吉) <[e-mail]>;
Christian Huitema <[e-mail]>; 李振宇 <[e-mail]>

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