Re: Multi-path QUIC Extension Experiments

Roberto Peon <fenix@fb.com> Fri, 16 July 2021 19:12 UTC

Return-Path: <prvs=6831a0d9fe=fenix@fb.com>
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 067813A0962 for <quic@ietfa.amsl.com>; Fri, 16 Jul 2021 12:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level:
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com
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 bZj8hl5Tns0t for <quic@ietfa.amsl.com>; Fri, 16 Jul 2021 12:12:48 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 C4D723A0945 for <quic@ietf.org>; Fri, 16 Jul 2021 12:12:47 -0700 (PDT)
Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16GJ2k27002858; Fri, 16 Jul 2021 12:12:21 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=+REMFRa3be8OU4p20Eaj6n+tHZClp/cunGRyeK1UIFY=; b=ZF/R7knZbHSTbrJKah1QmSHE3SzSeZFsbprtUiMqIVFB9u1q8n6pexyhrQWWsEfs6ty6 QqYldIG1qFaN+2IySiN1i9l67qDFrh5dSRt1zhqCz97jP/NbDDcFQb2+idKqqQe1cm1d YpD55Yj0XM0DTMm4EfQbBTAW2+quxaOJ7o4=
Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 39tw37p0hm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 16 Jul 2021 12:12:20 -0700
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.36.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 16 Jul 2021 12:12:19 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e2Ga7yK73QrFR8OndqYZfzwb78dpH9gcqs44f+dji8KO6npxzRjF6at7+fD8ALSJRUwp7afr4X+pli0H9czksEQsySBcTSj1x8T/XnbPqsh5g7TlL8C0K82ylfRrYWEcWIugd8FAqhWIuxi2d2bIhUGa8uBWGJwxF4xAt1UCVXJ3O2TYNKtx0MIHzCeM4E2hmoprZEVGXaPbr1aVLUsERTZuI6l3ktI7QeBAT3JqLe65gF/3IxwtXyrA7dZ7Q4f3QuULVxcpWN60LjwDnrFvWMLQ8Ue4owh9RgBP/L7peXYnZq+OP6XkCO7bY/rO+uGRfs1vCWKQWfyfBhVSIoey1w==
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=bTVSOkQVWWWTAySieHrzTkxPRqLpL29/K9SHk2sjJh0=; b=h/ehuO1t/JN98eGZ5hs8TRlr2lyXPptb/Bd4HGKqrG46yEvqefs4soYNsDqp0Kcy3yQXZbH8PXLomiibZrLYravvRER1sgG8vsBFwsltSjSbm/b9Qwil2U3GPFEybUuvYEXN3MYtsxEyCIsRLezMtVTc5hjC2n2/bBetJcE3sT9DUZ8jw2nrSOVgNKwiiliZ9R3GUVXjGxcf0fTtmjEc42nvkB8YE3QIiTN0DWemcMcQGa/UhtuxLOtxlCllgfikg65o62MYixImGBbVdSlddVYovtjpsoc/5VJXHTm2e/GCGE/NCoUc2Xx+c8r7V9z0uvkmS4jK4GjxltsI7g+D6Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none
Received: from DM6PR15MB2681.namprd15.prod.outlook.com (2603:10b6:5:1aa::28) by DM5PR15MB1705.namprd15.prod.outlook.com (2603:10b6:4:57::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21; Fri, 16 Jul 2021 19:12:18 +0000
Received: from DM6PR15MB2681.namprd15.prod.outlook.com ([fe80::c5:d5e1:fad0:5deb]) by DM6PR15MB2681.namprd15.prod.outlook.com ([fe80::c5:d5e1:fad0:5deb%6]) with mapi id 15.20.4308.027; Fri, 16 Jul 2021 19:12:18 +0000
From: Roberto Peon <fenix@fb.com>
To: Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, "Ma, Yunfei" <yunfei.ma=40alibaba-inc.com@dmarc.ietf.org>, Robin MARX <robin.marx@uhasselt.be>, Yanmei Liu <miaoji.lym@alibaba-inc.com>
CC: "matt.joras" <matt.joras@gmail.com>, 李振宇 <zyli@ict.ac.cn>, Christian Huitema <huitema@huitema.net>, "lucaspardue.24.7" <lucaspardue.24.7@gmail.com>, quic <quic@ietf.org>, Qing An <anqing.aq@alibaba-inc.com>
Subject: Re: Multi-path QUIC Extension Experiments
Thread-Topic: Multi-path QUIC Extension Experiments
Thread-Index: AQHXekR/rwb9xtCPfE2fLUknTCKSfqtFgxqA
Date: Fri, 16 Jul 2021 19:12:18 +0000
Message-ID: <0334A48E-B6C6-464C-A48C-4512A453DA81@fb.com>
References: <8C2E8EFB-756B-449B-84E0-11CD6B57E541@ericsson.com>
In-Reply-To: <8C2E8EFB-756B-449B-84E0-11CD6B57E541@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.50.21061301
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=fb.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 089ea648-b503-4b7d-f1de-08d9488da142
x-ms-traffictypediagnostic: DM5PR15MB1705:
x-microsoft-antispam-prvs: <DM5PR15MB1705DBB4D2C96A6DAF543FABCD119@DM5PR15MB1705.namprd15.prod.outlook.com>
x-fb-source: Internal
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: YOkEbSKqQ+BAwczXdRoIRtJLhMECBRL3Kn1dH0DrRhtni84XgZPf60tZ2jnXVIqXEVDhdaAE8HIbtly8vBK3V2Fxk1b1M5mQ5dInm1nvZkm0Q+QMNIGR2TdVYOKFkhtTQlZg7fZIkq4wAVnEhMLOG6u2ztyFt+f5wfxbelghNofKbTm6d4yQ895HKQqTHEqYAJc6Oi1ZPkpdww2Ns/uRokFejtdxAq/kEkCv7yPTat8/+rU6yMEi/tQjVd06tP2islEuOHjEbIwNRaoim83ucnZMKALXQlM7M+RmzK8tdPrABWxaZ/Hqp/wAmbivAsZzqbx6qtV4bLzm5HVivfepY0KPMzOpJ6Sxj1G84xshiZwu3Zzi0YEdGO1lmpvsTyr11ZeIs87/j12hNO4ubKnom2Sn2cUht9RHSY3rZxgpXbGnaZi934c3IfOFozOW+JqQl+ru+CRt511UblnED0Jv5+itZRotbOGytmVnAx6rwH9PAKDjcRc3zGFdpChv4JERiaHoL5xYa2YFDB2feu6Y7jVcaKbMxlvVOvpCRm/Q3JtdMSQnwCcWu3RuHeWBNtu72AaW8c4Hk1TQpeycjhKNg6F998c3DhO/56EckveeoBTa0Y3UuhvxliqmVb8Cmh//dqlI2lvXHDHXBkpXp5I2hZ8uNtHpcWC34nvuUJmOvDpdWBYcOaRU0AVy57sY5fcMqmADawMJAZ/4T1YWLD2bv6CcO/QQdmdZsjSXE/NPQdZ41pk7t+KZVnkKRG8zCyIyvgUB3iaO3gQ5SGIBtXRcbJHnz16/rvseQ4dn0dXnwcIxFHByKfI9gpZQxCje6QXtAteOXZt50s3BUm6rFdw/XQ7KHeONAvJwAu+rdwidcTM=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR15MB2681.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(136003)(396003)(376002)(346002)(66556008)(66446008)(66476007)(6506007)(64756008)(53546011)(54906003)(36756003)(122000001)(38100700002)(33656002)(110136005)(316002)(2906002)(166002)(83380400001)(2616005)(91956017)(76116006)(26005)(6512007)(8676002)(66946007)(8936002)(186003)(5660300002)(7416002)(6486002)(86362001)(71200400001)(4326008)(478600001)(3480700007)(45980500001)(38070700004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 1zQ7ViGK1LtELoHgLzF2dmVSSGgE6VhdWLozrz2EkAY+iH/wLOdcUbisYg9Mz90IrBqjjXr9u3QRx440T2v2n5twJCZRVTRsLNBP9jXwbhdglBYs5ivcmdqF+XBF0V1pquVltSLWoxyP6fEQsBH4EdqJ7dIelEzeozfCDIXlVA0E6kVfuXaj7a55PNTctlOTSlBOQlHOkQ4bTQvM5ALlA3dLrzqN7kO620BpXJB/20z7uFmyLNNbzG9DzU7TShYH+VoQckABSVv9uMtmxJQuE0y6Ix8S21VzV/waudIJbNllhZAXC44eUtPbMlvGnpu3AIrZKo7WHVISL5l4TMjLG6soFQMcRNJnpXc8Q92TgyVi9ggCH/tSMHrEZC41PHqHqCHQmlmAVgBF7QvX4g5Pes0w4C3QIkq9Teb4HNR3keV5PJ/eJP+jJOG9L/sPEmaZDa0deOPCube4tU1XXGWyLU9H4l/m4nk9POVQ1iax5ZF50PcbD1oWLlHvV5iF+ECoJgukrQ+uFfqMGj+7fNEwtvYhN5D15ZzJDaf3L1DctPAeYP/Ni8SfIVVEZVIp7ad9VuVrPCkWi3MYoZjJO7Hcrp9KgAK6lOwdVKN2OBIGFWmuMg4wd1oxkMwyAxCs4yR/OZkK55DNMV5FcpVQ3CeKGTgjOBPseBUS1Kg2kxv1dKMxTobNO0froKfL+WJv4jjWXOmDIop74ohmIK0aT/APX542SpVyu+0MFJxwXLeMAkpN38MXWegsi/+lbyKNIAwwB2eUaDtStdrKCi2ZmwnCiuJajpD4kgGIqZNjm2nIH6lkglg95qqfMQSke6VTKQTVdKRErf3WvRXRID3NPBrsB1Yr+7X73TmlymZKvii4Bqyoik+xlgWhlflosqh+VnXZmZVJ99VaAy/azBXfSN8xOajhkS6yoRnicjvPU4ZkMVDrPACIY/SEtIVlYvRyA49EOxGsiNzefINQq4CA0AcfuKo0BP7Hdnb9AlMg67GfgDsK/Bn3QKspeISB63aPrFjuUwIWvmRBIqHO7+Xp14v6J+agj8vVL0RkkSOM+FN4MGIq93MTgDhoWo09/TNe1MjlmIUczVVjMVp5a9tRj5S3ucvZh9PGY6t0AKBfu2mR/GQP7krdjh0IEYWuAGq0pKl2jU7/IcKdiFmZAKJL6rPOqRf7xDSqg2HUvZChnPbWaBnxWInim6d9/EZSzIYecvodyt/y1unKWspaoY6NorKpzA5+Cmp7MgXVAoV0ihTlFtjCEsPPtv9RmWK4+A9D7HQArQxqj1OTdGNXon0Ss822OPqZAZR1a6lgj+BKdwdOQglE+/LgHy1e2aAx3icrRK1d
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_0334A48EB6C6464CA48C4512A453DA81fbcom_"
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR15MB2681.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 089ea648-b503-4b7d-f1de-08d9488da142
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2021 19:12:18.1604 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: D4x3u2Smveg2GCxQnYASYwhOcAPSuSJ0tNh3wAvjmTYbMZZ023VQeyth+Z3RRx/j
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1705
X-OriginatorOrg: fb.com
X-Proofpoint-GUID: hr-uLqN8yTIsKEvQz8sgyA8FY8_GzojN
X-Proofpoint-ORIG-GUID: hr-uLqN8yTIsKEvQz8sgyA8FY8_GzojN
X-Proofpoint-UnRewURL: 6 URL's were un-rewritten
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-16_09:2021-07-16, 2021-07-16 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 bulkscore=0 impostorscore=0 priorityscore=1501 lowpriorityscore=0 clxscore=1011 mlxscore=0 phishscore=0 malwarescore=0 spamscore=0 mlxlogscore=902 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107160118
X-FB-Internal: deliver
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/B4cu78kKaw450qwDXH4h4yRaqz4>
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: Fri, 16 Jul 2021 19:12:53 -0000

I too am curious!
There are only two ways to handle flow control—overcommit, or don’t overcommit.

The “don’t overcommit” choice leads to blocking, since any of that resource allocated to one path can’t be used by the other.
The “overcommit” choice either leads to OOM, or throwing out some successfully transmitted and received data.

Underlying this is a fun question: Which inefficiency is worse? Not using resources that should be used (i.e. from choosing to not overcommit), or sometimes redundantly using a resource (from choosing to overcommit)?
I’m curious too about what implementation strategies we end up doing in general around this, and.. if enough implementations are choosing overcommit, if we need some different protocol mechanisms to bound the redundancy?
-=R

From: QUIC <quic-bounces@ietf.org> on behalf of Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>
Date: Friday, July 16, 2021 at 6:15 AM
To: "Ma, Yunfei" <yunfei.ma=40alibaba-inc.com@dmarc.ietf.org>, Robin MARX <robin.marx@uhasselt.be>, Yanmei Liu <miaoji.lym@alibaba-inc.com>
Cc: "matt.joras" <matt.joras@gmail.com>, 李振宇 <zyli@ict.ac.cn>, Christian Huitema <huitema@huitema.net>, "lucaspardue.24.7" <lucaspardue.24.7@gmail.com>, quic <quic@ietf.org>, Qing An <anqing.aq@alibaba-inc.com>
Subject: Re: Multi-path QUIC Extension Experiments

Hi Yunfei,

thanks as well for you sharing your results! Can you explain even a bit more what you mean by MP-HoL Blocking? Is this because of the flow control limits? If so wouldn’t it make sense to reserve a certain “space” for each path?

Mirja


From: QUIC <quic-bounces@ietf.org> on behalf of "Ma, Yunfei" <yunfei.ma=40alibaba-inc.com@dmarc.ietf.org>
Date: Thursday, 15. July 2021 at 04:18
To: Robin MARX <robin.marx@uhasselt.be>, Yanmei Liu <miaoji.lym@alibaba-inc.com>
Cc: "matt.joras" <matt.joras@gmail.com>, 李振宇 <zyli@ict.ac.cn>, Christian Huitema <huitema@huitema.net>, "lucaspardue.24.7" <lucaspardue.24.7@gmail.com>, quic <quic@ietf.org>, Qing An <anqing.aq@alibaba-inc.com>
Subject: Re: Re: Multi-path QUIC Extension Experiments

Hi Robin,

Thanks so much for your questions!

First, the head of line blocking discussed here is called multi-path head-of-line blocking or MP-HoL blocking, and its root cause is quite different from the stream HoL blocking usually discussed in QUICv1. The MP-HoL blocking happens when one path blocks the other path, not when one stream blocks the other stream. Please note that we indeed use multiple streams, for example, different video requests are carried in different QUIC streams. QUIC’s stream multiplexing ability and its benefits still hold in this scenario.

Second, regarding packet scheduling mode, right now, in our Taobao A/B test, we transmit packets on multiple paths simultaneously. However, you can definitely use traffic switching only and choose to switch when one path could not meet your bandwidth requirement. Basically, if you use multiple paths simultaneously, you get the most elasticity from a resource pooling perspective. It really comes down on what your application needs. We will also update the packet scheduling section soon in a newer version of the draft, in which we plan to include more discussions on the packet scheduling policy.

Third, regarding the benefits of more bandwith versus the "downsides". Whether you want more bandwidth depends on your application. For videos, yes, more bandwidth is extremely helpful in improving the long tail QoE, which is an important target for Taobao. We find multi-path QUIC helps us improve two important metrics, rebuffer rate and video start-up delays. In the past, if you work on multi-path scheduling that does not collaborate close enough with applications such as MPTCP, the MP-HoL blocking becomes the downside that cripples the performance. However, the user space nature of QUIC provides us the opportunity to solve this problem, so now our conclusion is that you can enjoy the benefits of more bandwidth and more reliable connectivity from multi-path without much of the “downsides”.

I hope my answer is helpful, but feel free to let me know if you have any additional comments.

Cheers,
Yunfei

from Alimail macOS<https://protect2.fireeye.com/v1/url?k=7cc82aa7-2353138a-7cc86a3c-8692dc8284cb-e08a325a5c75cf95&q=1&e=de295b4f-9105-4e32-980f-779c711eaa62&u=https://mail.alibaba-inc.com/>
------------------Original Mail ------------------
Sender:Robin MARX <robin.marx@uhasselt.be>
Send Date:Wed Jul 14 07:39:37 2021
Recipients:Yanmei Liu <miaoji.lym@alibaba-inc.com>
CC:quic <quic@ietf.org>, Ma, Yunfei <yunfei.ma@alibaba-inc.com>, Christian Huitema <huitema@huitema.net>, Qing An <anqing.aq@alibaba-inc.com>, 李振宇 <zyli@ict.ac.cn>, matt.joras <matt.joras@gmail.com>, lucaspardue.24.7 <lucaspardue.24.7@gmail.com>
Subject:Re: Multi-path QUIC Extension Experiments
Hello Yanmei,

Thanks for the additional results on an interesting topic. I'm looking forward to reading the SIGCOMM paper.

I was a bit surprised to (apparently) see HOL blocking mentioned as a major issue, as that's one of the things QUIC aims to be better at than TCP.
It's a bit difficult to understand from the slides, but it seems like you're sending packets for a single stream (Stream ID 1 in the diagrams) on both the slow and fast path, which would indeed induce HOL blocking.
Consequently, I was wondering what the practical reasons are for you to multiplex packets for a single stream over multiple paths, as opposed to for example attaching a single stream to a single path (say: high priority streams use the fast path for all their packets).

I see this mentioned a bit in the draft under "packet scheduling", where it talks about switching paths once the cwnd is full for one. That indeed leads to the behaviour seen in the slides, but that's my question: why would you take those approaches then?
Are there so many cases where the additional "bandwidth" from using multiple path's cwnd for a single stream outweigh the downsides of HOL blocking? Relatedly: what are the packet loss rates you've observed on real networks?
Have you experimented with e.g., tying streams to paths more closely? Does that work better or worse? Why?

I'm mainly wondering how these tradeoffs evolve depending on the type of paths available and if it's possible to make a model to drive this logic.
I assume there is much existing work on this for MPTCP, but I also assume some of that changes due to QUIC's independent streams / stream prioritization flexibility.

Thank you in advance and with best regards,
Robin


On Sun, 11 Jul 2021 at 20:48, Yanmei Liu <miaoji.lym=40alibaba-inc.com@dmarc.ietf.org<mailto:40alibaba-inc.com@dmarc.ietf.org>> wrote:
Hi everyone,

We have finished some experiments about deploying multi-path quic extension(https://datatracker.ietf.org/doc/draft-liu-multipath-quic/)<https://datatracker.ietf.org/doc/draft-liu-multipath-quic/)> in Alibaba Taobao short-form video streaming, and the experiment results are concluded in the slides (attached file).
If anyone is interested in the experimental details about multi-path quic, please let us know.
All the feedbacks and suggestions are appreciated!

Best regards,
Yanmei


--

dr. Robin Marx
Postdoc researcher - Web protocols
Expertise centre for Digital Media

Cellphone +32(0)497 72 86 94

www.uhasselt.be<https://protect2.fireeye.com/v1/url?k=37557dd4-68ce44f9-37553d4f-8692dc8284cb-fe608437d16ed9d9&q=1&e=de295b4f-9105-4e32-980f-779c711eaa62&u=http://www.uhasselt.be/>
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05

[Image removed by sender.]