Re: [Masque] ECN & Flow IDs

Martin Duke <martin.h.duke@gmail.com> Wed, 07 April 2021 17:06 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F5B3A21EC for <masque@ietfa.amsl.com>; Wed, 7 Apr 2021 10:06:51 -0700 (PDT)
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, 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 wZUntVdrZEUp for <masque@ietfa.amsl.com>; Wed, 7 Apr 2021 10:06:49 -0700 (PDT)
Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 9E9FB3A218D for <masque@ietf.org>; Wed, 7 Apr 2021 10:06:48 -0700 (PDT)
Received: by mail-il1-x12f.google.com with SMTP id p8so12485226ilm.13 for <masque@ietf.org>; Wed, 07 Apr 2021 10:06:48 -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=/YAvTw2wDX+YGlFHLUmAdoeEM13N55LksNktWObhLdI=; b=cqekpMOwF59PvNJZh0qpsJZ/ztpJks0YxmFor1BfDnOO76rfyMI7IpT494fBoAG2V8 LiOJ+ihqKsMyNNSxofCRlr2TX2skdTaDUdulHdLgFMHOJHsJryZ2W48BVyTPCP8Xa8ys yXjfxJnJPZdx17Ob7/R60vwOpR3LVY+wYRkURQ8ljW7MdugI9Wmhv+yw5IroAd/l7/Qs dZjLtCOJfXGrvpCYs6a5eo+/Oe3iaevVEUJZaWSSe/B2jqn1Y5qJDZVCd7wLG6lTpcxy TcXTctLWdL6ANLmpo0baB3+r5i0p1qeywnMeNA7iA0NwFxhcldH7zGUzLt4s/ohCNpGy AtCw==
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=/YAvTw2wDX+YGlFHLUmAdoeEM13N55LksNktWObhLdI=; b=S21oSO2T++aNx0d2H/Yc8IR/cmF0nPLB+g+u+xnrl+Gyg2yvJYdHCHh0QENK9Rar2n hN1e9Lo3CrDAElYNOrY5pD5KELwPhGH6eWjOPOF5Y7sYBnDYeDGs/CxkyGDZrg8c+Weq 0O0/5Of5jRsRrtkKFJCV6zNsD2dzqGbFiHh8lpvaPfkCu/ZClrtXLsygkq792pD96gpV BEzYhhfbP+2XjRlftg2z7CFfclDgFxog803psqkrLz9Ua+jP9InqguXa3cq5HHJXODA1 HXstS7zjKqR21EcYw0M6HBbCtSb4JQbhQ2a05VJKv1uyRdzFiITfPn2VClI3Gt5e5sdB WarA==
X-Gm-Message-State: AOAM5302SGfjlHFl78Is2DHfhQLa7Rv7BKshtZO/DQk+iQzOf81ECqeD zt/8VDHxBT1X8YNGXxJ3Y4aToXW9O294Ha8uBPQ=
X-Google-Smtp-Source: ABdhPJzNYZHrF2IvwQlxHQvas0g+AzDdgOe5lApp02q5N0VcINDjF5KJb0pgew0a6q14rHuzg3+Tzk2fSQ7aAj0r0cQ=
X-Received: by 2002:a92:ca4b:: with SMTP id q11mr3539194ilo.272.1617815206901; Wed, 07 Apr 2021 10:06:46 -0700 (PDT)
MIME-Version: 1.0
References: <CAM4esxRmjWr-y-9-KAJmmKvGdONpPufgAbubUhPu_KaS1_Md9Q@mail.gmail.com> <CAPDSy+6go4xh4E55220upECkrept1Yb15diVhC8e3HEWsz52fQ@mail.gmail.com> <BBA47C7D-FBEC-419D-9BED-2D998EF526B0@ericsson.com>
In-Reply-To: <BBA47C7D-FBEC-419D-9BED-2D998EF526B0@ericsson.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 07 Apr 2021 10:06:37 -0700
Message-ID: <CAM4esxTR1Y8oS0UpPu2_5cnDT_tnLTM-VbknCJDyWEz=JbyUKQ@mail.gmail.com>
To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Cc: David Schinazi <dschinazi.ietf@gmail.com>, MASQUE <masque@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b83e8605bf64f487"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/DS1elshcLM33iEH9_wIO53P4kS0>
Subject: Re: [Masque] ECN & Flow IDs
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2021 17:06:55 -0000

Again, adding two bits to the datagram payload is not "simple enough" if
it's an extension.

