Subject: [Masque] HTTP/3 Datagrams Design Comparisons

From: David Schinazi <[email-masked]>
Date: Mon, 12 Apr 2021 17:50:09 -0700

Hi MASQUE enthusiasts,

At IETF 110, there seemed to be a sense in the room that multiple folks
didn't like the Datagram-Flow-Id header. In particular, the fact that it
uses an end-to-end construct (header) to convey a hop-by-hop property (flow
ID) wasn't great. So through various conversations with WG members, we came
up with a few alternative designs, with the goal to find one that fits
everyone's use-cases.

But first, let's chat about the properties we want from this system.
- intermediaries: they complicate the design but we absolutely need to
support them
- supporting multiple datagram encodings in one request: we have various
use-cases (CONNECT-UDP with added information on some packets, CONNECT-IP
with IP address compression, etc.) that require multiplexing different
encodings associated with one request
- negotiating encodings mid-tunnel: this is useful for the IP compression
use-case. Using a separate request for this purpose isn't possible because
different requests can land on different backends, and we want the tunnel
lifetime to be tied to a single request.
- extensibility: we should be able to extend CONNECT-UDP and CONNECT-IP
without having to modify intermediaries

Now let's dive into the proposed designs we have:
1) Datagram-Flow-ID header: that's what's in the draft today
<https://datatracker.ietf.org/doc/html/draft-ietf-masque-h3-datagram-00>
    Flow IDs are negotiated during the request/response and can be a list
    Pro: it's relatively simple
    Con: it doesn't support mid-tunnel encoding negotiation
    Con: it effectively uses hop-by-hop headers in h3 which is frowned upon
    Con: slightly more complex for intermediaries than proposals (3) and (4)

2) REGISTER_DATAGRAM_FLOW_ID frame: #37
<https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/pull/37>
    Flow IDs are negotiated using an HTTP/3 frame
    Pro: supports all the requirements
    Con: slightly more complex for intermediaries than proposals (3) and (4)

3) two-layer approach: #38
<https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/pull/38>
    Datagrams carry two varints: the request stream ID and a flow ID
    Intermediaries only look at the first one to route and pass through
registration unchanged
    Flow IDs are negotiated using reserved flow ID 0
    Pro: simpler to reason about
    Con: wastes a little bit of wire encoding

4) two-layer approach with REGISTER_DATAGRAM_FLOW_ID frame: #39
<https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/pull/39>
    Same as (3) but using a frame instead of flow ID 0
    Same properties as (3)

There are definitely many things we can bikeshed on all these proposals,
but let's focus on the properties we want. I think it would be great if we
managed to reach consensus on a given general approach at the interim on
Thursday. We'll be able to figure out the minor details later.

Personally, I don't have a strong preference between these designs, I just
want to ensure we build a system with the right properties.

What do folks think? Do you have any use-cases that aren't met by some of
these designs to help us rule some of them out?

David

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 13 Apr 2021 20:31:13 -0700

Hi David,

Thanks for your work on consolidating these options. It will be very fruitful for the discussion.

Largely, I think that we do have two sets of complexity that are competing here:
- One is how to make this new method work well with intermediaries doing H2 and H1 in a way that will provide the greatest chance of success;
- The other is how to let the method and use of datagrams be extensible for new end-to-end features

To that end, I think that the waste of a few bytes on the wire for options (3) and (4) here is the right trade-off to make for a clean separation of these two layers.

Between these, I prefer your option (4), since it seems cleaner to register flow IDs outside of the actual frames that contain the flow data, and it means that REGISTER_DATAGRAM_FLOW_ID frames are always reliable and DATAGRAM frames can always be unreliable. My one comment is that I’d like to see the RELIABLE_DATAGRAM frame removed as part of this, since it would not be necessary (while it is necessary in option 3). This could be an option 4a or 5?

Best,
Tommy

