Re: Multi-path QUIC Extension Experiments

Yunfei Ma <> Wed, 22 September 2021 02:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 616513A17DF for <>; Tue, 21 Sep 2021 19:43:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p9ikzk-N1cag for <>; Tue, 21 Sep 2021 19:43:42 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D43E93A17E0 for <>; Tue, 21 Sep 2021 19:43:41 -0700 (PDT)
Received: by with SMTP id i4so5834651lfv.4 for <>; Tue, 21 Sep 2021 19:43:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QMqhGvu0e+OpNmx9hiARBitSFouDILEOhSZrn0kcgxM=; b=di1hWG1xXKgWo6bVZ12VXAnMLDCfgT5EqMioOwisY3J2V/myTASU4f3hqJRONBG+ZK EdSNjppRfcEg1arzoojrwmt1Hh3K5eDwLQIhg+OBg3IfV6gbtHNGcf1HwyPBDMFWrN3t VGAVyPlFb/nbTVS9pE+sobjUNuCXf55gSdG0bXC9yUVJVzkBDhWGG6nATEpLoRHJqNHU nQpWt8z/mzFKvjxc2AjH5rL6YzIlR4Pt3X1BJ5OnGBwp+7EE7L++8wJL8nkM8u8YlKQw qW5Lghwe8P6h38XmZa1YrA2h5Kc4kBwbgOnDB9eEndPF6VoCJ+Q6LI3FsXuDtx5yg6B7 PJSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QMqhGvu0e+OpNmx9hiARBitSFouDILEOhSZrn0kcgxM=; b=5ozvQQZDoNnR5X5ZSO4O/aotUKFLW+XKDsgeX84b+4pCcVa7wuhvOmidsQfLadiN3b Weqzze41PnX3dZCYa8u8CeXy0a3SxuVZlh/BIVa2955XH78DOl/vqTzRO/sTpknedjwA ksKubjq/xV2/NxIuERSggaMbDwqUk9oSlFp/DCHTKjX+1VUERCtZbRgyrOkn1RP8wyUA 9SX+4341piDGxRyck5W5f7uidp+vw3WoX6CpclMPOoQu2aj+yj0c09g6Fye4831/KX+w DwsM2tRqwkokqF55yJu3Ms2Sp2wGv77EfZoIAJ67p5OJEYBdTtlscOdXwN9JMsXVOeEX 9TYA==
X-Gm-Message-State: AOAM531q4SMSoGa6MUTzpJEe9LKwG7v3RRcTpMX2wadnOUNTUCckpq4I qjqYqjwcLsBqbWgk7JHcTXYJfTOw1M15pRzZKZA=
X-Google-Smtp-Source: ABdhPJzsHt09oOpTC2n8kLRuSpGkBrPws31WrL8jLIFU5ngR6nA3bzO1g6YFtYYMIyGNnnW4RPhH8UC1Go++WIywUiA=
X-Received: by 2002:a05:6512:1326:: with SMTP id x38mr26118408lfu.98.1632278619761; Tue, 21 Sep 2021 19:43:39 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Yunfei Ma <>
Date: Tue, 21 Sep 2021 19:43:03 -0700
Message-ID: <>
Subject: Re: Multi-path QUIC Extension Experiments
To: Spencer Dawkins at IETF <>
Cc: Christian Huitema <>, Robin MARX <>, Roberto Peon <>, Yunfei Ma <>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <>, "matt.joras" <>, =?UTF-8?B?5p2O5oyv5a6H?= <>, "Charles 'Buck' Krasic" <>, "lucaspardue.24.7" <>, Lars Eggert <>, quic <>, Qing An <>, Yanmei Liu <>
Content-Type: multipart/alternative; boundary="0000000000004e30b005cc8c7b48"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Sep 2021 02:43:48 -0000

Dear Spencer,

Thanks for your comments. To achieve real performance gain, it might take
you to design some "smart" algorithms depending on what you are working on,
but what we were hoping to understand in the earlier experiment was what
basic features we should include to enable a larger design space. In other
words, the algorithm may be more complex and flexible, but the protocol
feature that enables it is simple and independent of the algorithm, like
the QoE_Control_Signal frame defined in draft-liu. Just like what has been
pointed out by Christian, it solves the problem of how to close the
asymmetric knowledge gap between a client and a server. The "knowledge
sharing" mechanism can definitely go beyond our early experiments. I think
the power-saving use case you just mentioned serves as another example
where such a knowledge sharing mechanism can help.


On Tue, Sep 21, 2021 at 12:14 PM Spencer Dawkins at IETF <> wrote:

> Hi, Christian,
> On Tue, Sep 21, 2021 at 1:31 PM Christian Huitema <>
> wrote:
>> 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
>> >
>> ).
>> > 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.
> Yes, very much so. My point was that this is complex, and your point about
> asymmetric knowledge is well-taken. The idea that "clients" (UEs) know
> things that "servers" (in this case, UPFs) don't know is also popping up in
> 3GPP ATSSS discussions (for example, in clause 5.32.8 of 3GPP TS 23.501
> V17.1.1):
> *UE-assistance indicator: *This indicator may be provided only when the
> Steering Mode is Load-Balancing. When provided by the network, it indicates
> that (a) the UE may decide how to distribute the UL traffic of the matching
> SDF based on the UE's internal state (e.g. when the UE is in the special
> internal state, e.g. lower battery level), and that (b) the UE may inform
> the UPF how it decided to distribute the UL traffic of the matching SDF. In
> the normal cases, although with this indicator provided, the UE shall
> distribute the UL traffic as indicated by the network.
>> 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 like this (especially because what you're talking about is meaningful to
> applications and independent of changes in underlying network technologies
> along a path).
>> 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.
> You and I have shared the hope that we would be able to describe building
> blocks that applications can use, rather than define new codes every time
> someone comes up with a new way of distributing packets across multiple
> paths, for a while now -
> was based on a discussion we had, and that was submitted last January.
> I hope the QUIC working group's return to multipath discussions gives us a
> chance to make progress on that.
> Best,
> Spencer