Re: [Masque] ECN & Flow IDs

[Mirja Kuehlewind <[e-mail]>]

I wouldn’t call that a decent solution as there is work underway to make all packets ECN capable. This is especially important  since losing the first packet of a connection usually has a higher delay penalty than any other packet.


From: Masque <[e-mail]> on behalf of David Schinazi <[e-mail]>
Date: Sunday, 4. April 2021 at 23:19
To: Martin Duke <[e-mail]>
Cc: Alex Chernyakhovsky <[e-mail]>, MASQUE <[e-mail]>
Subject: Re: [Masque] ECN & Flow IDs

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]<mailto:[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]<mailto:[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<https://protect2.fireeye.com/v1/url?k=408475ca-1f1f4cab-40843551-86d8a30ca42b-3047b2712c0c3067&q=1&e=090bd79d-94f2-4b16-9aa9-8dcf0b51791f&u=https%3A%2F%2Fgithub.com%2Fietf-wg-masque%2Fdraft-ietf-masque-h3-datagram%2Fissues%2F35>) 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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/masque
--
Masque mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/masque