Re: [Masque] ECN & Flow IDs

[Alex Chernyakhovsky <[e-mail]>]

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