IETF Logo Mail Archive

Re: What to do about multipath in QUIC

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 12 November 2020 18:28 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 55DE13A1484 for <quic@ietfa.amsl.com>; Thu, 12 Nov 2020 10:28:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0vcmdXCmnUAm for <quic@ietfa.amsl.com>; Thu, 12 Nov 2020 10:28:03 -0800 (PST)
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 79F623A1489 for <quic@ietf.org>; Thu, 12 Nov 2020 10:28:03 -0800 (PST)
Received: by mail-yb1-xb2b.google.com with SMTP id v92so6279630ybi.4 for <quic@ietf.org>; Thu, 12 Nov 2020 10:28:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cm/fCVkAI6sa/xEfKDmu6SgdlwLjo/A7xqj15v4iCcs=; b=O7BEYEVX0A/O0fcc5MslOZL0F8OrUmsLc87JQGGJwQwUk+JG+Al7xsniCWBmCYAO92 W7ewHsU1zs++L0g3gkfnNKlZpP9enXKwMQ4nZH7S2U+871uJkDfoCvBnvsxvcSDkrdQl A1sLA3FgpdlZtyXue636zHv9z1rRY6Zl8/2mCDk3WyjeAjymoeYP92dzKhG2vCWl1ism 3jjwamNtEEXGwmEqi8Nly579QAOvOPKMcmNC9lrlnRWsSniyi1Nr6zAqDhgp7bPqiuA/ +JPL6Ml9XKtlRzFSe80GOs21qqAuZbAMIpmN44LljCFDvCEJnB89L6/fkXSFh0aNZ4Ms vjNA==
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=cm/fCVkAI6sa/xEfKDmu6SgdlwLjo/A7xqj15v4iCcs=; b=U6Jb1fNggrKimompZ9QtaChcI9UhbTvcAJppAS0B2vWhvlULuJ4IOqzj7ybucUHkO5 RjEZYGXjbHlgXieobcsAmNBQowgda8tHfFhNogETXfRRNtjK/8roHrR8FtTHIwxkdtyv orUSXhZnhgH5W3EXqL26M1/LDe3H94JRZB9XC/JMOxpdaYHpNYrP99s/pVwIrBmI3QkB 7kPFgwmJLu0apDON9h2Tw/YpY+BIZvReCS+av+WKotR8e8SR87XX+Nom2rynbUvFHF7P EviX3ujk03hrGpM/5MppksPvt10OAZfj1NGDlu5TA3HFaQgh4bokibPK6+bxd5UgHA+3 SPCw==
X-Gm-Message-State: AOAM53228yuKIPhqZ1vxh4KjO+pW7X58A088zpTA7I00DO0Ic2S+h91e bHeE06tw/sY1d8KRYGiEzr13QjWi3C2zWnj64qU=
X-Google-Smtp-Source: ABdhPJwiacRCxvHNzAxaVX0tib7KRcGlAuKx76hU9j3qVTkR8gOfFdK3YQA8WQ5bXSYyaOz7FLHrL9s3k2R0IMAX2Rc=
X-Received: by 2002:a25:bd7:: with SMTP id 206mr1130146ybl.84.1605205681676; Thu, 12 Nov 2020 10:28:01 -0800 (PST)
MIME-Version: 1.0
References: <538215d1-3b9e-4784-920d-03be4c3a503a.miaoji.lym@alibaba-inc.com> <CAN1APddB4JDo281L0USsU7FSiQxRNi-LaB8ZS0a9kLAgeNJwrw@mail.gmail.com> <54510017-fa91-555f-0219-0859d6686b74@huitema.net>
In-Reply-To: <54510017-fa91-555f-0219-0859d6686b74@huitema.net>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 12 Nov 2020 12:27:35 -0600
Message-ID: <CAKKJt-c-zGGcWTHHUQS52hxhgLAmmWpr6ZuGz2TsmRVUSxQwrw@mail.gmail.com>
Subject: Re: What to do about multipath in QUIC
To: Christian Huitema <huitema@huitema.net>
Cc: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, Yanmei Liu <miaoji.lym@alibaba-inc.com>, quic <quic@ietf.org>, healing4d <healing4d@gmail.com>, "Ma, Yunfei" <yunfei.ma@alibaba-inc.com>, "安勍(莳逸)" <anqing.aq@alibaba-inc.com>, "Liu, Hongqiang(洪强)" <hongqiang.liu@alibaba-inc.com>
Content-Type: multipart/alternative; boundary="00000000000072a5ef05b3ed12fd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/6vwOI_s_2tbc4Y0kp_0zzoUeRnQ>
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: Thu, 12 Nov 2020 18:28:05 -0000

FWIW ...

On Thu, Nov 12, 2020 at 11:05 AM Christian Huitema <huitema@huitema.net>
wrote:

> I think we need more work on the "multi-path scheduler". We have heard of
> three application scenarios: maintaining the lowest RTT when sending voice
> segments (Apple Siri), avoiding buffering delays when playing music (Apple
> Music), and using two available links with equal preference (Ali Baba "high
> speed train"). I wish that we could distillate that into a couple of simple
> concepts.
>
I'm working to capture these in
https://github.com/SpencerDawkins/draft-dawkins-quic-what-to-do-with-multipath.
Thanks, Christian, for the framing.

There are others from the multipath virtual interim (for instance, sharing
bandwidth if multiple paths have roughly equivalent RTTs, and using the
path with the lowest RTT if they don't).

So, I agree with Christian about needing more work on this, and it's not
clear to me how many "multipath schedulers" we should be thinking about -
but that's a question for another day.

Best,

Spencer

v2.46.0 | Report a Bug | By Email | System Status