> On Apr 12, 2021, at 5:50 PM, David Schinazi <[email-masked]> wrote:
> 
> Hi MASQUE enthusiasts,
> 
> At IETF 110, there seemed to be a sense in the room that multiple folks didn't like the Datagram-Flow-Id header. In particular, the fact that it uses an end-to-end construct (header) to convey a hop-by-hop property (flow ID) wasn't great. So through various conversations with WG members, we came up with a few alternative designs, with the goal to find one that fits everyone's use-cases.
> 
> - intermediaries: they complicate the design but we absolutely need to support them
> - supporting multiple datagram encodings in one request: we have various use-cases (CONNECT-UDP with added information on some packets, CONNECT-IP with IP address compression, etc.) that require multiplexing different encodings associated with one request
> - negotiating encodings mid-tunnel: this is useful for the IP compression use-case. Using a separate request for this purpose isn't possible because different requests can land on different backends, and we want the tunnel lifetime to be tied to a single request.
> - extensibility: we should be able to extend CONNECT-UDP and CONNECT-IP without having to modify intermediaries
> 
> 1) Datagram-Flow-ID header: that's what's in the draft today <https://datatracker.ietf.org/doc/html/draft-ietf-masque-h3-datagram-00>
> 2) REGISTER_DATAGRAM_FLOW_ID frame: #37 <https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/pull/37>
> 3) two-layer approach: #38 <https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/pull/38>
>     Intermediaries only look at the first one to route and pass through registration unchanged
> 4) two-layer approach with REGISTER_DATAGRAM_FLOW_ID frame: #39 <https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/pull/39>
> There are definitely many things we can bikeshed on all these proposals, but let's focus on the properties we want. I think it would be great if we managed to reach consensus on a given general approach at the interim on Thursday. We'll be able to figure out the minor details later.
> 
> Personally, I don't have a strong preference between these designs, I just want to ensure we build a system with the right properties.
> 
> What do folks think? Do you have any use-cases that aren't met by some of these designs to help us rule some of them out?
> 
> David
> -- 
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 14 Apr 2021 15:00:13 +0100

Hi David,

Thanks for summarising the principles and options.

I've got some implementations of design (1) that work for my needs today
but agree that additional uses are made difficult by the cons you have
listed there.

The one thing that isn't highlighted, but comes up in the proposals, is
whether flow IDs are bidirectional or unidirectional and what that means
for extensions. We don't need to solve how extensions get negotiated right
now but assuming we eventually do, here's my understanding of how things
play out. In design (1) the flows are bidirectional, and if both client and
server agree to carrying an extension on a flow ID ( For instance, an
extension that changes how the H/3 DATAGRAM frame payload is processed. ),
agreement means they must both use it. In design option (2), flows are
still bidirectional but the use of extension is unidirectional and
unilateral. In design option (3) and (4) , flows are unidirectional and use
of extensions is unidirectional and unilateral.

I think unidirectional flows are a more powerful abstraction so I find
appeal in option (3) and (4). Of those I agree with Tommy that reliable
flow registration seems important and useful. Therefore something like
design (4) or a derivative seems like the strongest choice to me if we
decide to change.

Cheers
Lucas

On Wed, Apr 14, 2021 at 4:31 AM Tommy Pauly <tpauly=
[email-masked]> wrote:

> - One is how to make this new method work well with intermediaries doing
> H2 and H1 in a way that will provide the greatest chance of success;
> To that end, I think that the waste of a few bytes on the wire for options
> (3) and (4) here is the right trade-off to make for a clean separation of
> these two layers.
>
> Between these, I prefer your option (4), since it seems cleaner to
> register flow IDs outside of the actual frames that contain the flow data,
> and it means that REGISTER_DATAGRAM_FLOW_ID frames are always reliable and
> DATAGRAM frames can always be unreliable. My one comment is that I’d like
> to see the RELIABLE_DATAGRAM frame removed as part of this, since it would
> not be necessary (while it is necessary in option 3). This could be an
> option 4a or 5?
>
> Best,
> Tommy
>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 14 Apr 2021 10:16:25 -0400

I would prefer a variation on #4 where the frame is called something like
"COMMAND", and the exact command (e.g. REGISTER_DATAGRAM_FLOW_ID) is
immediately following.  This would clarify separation of concerns (the
command is end-to-end, so the specific command is of no interest to an
intermediary), and enable improved extensibility (future commands do not
need intermediary support).

On Wed, Apr 14, 2021 at 10:00 AM Lucas Pardue <[email-masked]>
wrote:

>> To that end, I think that the waste of a few bytes on the wire for
>> options (3) and (4) here is the right trade-off to make for a clean
>> separation of these two layers.
>>
>> Personally, I don't have a strong preference between these designs, I
>> just want to ensure we build a system with the right properties.
>>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 14 Apr 2021 07:29:02 -0700

> On Apr 14, 2021, at 7:16 AM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> I would prefer a variation on #4 where the frame is called something like "COMMAND", and the exact command (e.g. REGISTER_DATAGRAM_FLOW_ID) is immediately following.  This would clarify separation of concerns (the command is end-to-end, so the specific command is of no interest to an intermediary), and enable improved extensibility (future commands do not need intermediary support).
> 

