Re: [Fwd: New Liaison Statement, "LS on need for Multi-Path QUIC for ATSSS"]

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Fri, 03 April 2020 07:55 UTC

Return-Path: <olivier.bonaventure@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 DA3243A1397 for <quic@ietfa.amsl.com>; Fri, 3 Apr 2020 00:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, MSGID_FROM_MTA_HEADER=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 Rt063gnhkrgo for <quic@ietfa.amsl.com>; Fri, 3 Apr 2020 00:55:35 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150110.outbound.protection.outlook.com [40.107.15.110]) (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 D119D3A1396 for <quic@ietf.org>; Fri, 3 Apr 2020 00:55:34 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k+83oU50UlwPd/Pxe5EpkWKLISDqcGbbwIX6v5H02TLXSjZXK1bW7r62SXqSnPFcF8tqx2UeG4Mlez8auX4DH896yzkpcMdhSrCWUKbT/xaUYDyo+pG9zjY7vi9sMePr8cs+FoXS6cWQC1PZ1aG0MxOrOLOEzCi8hJgIy+ETY49rLB0LnNa0+FXBapy+dsdZwDnroMTGRsAD1kKbf6pzYRs13PbSEWUOtBT7SozV3QaneXsH7mXT6drdGUcIFlfAma7mmgE3s7BVuZpo1Y65j6hbLQDVXgzJFFRrOfVHDJT6OZj2c9DgkDs5DMAH+JbRhv4dyaq7DkAKa+zPJeE9IA==
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=Uy7l1mFtaDwQEMzs7yPYlEnGmIGObazn8iNhXJSfeJc=; b=IqTU2LFPb3PceL7OMFfCJo4h+FurvXJzOQ3cJwjYbJ1mB5jQHdqXvs1kNfKbCWtK74hfMFHAmv9uZz+J0tOSLRO300Rn5LaGuKeWVgDNzWSNzptRGHo7/y9XfD4NKGXcX4qXvnJaOYGWJUuIxU1yBXuu6BDiBjI9WVodQuHrd4Rg2I1BzZRSQvoDq8z6d1S2XW9LJC3JpV/HQio6Sb6J5KyGR5+S82eoto/xxp2Sx/IHitPXGAB+SIcDnlkJ21xDAqpkgNoVbIximOJe5wbCV0rApd9i2nsl36MgPeVChT/DX9vzbFo5vLeptFL6UAc8NNzp3ITNvFUL+OZiQOk0jw==
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=Uy7l1mFtaDwQEMzs7yPYlEnGmIGObazn8iNhXJSfeJc=; b=vfSlT5bQmTPxakurgdY9/4U+VOmmdqzpzs6khnSZbbRb1CycoOoKeQLzyLbs32SqX4a0NwzDq+Z9SK5laBvS9D43n+tnNMxRHNhY7KJMTw5Js+nd/+DiARHs/vYHGxXG0+PXeHfka4/4grYGDMpAzsApl0eA7fBLKxskqtZLlK0=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=olivier.bonaventure@uclouvain.be;
Received: from AM5PR03MB2882.eurprd03.prod.outlook.com (2603:10a6:206:18::24) by AM5PR03MB2993.eurprd03.prod.outlook.com (2603:10a6:206:24::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Fri, 3 Apr 2020 07:55:32 +0000
Received: from AM5PR03MB2882.eurprd03.prod.outlook.com ([fe80::7479:6d4:80f1:9ef1]) by AM5PR03MB2882.eurprd03.prod.outlook.com ([fe80::7479:6d4:80f1:9ef1%3]) with mapi id 15.20.2856.019; Fri, 3 Apr 2020 07:55:32 +0000
Reply-To: Olivier.Bonaventure@uclouvain.be
Subject: Re: [Fwd: New Liaison Statement, "LS on need for Multi-Path QUIC for ATSSS"]
To: Lars Eggert <lars@eggert.org>, Ted Hardie <ted.ietf@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Martin Thomson <mt@lowentropy.net>
References: <CA+9kkMBcsuJGy5A7cVuooCycfskGLDPnng6O7iN_5t9KWm21DQ@mail.gmail.com> <09D76C30-BB5D-43E5-8F93-661A6C7C105D@eggert.org>
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <85eefd12-1e10-df7f-d66e-3d0e317b1f00@uclouvain.be>
Date: Fri, 03 Apr 2020 09:55:30 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
In-Reply-To: <09D76C30-BB5D-43E5-8F93-661A6C7C105D@eggert.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr-classic
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: AM0PR06CA0047.eurprd06.prod.outlook.com (2603:10a6:208:aa::24) To AM5PR03MB2882.eurprd03.prod.outlook.com (2603:10a6:206:18::24)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from mbpobo.local (2a02:2788:484:b4f:9c48:ebf0:8f7:5dba) by AM0PR06CA0047.eurprd06.prod.outlook.com (2603:10a6:208:aa::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Fri, 3 Apr 2020 07:55:31 +0000
X-Originating-IP: [2a02:2788:484:b4f:9c48:ebf0:8f7:5dba]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: a35fb25a-764c-4921-5db2-08d7d7a46242
X-MS-TrafficTypeDiagnostic: AM5PR03MB2993:
X-Microsoft-Antispam-PRVS: <AM5PR03MB2993DD9B541B90E7A67BF44E86C70@AM5PR03MB2993.eurprd03.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:8882;
X-Forefront-PRVS: 0362BF9FDB
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM5PR03MB2882.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(136003)(396003)(346002)(39860400002)(376002)(366004)(186003)(81166006)(16526019)(8676002)(31686004)(6486002)(966005)(66946007)(66476007)(478600001)(66556008)(8936002)(86362001)(5660300002)(81156014)(2616005)(786003)(110136005)(4326008)(31696002)(6512007)(316002)(36756003)(2906002)(54906003)(3450700001)(52116002)(6506007); DIR:OUT; SFP:1102;
Received-SPF: None (protection.outlook.com: uclouvain.be does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: Xy6zc16dqZz35+kvymRYdgaxAui+BDXhOL5h2xrr5HzoWLi2krnYPcgSl326s57vAdxi9R48sFXoeJ6fT+l/TgExSAe+dp4F0gaU0+vyTfO8GSyU2ZL/H/48OAhqG5ggMixUXggyPEGNjbiyc8bu2v/ILodOwepF0kTQg6HXV5qudMLPDl5X4+iV2bIimDgbc4XaFq08Ye6jfhdvJZolwRWbd+IVSNT17CDJzQOAul04/fD6/vMMht5MH5sdkNLNwizDAoQfo+IKFrE6CWtp6uqz0jZaeMe0ykXTFRfYQGFE6SltK51Apay2Ex9VaijoK7XilxZtWeSkMPx1X5BPPI9/wh8ng2W/HESkHAQYEfQKEpNXJUS0/Q3ujR0lnZM8PtPVVPKhzAWH6t6cjthopttiUejhgjR9IsP08UxvyeJXGpVb7edNkd600sOY5uHIiuSeIGaL9iUGJESvl3yE0WsYKXxarVGLFfl1UKzQt//SM7CqoW5t9qM0v2yW/wyfZJFnxA+MEFGJl7AUBR8JAQ==
X-MS-Exchange-AntiSpam-MessageData: ET60UvnPqAd4aHSBkiyA+rS0fvAU0d4eps7XG2DFA0v4DtIwKBe9Lf5KgARZ0Rm0mEtSSvfPxBGyiV4NdmO4dhRWbXuMsJJdkYWj1gk1/eWIUJdZiaxoLFTQow8CYXXoP/20IuUtQ+QHmI62PRWOH1f388mT9d/rr0YBrD7yblIVM/UcrksKxsulQPNutPQjaio1KOBUIxzg6IuVYjg9jw==
X-OriginatorOrg: uclouvain.be
X-MS-Exchange-CrossTenant-Network-Message-Id: a35fb25a-764c-4921-5db2-08d7d7a46242
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2020 07:55:32.0838 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7ab090d4-fa2e-4ecf-bc7c-4127b4d582ec
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: e3IjhtDzDCmCws9RK3HBtO4V1l3P1xQ+BYlA4toKd5hVyJ2KBGBG9F6PfROhZQFro5db+oW8Y7uW13t8YqaTULx7Ig+Zs2sE51h9vt5ibXcNGHWn29/FQuikjY/0LGnN
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR03MB2993
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/HFseVpC8Uqw2huDCiRLC8t0WPG0>
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, 03 Apr 2020 07:55:37 -0000

Lars,
> 
> what we have done with MPTCP is build a system that is reasonably good 
> at pooling the capacity of multiple paths for one connection, *if* these 
> paths have reasonably similar characteristics, esp. RTT.
 >
> With paths with dissimilar RTTs, we can still pool the capacity, but 
> only make it available for use to the application at pretty much the 
> maximum of the individual RTTs. That’s still somewhat useful if you care 
> about bulk throughput. It’s basically useless if you care about 
> small-transfer latencies, which the web has been gravitating to for 
> years. (Remember that the MPTCP design is ten years old - from a 
> different world. Bandwidths have gone up a lot, making capacity pooling 
> less urgent, but late cues have not decreased much.)

This corresponds to the hybrid access network case that pools bandwidth.

> To make multi path useful to today’s mostly latency-sensitive 
> applications, we need a path scheduler that can pool (some of) the 
> capacity of multiple dissimilar paths at some effective RTT that is much 
> lower than the maximum of the individual ones. I am not aware of any 
> proposed scheduler - for MPTCP or otherwise - that achieves that.


AFAIK, this is exactly what Apple is doing with MPTCP. They call this 
the "interactive mode" and the stack dynamically selects the path (wifi 
or cellular) having the best performance (rtt, losses) for interactive 
applications. See https://developer.apple.com/videos/play/wwdc2017/707/

> Even if we change the argument from pooling latency to increasing 
> resilience, I still doubt that increased resilience at the cost of 
> much-increased late zu is a worthwhile trade off for many apps.

AFAIK, Apple calls that the "handover mode", it is probably less useful 
that the interactive one. Maybe Apple engineers who are on this list can 
comment and provide more details.

I don't think that Apple uses MPTCP to pool bandwidth. They use MPTCP to 
improve user experience and mainly latency.


Olivier