Re: [Masque] ECN & Flow IDs

[David Schinazi <[e-mail]>]

You can't use SETTINGS for negotiating CONNECT-UDP extensions because
SETTINGS are per-hop and methods are end-to-end.

David

On Thu, Apr 15, 2021 at 9:03 AM Martin Duke <[e-mail]> wrote:

> Hi Alex,
>
> Thanks for clarifying. IIUC one objective of David's design is to not
> advertise MASQUE capabilities quite so explicitly, which is a drawback of a
> SETTINGS-based mechanism.
>
> On Thu, Apr 8, 2021, 16:36 Alex Chernyakhovsky <[e-mail]>
> wrote:
>
>> Hi Martin,
>>
>> Yes, I was imagining that the presence if this extension is negotiated,
>> possibly by way of SETTINGS. Any
>>
>> Sincerely,
>> -Alex
>>
>> On Thu, Apr 8, 2021 at 4:29 PM Martin Duke <[e-mail]>
>> wrote:
>>
>>> Hi Alex,
>>>
>>> I'm not sure what you mean by "sending the 1RTT value" but IIUC you're
>>> proposing that the proxy drops all payloads if it doesn't understand the
>>> extension? How would it know when DATAGRAMs transfer from the extension
>>> format to the non-extension format?
>>>
>>> Or are you saying this would be a connection-level capability negotiated
>>> by SETTINGS or something?
>>>
>>> On Thu, Apr 8, 2021 at 7:29 AM Alex Chernyakhovsky <[e-mail]>
>>> wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> There's a few issues with your example, which is namely that step (4)
>>>> should not occur. The extension needs to be pre-declared, or else the proxy
>>>> does as you describe and we have undefined behavior. I instead was
>>>> imagining a header (or some other signalling mechanism) that says "we want
>>>> to use ecn extension" and when the proxy gets its first payload after that
>>>> header, it drops it because it doesn't know about the extension and replies
>>>> back that it doesn't support it. The client then has to send the 1RTT
>>>> value. You end up with the same behavior as David's draft.
>>>>
>>>> of course, we can also fix this more explicitly in the CONNECT-UDP
>>>> draft by creating another stream-chunk type for UDP packet with additional
>>>> data for extensions in addition to the packet. Then all a proxy has to know
>>>> is there's data it doesn't support, and it just doesn't read and act upon
>>>> it when sending the packet payload.
>>>>
>>>> Sincerely,
>>>> -Alex
>>>>
>>>> On Wed, Apr 7, 2021 at 2:21 PM Martin Duke <[e-mail]>
>>>> wrote:
>>>>
>>>>> Alex,
>>>>>
>>>>> Maybe I'm missing something obvious, but here's an example.
>>>>>
>>>>> Let's say that the "ecn" extension means the first octet of the
>>>>> datagram after the flow ID is the ToS byte.
>>>>>
>>>>> 1. The client sends a CONNECT-UDP request with the "ecn" extension
>>>>> 2. The client sends a datagram with the second byte reflecting the ToS.
>>>>> 3. The proxy does not understand the ecn extension and ignores it
>>>>> 4. The datagram arrives; the proxy sends a UDP packet with the ToS
>>>>> byte as the first byte of payload.
>>>>> 5. The client receives the response without the "ecn" extension and
>>>>> stops sending the ToS byte.
>>>>>
>>>>> In #4 we're going to have some weird undefined behavior.
>>>>>
>>>>> Compare this to David's draft
>>>>>
>>>>> 1. The client sends a CONNECT-UDP (flowID = 12) request with the "ecn"
>>>>> extension (flowID = 16 for ECT(0))
>>>>> 2. The client sends a datagram with flowID = 16
>>>>> 3. The proxy does not understand the ecn extension and ignores it
>>>>> 4. The datagram arrives; the proxy drops flowID 16 because it doesn't
>>>>> know what that is
>>>>> 5. The client receives the response without the "ecn" extension and
>>>>> stops sending flowID 16.
>>>>>
>>>>> packet losses aren't great, but are better than undefined behavior.
>>>>>
>>>>> On Wed, Apr 7, 2021 at 10:53 AM Alex Chernyakhovsky <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> 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 <[e-mail]>
>>>>>> 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 <
>>>>>>> [e-mail]> 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 <[e-mail]> on behalf of David
>>>>>>>> Schinazi <[e-mail]>
>>>>>>>> *Date: *Wednesday, 31. March 2021 at 02:36
>>>>>>>> *To: *Martin Duke <[e-mail]>
>>>>>>>> *Cc: *MASQUE <[e-mail]>
>>>>>>>> *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 <
>>>>>>>> [e-mail]> 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
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/masque
>>>>>>>>
>>>>>>>> --
>>>>>>> Masque mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/masque
>>>>>>>
>>>>>>