Yes, that’s a clean solution. You’re correct that the content of the frame is not important to the intermediary—this is really just an end-to-end reliable message that carries control data associated with a stream.

Tommy

> On Wed, Apr 14, 2021 at 10:00 AM Lucas Pardue <[email-masked] <mailto:[email-masked]>> wrote:
> Hi David,
> 
> I've got some implementations of design (1) that work for my needs today but agree that additional uses are made difficult by the cons you have listed there.
> 
> The one thing that isn't highlighted, but comes up in the proposals, is whether flow IDs are bidirectional or unidirectional and what that means for extensions. We don't need to solve how extensions get negotiated right now but assuming we eventually do, here's my understanding of how things play out. In design (1) the flows are bidirectional, and if both client and server agree to carrying an extension on a flow ID ( For instance, an extension that changes how the H/3 DATAGRAM frame payload is processed. ), agreement means they must both use it. In design option (2), flows are still bidirectional but the use of extension is unidirectional and unilateral. In design option (3) and (4) , flows are unidirectional and use of extensions is unidirectional and unilateral.
> 
> I think unidirectional flows are a more powerful abstraction so I find appeal in option (3) and (4). Of those I agree with Tommy that reliable flow registration seems important and useful. Therefore something like design (4) or a derivative seems like the strongest choice to me if we decide to change.
> 
> Cheers
> Lucas
> 
> On Wed, Apr 14, 2021 at 4:31 AM Tommy Pauly <tpauly=[email-masked] <mailto:[email-masked]>> wrote:
> Hi David,
> 
>> On Apr 12, 2021, at 5:50 PM, David Schinazi <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi MASQUE enthusiasts,
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>
> 
> -- 
> Masque mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>
> -- 
> Masque mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>
> -- 
> Masque mailing list
> [email-masked]

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Wed, 14 Apr 2021 10:33:21 -0400

Hi Tommy,

Why do you want to see RELIABLE_DATAGRAM removed? I believe this is a
desirable property for both the CONNECT-UDP and IP Proxying use case, where
a peer may decide it wants to send a datagram in a reliable fashion. I
believe we've already indicated this is a desirable feature in previous
meetings, so I'm a bit confused why you want to see it removed.

Sincerely,
-Alex

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 14 Apr 2021 15:42:32 +0100

On Wed, Apr 14, 2021 at 3:29 PM Tommy Pauly <[email-masked]> wrote:

> On Apr 14, 2021, at 7:16 AM, Ben Schwartz <
> bemasc=[email-masked]> wrote:
>
> Yes, that’s a clean solution. You’re correct that the content of the frame
> is not important to the intermediary—this is really just an end-to-end
> reliable message that carries control data associated with a stream.
>

 Something like that sounds fine to me.

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 14 Apr 2021 08:03:38 -0700

Mainly for simplicity, although if people have a strong need for it, we can keep it in.

The notion of having a reliable datagram sounds like an extension for a relatively niche use-case to me. Part of the point of CONNECT-UDP and CONNECT-IP is to remove the need for nested reliability, and generally the applications on top should remain assuming that their transport isn’t adding redundant reliability. Personally, if we need reliable data associated with a stream, I’d be inclined to just use a normal H3 data frame, which already has this function, rather than creating a new frame that also means “reliable data on the stream”.

Best,
Tommy

> On Apr 14, 2021, at 7:33 AM, Alex Chernyakhovsky <achernya=[email-masked]> wrote:
> 
> Hi Tommy,
> 
> Why do you want to see RELIABLE_DATAGRAM removed? I believe this is a desirable property for both the CONNECT-UDP and IP Proxying use case, where a peer may decide it wants to send a datagram in a reliable fashion. I believe we've already indicated this is a desirable feature in previous meetings, so I'm a bit confused why you want to see it removed.
> 
> Sincerely,
> -Alex
> 
> On Tue, Apr 13, 2021 at 11:31 PM Tommy Pauly <tpauly=[email-masked] <mailto:[email-masked]>> wrote:
> Hi David,
>

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Wed, 14 Apr 2021 12:18:59 -0400

Hi Tommy,

> Part of the point of CONNECT-UDP and CONNECT-IP is to remove the need for
nested reliability

I don't quite agree with this framing. In my opinion, it's removing the
need for *mandatory* nested reliability. If an application would like to
opt into QUIC's reliable transport for a datagram-like message, it
should be able to do so.

