Re: [Masque] ECN & Flow IDs

[David Schinazi <[e-mail]>]

Martin, your understanding matches mine. I think using RFC3168-style ECN
(where the client's first flight isn't ECN-Capable) seems like a decent
solution here.

David

On Sat, Apr 3, 2021 at 1:37 PM Martin Duke <[e-mail]> wrote:

> There's a problem with ECN (and anything else) that is both an extension
> and implies a different datagram format: IIUC, you are likely to add 1RTT
> of latency.
>
> For example, with ECN, say there was just an "ecn" header field that mean
> the first byte was the TOS byte. If the server doesn't understand the
> extension, then datagrams that arrive before the response will be
> incorrectly parsed. It is therefore unsafe to send packets before the
> capability if fully negotiated.
>
> With David's design, datagrams with ECT(0) are simply dropped by the
> proxy, because it doesn't have a mapping for the flow ID. To avoid loss,
> the client can simply send Not-ECT until it gets a response. This isn't a
> great outcome, but far better than always having to withhold the
> first flight.
>
> Am I misunderstanding how this would work in practice?
>
> On Tue, Mar 30, 2021 at 7:31 PM Alex Chernyakhovsky <[e-mail]>
> wrote:
>
>> I don't think ECN is a good example for discussing datagram flow IDs. I
>> have a github issue (
>> https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/issues/35)
>> out to remove the ECN example. (I much prefer passing the ECN information
>> in the datagram payload, prefixed ahead of the packet as David describes).
>>
>> In addition to the issues that David describes, I think we should also
>> consider whether the Datagram-Flow-Id header is a list separately from
>> whether we allow a 1:many mapping between streams and datagram flow IDs. (I
>> would like to make sure we do not have a many:many or many:1 mapping where
>> multiple streams are responsible for multiple datagram flow IDs)
>>
>> Sincerely
>> -Alex
>>
>> On Tue, Mar 30, 2021 at 8:36 PM David Schinazi <[e-mail]>
>> wrote:
>>
>>> 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
>>>
>>