WEBTRANS Interim

2024-02-22 (or 2024-02-23)

W3C Update

Jan-Ivar Bruaroey (jib)

Two things to discuss with IETF dependencies

Issue 411 - Keying material exporters

Request to IETF to change the interface.

Victor V: What this would do depends on what the application needs to
do.

jib: Not looking to design an API, just to agree on mechanism.

david: There is a proposed design on the issue.

Issue 580 - DataRecvd state dependency

jib: Holding streams available until data is received can be useful for
implementing a form of partial reliability.

victor: We have to tell the upper layers when the stream transitions
from a state where you sent FIN, but you can still reset, and when there
is no further prospect of being able to send a reset.

Eric Kinnear: is the idea to add a new state, or expose the existing
one?

victor: rename the states perhaps - for h3 use DataRecvd and for h2
something else

martin: discussion about distinction between h2 and h3 and what point
things are considered "done"

victor: takes action to open an issue on this

(other note fork)

#580 Data Received State
MT: For H3 you can abort retransmissions if packets are lost, but in H2
once you've committed data into the pipe there's no way to go back.
Victor: In H2, you can also still write ahead of flow control, so it's
not entirely meaningless, but potentially still less effective.
MT: Promise resolution on writes would happen once data has been
committed to the network, so a client that respects backpressure would
not have anything outstanding from a flow control perspective. Some
clients just ignore that, of course. Have previously made decision to
not drive this from acknowledgements, etc. More work required to specify
exactly what this would mean for each mapping.

Action: Victor to file issue to track that work on the IETF side.

MAX_STREAMS and Flow Control

A: Do nothing
B: Hint (server sends either MAX_TOTAL or MAX_PER_SESSION+MAX_HTTP)

C: QUIC-level partitioning
D: An additional layer of flow control at the WT session level

Lucas: Something mandatory is what I would desire. Hints don't seem to
work because you can't guarantee that a new implementation would work.

David: QUIC changes means opening up the design space. Expediency
suggests doing things in WT.

Lucas: Doing it here seems better. Maybe in the future we can take this
into the transport layer.

Martin: Do the work here, not QUIC. Make it mandatory.

Victor: Take either 1 or 2 of the options (mandatory or mandatory
conditional on pooling). Which of those options determines what I think
about the A/B/C/D choice.

Eric: Doing it here is fine. If QUIC builds a mechanism that we could
use, we can revise WT to pick that up. Some value in sharing mechanisms
between h2 and h3. Having it mandatory, especially for intermediaries,
is useful. That means that you can guarantee that participants will
respect your limits.

Bernard: Agree to do this work here. Preference is only to make it
mandatory if pooling.

Martin: Argues for 1 over 2. HTTP needs to share with WT.

Eric: in terms of 1 vs 2, I'm in a similar place. Having it be mandatory
is not a huge lift

Victor: more in support of 2 than 1 because its easier for implementers,
especially those that don't want pooling. From practical point of view,
option one might not work because there are already deployments of
existing spec without this complication

David: are you saying browsers wouldn't update?

Victor: more about the servers.

David: browsers have ability to deprecate

Victor: subject to web compat

Alan: do we have a good understanding of what pooling means. Is it only
WebTransport or is it HTTP too

David: my understanding, any time the WebTransport session has something
else on the connection

Alan: ok. weh nwe talk about what browsers have implemented, nobody has
implemented pooling?

David: as far as I am aware

Bernard: I beleive you're correct David

Alan: not sure how many server implementations of WebTransport there
are. Do those people have WebTransport and QUIC implementations.

Bernard: some have earlier implementaions

Alan: that's true for ours

Victor: there is a definition. once we create a WebTransport session it
has it's own connection. What would happen when we allow pooling, step 1
is having a generic create HTTP/3 connection. Then we'll try and
negotiatite WebTransport with pooling. If server says yes we can mark
that. On servers, there is a way to enforce no pooling. There are some
control streams still but they don't particularly affect flow control

