2-layer design

[DavidSchinazi]

During the 2021-04 MASQUE Interim, we discussed a design proposal from @bemasc to replace the one-layer flow ID design with a two-layer design. This design replaces the flow ID with two numbers: a stream ID and a context ID. The contents of the QUIC DATAGRAM frame would now look like:

HTTP/3 DATAGRAM Frame {
  Stream ID (i),
  Context ID (i),
  HTTP/3 Datagram Payload (..),
}

While the flow ID in the draft was per-hop, the proposal has better separation:

• the stream ID is per-hop, it maps to an HTTP request
• the context ID is end-to-end, it maps to context information inside that request

Intermediaries now only look at stream IDs and can be blissfully ignorant of context IDs.

In the room at the 2021-04 MASQUE Interim, multiple participants spoke in support of this design and no one raised objections. This issue exists to ensure that we have consensus on this change - please speak up if you disagree.

[martinduke]

I am fine with the 2-layer design for CONNECT-UDP, but I am not sure if the second identifier should be in H3 DATAGRAM or should be specific to CONNECT-UDP. As I indicated to the list, webtrans and httpbis might weigh in on this with broader consideration of other use cases.

[DavidSchinazi]

Hi @martinduke the topic of the optionality of context IDs is discussed in issue #45.

[ianswett]

I think this is a good design, because it minimizes the core functionality of the draft, but avoids every application that needs multiple dynamically created sub-flows from re-inventing a different mechanism.

Nit: I would not call this a 'Frame', since it's not an HTTP(TLV) frame.