Re: Multi-path QUIC Extension Experiments

Christian Huitema <huitema@huitema.net> Tue, 21 September 2021 18:31 UTC

Return-Path: <huitema@huitema.net>
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 4A0163A157C for <quic@ietfa.amsl.com>; Tue, 21 Sep 2021 11:31:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 XuHJK0SmBI1H for <quic@ietfa.amsl.com>; Tue, 21 Sep 2021 11:31:14 -0700 (PDT)
Received: from mx36-out21.antispamcloud.com (mx36-out21.antispamcloud.com [209.126.121.69]) (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 C0C593A1577 for <quic@ietf.org>; Tue, 21 Sep 2021 11:31:14 -0700 (PDT)
Received: from xse47.mail2web.com ([66.113.196.47] helo=xse.mail2web.com) by mx134.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mSkXv-000D2l-3p for quic@ietf.org; Tue, 21 Sep 2021 20:31:13 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4HDVP83S9Yz9nV for <quic@ietf.org>; Tue, 21 Sep 2021 11:31:08 -0700 (PDT)
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mSkXs-0006UX-Bl for quic@ietf.org; Tue, 21 Sep 2021 11:31:08 -0700
Received: (qmail 23273 invoked from network); 21 Sep 2021 18:31:07 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.0]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <miaoji.lym@alibaba-inc.com>; 21 Sep 2021 18:31:06 -0000
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Yunfei Ma <yfmascgy@gmail.com>
Cc: Robin MARX <robin.marx@uhasselt.be>, Roberto Peon <fenix=40fb.com@dmarc.ietf.org>, Yunfei Ma <yunfei.ma@alibaba-inc.com>, =?UTF-8?Q?Mirja_K=c3=bchlewind?= <mirja.kuehlewind@ericsson.com>, "matt.joras" <matt.joras@gmail.com>, =?UTF-8?B?5p2O5oyv5a6H?= <zyli@ict.ac.cn>, Charles 'Buck' Krasic <charles.krasic@gmail.com>, "lucaspardue.24.7" <lucaspardue.24.7@gmail.com>, Lars Eggert <lars@eggert.org>, quic <quic@ietf.org>, Qing An <anqing.aq@alibaba-inc.com>, Yanmei Liu <miaoji.lym@alibaba-inc.com>
References: <8C2E8EFB-756B-449B-84E0-11CD6B57E541@ericsson.com> <0334A48E-B6C6-464C-A48C-4512A453DA81@fb.com> <CAPhuoz0vz2k63_ZaWmUg_XgSHUopid7vf+JY=JVFm_VqQJY87w@mail.gmail.com> <CAHgerOGhX3G_aBMrwZ0zXjN8tu9dqtu-9tu4z7YU80qfqaZkzQ@mail.gmail.com> <CAPhuoz1cG_ZftSFtapg-cKR23Y5AzWLxzqYq3NUfeL-8r890-g@mail.gmail.com> <0B9EAA73-802A-49F9-AEA3-A4F6C574A3F9@fb.com> <41414E77-B01A-4EC1-9FF7-37A03DA5EF5A@eggert.org> <CAC7UV9Y0WzDp=pM9uu41pqtV+ORuT+u6LBP2RD0F9QeO5Hd-PA@mail.gmail.com> <CAHgerOFMarhmVFc5Ej00sgk_GfYeTfK5cuujMAVRkDw3sFvoxQ@mail.gmail.com> <CAKKJt-f-t7mGsbR-ykpTEuEQ86SRUMXSiqQDX1icdHM=W2t3tQ@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Subject: Re: Multi-path QUIC Extension Experiments
Message-ID: <81a9f2b4-bdb3-099a-b34a-d3dfa810ac28@huitema.net>
Date: Tue, 21 Sep 2021 11:31:05 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <CAKKJt-f-t7mGsbR-ykpTEuEQ86SRUMXSiqQDX1icdHM=W2t3tQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.196.47
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCFtd 0XtfD+3Rdld8WKSZCJfmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7ImcaqlHdH9stIYSUOP2ajLGtTxQ6V51u76v35b1wNe/MvdIN+Yj9 JT+HIE3AciYbXmyy2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NDxdyIeJZUl7T+dBx2dACjzLgz0E5RJCv3HPLMWhQJbYo u1j9Hd5FcEswOuV9IGJdDRojSVizNl0ce/s7u0P9b9Tml6eOMCV9kYYwkPx6ZsXvIUzTXkDAiiJi mGhLUFuSW8D9t0kz0vlag+LRt89q4Bjs9BEJ6iGVRxfRt5ZEXJ6yuLfHqAnAj7rgKH7+eCmmoKHu gA/27u5XHuDhEFGBg1ShcA6Xvva2QAVEjpqzANap+28aWyCRVT7YkY7LckVc1JrZ5DST3LL0xXMa GvDs1L13qFZSq8Fx+9otn0aqja8VKPqpdskk5LxBR/9t1zMMkdu6/R2FM84kxYRFSvC1IDg1BRW7 hzp8w3iHcOwbVtsmWfnQGGis4EvbR3jXsI0ESXwhBU2hwt/J18C+HygJl/jEzm1SsR8v3aJbN/NZ fa8pHhHaz+HPa0HAgEx4sWDF
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/A-83QGaJOVnVEX-ztKfSmMh9odg>
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, 21 Sep 2021 18:31:19 -0000

On 9/21/2021 9:37 AM, Spencer Dawkins at IETF wrote:

> I have been maintaining a collection of various goals for path selection
> (most recently, in
> https://datatracker.ietf.org/doc/html/draft-dawkins-quic-multipath-selection-01#section-3).
> It's not a short list.
>
> If we're also including user preferences that would include knowing the
> difference between cellular connections that are metered, cellular
> connections that are unmetered but being throttled, and cellular
> connections that are unmetered and unthrottled, and cross-matching them
> with wifi connections that are likely to work better than cellular
> connections vs. wifi connections that are only intermittently performing
> well, that's not a small amount of complexity.

This leads to the problem of asymmetric knowledge between client and 
server. On the client, applications can use system APIs and user 
preferences to identify which connections are "metered, cellular 
connections that are unmetered but being throttled, and cellular 
connections that are unmetered and unthrottled." But the server side 
does not know that. Yet in many scenarios most of the traffic volume 
originates from the server, and the scheduling choices of the server may 
cause increased bills or exhaustion of quotas for the client. Which 
implies that there should be some way for the client to signal how the 
server shall consider connection.

I think this "knowledge sharing" is independent from "application 
preferences". The work at Ali Baba shows that there is a lot of benefits 
in incorporating application states in scheduling decisions. For 
example, if the video streaming application notices that the video 
buffers are emptying too fast, it might tell the server to start using 
more bandwidth, even if that means using metered connections. But that 
application state, "video buffers are emptying", is not the same as the 
network state, "path 3 is on a metered connection".

I don't think that we will be able to fully standardize the way 
applications pass their preferences. That's why in draft-liu the 
"QOE_CONTROL_SIGNALS" is mostly used to pass application-defined 
signals. But we might be able to have a reasonable set of codes (or 
priorities) explaining the "state of a path", and use that in the 
"PATH_STATUS" frame.

-- Christian Huitema