Re: [Masque] ECN & Flow IDs

On Thu, Apr 8, 2021 at 1:56 AM Mirja Kuehlewind <
mirja.kuehlewind@ericsson.com> wrote:

> Hi David,
>
>
>
> please see inline.
>
>
>
> *From: *David Schinazi <dschinazi.ietf@gmail.com>
> *Date: *Wednesday, 7. April 2021 at 19:53
> *To: *Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
> *Cc: *MASQUE <masque@ietf.org>
> *Subject: *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.
>
>
>
> For compression I would usually think that things are negotiated on a per
> connect association basis and that you doesn’t necessarily need to provide
> any information on a per packet basis. However, if there are any per packet
> information needed, you can always add another extension specific field
> after the flow ID.
>
>
>
> 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.
>
>
>
> If you have two different UDP “connections” without a proxy in between,
> this is the same, no? Maybe we are talking about different scenarios here?
>

If it's the same "connection" (let's say different ECN values for the same
UDP "connection", or different compression contexts for the same IP tunnel)
then you need to go through the same backend. That's why you need a way to
use multiple encodings in one "connection".

David

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