> inclined to just use a normal H3 data frame, which already has this
function

Sure, but I think we still need to describe a framing for H3-datagram over
this functionality.

Sincerely,
-Alex

On Wed, Apr 14, 2021 at 11:03 AM Tommy Pauly <tpauly=
[email-masked]> wrote:

> The notion of having a reliable datagram sounds like an extension for a
> relatively niche use-case to me. Part of the point of CONNECT-UDP and
> CONNECT-IP is to remove the need for nested reliability, and generally the
> applications on top should remain assuming that their transport isn’t
> adding redundant reliability. Personally, if we need reliable data
> associated with a stream, I’d be inclined to just use a normal H3 data
> frame, which already has this function, rather than creating a new frame
> that also means “reliable data on the stream”.
>
> Best,
> Tommy
>
> On Apr 14, 2021, at 7:33 AM, Alex Chernyakhovsky <
> achernya=[email-masked]> wrote:
>
> Hi Tommy,
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 14 Apr 2021 09:53:12 -0700

> On Apr 14, 2021, at 9:18 AM, Alex Chernyakhovsky <achernya=[email-masked]> wrote:
> 
> Hi Tommy,
> 
> > Part of the point of CONNECT-UDP and CONNECT-IP is to remove the need for nested reliability
> 
> I don't quite agree with this framing. In my opinion, it's removing the need for *mandatory* nested reliability. If an application would like to opt into QUIC's reliable transport for a datagram-like message, it should be able to do so.
> 
> > inclined to just use a normal H3 data frame, which already has this function
> 
> Sure, but I think we still need to describe a framing for H3-datagram over this functionality.

That could be left to individual methods (like CONNECT-UDP) or extensions to define how they want to use their reliable DATA frames. The document at hand here is about defining how H3 DATAGRAMs work in general, and how to ensure that intermediaries can correctly route the frames. I’m fine defining this reliable proxying mode, but I think it belongs at the method layer, not at the generic H3 datagram layer.

Thanks,
Tommy
> 
> Sincerely,
> -Alex
> 
> On Wed, Apr 14, 2021 at 11:03 AM Tommy Pauly <tpauly=[email-masked] <mailto:[email-masked]>> wrote:
>> On Apr 14, 2021, at 7:33 AM, Alex Chernyakhovsky <achernya=[email-masked] <mailto:achernya=[email-masked]>> wrote:
>> 
>> Hi Tommy,
>>

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 14 Apr 2021 18:08:19 +0100

Hey,

On Wed, Apr 14, 2021 at 5:53 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

>
>
> That could be left to individual methods (like CONNECT-UDP) or extensions
> to define how they want to use their reliable DATA frames. The document at
> hand here is about defining how H3 DATAGRAMs work in general, and how to
> ensure that intermediaries can correctly route the frames. I’m fine
> defining this reliable proxying mode, but I think it belongs at the method
> layer, not at the generic H3 datagram layer.
>

I was typing something but Tommy beat me to it.

Defining how to send "messages" inside HTTP is useful, in such a design
there is a logical HTTP message flow that can be mapped a few ways. The
most native mapping is to use this HTTP/3 DATAGRAM spec, which focuses on
how to use QUIC's DATAGRAM feature. Another mapping could define how to use
something like Stream Chunks or framed HTTPcontent, which IMO is better
defined in a different document. A document like CONNECT-UDP would define
that encapsulated data is sent in "HTTP messages" and then leave the
details of how that happens to those mapping documents.

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Wed, 14 Apr 2021 13:14:24 -0400

I do not feel strongly if it should be in the same or separate documents,
but I agree that CONNECT-UDP and any other method we develop should not
have to reinvent their own mechanisms and should have 1 or more
documents to cite.

Sincerely,
-Alex

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 15 Apr 2021 06:08:56 -0700

One additional question about option 4 (and variants thereof):

In today’s current design, there is the very useful property that any extension’s use of a flow mapping must be accepted by the peer, and can be rejected. For example, in quic-aware, we let the connection ID mapping be accepted or rejected by the proxy on a per-request basis. 

It wasn’t clear to me that the request flow ID frame would support the same thing. Is the idea that if this is desired, an extension would specify that the peer would echo with their own request to confirm? Can we make this more explicit?

Best,
Tommy

> On Apr 13, 2021, at 8:31 PM, Tommy Pauly <[email-masked]> wrote:
> 
> Hi David,
>

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 15 Apr 2021 10:08:59 -0400

