Re: [Masque] ECN & Flow IDs

Hi Martin,

What's stopping the client from opportunistically sending the packet with
the extension in the same flight as requesting the extension? Then you'd
at-best get the expected behavior and at-worst fall back to the
1RTT penalty.

Sincerely,
-Alex

On Wed, Apr 7, 2021 at 1:07 PM Martin Duke <martin.h.duke@gmail.com> wrote:

> 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
>>
>> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>