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

Quentin De Coninck <quentin.deconinck@uclouvain.be> Tue, 15 December 2020 11:47 UTC

Return-Path: <quentin.deconinck@uclouvain.be>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F233A1060 for <quic@ietfa.amsl.com>; Tue, 15 Dec 2020 03:47:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iODi3EYqGiT7 for <quic@ietfa.amsl.com>; Tue, 15 Dec 2020 03:47:18 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150125.outbound.protection.outlook.com [40.107.15.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791543A105F for <quic@ietf.org>; Tue, 15 Dec 2020 03:47:17 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UOoz+c/ur8A4LaemZ8oI6dRHgLwmxKAZlNZfe8QpGOdixBkCVxbJ3a9JI3lfyRqiVB393+o9q7+Xhsc4cvev2gQ+z9GnNUhdK4XL3d7MUx9PJ6lEzFGPI4J/RtpYrVTvlfMqsDrwWLBpScfOEzd9FpsGt8wiSGASQxNsxT6BdpJiCFaWnx3ZkLMWy7X1ridT121RvURkhh9wfVsCkfWpflK8rHldWzf1wta4AM31ovSNy/lDGwHW/lbdEq45nRsdbKEtvp75CK0UqNBcSp3BeqteXrYkiXIetaVqUm19qfCS7fKWAtXPTTYuaCrthn+zkD5z7gtJKOc496JCckkpIw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zFixRRbO4622Dd60kxbH3WUZcmck05AKbvVQjl+DANE=; b=ZkXNC+/8nxz5DcUkDq26VNtxpMa7Jcky4xYEZWaa/uw18+0jCYHoPx2qGekTWR/UBVvVr89qsHO4BqzK4C9aliu6f4bl/c42QDv40F6KUIwVqeMFbYKjc9uAUDt1O0VYoF0bkbrDgyFzopSZXd2rMC/UsOzNJPAxnxDhrmVnx58A/iheQB8hyZ1WpQqgYDZk3pVyYzb1FOTEpIhlU8HqzJdakSzgiAp1rLdl3hOQHHQXBD7FdqgKfcmYscq7H9ee8Dhg58CkFx3htNfRGey7AShmMzZf2Nu7QTeA2c2c219GZs9b+hAF41vxN9I7x7vSfjxBtTGXWfvuX+h38sJyDw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uclouvain.be; dmarc=pass action=none header.from=uclouvain.be; dkim=pass header.d=uclouvain.be; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uclouvain.be; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zFixRRbO4622Dd60kxbH3WUZcmck05AKbvVQjl+DANE=; b=q4zA/bkq7LtaKe882ECCS5eCVlbXHudMkeJlwdZgJS9+XMxlOeAgkH1PUUpZ6urbnrAMD+I4rSfKfviX3M7rZD/0rtrGziFIyqgXOoiVW/J792XhnE3W7X7zXYLGpaBe1Q3WR/VrVw0bG4jDzSd4pN4HrxynQNP9oyDvZH4eTNs=
Authentication-Results: ict.ac.cn; dkim=none (message not signed) header.d=none;ict.ac.cn; dmarc=none action=none header.from=uclouvain.be;
Received: from PA4PR03MB7344.eurprd03.prod.outlook.com (2603:10a6:102:10e::7) by PR3PR03MB6554.eurprd03.prod.outlook.com (2603:10a6:102:76::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.20; Tue, 15 Dec 2020 11:47:08 +0000
Received: from PA4PR03MB7344.eurprd03.prod.outlook.com ([fe80::7d36:eaa9:2bfe:8846]) by PA4PR03MB7344.eurprd03.prod.outlook.com ([fe80::7d36:eaa9:2bfe:8846%6]) with mapi id 15.20.3654.025; Tue, 15 Dec 2020 11:47:08 +0000
Subject: Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt
To: Yanmei Liu <miaoji.lym@alibaba-inc.com>, quic <quic@ietf.org>, huitema <huitema@huitema.net>, "Ma, Yunfei" <yunfei.ma@alibaba-inc.com>, "安勍(莳逸)" <anqing.aq@alibaba-inc.com>, 李振宇 <zyli@ict.ac.cn>
References: <1baa86a9-455d-4256-85f2-9aee159afed9.miaoji.lym@alibaba-inc.com>
From: Quentin De Coninck <quentin.deconinck@uclouvain.be>
Message-ID: <e8027334-2615-30fc-c4c4-e890c5f527b8@uclouvain.be>
Date: Tue, 15 Dec 2020 12:47:07 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
In-Reply-To: <1baa86a9-455d-4256-85f2-9aee159afed9.miaoji.lym@alibaba-inc.com>
Content-Type: multipart/alternative; boundary="------------FAC7ACBBC7302D5ABF53D4E0"
Content-Language: en-US
X-Originating-IP: [178.51.69.230]
X-ClientProxiedBy: PR0P264CA0210.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1f::30) To PA4PR03MB7344.eurprd03.prod.outlook.com (2603:10a6:102:10e::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.0.6] (178.51.69.230) by PR0P264CA0210.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1f::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.17 via Frontend Transport; Tue, 15 Dec 2020 11:47:08 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: add94fc1-68c2-405d-b61e-08d8a0ef272b
X-MS-TrafficTypeDiagnostic: PR3PR03MB6554:
X-Microsoft-Antispam-PRVS: <PR3PR03MB6554C46FC97E2053DCCF08469DC60@PR3PR03MB6554.eurprd03.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 8LoP8AZN5xUcmHJgvBTmeammfibB+2VF7mEqpMbmHcT0HF3y7NUfbU1nlP9IeJzftGpzYBZSsrGkrn5uliKLiwHlYXg5q4D6IysBgl9yqHd8HXUh2eBm2wzFRO3QNxWnRY7fzTitWGbnh45e5s1JOSpQeQeBiQCii28NK6BnzJ7wWIHfYVMQskgQlovlIs9XzTxy7TrihcKWgyKP9Mnf6Fdchiagebz/0U6xAU/ByDcHzKSG9CU6TFWIWe/RG3jmt5tcW2Ear9PzN8oiAQU19G5b0f0k7C12U2X6lnGCgzfvwuoCfFvQux8undmHsX79CidUzuNBd+vb/BEI4TnkyWIfzRFy9bAF9fSdICRmTT14j/AaVy4bDvOdxsUBjrktHcPnBQ/rfj2Wz/fg7/4f+pgVmI9rRhJ0WLzZt4gihAy4SylA2jvfx/5ymrZGdxBkph63/saon2wffONGGsmSqkaavj+ZFgdaHHt5HmGbb6M=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PA4PR03MB7344.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(31696002)(83380400001)(45080400002)(498600001)(66946007)(31686004)(66476007)(86362001)(52116002)(16526019)(66556008)(33964004)(30864003)(16576012)(2616005)(186003)(66574015)(8936002)(110136005)(966005)(166002)(956004)(26005)(5660300002)(4001150100001)(36756003)(6486002)(15650500001)(8676002)(2906002)(43740500002)(45980500001); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: M6kVCM7Ox0OC32JmXUMiC0tqu/f9M0tsKPM3DSAqM4xaSucCKFxBw2xHGrehPth3zUcoJZ+CdjEX/UKhrrxxmQxBGuHOYsW4RJi2IHxPSGB+AwL5gV1SdAf5+FrWzRaYEJWqQ3rsgYpnE1/2XwSJ1iTEvt+klfwaA/ujgQBk/SKGDGmAXkIIfpw3XfQsmo/efLYnBwC3YE6iCUqVOSLjW/CoE0MM1uglWVMcyaxL97rp2C5qLu2nAdG2I09Zx9CngfRB4ge2EK8rq3cKA/RQqgFKqg0rPMAGh2w9eB1OPM1wn58Gn8UMTxF0+NRfV16ZgCU+UbzT1aCtbo/IfZI5pvY70B17j6mB4c1eL3pZPRj1adMlUp1RQfb/SUJJaq1LpiDh1QVffqvKMeYJjX7BNLsNw6FC0HalJoWp4av0+shsKGa/5TBV48eLqKis0B1jXWJ5grm9bbwRBfgiMMstqUhJaW7s2WzvocLaNM4npWBQ4DSVVFZLsxx2hSho4h0Z2ycS3xkvWfXbVi7PKnKyoKYWMnJMgqohVUvCXcAvC+VPe84lo1a9WowiRInzQb2aYuOv34YrYc3e2trPGV1bsW9FYxNd9klaLpEky/zLzpZAZodCGWiIdoR/VaqS4dv/gQuW4QhFVK5jqBEnCBb7JMcIaCuufF/t+AP5dumKzumFK+hZbnGTP9irF+Zaf1uV44AKf1CmSiSnAR/IIPrPy/JSUH6twi/mu8ndeK3FUNRybV4N7H893X8UQ284DlmH1cN96fSxf17/BqmibdPj6z+bxCvGlH+8W/TAwSuDP68Zs62woI53M9AzyTmZZZfDSFIUI8evrkvRFZI/EZ/No3OnuRZrZK7IURwh8lyyCb7Hiw6yeyMp4EL/bctVKyeBTHxY407l2hz5hYsre39XxIdG+hLvlaGGdhJH8ridGdpiQQMsxHy1zG8EUXtqt++5SHPGc9NRtziyGLRqPnDqVfjXFY14kPxP8VeaKrek0vCeLGJcENJ7qJ2w70rJnGV8
X-OriginatorOrg: uclouvain.be
X-MS-Exchange-CrossTenant-AuthSource: PA4PR03MB7344.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Dec 2020 11:47:08.6265 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7ab090d4-fa2e-4ecf-bc7c-4127b4d582ec
X-MS-Exchange-CrossTenant-Network-Message-Id: add94fc1-68c2-405d-b61e-08d8a0ef272b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: pKE+4rJEsqgZsYmncX3Tor8RjRTgzUpFuiRYafcIjUi4fSGb66CKbzID+SJJ9LGX2iC68dKFWajeNayvc67v7bAwlG7A9D2J7n7MBrkB9NI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR03MB6554
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/1fmaCeQD5Emt1gJuTVRWa0MKXDY>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Dec 2020 11:47:21 -0000

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: 
> https://tools.ietf.org/html/draft-liu-multipath-quic-01 
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-liu-multipath-quic-01&data=04%7C01%7Cquentin.deconinck%40uclouvain.be%7C281d8515dee042881e9e08d89ff77c50%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%7C637435233091447064%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=PNExv4lCxGy5uVoMRc1g8X52IZBMpjEk7NOx%2FWF55mk%3D&reserved=0>
> 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 <internet-drafts@ietf.org>
>     Date: 2020年12月14日(星期一) 12:36
>
>     To:安勍(莳逸) <anqing.aq@alibaba-inc.com>; "Ma, Yunfei"
>     <yunfei.ma@alibaba-inc.com>; 刘彦梅(喵吉)
>     <miaoji.lym@alibaba-inc.com>; Christian Huitema
>     <huitema@huitema.net>; 李振宇 <zyli@ict.ac.cn>
>
>     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
>     <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-liu-multipath-quic-01.txt&data=04%7C01%7Cquentin.deconinck%40uclouvain.be%7C281d8515dee042881e9e08d89ff77c50%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%7C637435233091457023%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=qr8JPusFk9FKI26mNbYTtde1t4G1zyQSEibBqTbMIG0%3D&reserved=0>
>     Status: https://datatracker.ietf.org/doc/draft-liu-multipath-quic/
>     <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-liu-multipath-quic%2F&data=04%7C01%7Cquentin.deconinck%40uclouvain.be%7C281d8515dee042881e9e08d89ff77c50%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%7C637435233091457023%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=2lNP%2BDxp3qlRncBcf6IPvoSUHx5cs7N7BqUkaMarQ5k%3D&reserved=0>
>     Htmlized:
>     https://datatracker.ietf.org/doc/html/draft-liu-multipath-quic
>     <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-liu-multipath-quic&data=04%7C01%7Cquentin.deconinck%40uclouvain.be%7C281d8515dee042881e9e08d89ff77c50%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%7C637435233091466978%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=uBBdwodffWgFbeR7e6PESxrSkxPT9pu4tYwyPdx16A4%3D&reserved=0>
>     Htmlized: https://tools.ietf.org/html/draft-liu-multipath-quic-01
>     <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-liu-multipath-quic-01&data=04%7C01%7Cquentin.deconinck%40uclouvain.be%7C281d8515dee042881e9e08d89ff77c50%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%7C637435233091466978%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0F1QrItnLruPTm4cRISETmA4pn0F0ygPqqmGWr9NLtk%3D&reserved=0>
>     Diff:
>     https://www.ietf.org/rfcdiff?url2=draft-liu-multipath-quic-01
>     <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-liu-multipath-quic-01&data=04%7C01%7Cquentin.deconinck%40uclouvain.be%7C281d8515dee042881e9e08d89ff77c50%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%7C637435233091466978%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=WBUZ%2Fm9vYpzuQ1a57XhKVlF8gdpYMXl02PiTDXmXpZ8%3D&reserved=0>
>
>     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
>
>