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

Yunfei Ma <> Wed, 16 December 2020 07:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15DE33A1070 for <>; Tue, 15 Dec 2020 23:25:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WoAZyBkz_w2X for <>; Tue, 15 Dec 2020 23:25:14 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9A333A106A for <>; Tue, 15 Dec 2020 23:25:13 -0800 (PST)
Received: by with SMTP id p7so12415525vsf.8 for <>; Tue, 15 Dec 2020 23:25:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n9n9jQp93ZlqH2/7/6Mp3tVXspS0c6siJfaVG+BlpLE=; b=MZDB+cF4ZZkH0O68Mauu4ARtkq1Ef9YrutUh1P6tAD6ubbUK0T8EcinWMrzoOtzoYo QSab+3InBI80lhBP4sy27/dHp0vaJEimEw9yZ43tgF0CUu0n2OmLPNRYUYeVz9Mop5iL QgL7H7gocw5ufOMaiLoUIZDXSjPLVP9Sa0Nsnx2bCSSibBVXyoY5SSZcx/G/A8M/qcZP ds3xOSgcgNT22kNnQFRdpUSIygrBeU2xVcoyY3A9iZpd9eb9KsEq2ZLgyMlw35SpCYYU 4esnBSa/+Lzl/vQ4GGumGqcj6yb9gjrdGj6vDpc3FN+F0KAlXg6noZ7vV/wKuN5j8ddZ NdEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n9n9jQp93ZlqH2/7/6Mp3tVXspS0c6siJfaVG+BlpLE=; b=aN2FinZ10X7hhkLMdMoKl29SUvFZ88gSEIK02AH9aSkH5HrPFvZ/0I6No+errRnMtn Yi5bGevKBg5hdb67SX+gEwKk07ScRGGLrannCGW2M/S++0dq87BvbH2rAoRrDoCoHFjV tBBPcUbyDXqcElmrmdqQOCkT8mFeVR+jmpD3Ww2FpOocXmMSU2Fyt1dHBBTIw4VOoomj Mo8yiIHcllLGu7pThes8W/1wvHiNV/06GqOilFoP3gNojEPzHh4qI7naKtY29U+dQ8G5 P3fFnOUF0dUK4TqEg4E9ScKPYpacrNPqM2bC0ehFsDcmBQPHQsUZay3SGFUeMz5wmZGd KV8g==
X-Gm-Message-State: AOAM532Qr1ThJ7vESQP/UODM/UZIH0X4COTnapjmlfHHhcPN8hRyEZ3B hRWVyaCT89+o7+LJkkSIEGMPWeq1beGn2SJ+h08=
X-Google-Smtp-Source: ABdhPJxGZFB4tu4ifs+wrD+oDPm3EVtp8vh2K9q04NRndISoCoAgOpbbQ2VvR61euRsS6XEHIz5SA8Ygsemj72iyvOM=
X-Received: by 2002:a05:6102:308f:: with SMTP id l15mr30293949vsb.15.1608103512861; Tue, 15 Dec 2020 23:25:12 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Yunfei Ma <>
Date: Tue, 15 Dec 2020 23:24:36 -0800
Message-ID: <>
Subject: Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt
To: Quentin De Coninck <>
Cc: Yanmei Liu <>, quic <>, huitema <>, "Ma, Yunfei" <>, "安勍(莳逸)" <>, 李振宇 <>
Content-Type: multipart/alternative; boundary="000000000000a570b605b68fc622"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Dec 2020 07:25:16 -0000

Dear Quentin,

Thanks so much for your comments. Indeed, we are looking forward to further
collaboration. For the time being, the most critical thing is to get as
much experimental experience as possible. We would love to talk in further
detail with you and Oliver.


On Tue, Dec 15, 2020 at 3:47 AM Quentin De Coninck <> wrote:

> Hi,
> I'm glad to finally see some interesting discussion about some multipath
> proposals :-)
> As one of the authors of the draft-deconinck-quic-multipath, I would like
> to discuss a little about the design differences between both drafts, which
> I currently understand to be small. Basically, all the basic design points
> you list are also valid for draft-deconinck-quic-multipath (reuse of QUICv1
> mechanisms, unmodified header, PSN per path,...), except that we associate
> a separate "Uniflow ID" (which identifies the path) to a Connection ID .
> That is, we do not directly use the sequence number of the CID as the path
> identifier.
> You propose to use the Connection IDs to identify the path in each
> direction. Its sequence number determines the Path ID. I see that in your
> Figure 1, you propose an example where you start a new "path" by using the
> sequence number 2 towards the server and the sequence number 1 towards the
> client. So your proposal does not require to use the same path ID over a
> same network path, am I right?
> In your same example, you state that the client must check that are unused
> available connection IDs at both sides before starting a new path. So if
> the client wants to reach the server over a new network path but the server
> does not start using a new path ID, what happens? Is the client unable to
> send data over it? It also seems odd to create a (bidirectional?) "path"
> with different identifiers at both sides.
> For the scheduling section, I wonder what is really specific to Multipath
> QUIC. For me, many of the proposed schemes are applicable to any multipath
> transport protocol (like MPTCP). Why not discussing them in a document like
> draft-bonaventure-iccrg-schedulers-01? Also, why is the per-stream policy
> multipath specific?
> I wonder why there is a MUST enforcing the ACK frame to return on the same
> path. Couldn't the ACK frame just refer to a specific, well-known path ID?
> For the remaining, the ACK_MP frame is identical to the MP_ACK frame.
> Regarding the section discussing the differences with our draft:
> 1- Your draft states that your extension builds on the concept of
> bidirectional paths. But I see nothing in your description preventing a
> host from using only the initial path while receiving data on the other
> path. For instance, a server could receive data on two different paths but
> send all its data (including ACK_MP, PATH_RESPONSE,...) over the initial
> path, which is quite a unidirectional (or at least asymmetrical) usage of
> the second path.
> 2- I'm not sure to understand the difference here regarding
> "feedback-based dynamic scheduling strategy" using "ACK packet". Could you
> elaborate a bit more on this?
> Again, thanks for bringing this to this list. I would be glad if we could
> at some point merge our both drafts into a single one and I am willing to
> contribute to this effort :-)
> Best,
> Quentin
> Hi all,
> Here is an updated version of the draft which was posted in the mailing
> list last Friday. Please check this link:
> <>
> 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 <>
> <>
> Date: 2020年12月14日(星期一) 12:36
> To:安勍(莳逸) <> <>; "Ma, Yunfei" <> <>; 刘彦梅(喵吉) <> <>; Christian Huitema <> <>; 李振宇 <> <>
> 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:
> <>
> Status:
> <>
> Htmlized:
> <>
> Htmlized:
> <>
> Diff:
> <>
> 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
> The IETF Secretariat