Re: Multi-path QUIC Extension Experiments
Robin MARX <robin.marx@uhasselt.be> Tue, 20 July 2021 09:28 UTC
Return-Path: <robin.marx@uhasselt.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 AB2E43A1A74 for <quic@ietfa.amsl.com>; Tue, 20 Jul 2021 02:28:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=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=uhasselt.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 oL7bB3Lnb1dM for <quic@ietfa.amsl.com>; Tue, 20 Jul 2021 02:27:54 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E31A3A1A75 for <quic@ietf.org>; Tue, 20 Jul 2021 02:27:53 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id q18-20020a1ce9120000b02901f259f3a250so1627341wmc.2 for <quic@ietf.org>; Tue, 20 Jul 2021 02:27:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uhasselt.be; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PVQ5Gcx018H4L3d2Waecxcl/6eiygY9y9PrAUV6vPSA=; b=MZuGzTCZa1QsDaO6/SoW2MZ2D6Jx1FNtY3fiJ1EKUYry3FclJZN77ThLK9/bSKSAvJ 8Tg1Uv+7hW3BlCUgRna0ymouousV4BwNZBHNjQY7Sj2L80GgAruepCzedwQLdDP4tNpm Puepd3g8dH+FaISTb7QV0qEBirBvOXn85SUmE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PVQ5Gcx018H4L3d2Waecxcl/6eiygY9y9PrAUV6vPSA=; b=BzbzGryPZkV5TiGEHG7HncvvTY/3MjFDvmxhnQNBIS10eI6SAVK6ix7jbLgFRhRVTW E68GYXTdCdG5PIQqC2kZfoi/F+xhaQE/IhXzjE4MEy3JfPYAHUX5keX7h9QAP+0JZuDZ YtcwXSA5Eb0yrGWapxicAhd6h0H+rPVbmbVRda0WKT9BwaWXXYp46ChzQniSai74hyA5 nNl5vwG052jwjv0KdglqAB3h9VBhqTTRQhnH3WPp8FMFr5ESHhvFFo7X5QyWBKWwcqKN GSulbKG401pg4hD1aovMIVQSuqUfnsbkJ/EotC7lqiX33eHXoHXDvDBoBFYHnD2G9Nd4 yPSg==
X-Gm-Message-State: AOAM533TwNeswEWYcve330Lq8dKb9DYbOgcS6eI2bxgx+WhcbdnSF9J2 hs4gH28RuYQf2uoNSNuSTAij6fVc/2tU1IHQgTDPOQ==
X-Google-Smtp-Source: ABdhPJyNRl8HNmYq9FkK25C1AtwqWuwr8RQet6eC4u112hEUkVrByXB71/zPjqmlc7yEo0QY4hBaISrcQmYEAhqsaDg=
X-Received: by 2002:a05:600c:364c:: with SMTP id y12mr36189975wmq.78.1626773270541; Tue, 20 Jul 2021 02:27:50 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <41414E77-B01A-4EC1-9FF7-37A03DA5EF5A@eggert.org>
From: Robin MARX <robin.marx@uhasselt.be>
Date: Tue, 20 Jul 2021 11:28:26 +0200
Message-ID: <CAC7UV9Y0WzDp=pM9uu41pqtV+ORuT+u6LBP2RD0F9QeO5Hd-PA@mail.gmail.com>
Subject: Re: Multi-path QUIC Extension Experiments
To: Lars Eggert <lars@eggert.org>
Cc: Roberto Peon <fenix=40fb.com@dmarc.ietf.org>, quic <quic@ietf.org>, "matt.joras" <matt.joras@gmail.com>, 李振宇 <zyli@ict.ac.cn>, Christian Huitema <huitema@huitema.net>, Charles 'Buck' Krasic <charles.krasic@gmail.com>, "lucaspardue.24.7" <lucaspardue.24.7@gmail.com>, Yanmei Liu <miaoji.lym@alibaba-inc.com>, Yunfei Ma <yfmascgy@gmail.com>, Yunfei Ma <yunfei.ma@alibaba-inc.com>, Qing An <anqing.aq@alibaba-inc.com>, Mirja Kühlewind <mirja.kuehlewind@ericsson.com>
Content-Type: multipart/alternative; boundary="000000000000ebd28b05c78aaa01"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/1WylVc-N8mWPd0ohNZCax16Sihs>
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, 20 Jul 2021 09:28:01 -0000
Hello Yunfei, Thanks for your extended explanations on Multipath HoL-blocking and especially: > I think the stream dependencies you mentioned here is a great point. In our implementation, we introduced a stream-priority based reinjection which tries to address such dependency (There is a figure in the material that Yanmei sent). But we haven't tried when each stream is limited to a single path. In our case, streams are distributed on multiple paths. I would definitely want to hear more about the application you are dealing with, and maybe for wired transport, such a design is needed. This is exactly what I was trying to explore in my previous mail. You're basically intentionally causing (or perhaps risking?) HOL blocking because you split a single stream over multiple paths. As noted by Christian with the 'equal cost multipath', this can have bandwidth usage benefits, but only if paths are usable/similar. If not, HOL blocking might undo all the benefits you get from this setup (and using a single path per stream would be better). So my question was: where is the inflection point where you might decide to switch modes? At which parameters is one better than the other? I'd hoped you would have experimented with the fixed-path-per-stream setup to get some insight into this. In my mind, the idea of doing a purely transport-level multipath scheduler (i.e., without taking into account application layer streams / data dependencies / etc.) has historically made some sense for TCP / for completely separated stacks, as the transport didn't have that type of information available. It is however utterly strange to me that this approach would continue for QUIC (at least in endpoint multipath, not things like in-network aggregators that have been discussed), where we have clear splits between streams and (hopefully) already some type of prioritization information for each stream. For QUIC, I'd expect one-path-per-stream to be the default, with multiple-paths-per-stream to be an edge case if you have a single, high-traffic stream (which I do assume is your situation with a video stream). With best regards, Robin On Tue, 20 Jul 2021 at 09:15, Lars Eggert <lars@eggert.org> wrote: > On 2021-7-20, at 1:19, Roberto Peon <fenix=40fb.com@dmarc.ietf.org> wrote: > > > > If we have to send data along a path in order to discover properties > about that path, then sending less data on the path means discovering less > about that path. > > > > The ideal would be to send *enough* data on any one path to maintain an > understanding of its characteristics (including variance), and no more than > that, and then to schedule the rest of the data to whichever path(s) are > best at the moment. > > ^^^ This. > > Because the Internet has no explicit network-to-endpoint signaling, an > endpoint must build its understanding of the properties of a path by > exercising it, and specifically exercising it to a degree that causes > queues to form (to obtain "under load" RTTs, see bufferbloat) and > congestion loss to happen (to obtain an understanding of available path > capacity.) Some people have called this "putting pressure on a path". > > There has been a long-standing assumption that if you exercised a path in > the (recent) past you can probably assume that the properties haven't > changed much if you want to start exercising it again. This is why > heuristics like caching path properties (RTTs, etc.) are often of benefit - > often, but not always, and maybe never in some scenarios (e.g., > overcommitted CGNs.) > > There has been some work on this in the past for MPTCP. For example, on > mobile devices - which most often have multiple possible paths to a > destination via WiFi and cellular - exercising multiple paths comes at a > distinct increase in energy usage. So you need a heuristic to determine if > the potential benefit of going multipath is worth the energy cost of > probing multiple paths before you do so. > > Thanks, > Lars > > -- dr. Robin Marx Postdoc researcher - Web protocols Expertise centre for Digital Media *Cellphone *+32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05
- Multi-path QUIC Extension Experiments Yanmei Liu
- Re: Multi-path QUIC Extension Experiments Robin MARX
- Re: Re: Multi-path QUIC Extension Experiments Ma, Yunfei
- Re: Multi-path QUIC Extension Experiments Mirja Kuehlewind
- Re: Multi-path QUIC Extension Experiments Roberto Peon
- Re: Multi-path QUIC Extension Experiments Charles 'Buck' Krasic
- Re: Multi-path QUIC Extension Experiments Yunfei Ma
- Re: Multi-path QUIC Extension Experiments Mikkel Fahnøe Jørgensen
- Re: Multi-path QUIC Extension Experiments Roberto Peon
- Re: Multi-path QUIC Extension Experiments Christian Huitema
- Multi-path QUIC Extension Experiments Alexis Norech
- Re: Multi-path QUIC Extension Experiments Charles 'Buck' Krasic
- Re: Multi-path QUIC Extension Experiments Roberto Peon
- Re: Multi-path QUIC Extension Experiments Lucas Pardue
- Re: Multi-path QUIC Extension Experiments Yunfei Ma
- Re: Multi-path QUIC Extension Experiments Yunfei Ma
- Re: Multi-path QUIC Extension Experiments Yunfei Ma
- Re: Multi-path QUIC Extension Experiments Christian Huitema
- Re: Multi-path QUIC Extension Experiments Lucas Pardue
- Re: Multi-path QUIC Extension Experiments Lars Eggert
- Re: Multi-path QUIC Extension Experiments Robin MARX
- Re: Multi-path QUIC Extension Experiments Mikkel Fahnøe Jørgensen
- Re: Multi-path QUIC Extension Experiments Mikkel Fahnøe Jørgensen
- Re: Multi-path QUIC Extension Experiments Behcet Sarikaya
- Re: Multi-path QUIC Extension Experiments Christian Huitema
- Re: Multi-path QUIC Extension Experiments Yunfei Ma
- Re: Multi-path QUIC Extension Experiments Ian Swett
- Re: Multi-path QUIC Extension Experiments Yunfei Ma
- Re: Multi-path QUIC Extension Experiments Spencer Dawkins at IETF
- Re: Multi-path QUIC Extension Experiments Christian Huitema
- Re: Multi-path QUIC Extension Experiments Spencer Dawkins at IETF
- Re: Multi-path QUIC Extension Experiments Yunfei Ma