Re: [Masque] ECN & Flow IDs

[Martin Duke <[e-mail]>]

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