Re: [Masque] ECN & Flow IDs

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).
>

Imagine an extension to CONNECT-IP that allows compressing IP addresses.
That would change the datagram format.

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.
>

That wouldn't work because two separate requests have (a) different
lifetimes and (b) can land on different HTTP backends.

David

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
>
>