RE:(2) Preparing for discussion on what to do about the multipath extension milestone

Madhan Raj Kanagarathinam <madhan.raj@samsung.com> Wed, 30 September 2020 07:29 UTC

Return-Path: <madhan.raj@samsung.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 9CA6E3A12A4 for <quic@ietfa.amsl.com>; Wed, 30 Sep 2020 00:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.197
X-Spam-Level:
X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=samsung.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 p3198xHaK6XN for <quic@ietfa.amsl.com>; Wed, 30 Sep 2020 00:28:58 -0700 (PDT)
Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50803A12B9 for <quic@ietf.org>; Wed, 30 Sep 2020 00:28:51 -0700 (PDT)
Received: from epcas5p4.samsung.com (unknown [182.195.41.42]) by mailout3.samsung.com (KnoxPortal) with ESMTP id 20200930072850epoutp035d74be3a461767f4105b2357e06037e3~5fyLdxhZQ0236702367epoutp03v for <quic@ietf.org>; Wed, 30 Sep 2020 07:28:50 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mailout3.samsung.com 20200930072850epoutp035d74be3a461767f4105b2357e06037e3~5fyLdxhZQ0236702367epoutp03v
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1601450930; bh=bIfxEePjK2qABtRiyqXbFQMVInCucTAPtaQ8Te/SiJI=; h=Subject:Reply-To:From:To:In-Reply-To:Date:References:From; b=u4vatLR320c5UHBwdJnGXgw8hXkaRk/wD+fmY+kKaK7G52Awjr+MXWyVSkFe06L3L grtgMp96YmWQHHNZANTODycJLsjqWqScl3WSEEBJVK0MMS96snolg2QBC38G3cJk+T PpC+ghHvWUdRaWTvQ1EKd/xzVWT02Py006uGXCKs=
Received: from epsmges5p2new.samsung.com (unknown [182.195.42.74]) by epcas5p3.samsung.com (KnoxPortal) with ESMTP id 20200930072850epcas5p32336975c6f1e542277583cc236d9a412~5fyLQMGWn2426324263epcas5p32; Wed, 30 Sep 2020 07:28:50 +0000 (GMT)
X-AuditID: b6c32a4a-337ff700000026c2-54-5f7433b1629c
Received: from epcas5p2.samsung.com ( [182.195.41.40]) by epsmges5p2new.samsung.com (Symantec Messaging Gateway) with SMTP id E0.96.09922.1B3347F5; Wed, 30 Sep 2020 16:28:49 +0900 (KST)
Mime-Version: 1.0
Subject: RE:(2) Preparing for discussion on what to do about the multipath extension milestone
Reply-To: madhan.raj@samsung.com
Sender: Madhan Raj Kanagarathinam <madhan.raj@samsung.com>
From: Madhan Raj Kanagarathinam <madhan.raj@samsung.com>
To: "olivier.bonaventure@uclouvain.be" <olivier.bonaventure@uclouvain.be>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, QUIC WG <quic@ietf.org>
X-Priority: 3
X-Content-Kind-Code: NORMAL
In-Reply-To: <78651438-2fce-ba67-4f44-4228bbc79a75@uclouvain.be>
X-Drm-Type: N,general
X-Msg-Generator: Mail
X-Msg-Type: PERSONAL
X-Reply-Demand: N
Message-ID: <20200930072849epcms5p6f5fecb17181bcf8a84f81ef25833179b@epcms5p6>
Date: Wed, 30 Sep 2020 12:58:49 +0530
X-CMS-MailID: 20200930072849epcms5p6f5fecb17181bcf8a84f81ef25833179b
Content-Type: multipart/related; boundary="----_PpqB9.vhNVY3WRkLRmaNHTZiFYjymNx99ZKkZeBL6zO1n7N=_1e8f5_"
CMS-TYPE: 105P
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42LZdlhTQ3ejcUm8wbv1phY3Gn6wWPQs4LZY NmUPswOzx85Zd9k9liz5yeTx6th3lgDmKC6blNSczLLUIn27BK6MqU93Mhe8nMZccfLuTeYG xjk9zF2MnBwSAiYSl57OZepi5OIQEtjNKDFtylagBAcHr4CgxN8dwiCmsECCxMO/qSDlQgIK Enuv7GQCsYUFrCT6Z99kBbHZBCwkFm7eBjZGRGA+o8SUbX9ZIObzSsxofwplS0tsX76VEcTm FHCQ+H9oEhtEXFTi5uq37DD2+2PzGSFsEYnWe2eh7hSUePBzNyPIPRICUhI9y3lBdkkIbGKU uPxzHjuEA3T/j44PUM3mEst+TANbwCvgK9G/eR/YIBYBVYmNEzdD1bhIHDv5C6yGWSBLomt1 MyOEzSfR+/sJE8wDO+bB2CoSS+cchjpISuL/011QR3tIvDuyjxUSiE1MEif+v2CdwCg7CxGO s5CsgLA1JFrnzGWHsBUlpnQ/hLJtJGZfP8aCKa4q8evAEtYFjOyrGCVTC4pz01OLTQuM8lLL 9YoTc4tL89L1kvNzNzGCk4mW1w7Ghw8+6B1iZOJgPMSoAtT+aMPqC4xSLHn5ealKIry+OQXx QrwpiZVVqUX58UWlOanFhxilOViUxHmVfpyJExJITyxJzU5NLUgtgskycXBKNTBpWhtY3Vhx 55xjScQZT8adKYtVj7zZzjkzv5hj++N71hxfw+TixeQ2fUy1TkkvM33cfGPNVFWXc2mH9124 mm6+fZWrxb+/erL6T2xWLLlxaOXbnm06tmqanfMXPDL7ufLWjWPrAyIdVosGLHHZXVQ2s6lI /e2ktXNmTF4yOSewrD7bwKKsXG6rVM/ux/mnMqX3GXn+37+iosfU6EbxY8GcqL4fi7wNWv6G 6/0Scd6Qt1/+xFyubTeKJv5Mui8XnVdlLSv7Lppvz6q4AvGcjFjz5n0Xpv3ijUvaUjhjR90+ Cd3ZfFNmK8WJCd6oFtg2+dvcKgXjwGPzt3OW/Jb+/k0wbae8xabrrgVeXo4Xbt5WYinOSDTU Yi4qTgQAjx3bVKEDAAA=
X-CMS-RootMailID: 20200929201205epcas5p1f1af180df22b55ccc61db39d1924fa66
References: <78651438-2fce-ba67-4f44-4228bbc79a75@uclouvain.be> <F0A5E38D-4117-4729-BFF8-72D97CAA9908@eggert.org> <CAKKJt-e=+XLZhNWqaG9YSLTRqyQRvDc-dagUSkFwHOByFwZ++Q@mail.gmail.com> <CGME20200929201205epcas5p1f1af180df22b55ccc61db39d1924fa66@epcms5p6>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/_oxkPpSSvgkMnwGzbLB_ycTqp0s>
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: Wed, 30 Sep 2020 07:29:01 -0000

