Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Mon, 14 December 2020 20:31 UTC

Return-Path: <mikkelfj@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 157773A1BF9 for <quic@ietfa.amsl.com>; Mon, 14 Dec 2020 12:31:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.195
X-Spam-Level:
X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 XmG1AxxFrHO2 for <quic@ietfa.amsl.com>; Mon, 14 Dec 2020 12:30:59 -0800 (PST)
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 773793A1BEF for <quic@ietf.org>; Mon, 14 Dec 2020 12:30:59 -0800 (PST)
Received: by mail-yb1-xb2a.google.com with SMTP id v67so16760608ybi.1 for <quic@ietf.org>; Mon, 14 Dec 2020 12:30:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=Q2V3sdP+DtkfWPvyr0wVUZJ+7mtk/6OffBTSXVZPWso=; b=B1IYo/E89/CV6OgcOFfQkidr5IdUhoy0DWA4ZciBdoxE6R9WTy50hwM41Jml5H8Iav 9qKyCZcE0DIfc24+Bb5DmFbnILW+SoC2FwKCGHEyydqFPfcnWn7jpnPQHrQHitlLRHCi n2iHvOl1TR8Ci2h6nTSo8GziumuqEW+Fyp2KScy5BrpbJ1zH67fm0QHOw6f4+09sS4Yg Qpm3lbmIBD1t3TznLJfMFwDuwtjPm1y+9wDRadF4QXy4NymvQRG9dEbsEcR51XBHIQFr wURLRVA8NUIDXz+N3b6Me7x1Q1ryuU7lGDtGB6JfQZ4Hr6ANx1RbZv5VyToufHVExZMv 0seQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=Q2V3sdP+DtkfWPvyr0wVUZJ+7mtk/6OffBTSXVZPWso=; b=HMDW3U7n7Te0/zQ9PpCwZSkKSgVL7Th8GR2swQxRwZnHSB6Rk9Wn7GWvYyW5DZGILU BL8CK3AVZdIKF29C7Z6NOJhwx00xfrJN0WHZ9YnzhQKY9GdLMye8imdQWbQ3knlW+GU2 3nutJXj1rM+Y3oxXF1MLAfhvhyeGRMseo9EvYhJ0ovi072uPc6qEpDLR6Ow2hMYctxNd CdBrPZgvCbn50GjHPyFUk2wP87y983kcWWAkbxi0dRM0POwCvm8tHhjzl4IZUb3uMWLv hT7Ako6qJvX+XlrNbaoViV/QDR3JQVPcGsfQ9aIH+WUUlwetdXhk0qieCw6/59C1fq0+ 0XOA==
X-Gm-Message-State: AOAM532nunpJwfUu8o9L/lrx0tp3VEb77nRnB4xT4ukxJvI7lFJ8XViY mChZdJd7/vBpt3xfenc1RgQrNAlw8ES5DFrWzvo=
X-Google-Smtp-Source: ABdhPJz7MMYQrn4SIzFfyXtQA9x2CHW5htAHGofQf+xN5epqXh2+3aU58Ua2f4tz3jElPnOICpQ4SxYmJYPGgY12eKU=
X-Received: by 2002:a25:4409:: with SMTP id r9mr39653153yba.113.1607977858361; Mon, 14 Dec 2020 12:30:58 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 14 Dec 2020 12:30:57 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <7e875886-3589-e2a9-8891-4c652e449af6@huitema.net>
References: <1baa86a9-455d-4256-85f2-9aee159afed9.miaoji.lym@alibaba-inc.com> <CAN1APdc_1+VwOoGaX16iaQPUXfySoD-bmjuSVBJ_gLF4HUBO1Q@mail.gmail.com> <CAN1APddoML7akHEE7EiR8qbfjf=D+0n+gNP=FccvL3JSt19a0w@mail.gmail.com> <CAN1APdcwEU+YrM=WcO5KV+BuEWSzes+CbAzhNCCKxdo7NuG78Q@mail.gmail.com> <7e875886-3589-e2a9-8891-4c652e449af6@huitema.net>
MIME-Version: 1.0
Date: Mon, 14 Dec 2020 12:30:57 -0800
Message-ID: <CAN1APde9DJcK7oHbAjfhCmziBoY3HmJQ5ssywiC5HqQvzactkw@mail.gmail.com>
Subject: Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt
To: "安勍(莳逸)" <anqing.aq@alibaba-inc.com>, quic <quic@ietf.org>, 李振宇 <zyli@ict.ac.cn>, Yanmei Liu <miaoji.lym@alibaba-inc.com>, Christian Huitema <huitema@huitema.net>, "Ma, Yunfei" <yunfei.ma@alibaba-inc.com>
Content-Type: multipart/alternative; boundary="0000000000000dee8b05b6728509"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/OVhBFLme5UTiqsnMtVA10HVbxSg>
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: Mon, 14 Dec 2020 20:31:01 -0000

OK, thanks for explaining.

I wonder if the current asymmetric approach could be enhanced relatively
easily by allowing a server to announce a list of address/port/QoE tuples
that it can recommend the client to use as virtual endpoints, without
initiating anything. The client would then issue path challenges as usual,
but can do so to any one of the proposed endpoints. The server could
periodically propose new such tuples or update QoE on existing. If a server
wants to retire an endpoint, it could send that information too, but a
draining period would be needed.

This could also piggy back on the existing CID update system where a server
CID is associated with a virtual endpoint.

Mikkel

On 14 December 2020 at 21.01.27, Christian Huitema (huitema@huitema.net)
wrote:

On 12/14/2020 2:38 AM, Mikkel Fahnøe Jørgensen wrote:

Sorry, “async design “ should read asymmetric design, in that only one
endpoint can create multiple paths, as opposed to a symmetric design where
both can.


On 14 December 2020 at 11.33.46, Mikkel Fahnøe Jørgensen (mikkelfj@gmail.com)
wrote:

async design

The proposal indeed keeps the asymmetric design of QUIC v1. That design is
grounded in practical realities, such as the prevalence of NAT and stateful
firewalls that would drop "unexpected" packets sent to a client. Also, the
client typically knows about the cost of paths better than the server, for
example whether sending more data on a given path will generate larger
invoices from the provider. The design goal is to let the client express
these preference to the server using a simple priority scheme.

Anything more complex probably requires application level decisions. That
why the design provides the QOE frame. That frame let applications exchange
information about paths in an application specific way. The expectation is
that the application posts them as it sees fit, and the transport delivers
them as they are received. The application then uses locally provided API
to affect the way data is sent over multiple paths.

We could debate whether the QOE frame is needed at all. Applications could
also exchange the data as part of application protocol itself. I think that
having a separate frame reduce the overall complexity, by separating
application specific path control from the application protocol itself.

We could also debate whether the QOE frame should be specified in greater
details. The current design simply passes a byte string. The DNS SVCB RR
type addresses a related problem by an SvcParams field that contains a list
of key-value pairs. It is possible that having a similar list of key-value
pairs would be useful there. On the other hand, we do not yet have a lot of
experience. And open design with a byte string is probably good enough for
now.

-- Christian Huitema