Re: [Masque] ECN & Flow IDs

[Martin Duke <[e-mail]>]

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