On Thu, Apr 15, 2021 at 9:09 AM Tommy Pauly <tpauly=
[email-masked]> wrote:

> In today’s current design, there is the very useful property that any
> extension’s use of a flow mapping must be accepted by the peer, and can be
> rejected. For example, in quic-aware, we let the connection ID mapping be
> accepted or rejected by the proxy on a per-request basis.
>

If the supported extensions are announced/negotiated in the request and
response, do you still think it's important to have a flow registration
rejection signal?

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 15 Apr 2021 08:24:48 -0700

> On Apr 15, 2021, at 7:08 AM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> 
> On Thu, Apr 15, 2021 at 9:09 AM Tommy Pauly <tpauly=[email-masked] <mailto:[email-masked]>> wrote:
> If the supported extensions are announced/negotiated in the request and response, do you still think it's important to have a flow registration rejection signal?

Yes, I do think we need this capability. It’s one thing to negotiate that your implementation supports a given extension. That does not mean that every request associated with that extension will succeed. This is equivalent to saying that just because you support CONNECT-UDP doesn’t mean that every CONNECT-UDP request will have a successful 200 response!

In the QUIC-aware case, this is about settings up connection ID mappings. It’s possible for the connection ID the client sends to create a conflict or be invalid, so the proxy can reject it.

Even beyond that, if you imagine that we’ll use these control messages to set up new flow IDs for different IP tunnel traffic selectors, compression mechanisms, etc, we should handle the ability to send an error or respond with what was actually chosen. For example, if we compare to IKEv2, where the VPN can exchange what traffic selectors (routes/addresses/etc) are supported for a given association (like a flow), there’s a request that says what the initiator wants to include, but the peer can respond to either reject it, or reduce the included routes if they violate policy or would create conflicts.

Best,
Tommy

---

From: Ian Swett <[email-masked]>
Date: Thu, 15 Apr 2021 11:57:22 -0400

In regards to a variant of option 4:

There are use cases that don't need the extra level of multiplexing
provided by flow IDs, can we allow it to be unused, saving a varint and
making the flow registration an optional feature?

If an application has a fixed use of flow IDs, and that is specified by the
application, is the flow registration/etc unused?  Or maybe that's a
variant of the case when the flow ID functionality being described isn't
used, since part of the payload from H3-datagram's perspective?

I think as long as using flow IDs is optional on a per-application basis,
then I think this is a good design direction.

Ian

On Thu, Apr 15, 2021 at 11:25 AM Tommy Pauly <tpauly=
[email-masked]> wrote:

>
>
> On Apr 15, 2021, at 7:08 AM, Ben Schwartz <
> Yes, I do think we need this capability. It’s one thing to negotiate that
> your implementation supports a given extension. That does not mean that
> every request associated with that extension will succeed. This is
> equivalent to saying that just because you support CONNECT-UDP doesn’t mean
> that every CONNECT-UDP request will have a successful 200 response!
>
> In the QUIC-aware case, this is about settings up connection ID mappings.
> It’s possible for the connection ID the client sends to create a conflict
> or be invalid, so the proxy can reject it.
>
> Even beyond that, if you imagine that we’ll use these control messages to
> set up new flow IDs for different IP tunnel traffic selectors, compression
> mechanisms, etc, we should handle the ability to send an error or respond
> with what was actually chosen. For example, if we compare to IKEv2, where
> the VPN can exchange what traffic selectors (routes/addresses/etc) are
> supported for a given association (like a flow), there’s a request that
> says what the initiator wants to include, but the peer can respond to
> either reject it, or reduce the included routes if they violate policy or
> would create conflicts.
>
> Best,
> Tommy
>
>
> --
> Masque mailing list
> [email-masked]

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 15 Apr 2021 17:19:37 +0100

On Thu, Apr 15, 2021 at 4:57 PM Ian Swett <ianswett=
[email-masked]> wrote:

> If an application has a fixed use of flow IDs, and that is specified by
> the application, is the flow registration/etc unused?  Or maybe that's a

Another way to rephrase this (I think) is, can we omit sending a flow ID
field when the flow ID is 0? A Register command could still state flow ID 0
to make it unambiguous if an extension applies, sender/receiver just don't
need the value on the wire.

Cheers,
Lucas

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Apr 2021 09:43:33 -0700

re: Tommy & Ben

    I think there is an interesting point there about whether we need to