Eric: when talking about previous versions, there's a huge amount that's
different. I'm not sure I would let old versions have too much influence
of decisions we make. Victor's point about server making decisions about
what to accept. Can limit pooling or flow control to 1 still. Not sure
its a huge factor in ddeciding if this should be mandatory or not.

Victor: actually only 2 backwards-incompatible changes. Long story of
vendors introducing APIS, adding a new version that adds more
complexity, and then not being able to unship the simpler thing.

David: as individual, on topic of servers disabling pooling, pretty
straightforward to put server on separate hostname. But that still might
consume credits, nevermind...

David: I've heard support for 1 and 2, doesn't seem like clear winner.
Let's change gears to talk about proposals again. Any strong feelings?

Victor: if mandatory: B and then A. If it is , then B and D is fine. ()

Bernarnd: I agree with Victor, if non-mandatory B and D. Otherwise A.

Victor: I want to clarify about complexity. Previously, the only way to
do unreliable data was WebRTC. Requires lot of services and parts.
People find RTCDataChannel unsatisfactory. WebTransport motivation was
largely to define something simpler and to have increased server-side
diversity. Would liek to avoid repeating situation with RTCDataChannel

Eric: on one hand good to reduce complexity. One reason people use
WebSockets is that it's there. And a big part of that is becuase there
is server diversity. WebSocket is also there because it doesn't do
things that are as complex as other things. Not sure there is that much
complexity difference between B and D. Server cares about flow control
becuase it also needs to care about number of clients etc. I think we've
established option A is not suitable. I think where we land is that D is
the best option. C is nice architecturaly but lets not try to be
perfect.

David: sense that if we want pooling, D is looking like a winner

Alan: I'm not going to disagree. Don't want A. Don't think C is the
right thing today. In terms of complexity and success of WebTransport -
I don't think flow control is a barrier. Shouldn't be visible to
developers, only the folks on this call. I think Eric is the only person
that implemented this and he says its not too hard. Maybe if we pick D,
it will force the others to implement it and we can understand if they
foudn it hard or not

Eric: to speak to implementation - we have prototypes, not finished
HTTP/3 stuff. That said, wrt flow control there are complexities but
some of those things have to be handled anyone. The same thought is
required for this as the rest of the stuff.

David: sense I'm getting is everyone could live with D and some would
like it. So assuming option D, looking at slide 41 (timeliness) - is 2
plus D livable

Victor: I could live with ti. But wrt server implementations, some
people say its ok to make HTTP/3 more complex because there's only like
10 people that would implement. There's like 100 WebSocket
implementations. HTTP/3 is harder anyone because of QPACK, as I've
historically complained.

Eric: amending prior comment. I had a slight preference for 1, but if we
land on 2 plus D, that's ok

Bernard: I like 2 plus D as well. There's a few server implementations
that don't do pooling. So we wouldn't upset them by making flow control
mandatory

Victor: comment on complexity. Not only comes from sending frames and
doing accounting - instead you now have QUIC buffer and WebTransport on
top needs to interact. There are are compolications with stream state
management that might not be apparent, the more I think about it there
are some rough edges

Alan: curious what option 1 is if you weren't pooling, just set a big
number?

David: on receiver can set "infinite" but complication on the sender.
Requires buffering or management to respect peer's limit

Eric: can't unilaterally opt-out. Problem exists with or without pooling
though. Option 2 doesn't make life drastically easier. But if we
discover its drastically painful to implement, that's part of the IETF
process.

Alan: feeling is we shouldn't ship this without some interoperable
implementations of pooling.

David: we won't WGLC until we're ready

Lucas: restricitng to hostnames can be difficult

David: we can use a setting!

David: we will send 2 plus D for a consensus call to the list.

AOB

End of session. Hallway discussion about QUIC over streams and
WebTransport over HTTP/2

Chaff