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 > >
- Fwd: New Version Notification for draft-liu-multi… Yanmei Liu
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Christian Huitema
- Re: Fwd: New Version Notification for draft-liu-m… Yanmei Liu
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Christian Huitema
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Christian Huitema
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Christian Huitema
- Re: Fwd: New Version Notification for draft-liu-m… Christian Huitema
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Christian Huitema
- Re: Fwd: New Version Notification for draft-liu-m… Yunfei Ma
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Quentin De Coninck
- Re: Fwd: New Version Notification for draft-liu-m… Yunfei Ma
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Quentin De Coninck
- Re: Fwd: New Version Notification for draft-liu-m… Mikkel Fahnøe Jørgensen
- Re: Fwd: New Version Notification for draft-liu-m… Quentin De Coninck
- Re: Fwd: New Version Notification for draft-liu-m… Christian Huitema