If it's part of the CONNECT-UDP standard, then sure.

Otherwise, there is ambiguity in processing an H3 DATAGRAM frame sent by
the client before receiving the response from the server. The client can
send not-ECT or eat the 1RTT latency penalty.

With flow IDs, the proxy will simply drop the datagram, incurring a 1RTT
penalty only if it doesn't support the extension.

On Wed, Apr 7, 2021 at 10:00 AM Mirja Kuehlewind <
mirja.kuehlewind@ericsson.com> wrote:

> Hi David, hi all,
>
>
>
> to also add to your question about multiple flow IDs. I guess we kind of
> agree that we don’t want flow ID for ECN information, as adding two bits is
> simple enough, however, then it is actually not fully clear to me why
> multiple flow IDs per connect request are needed. You briefly mentioned
> other extension below, however, not all, or only very few information,
> require per-packet information (as it was used for the ECN example). If you
> want to actually send multiple flows/connections to the same server you,
> can always send multiple connect requests. That’s slightly more overhead at
> connection establishment but not much, and I would say it’s architecturally
> more clean and therefore also simpler.
>
>
>
> Mirja
>
>
>
>
>
> *From: *Masque <masque-bounces@ietf.org> on behalf of David Schinazi <
> dschinazi.ietf@gmail.com>
> *Date: *Wednesday, 31. March 2021 at 02:36
> *To: *Martin Duke <martin.h.duke@gmail.com>
> *Cc: *MASQUE <masque@ietf.org>
> *Subject: *Re: [Masque] ECN & Flow IDs
>
>
>
> The trivial other approach to solving ECN would be to prefix the UDP
> payload with a type byte that contains the two ECN bits and 6 unused bits.
>
> That would definitely work, and therefore I don't think ECN is a good
> example to use as a discussion starter for how flow IDs are managed.
>
> I wrote that draft to test out the extensibility of the CONNECT-UDP
> design, I'm not planning on moving it forward at this time.
>
>
>
> More conceptually, the main question is whether we allow one
> client-initiated bidirectional stream to map to multiple datagram flow IDs.
>
> The approach I've taken is to say yes: that allows us to reuse the flow ID
> multiplexing logic to encode additional information in the flow ID.
>
> You could build something isomorphic to this where you say no and have one
> flow ID per stream, and then add a second varint right after the flow ID.
>
> Since datagrams have to fit in a QUIC packet, adding more varints eats
> into available datagram MTU which makes me prefer the multiple flow IDs per
> stream approach.
>
> Both are pretty much equivalent in terms of implementation complexity:
> either way you need a hash table mapping from a varint to what that varint
> means.
>
> There is more complexity in how you convey that mapping (right now this is
> done using parameters on the Datagram-Flow-Id header), but I don't think
>
> requiring one flow ID per stream solves any of that complexity, you'll
> still need a way to convey extension information. The ECN example is so
> simple that
>
> it doesn't require sending much extension information, but if you look
> further at enabling optional IP header compression in CONNECT-IP, then
> you'll want
>
> a way to associate a varint with which IP addresses you're compressing.
>
>
>
> I think the question we have to answer becomes: do we want MASQUE
> protocols to be extensible? Our options are:
>
> - disallow extensibility and slightly simplify the protocol
>
> - allow extensibility via multiple flow IDs per stream, and deal with the
> slight complexity
>
> - allow extensibility with a single flow ID per stream, and deal with the
> slight complexity
>
> Personally, I feel strongly that we should allow extensibility.
>
>
>
> David
>
>
>
>
>
> On Tue, Mar 30, 2021 at 3:40 PM Martin Duke <martin.h.duke@gmail.com>
> wrote:
>
> Hello MASQUE,
>
>
>
> At IETF 110 there was a lot of good discussion challenging the foundations
> of the CONNECT-UDP framework, including the relationship between streams
> and Flow-IDs. While CONNECT-UDP happens to use flow IDs somewhat
> incidentally, the real action with the controversial
> multiple-flow-id-per-CONNECT happens in David's (unadopted) ECN draft:
> https://datatracker.ietf.org/doc/draft-schinazi-masque-connect-udp-ecn/
>
>
>
> Leading up to the interim, it would be great if one of the detractors of
> the flow-id mapping submitted their own approach to solve ECN. This would
> help to illuminate the tradeoffs. Speaking as an individual, I am also
> hoping to move the ECN work forward and having another design would help to
> do that.
>
>
>
> Thanks,
>
> Martin
>
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>
>