give endpoints the ability to accept/reject flow ID registrations. I've
added a slide about this to discuss at the interim later today.

re: Ian & Lucas

    Making this optional is interesting, but I don't know how to negotiate
whether it's there or not if it's optional. Lucas, how do you know if the
varint is there or not? (We don't want to break false start) I've also
added a slide to discuss this today

I'll file GitHub issues after today's interim so we can keep track of these
conversations in individual threads

David

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 15 Apr 2021 17:55:01 +0100

HI

> added a slide to discuss this today

Very good question. In a model where a user *has* to register for the flow
to do anything, something that could be done is a split mode

* REGISTER_SINGLE - only one flow is allowed per request, flow is logically
0 but DATAGRAMs do not contain a flow ID.
* REGISTER_ONE_OF_MANY - multiple flows per request. Flow is explicitly
signalled, all DATAGRAMs contain a flow ID. Can use this to register a
single flow if you don't know you need more later on.

The first case reduces to something like we have today.

I don't think this breaks TFO because the "ends" that issue and process the
REGISTER_SINGLE know what is supposed to happen. Intermediaries don't need
to know and can just forward DATAGRAMS.

Cheers
Lucas

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 15 Apr 2021 13:24:08 -0400

On Thu, Apr 15, 2021 at 12:43 PM David Schinazi <[email-masked]>
wrote:
...

> added a slide to discuss this today

My thought is: you know whether the varint is there based on the method.
CONNECT-UDP uses Flows, so the Flow ID is there.  Some future HTTP method
might not need multiple flows, in which case the client and server will
know that there is no Flow ID.

I don't think the gain of saving one byte in some cases is worth the added
complexity of supporting both modes for CONNECT-UDP.

>>> I think as long as using flow IDs is optional on a per-application
>>> basis, then I think this is a good design direction.
>>>
>>

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Apr 2021 10:25:59 -0700

Oh nice, I like that idea Lucas, thank you! I've added it to the slides to
discuss today.

On Thu, Apr 15, 2021 at 9:55 AM Lucas Pardue <[email-masked]>
wrote:

>>     Making this optional is interesting, but I don't know how to
>> negotiate whether it's there or not if it's optional. Lucas, how do you
>> know if the varint is there or not? (We don't want to break false start)
>> I've also added a slide to discuss this today
>>
>
> * REGISTER_SINGLE - only one flow is allowed per request, flow is
> logically 0 but DATAGRAMs do not contain a flow ID.
> I don't think this breaks TFO because the "ends" that issue and process
> the REGISTER_SINGLE know what is supposed to happen. Intermediaries don't
> need to know and can just forward DATAGRAMS.
>
> Cheers
> Lucas
>
>

---

From: Ian Swett <[email-masked]>
Date: Thu, 15 Apr 2021 17:18:20 -0400

I think Lucas' suggestion is good, though if there's already another
indication of the method/application, and it's expected intermediaries will
treat flow IDs as opaque, since they all route to the same location, I'm
not sure what the standardized indication accomplishes?  No objection to
it, I'm just unsure who would be looking at it?

For example, if WebTransport only uses one flow, as is the current design,
then it wouldn't need Flow ID and one would know that because it's a
WebTransport session.  One could add an extra indication, but that only
adds another potentially illegal operation I believe?

Part of my reason for asking for this is that I would prefer a design where
intermediaries are looking at as little payload as possible, and if it's
clearly unnecessary and potentially dangerous to look at the location where
the Flow ID would be without understanding the application, then I expect
they won't.

Ian

On Thu, Apr 15, 2021 at 1:26 PM David Schinazi <[email-masked]>
wrote:

>> Very good question. In a model where a user *has* to register for the
>> flow to do anything, something that could be done is a split mode
>>

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 15 Apr 2021 23:04:48 +0100

Hi Ian,

On Thu, 15 Apr 2021, 22:18 Ian Swett, <[email-masked]> wrote:

> Part of my reason for asking for this is that I would prefer a design
> where intermediaries are looking at as little payload as possible, and if
> it's clearly unnecessary and potentially dangerous to look at the location
> where the Flow ID would be without understanding the application, then I
> expect they won't.
>

That's a fair point and echo's what Ben said during the MASQUE interim
meeting. I think there are options here.

I think what you describe is fine, iff at the time a request arrives, the
expectations of use are set out. So some of the design choices here depend
on how extensions get negotiated, that seems to be a per request property
once we add in the potential for intermediaries.

Cheers
Lucas