I second Pr.Olivier.

Multipath Protocol gives more benefits and flexibility for Smartphones.

Apart from the Aggregation (Cellular + Wi-Fi) and Reliability (Cellular <-> Wi-Fi), it can also provide much advantages (like ndiffmode).

The multipath scheduling, path management(pm), and congestion control(cc) is a bit of a challenge, but fairly explored and addressed area.

With the deployment of MPTCP in Smartphones for more than 4 years, I feel that MPTCP scheduler/pm/cc has worked pretty good.

 

Multipath QUIC, with inherent advantages of QUIC protocol, can provide much more benefits than MPTCP.

 

 

--------- Original Message ---------

Sender : Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>

Date : 2020-09-30 01:42 (GMT+5:30)

Title : Re: Preparing for discussion on what to do about the multipath extension milestone

 

Spencer,
> 
> On Fri, Sep 25, 2020 at 5:00 AM Lars Eggert <lars@eggert.org 
> <mailto:lars@eggert.org>> wrote:
> 
>     In parallel to progressing the "base drafts" towards RFC
>     publications, the WG should now also begin to pick up the pace on
>     our other adopted work items (ops drafts, extensions, etc.)
> 
>     One important other discussion item is what to do about the
>     multipath extension milestone, which some have suggested should be
>     dropped, while others still show interest to pursue it.
> 
> 
> So, I'd like to understand the suggestion to drop this milestone, before 
> I start trying to discuss that suggestion :-).

I'd like to understand this as well.
> 
> In conversations with individual folk, I've heard these concerns about 
> QUIC multipath:
> 
> - Whether it will be possible to evaluate multipath performance at 
> scale, both for evaluating proposals and testing implementations.

We already have plenty of experience with MPTCP with several large 
deployments, including :

- MPTCP on all iPhones since 2013 with a growing number of applications
- MPTCP on Android smartphones in South Korea for WiFi/4G offload
- MPTCP in hybrid access networks that are used by different network 
operators to combine xDSL and LTE

Multipath extensions to QUIC would be applicable in these different use 
cases

> - The complexity involved in making decisions dynamically about which 
> path to send a given packet on (which could be a research topic, given 
> certain constraints and goals).

The packet scheduling problem is a much simpler problem in multipath 
transport protocol than congestion control. I would not consider this as 
a research topic given all the experience we have with MPTCP

> If I've misunderstood or misquoted, my apologies, of course. Please 
> correct me.
> 
> What other concerns do people have? I'd like to get all the objections 
> out at the beginning of the discussion.

Same for me


Olivier