Minutes IETF117: webtrans: Thu 20:00
minutes-117-webtrans-202307272000-01
Meeting Minutes | WebTransport (webtrans) WG | |
---|---|---|
Date and time | 2023-07-27 20:00 | |
Title | Minutes IETF117: webtrans: Thu 20:00 | |
State | Active | |
Other versions | markdown | |
Last updated | 2023-08-04 |
IETF 117 WEBTRANS WG Agenda
Date: Thursday, July 27, 2023
Time: 13:00 - 15:00 Pacific Time
Session II, Plaza A
Chairs: Bernard Aboba and David Schinazi
Note taker: Nidhi Jaju
IETF 117 info: https://www.ietf.org/how/meetings/117/
Notes: https://notes.ietf.org/notes-ietf-117-webtrans
Meeting URL: https://meetecho.ietf.org/conference/?group=webtrans
Slides:
https://docs.google.com/presentation/d/1oBHF7awsLIzQON_9O4SBMM6Fss1YuAUPuVJnLvR4I1w/
Preliminaries, Chairs (15 minutes)
Note Well(s), Note Takers, Participation hints
Speaking Queue Manager (David Schinazi)
Agenda Bash
Hackathon Interop Report
Alan: New draft called devious-baton-protocol which can be run over WT
to exercise streams and datagrams, there were three or four
implementations that had at least some degree of interop with each
other. Lucas has one, I have one, Victor, and Christian has one, and
then a Javascript one.
W3C WebTransport Update, Jan-Ivar Bruaroey & Will Law
Jan-Ivar: Firefox 114 now has WebTransport!
- Congestion control is CUBIC
- Protocol implementation is largely in Rust as part of our neqo http3
support - Passes 551 / 594 web-platform tests
- A few features haven’t landed yet: sendOrder support, getStats
Current issues of debate:
Priority Groups (#515)
Mo Zanaty: We're missing that the these applications will have a
combination of transport types. Hard to bridge the gap between
application-limited media types and flows that can immediately saturate
the link. What are the application needs and how do we carve out a
policy for each when queueing? We may need different priorities and
queueing disciplines for them. I'm actually working on a priority draft,
more specifically for MoQ, but it should apply to WebTransport and HTTP
streams as well. Hopefully it will be ready soon and feedback would be
appreciated.
Alan Frindell: My concern is that it's going to be challenging to come
up with an API for priorities that will meet every application's needs
for applications that haven't been written yet. You need to be generic
enough, and we've been doing h2, h3 priorities and we're still
iterating. I think the best bet is to probably make something very
simple that people can easily understand what they're trying to do. Also
create something that is an upcall or some way to ask JS what to send
next, so we can defer some of those choices to the application without
needing to perfect the API between the application and the transport. I
don't think you're going to get one API that covers everything without
running into issues.
Will: From the W3C group side, not trying to make a perfect API. Would
you still consider send order to be optional and something that should
be supported? Do you think groups are reasonable?
Alan: Send order seems simple enough to understand. I haven't ever
written an application to try to use it or measure if it's actually able
to capture the application's intent. It's easy enough to implement a
queue that way when you're sending. I couldn't say that it is going to
work, there is a time where we got together and thought the hierarchical
tree would be the greatest thing ever, once we used it we saw that it
was really hard to capture the application intent. I think send order is
probably fine, I haven't thought a lot about groups, but it seems like
it might be okay. You are almost guaranteed to find at least some
application for whom it doesn't work, that's why I'm thinking it might
be better to try to force everything back to the application.
Marten Seeman: Looking RFC9218, there's an incremenetal flag. Wondering
if there's a need to define a new thing if we can use that.
Will: I think for compatibility, it seems there would be, so that's a
good suggestion.
Victor Vasiliev: I don't think we need incremental when you have uint64
priorities because you can just order things the way you need to.
Regarding the upcall that Alan mentioned, that would be the ideal
solution, but it's not feasible to have an upcall in JS for every
packet, because it will make your network stack perform extremely
slowly, at least by my current estimates. I have considered various
solutions, one of which was a terrible thing called WebBPF, but in
general I feel like the solution that is currently on the slide that
tries to accomodate two problems, while being as simple as possible,
restrict the order of streams and pass along carve-outs between streams.
Seems to be simplest and generally agreeable to all of the implementers.
Definitely understand that there are other use cases that might not be
addressed.
Mo Zanaty: I agree with Alan that we should keep it simple, but I
disagree that this will ever be simple. All the simple approaches have
been doomed to fail, I'm convinced that strict ordering will never
provide a useful semantic for applications. Look at existing work in
this space, mechanisms are known that have issues and are not useful to
deploy, they're probably not useful to deploy here too. Application
folks are thinking of this just like that, but layers below you will
have queues and such as well, so understanding how the application level
semantics map to delivery is very important.
Luke Curley: Pretty much agree with what Victor said. Don't want to have
the callback mechanism and it's just not going to work. Like Victor
said, you can do incremental yourself. Groups are nice because you can
do round-robin. Prioritization is a never-ending topic, and this is a
good starting point.
Cullen Jennings: As a thought experiment, how much of this can be done
as a polyfill on top of sendOrder. But better to send it over to
application.
Victor: Just to answer the thought experiment, it's possible to emulate
over sendOrder if the segments are short.
Retransmissions and send order (#523)
Cullen Jennings: If we just did this by default, it would not be great.
Lossy networks would have priority inversions from other networks. If
you say that the application can set different send orders for the main
packets and then a separate one for if it's retransmitted, you have to
let the application control it. Everyone thinks about improving the
priority of something, but in real life you need to make something
worse, not better. If the application is trying to make that stream
worse, but the underlying WebTransport implementation is doing it
backwards and now putting that priority higher. If you want to separate
send orders, you should have two, both set by the application.
Luke Curley: I've done two, one with and one without, didn't see any
difference really. There are some flow control issues, unless your
packet loss rate is really high, you don't really see any difference.
Always retransmit first, otherwise flow control is hell, you have gaps
in streams that still consume flow control.
Mo: I like Cullen's idea of having specific retransmission order. If I
can use it as a hack to get datagram semantics with streams, set it to
the lowest possible.
David (as individual): Sad that you don't want to implement datagrams.
Mo Zanaty: There are a lot of people who do not love datagrams.
WebTransport using HTTP/2, Eric Kinnear
https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http2
Submitted draft-06 that adds initial flow control limits, and default
settings for new sessions on connection and default header fields for
each session.
Also, updated examples.
What's left? Error handling, which we're pretty much ready to write up.
Many thumbs up, and no thumbs down, from the room regarding reseting
Http/2 stream if fatal error is found.
Final Size field is important for flow control, which is especially
important for H3.
Is everybody okay for us to leave that out?
Victor: What does H2 do?
Eric: We just reset the stream, and there's no final size.
Alan: This is the only difference between capsules in H2 and the field
in H3, right? I kind of want it back, but lost that argument a while
back. Resetting should be enough.
Who has implemented WT over H/2?
Eric: There are 2 people in the room who are implemeting this currently.
Alan: Would be good to hear about issues from them.
Marten Seemann: Can you clarify what it means by consumed? Final Size is
how much data is sent on stream. This is obvious on H2.
General consensus is to leave the Final Size out.
Flow Control Terminology
Would definitely be worth writing some examples, to clarify the
cumulative word.
Mo: Had similar arguments with people who know much more about QUIC
than. Very important to clarify for all implementers. Not sure if
cumulative is the right word.
WebTransport over HTTP/3, Victor Vasiliev
https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3
Key exporters
Wrote proposal for how to derive key exporters for a given WT session.
Do we need this?
Marten Seemann: It was me who opened the proposal, but I haven't seen
your sketch, so I can't comment on that.
You put the session ID in the context.
Victor: It provides the same ___
Marten: That sounds reasonable to me, but I don't know a ton about
crypto.
David: Why are we building this? Are there use cases for this?
Marten: I know a guy from HTTP who is writing a draft about unprompted
authentication. To build something similar to this on top of
WebTransport, it would be really helpful to be able to export the keys.
David: Are you planning to implement it?
Marten: I have a use case exactly for that
Bernard: Will not be useful for MoQ or RoQ payload encryption, or hop by
hop encryption (e.g. SRTP).
Mo: Unless we wanted applications to have an interoperable way to do
this, this is a helper, they can do it without a spec.
Victor: This is to ensure that whatever you are doing is bound to a
specific TLS channel between the client and the server
Mo: What do you mean by bound?
Victor: You cannot set up a scheme where you authenticate with one party
and they're really proxying the authentication to another party.
Mo: But that just gets you another permutation of the keying material
that you have, but it doesn't get you anything else.
Victor: As a TLS client server, you have access to it, but the client
application does not.
Mo: I don't see applications needing this.
Luke Curley: Could you clarify if this impacts the transport, or just an
API thing?
Victor: This is an API thing, gets you keying material that is derived
from the secret TLS session key.
Luke: This would just be a W3C API right? Not affecting the bits on the
wire?
Victor: Correct, This would be W3C API, doesn't change anything on the
wire, doesn't add burden to any implementation that is not a browser or
a server that wants to use this.
David (chair): This sounds more like a W3C issue. Not a lot of use cases
here. Propose to send to W3C and ask over there if they have use cases,
only add if there's a strong need. Not consensus to add this at the
time. Marten, can you take this to the W3C and gather use cases to get
more consesnsus?
Marten: Yeah, will do.
Protocol negotiation
SETTINGS_WEBTRANSPORT_MAX_SESSIONS is currently required in both
directions.
Eric Kinnear: Seems like we'd been coming to the conclusion that we
could encode future versions in the :protocol token that we use in
extended connect, which means that we can get rid of the extra
codepoints here. The client needs to send the request to the server
anyways, and the server isn't opening sessions, so there's not really
any need to send this from the client other than to identify version,
but by the time you've sent the connect the server can tell the version.
Victor: My personal opinion is that I didn't like this proposal, but
then I liked it and went and implemented draft-07 support in Google
quic, but then decided I didn't like it. I found it extremely painful to
deal with, so prefer a scheme that
Eric: If you have a challenge between versions, how are you sending the
connect request before you know what version is supported? Don't you
always know the version before you can do anything that would include
using frames?
David: Unless I'm misunderstanding, your opinion doesn't amtch the
slide. It sounds like there are 2 proposals.
1) change the upgrade token
2) change the SETTINGS codepoint
Server sends the SETTINGS. When client picks one,
Victor is saying it uses different capsules
Eric: Why can't server just send which versions it supports, and the
client picks which one it wants to use?
David: It sounds like this is quite confused, we should take this back
to the issue.
Marten: Why is it max of max of max. Shouldn't it be the max of the
intersection of the two?
David: Yes, it should be a intersection of the two sets of versions.
Victor: No, this does not require additional roundtrips
Luke: Preference is that the client optimistically sends something with
no knowledge of server settings so it doesn't take a roundtrip
Flow Control (draft-thomson-webtrans-session-limit)
Some of this depends on document in QUIC
Similar to H2, should we include the WebTransport-Init header. Could we
have some general thumbs up and down? (no general reaction)
Don't use a max streams data capsule
Victor: When do we want to require this?
Alan Frindell: Wanted this because don't want to run out of memory, but
don't feel like implementing it. Maybe there are other people who have
added this for H2 and add it to H3. I think it's a good idea in the long
run. But I think we'll regret it if we don't implement it.
Luke Curley: This is requirement unfortunately if you use session
pooling. I don't want to do session pooling, and set max sessions to 1
and never do this.
David: We could say that this is only required when max sessions is more
than 1. How do you feel about that?
Luke: That's a fair thing.
Alan: Skeptical how you're going to prevent extra sessions.
David: In our implementation, it's not fed into the connection pool.
Eric: Challenge is shouldn't matter if we pool or not. Run into issues
when you have other H3 traffic. Sure, you can say don't put it into the
connection pool, with lots of hand-waving. If our general principle is
that we don't allow any WebTransport sessions to see anything about
other sessions.
If max sessions is 1, and we use the existing H3 flow control. Bugs are
not going to be different, but small delta of limitations.
Lucas Pardue: Lagging behind in implementation, doesn't fill me with
joy, how do we test and make sure that we're not adding tons of bugs
that make everyone's day bad?
David: Defer as in publish first or defer and include after we catch up?
Lucas: Maybe we're just over indexing on the problems
Marten: I agree, we shouldn't ship multi-session without flow control.
I'd rather go through the pain and implement it now rather than doing it
later and potentially delaying the document because people still need to
implement this proposal.
Victor: My specific proposal would be only require flow control if you
allowed pooling with the WebTransport in the browser.
Luke Curley: Would anybody do session pooling without flow control? That
seems like deadlock central. Seems very easy to starve. Max sessions and
flow control are fate-bound?
Victor: Max sessions is a decision to pool or not pool is a client
decision.
Luke: Anyone want to do session pooling but no flow control?
Eric: I don't want to do it, but if we have
Victor: I will make sure that the text makes it clear.
Lucas Pardue: I hear a lot about clients doing a thing to support this.
I need to update my understanding here, but supporting these vs. not is
ambigious to me, if I'm going to say yes I can do this thing but the
client chooses not to do it, what position does that put me in? +1 on
clarifying.
David: It sounds like if we tie this to pooling, we need to write the
"how" before people can decide if we like this, and it sounds like the
"how" might not be super straight forward.
Bernard Aboba: I have a concern on how we roll this out and the effect
on the API. Right now we don't have pooling in the client so nobody is
really using this. Would this be JS observable?
Victor: Should be JS neutral, to some extent you have to already handle
the situation where you run out of flow control limits for H3, so people
have to already deal with limits, this just changes some of those
limits.
Bernard: You'd have to introduce this along with pooling and at that
time people would observe changes in the behavior with their apps. I
wouldn't use this or pooling either, but I think in some sense it's
probably good to understand it now and have it in the spec, but it's one
of those things you'd have to test with developers to make sure people
understood the behavior.
Alan Frindell: Would I do pooling without this? It's fine for me if the
states get coupled. it's still strange that you can put this on the
WebTransport side, but no limit on the H3 side. Don't know if we need to
solve this.
Martin Thomson: I don't think this is a problem. If the connection is
choked up and you can't make more HTTP requests, that's fine, just make
another connection. The other way was always definitely going to be the
problem. I don't get why you would add extra complexity, we need these
things, it's easier to always implement these things, I don't know why
you would want to not have them sometimes. If we agree that we need them
in one context, we might as well have them in every context.
David: The idea of having optional and only when pooling, you don't like
that?
MT: Agreed, very much don't like that.
Alan: If you're out of flow control can you just keep opening more
connections?
MT: Don't know if that's written down anywhere. Number of connections
may be equal to number of webtransport sessions + 1 worst case.
Marco Munizaga: Added complexity for stacked flow controllers. What's
the benefit you're getting when we pool these sessions?
David: Talked about this a while back. You can have multiple requests on
the same connection, we decided WT is a request unless we do something
special, do we want to allow that or not. Decision at the time was to
say yes we allow that.
Eric: Part of the point from the JS side for pooling is that it doesn't
make any difference, turns out this isn't that bad.
David: We said it would be hard and no one implemented it, and turns out
it is hard.
Eric: Regarding impact on apps in JS land, pooled vs non-pooled
connections should not be visible to the JS layer. Can see an argument
that you shouldn't be able to say in the constructor that it should be
pooled or not, if it makes a difference then we have a bug.
Marten: There's also the option to solve this problem at a different
layer, maybe the QUIC layer. Not sure that's the right layer, but would
solve the H3-eats-all-your-streams proposal. I wrote something a while
back for stream groups.
Luke Curley: You said when create a WebTransport connection, you don't
use that connection for other H3 in Chrome?
Victor: Correct, that connection is not related to any pools for Chrome.
Luke: WT and H3 do not share a connection at all in Chrome then.
Victor: It is not entirely necessary, but if you are relying on things
like your congestion controller providing estimates for send rate.
Mo: To Martin's point, not liking being this optional, I heard the
arguments for not wanting to do this is laziness, if it's too hard just
set it to a giant number, you can still be lazy and not have to think
about it.
Victor: Laziness is part of it, part of the issue is that when you have
a dedicated connection it is redundant with the connection level flow
control.
Bernard: Just one comment, people mentioned when you don't have pooling
that you get the connection to yourself and you get a bandwidth
estimate. The other part of pooling is having to share the congestion
window. Keyframes are often bigger than congestion window and require
multiple RTTs. It can improve your efficency to pool, if a bunch of
stuff pushes up the congestion window, you'll find that things go better
for you. If you're going to pool you need to know what's being sent.
Spencer Dawkins: Wanted to rewind back to agree with Eric about
applications getting different behavior using pooled and non-pooled
connections. I wanted to add that if applications can do that, there's a
pretty good chance that developers will try to exploit that and it will
be up to transport people to try to unwind what we've built to make sure
that you can't get different behavior. That seems like something we
might be able to head off by saying why pool.
Lucas Pardue: To the point about setting big numbers, in my experience
working with QUIC streams it doesn't work because you've got a bunch of
other stuff that needs to happen, when you reset a stream do you get
some of that flow control back. There are ways to do this if you're not
lazy and do the work, but there are edges that are tricky. You can't be
lazy because you will hit weird sharp edges and cause issues.
Luke Curley: Replying to Mo, if you just set big values, you're gonna
run into the QUIC flow control, you're gonna have a background tab that
is not reading from streams, a new tab is going to immediately get
blocked by flow control and that new tab is unresponsive. If you make a
brand new connection, you get brand new flow control, and you're
unblocked immediately. You can't have pooled/non-pooled seem the same if
you don't do this.
Mo: If you don't use these, they're effectively infinite. In both cases,
David: Let's see if I can synthesize a few of those points. I think we
have a bunch of agreement that we cannot do pooling without flow
control, otherwise bad things happen. And I think we also have
agreement, although I'm a bit less sure, on this property that if you
select pooled vs. not-pooled it shouldn't be too visible to the JS. I
think we have agreement that that means you need flow control in both
cases, if you only have in one and not the other then you can detect
that difference. That means that we need flow control. Also hearing that
flow control is hard and we are engineers, therefore lazy. We want to do
this, but nobody wants to do this now. I'm thinking perhaps we don't
require it in the spec right now, but nobody wants to ship this until
we've actually figured this out. Maybe what we need is implementation
experience from this, and then we can revisit this conversation. I'll
type that up in the issue.
Wrap up and Summary, Chairs & ADs
Murray: Some of this is getting close to last call, reminder to email me
since I don't see pub-reqs.
David: It seems that these specs are blocked on implementations. I'll
take an action item to talk to the httpbis chairs.