IETF Logo Mail Archive

Re: Preparing for discussion on what to do about the multipath extension milestone

Lucas Pardue <lucaspardue.24.7@gmail.com> Thu, 01 October 2020 13:04 UTC

Return-Path: <lucaspardue.24.7@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 60E183A1033 for <quic@ietfa.amsl.com>; Thu, 1 Oct 2020 06:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KAdnrc0RiHQP for <quic@ietfa.amsl.com>; Thu, 1 Oct 2020 06:03:59 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 619143A102F for <quic@ietf.org>; Thu, 1 Oct 2020 06:03:59 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id g3so1221548edu.6 for <quic@ietf.org>; Thu, 01 Oct 2020 06:03:59 -0700 (PDT)
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=ZdyzpsZiRWFHnROD+EQ/jRCZffIrnWY+0xko+gE62LM=; b=V60UQXGFSFYY3FI04Wv4UwYSJfDNAeEiJl7U3L6XUtb2G3czZBulCZBSzp5t4ldEGJ DaTk12ofclQ1fAH/W+18hpO89hVOCpa0qc765A3UnPdO5nyk2mXjJkIZbV6HJVibrTxD n4SJvbzIeAgs8nA9mgp0bfr0Ka+8uKKRJOkV4lbdV54S81VM9hfqEqFG3tnDX9Le9a21 Bidh3YegNGKGAFDIrN2I9AiRSaeOyR1VR/1k7DGGdFjgFlB6i+y+4N0T1p7qAH9F2w/p eR25B0rB6IQfycgztxVc0DnWDeltL9aqy1tHJGQb9vLd2vwD0cQ4/jfRqkjaH9CbWkx4 MaXQ==
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=ZdyzpsZiRWFHnROD+EQ/jRCZffIrnWY+0xko+gE62LM=; b=nkCsXj5twh24nwWhovqUZIqbHbaNUoBr1MlWplOcBz7nEY3h6JRxWMU2dBMZgyZtDK ZX6wKWoOmS4bPvdLBOj7P3PW4a6LdCP/jl2Vqqa/C8676Kmuz5Mt5aMp1EailqEpHdBJ z9IQfrvXP6K8SwSK1bS3sL2B9Ask3I7g7S5ZZwN8fFEZVhIEJGxZ0cgPOppOk57gbeFC g7PJ3vhX2pXfhftnmQKeOXSgRf7STZi986xb0uA38EtFAX2G8aE26Ac6amOBJxW1krWJ KWKx5rT3dV2nRPDHd71qZ3VQCiXSywRQ2wgnHs7n6iYUnKqjnylffSRiXlR++IvHuPRa PWxg==
X-Gm-Message-State: AOAM530lkk3VUeadEhpWWPOJjBW0jpuOYdg58Fjq/8ZuBDpgshcSjkrS HioDRQCyGOGCCRVZRuiZ63L/1zaM6dcBRC/m85I=
X-Google-Smtp-Source: ABdhPJz882Uwb05mex5NmrNp2UO7LpBSIjxbDXGCkbsYyrBQZ21Zcs9cajO/LzDPBRiCjjRSDGBPIcF1pk2HjgSKyKk=
X-Received: by 2002:aa7:d4d4:: with SMTP id t20mr8146335edr.229.1601557437837; Thu, 01 Oct 2020 06:03:57 -0700 (PDT)
MIME-Version: 1.0
References: <F0A5E38D-4117-4729-BFF8-72D97CAA9908@eggert.org> <CAKKJt-e=+XLZhNWqaG9YSLTRqyQRvDc-dagUSkFwHOByFwZ++Q@mail.gmail.com> <78651438-2fce-ba67-4f44-4228bbc79a75@uclouvain.be> <CADdTf+hOACZ1x=d8SV-aX0f3vc+_fyqTziRqi5gi+nJgppaz8A@mail.gmail.com> <1ada66fc-61b1-c541-8a25-afbc7c978940@uclouvain.be> <CALGR9oZzi=Ucf54xZxcy4Qfc3Q6JWuxjv5jxwR41JaEUHkcXZw@mail.gmail.com> <1e9119a6-ef0a-ebe1-8925-e0ff0d6ce9aa@uclouvain.be> <CALGR9oaSXtzi8eTdm03CQ4jt2-O1iENzD1D-8aCwn-osrjbyPQ@mail.gmail.com> <142e8430-1afa-a0f9-7089-26b1be9af79f@uclouvain.be> <CALGR9oahmGZo5HhnAX4Ke=4q=7ZT6t4TfusbF8xOdkfU9yCXGw@mail.gmail.com> <b1c5919e-43a3-449d-3b8f-a73b0558aff9@uclouvain.be> <CALGR9oao-riThu9QB2+c0kG6ODKKyzQccJnGDWAxFFFVn6816g@mail.gmail.com> <b43ad577-1ad2-e80b-06b0-6a6af9a92ed9@uclouvain.be>
In-Reply-To: <b43ad577-1ad2-e80b-06b0-6a6af9a92ed9@uclouvain.be>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Thu, 01 Oct 2020 14:03:46 +0100
Message-ID: <CALGR9oZsqQJ5Kf15O9wL=MRma4bvbNfY=6K6xr3=MuCiJLveJw@mail.gmail.com>
Subject: Re: Preparing for discussion on what to do about the multipath extension milestone
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Cc: Matt Joras <matt.joras@gmail.com>, QUIC WG <quic@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000002b750705b09ba64f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/iAMt6uMEKirma3i5aHtHS_gnezU>
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, 01 Oct 2020 13:04:01 -0000

On Thu, Oct 1, 2020 at 12:37 PM Olivier Bonaventure <
Olivier.Bonaventure@uclouvain.be> wrote:

> Lucas,
>
> In a single-path QUIC implementation, the implementation sends the next
> frames according to the congestion control scheme. When the congestion
> window is open, new frames can be sent. The QUIC protocol does striclty
> not mandate how different frames from different streams will be sent.
> Robin's measurements show that different implementations use very
> different strategies. The same will be true for multipath, expect that
> there will be one congestion controller per path. Each of these
> congestion controllers will open opportunities to transmit frames and
> the QUIC implementation will send frames when any of the underlying
> congestion window is open. This can be further optimised depending on
> the policies that are function of the considered use case.
>

Right. But the opportunities to send STREAM frames are driven by flow
control not just congestion. There are some strict mandates there.
Approaches such as binding a stream to a uniflow could cause starvation of
the related-path due to flow control even when congestion window is open.
Flow control is driven by applications putting data into the transport, and
consuming from it. I suspect HTTP/2 over MPTCP does not have this problem,
mainly because TCP's flow control trumps. But maybe I'm wrong.

Some implementations like quiche decouple the transport library from UDP.
Applications hoping for MP-QUIC with such implementations will have to
accommodate some of the complexity, the transport cannot do it all.

I do agree that we don't have to solve all of these things upfront and in
one document. But I think there is a risk of defining mechanisms and
ignoring some pathological cases. As a parallel, QUIC provides congestion
control mechanisms and does not mandate any algorithms but it has taken
care to suggest one that is going to be safe to deploy on the Internet.

Lucas

[1] https://mailarchive.ietf.org/arch/msg/quic/OlwAHMyK2mAuRCRuCP-Lpyb7ntA/
[2] https://github.com/quicwg/base-drafts/issues/3332

v2.23.0 | Report a Bug | By Email