[{"author": "David Schinazi", "text": "

/me waves

", "time": "2022-11-10T13:01:58Z"}, {"author": "Jonathan Lennox", "text": "

Meetecho: the mouse pointer is showing on the in-room screen such that it's right in the middle of the remote speaker's face. Can it be moved?

", "time": "2022-11-10T13:07:39Z"}, {"author": "Jonathan Lennox", "text": "

Thank you!

", "time": "2022-11-10T13:07:56Z"}, {"author": "David Schinazi", "text": "

I got it, thx for letting me know

", "time": "2022-11-10T13:07:57Z"}, {"author": "Lorenzo Miniero", "text": "

Let me check, just a sec

", "time": "2022-11-10T13:08:15Z"}, {"author": "David Schinazi", "text": "

It's fixed now

", "time": "2022-11-10T13:08:23Z"}, {"author": "Lorenzo Miniero", "text": "

Ack, thx!

", "time": "2022-11-10T13:09:11Z"}, {"author": "Eric Kinnear", "text": "

Alan has a nice blurb about when and where priorities are helpful :)

", "time": "2022-11-10T13:15:51Z"}, {"author": "Martin Thomson", "text": "

This isn't a question for the IETF, at least not really. Though many people here have good experience with it.

", "time": "2022-11-10T13:16:20Z"}, {"author": "Martin Thomson", "text": "

We're not talking about signaling priorities.

", "time": "2022-11-10T13:16:35Z"}, {"author": "Eric Kinnear", "text": "

Fair point

", "time": "2022-11-10T13:16:47Z"}, {"author": "Christian Huitema", "text": "

The key issue for MoQ is to be able to change priorities of streams over time, so new frames don't wait for old ones.

", "time": "2022-11-10T13:17:18Z"}, {"author": "Jonathan Lennox", "text": "

I'd be a little concerned about having an API that we later decide is stupid and poorly-defined, but which has to be kept around for backward compatibility, and which then makes implementations of better APIs harder.

", "time": "2022-11-10T13:17:56Z"}, {"author": "Victor Vasiliev", "text": "

My inclination is to answer \"no\" to all four

", "time": "2022-11-10T13:18:56Z"}, {"author": "Christian Huitema", "text": "

+1 David, L4S is not magical

", "time": "2022-11-10T13:20:01Z"}, {"author": "Martin Thomson", "text": "

I'm with Victor.

", "time": "2022-11-10T13:20:06Z"}, {"author": "Alan Frindell", "text": "

\"JS based CC\" is on top of the user-agent's congestion controller, as streams and datagrams are congestion controlled

", "time": "2022-11-10T13:20:55Z"}, {"author": "Christian Huitema", "text": "

There is a privacy angle to all that. Exposing properties of the local network stack is not free.

", "time": "2022-11-10T13:21:13Z"}, {"author": "Jonathan Lennox", "text": "

Yeah, the point of the JS-based CC would be to avoid queue-building behaviors (either in the network or in your local output buffers).

", "time": "2022-11-10T13:23:18Z"}, {"author": "Christian Huitema", "text": "

What if several web transport clients require different congestion control for the same connection?

", "time": "2022-11-10T13:24:12Z"}, {"author": "Martin Thomson", "text": "

Yeah, managing competing interests is something that will require some magic. At some level, you might imagine creating separate connections, but then those connections will end up competing in fun ways.

", "time": "2022-11-10T13:26:00Z"}, {"author": "Martin Thomson", "text": "

The fingerprinting risk doesn't bother me

", "time": "2022-11-10T13:26:28Z"}, {"author": "Martin Thomson", "text": "

Fingerprinting that derives from what a browser has chosen to implement is not interesting.

", "time": "2022-11-10T13:26:54Z"}, {"author": "Eric Kinnear", "text": "

The naive response is that you only pool WT clients that are \"compatible\", but they end up competing somewhere else, anyways. Not unlike the rest of the internet, to be fair.

", "time": "2022-11-10T13:28:25Z"}, {"author": "Randell Jesup", "text": "

Lennox said what I was going to.

", "time": "2022-11-10T13:28:36Z"}, {"author": "David Schinazi", "text": "

Thanks

", "time": "2022-11-10T13:28:51Z"}, {"author": "Martin Thomson", "text": "

I can see @Jonathan Lennox's point here, but I would note that this is a wonderful thing for after we ship something that works.

", "time": "2022-11-10T13:29:11Z"}, {"author": "Martin Thomson", "text": "

+1 to Peter's point here.

", "time": "2022-11-10T13:29:32Z"}, {"author": "Alan Frindell", "text": "

If you want to express a priority of two things they have to be on the same connection.

", "time": "2022-11-10T13:29:37Z"}, {"author": "Victor Vasiliev", "text": "

for what it's worth, I don't believe we allow CC changes for pooled WebTransport connections, so I am not sure how much this applies

", "time": "2022-11-10T13:29:57Z"}, {"author": "Eric Kinnear", "text": "

Can you go \"lower\" than the built in CC by just not sending data? Is there a more concrete use case for JS-based CC? (Sounds neat, just curious what it's for)

", "time": "2022-11-10T13:29:59Z"}, {"author": "Alan Frindell", "text": "

Maybe you just want to know how deep the local queues are / backpressure?

", "time": "2022-11-10T13:30:47Z"}, {"author": "Martin Thomson", "text": "

@Eric Kinnear I think that's the shape of the API currently

", "time": "2022-11-10T13:30:54Z"}, {"author": "Jonathan Lennox", "text": "

I'd state it slightly differently as \"no for now, but maybe yes in the future when we know more\". I'm not sure that's meaningfully different though.

", "time": "2022-11-10T13:31:47Z"}, {"author": "Alan Frindell", "text": "

Is there a faint ghost effect on the screen in the room?

", "time": "2022-11-10T13:31:53Z"}, {"author": "Martin Thomson", "text": "

the burn-in on this projector is insane

", "time": "2022-11-10T13:32:02Z"}, {"author": "David Schinazi", "text": "

I'm not seeing any ghosts?

", "time": "2022-11-10T13:32:10Z"}, {"author": "Martin Thomson", "text": "

I can still read the previous slides

", "time": "2022-11-10T13:32:10Z"}, {"author": "Jonathan Lennox", "text": "

Plus shadows from the curtains around the screen

", "time": "2022-11-10T13:32:23Z"}, {"author": "Martin Thomson", "text": "

it's fading with each transition

", "time": "2022-11-10T13:32:23Z"}, {"author": "David Schinazi", "text": "

Ah, can't see it from this angle

", "time": "2022-11-10T13:32:26Z"}, {"author": "Alex Chernyakhovsky", "text": "

I didn't know projectors could get burnin!

", "time": "2022-11-10T13:32:38Z"}, {"author": "Alex Chernyakhovsky", "text": "

I didn't know projectors could get burnin!

", "time": "2022-11-10T13:32:48Z"}, {"author": "Momoka Yamamoto", "text": "

I have a comment about the SETTINGS_ENABLE_CONNECT_PROTOCOL and WebSockets, but since it's not about WebTransport I will make it later on the mailing list.

", "time": "2022-11-10T13:39:52Z"}, {"author": "David Schinazi", "text": "

That makes sense Momoka, thanks! Or maybe we can talk about it at the end if we have spare time

", "time": "2022-11-10T13:40:39Z"}, {"author": "Victor Vasiliev", "text": "

Funny that you ask

", "time": "2022-11-10T13:42:20Z"}, {"author": "Victor Vasiliev", "text": "

The redirect is on my slides

", "time": "2022-11-10T13:42:25Z"}, {"author": "Kazuho Oku", "text": "

CONNECT (for TCP) cannot be redirected, correct? (because there's no URI)

", "time": "2022-11-10T13:42:51Z"}, {"author": "Alex Chernyakhovsky", "text": "

Is that still true with extended connect?

", "time": "2022-11-10T13:43:17Z"}, {"author": "Victor Vasiliev", "text": "

I don't believe versioning can be done via headers

", "time": "2022-11-10T13:43:32Z"}, {"author": "Alan Frindell", "text": "

Luke, you can just error or close if you get anything other than CONNECT

", "time": "2022-11-10T13:44:00Z"}, {"author": "Victor Vasiliev", "text": "

I object to only sent from the server

", "time": "2022-11-10T13:44:30Z"}, {"author": "Martin Thomson", "text": "

For versioning, at the server end, we can define a WebTransport-Draft: -43 field for clients to use.

", "time": "2022-11-10T13:45:06Z"}, {"author": "Luke Curley", "text": "

@Alan Frindell possibly, although the earlier the better

", "time": "2022-11-10T13:45:20Z"}, {"author": "Alan Frindell", "text": "

In fact the chrome impl uses a header to do this right now I think?

", "time": "2022-11-10T13:45:29Z"}, {"author": "Luke Curley", "text": "

I don't really want my server to complete handshakes with clients that will never use WebTransport... but it doesn't really matter

", "time": "2022-11-10T13:45:58Z"}, {"author": "Lucas Pardue", "text": "

you can fix negotiation by sending multiple SETTINGS with different code points

", "time": "2022-11-10T13:46:06Z"}, {"author": "Jonathan Lennox", "text": "

If it's a header then in theory pooled WebTransport sessions could have different versions, couldn't they?

", "time": "2022-11-10T13:46:21Z"}, {"author": "Martin Thomson", "text": "

Victor, can you explain why the header doesn't work?

", "time": "2022-11-10T13:46:44Z"}, {"author": "Martin Thomson", "text": "

Option 1: the server sends a setting and the type determines which version (or versions if there are many) the server supports.

", "time": "2022-11-10T13:47:21Z"}, {"author": "Martin Thomson", "text": "

...The client indicates a draft version in a header field on the CONNECT-WTF request.

", "time": "2022-11-10T13:47:37Z"}, {"author": "Martin Thomson", "text": "

Option 2: The client indicates that it supports webtransport in a setting, the type of sertting indicates what version the client supports.

", "time": "2022-11-10T13:48:01Z"}, {"author": "Martin Thomson", "text": "

I need a concrete reason for the client-side setting.

", "time": "2022-11-10T13:50:17Z"}, {"author": "Martin Thomson", "text": "

One reason.

", "time": "2022-11-10T13:50:59Z"}, {"author": "Alan Frindell", "text": "

Can you send multiple SETTINGS in h3?

", "time": "2022-11-10T13:51:14Z"}, {"author": "Alan Frindell", "text": "
\n

SETTINGS frames always apply to an entire HTTP/3 connection, never a single stream. A SETTINGS frame MUST be sent as the first frame of each control stream (see Section 6.2.1) by each peer, and it MUST NOT be sent subsequently

\n
", "time": "2022-11-10T13:51:59Z"}, {"author": "David Schinazi", "text": "

You can send multiple setting identifiers in a single SETTINGS frame

", "time": "2022-11-10T13:52:27Z"}, {"author": "Alan Frindell", "text": "

ah sorry, misunderstood

", "time": "2022-11-10T13:52:38Z"}, {"author": "Eric Kinnear", "text": "

@Alan Frindell one SETTINGS frame, multiple settings inside?

", "time": "2022-11-10T13:52:39Z"}, {"author": "Eric Kinnear", "text": "

Yeah, that

", "time": "2022-11-10T13:52:43Z"}, {"author": "Martin Thomson", "text": "

Developer tooling on this is probably an answer.

", "time": "2022-11-10T13:55:17Z"}, {"author": "Martin Thomson", "text": "

This is only going to need to happen once.

", "time": "2022-11-10T13:55:48Z"}, {"author": "Martin Thomson", "text": "

Maybe someone could build a site: ismyserverwebtransportcapable.io or some such

", "time": "2022-11-10T13:56:30Z"}, {"author": "Martin Thomson", "text": "

That can provide a nice checklist.

", "time": "2022-11-10T13:56:39Z"}, {"author": "Martin Thomson", "text": "

MAY tear it down, not MUST

", "time": "2022-11-10T13:57:04Z"}, {"author": "Alan Frindell", "text": "

Yeah, better developer tools would be fine too. I'm ok with N

", "time": "2022-11-10T13:57:17Z"}, {"author": "Jonathan Lennox", "text": "

Apologies for cutting the queue.

", "time": "2022-11-10T13:58:03Z"}, {"author": "Luke Curley", "text": "

yeah, the issue is learning which settings you're supposed to send for WebTransport, but that can be fixed with proper error messages

", "time": "2022-11-10T14:00:30Z"}, {"author": "Alan Frindell", "text": "

I devolved to reading the chrome code and the aioquic code.

", "time": "2022-11-10T14:00:53Z"}, {"author": "Alan Frindell", "text": "

Seems like 3xx implies all the the streams will be reset and the datagrams discarded is ok?

", "time": "2022-11-10T14:04:05Z"}, {"author": "Martin Thomson", "text": "

3xx means \"I did not process anything, feel free to try again\"

", "time": "2022-11-10T14:04:52Z"}, {"author": "Jonathan Lennox", "text": "

Do all >2xx responses mean \"I did not process anything\", or can a late 4xx/5xx happen?

", "time": "2022-11-10T14:05:42Z"}, {"author": "Alex Chernyakhovsky", "text": "

I would be very upset if a server sent a 4xx/5xx response to the extended-connect after processing some datagrams

", "time": "2022-11-10T14:06:19Z"}, {"author": "Kazuho Oku", "text": "

IIUC that's up to webtrans. HTTP itself allows either ways, for ordinary request 5xx can be sent after the request is processed, but for CONNECT any response other than 200 means that the stream was not upgraded to a bi-directional connection.

", "time": "2022-11-10T14:07:53Z"}, {"author": "Martin Thomson", "text": "

@Jonathan Lennox no, that's not a guarantee

", "time": "2022-11-10T14:08:17Z"}, {"author": "Lucas Pardue", "text": "

not saying I told you so but https://github.com/quicwg/base-drafts/issues/2559

", "time": "2022-11-10T14:08:24Z"}, {"author": "Martin Thomson", "text": "

As Kazuho says, we can make a call here

", "time": "2022-11-10T14:08:32Z"}, {"author": "Kazuho Oku", "text": "

+1 to stream type, because unless we add a type, webtrans cannot coexist with another H3 extension that tries to use client-initiated bidi stream for itself.

", "time": "2022-11-10T14:15:21Z"}, {"author": "Kazuho Oku", "text": "

(but I know this is related to the Reliable Reset Stream proposal)

", "time": "2022-11-10T14:16:50Z"}, {"author": "Marten Seemann", "text": "

I can confirm that my parser also just reads the first varint, and then hands off the stream to the WebTransport stack. (as Alan described)

", "time": "2022-11-10T14:24:54Z"}, {"author": "Lucas Pardue", "text": "

We don't need to register it with a good name. We just need to reserve the codepoint from frame space

", "time": "2022-11-10T14:25:24Z"}, {"author": "Jonathan Lennox", "text": "

MOQ is almost certainly going to go over webtransport, so that's probably a fairly large family of potential future implementors who haven't been looking at webtransport yet.

", "time": "2022-11-10T14:25:40Z"}, {"author": "Kazuho Oku", "text": "

Or create an HTTP/3 extension that sends the type, and negotiate the use of it using H3 SETTINGS.

", "time": "2022-11-10T14:28:01Z"}, {"author": "Victor Vasiliev", "text": "

I believe our code actually parses the length, but then interprets as the session ID

", "time": "2022-11-10T14:28:26Z"}, {"author": "Martin Thomson", "text": "

2^62-1 frame length is always invalid, so you would be OK to reject the stream in that case

", "time": "2022-11-10T14:28:40Z"}, {"author": "Martin Thomson", "text": "

I don't want to have a stream type ahead of HEADERS on an HTTP request stream

", "time": "2022-11-10T14:29:24Z"}, {"author": "Alan Frindell", "text": "

I think it's the combination of things that makes it not really belong in the frame parser. Has to be first, doesn't have a length, doesn't parse any more frames after that

", "time": "2022-11-10T14:29:53Z"}, {"author": "Alan Frindell", "text": "

The only thing that makes it a frame is it holds a place in the frame registry

", "time": "2022-11-10T14:30:13Z"}, {"author": "Martin Thomson", "text": "

I agree. We also have some special code to handle SETTINGS.

", "time": "2022-11-10T14:30:21Z"}, {"author": "Alan Frindell", "text": "

I think Luca pointed out that SETTINGS is more of a \"stream preface\" a few years ago

", "time": "2022-11-10T14:30:44Z"}, {"author": "Martin Thomson", "text": "

This is essentially what it is described as.

", "time": "2022-11-10T14:30:58Z"}, {"author": "Victor Vasiliev", "text": "

We're up to three design teams for this meeting!

", "time": "2022-11-10T14:31:03Z"}, {"author": "Martin Thomson", "text": "

@David Schinazi Talking to the furniture probably won't help: what you need to do is talk to the people who implement HTTP/3.

", "time": "2022-11-10T14:31:52Z"}, {"author": "Lucas Pardue", "text": "

I agree with not delaying WT progress too much, fast solution please

", "time": "2022-11-10T14:32:09Z"}, {"author": "Martin Thomson", "text": "

I don't want to have technical decisions being made by furniture talking to furniture

", "time": "2022-11-10T14:32:31Z"}, {"author": "Victor Vasiliev", "text": "

Back in college days, we had a thing called \"furniture exchange\"

", "time": "2022-11-10T14:33:15Z"}, {"author": "Martin Thomson", "text": "

Ours is match varint { WEBTRANSPORT_STREAM => webtransport, _ => http }

", "time": "2022-11-10T14:35:42Z"}, {"author": "Victor Vasiliev", "text": "

wow, a language with working pattern matching

", "time": "2022-11-10T14:36:22Z"}, {"author": "David Schinazi", "text": "

re: talking to furniture it's not about which one we pick it's about which WG we fix it in

", "time": "2022-11-10T14:37:12Z"}, {"author": "Martin Thomson", "text": "

This is WT_RESET_STREAM as it is currently defined, more or less.

", "time": "2022-11-10T14:38:14Z"}, {"author": "Eric Kinnear", "text": "

Yeah, seems less nice than having an extended reset stream in QUIC that lets you carry application metadata, but otherwise not bad

", "time": "2022-11-10T14:39:07Z"}, {"author": "Kazuho Oku", "text": "

Is it already a requirement to expose reset signal to webtransport apps?

", "time": "2022-11-10T14:39:15Z"}, {"author": "Martin Thomson", "text": "

@Kazuho Oku yes

", "time": "2022-11-10T14:39:31Z"}, {"author": "Kazuho Oku", "text": "

thank you for the answer

", "time": "2022-11-10T14:39:42Z"}, {"author": "Martin Thomson", "text": "

The goal is to provide an API that is consistent with that defined in the QUIC spec

", "time": "2022-11-10T14:39:44Z"}, {"author": "Martin Thomson", "text": "

at least the streams part of that API

", "time": "2022-11-10T14:39:57Z"}, {"author": "Martin Thomson", "text": "

note that RESET_STREAM can be an application-layer signal

", "time": "2022-11-10T14:40:27Z"}, {"author": "Martin Thomson", "text": "

I think that we need to consider this \"partial stream delivery\" as opposed to \"reliable resets\" because resets are already reliable

", "time": "2022-11-10T14:43:05Z"}, {"author": "David Schinazi", "text": "

Yeah partial delivery is a good way to reason about it

", "time": "2022-11-10T14:43:32Z"}, {"author": "Lucas Pardue", "text": "

partial delivery, constrained to one packet's worth of data?

", "time": "2022-11-10T14:44:27Z"}, {"author": "Martin Thomson", "text": "

the metadata extension to RESET_STREAM (RESET_STREAM_WITH_EXTRA_SAUCE) also addresses the concern, maybe

", "time": "2022-11-10T14:44:28Z"}, {"author": "Martin Thomson", "text": "

@Lucas Pardue I'm not sure that there is any guarantee that the metadata would match the data that was sent

", "time": "2022-11-10T14:45:04Z"}, {"author": "Lucas Pardue", "text": "

indeed

", "time": "2022-11-10T14:45:18Z"}, {"author": "Victor Vasiliev", "text": "

I like 3(b) because that's what I proposed back at the lunch after 114 meeting

", "time": "2022-11-10T14:45:40Z"}, {"author": "Alan Frindell", "text": "

What I was trying to say is that we'd also have to specify what do to when you get a regular RESET_STREAM, or if that's even legal

", "time": "2022-11-10T14:48:02Z"}, {"author": "David Schinazi", "text": "

https://dictionary.cambridge.org/dictionary/english/trundle

", "time": "2022-11-10T14:52:14Z"}, {"author": "David Schinazi", "text": "

Huh I wasn't that far off, the word actually exists]

", "time": "2022-11-10T14:52:28Z"}, {"author": "Martin Thomson", "text": "

I see three options: 1. partial delivery 2. reset with a partial slice of the stream content 3. reset with a small piece of arbitrary data

", "time": "2022-11-10T14:52:43Z"}, {"author": "Lucas Pardue", "text": "

example: the buses in London are trundling around with full capacity due to tubes strikes

", "time": "2022-11-10T14:53:01Z"}, {"author": "Martin Thomson", "text": "

I think that London buses \"wallow\" more than trundle

", "time": "2022-11-10T14:53:20Z"}, {"author": "Eric Kinnear", "text": "

Partial slice of stream content feels like it could be opening a bunch of other issues, but I'm not super clear on what those are yet

", "time": "2022-11-10T14:53:21Z"}, {"author": "Martin Thomson", "text": "

@Eric Kinnear David's framing of this as a RESET_STREAM frame with attached STREAM frame starting at offset 0 was fairly good.

", "time": "2022-11-10T14:54:16Z"}, {"author": "Eric Kinnear", "text": "

Ohhh vs. \"partial delivery\" of something that may have already been delivered, which could then ask for additional signaling or mean that endpoints have a new way to disagree about what got processed

", "time": "2022-11-10T14:55:11Z"}, {"author": "Martin Thomson", "text": "

In the case where the STREAM frame is lost, the first solution requires that you send both STREAM and RESET_STREAM, which is awkward, but it keeps the logic simple.

", "time": "2022-11-10T14:55:14Z"}, {"author": "Eric Kinnear", "text": "

Thanks, that makes more sense, but does mean that you only solve it for other uses that put it in position 0 of the stream

", "time": "2022-11-10T14:55:35Z"}, {"author": "Eric Kinnear", "text": "

Which is probably fine, seeing as basically every protocol will need to identify streams immediately

", "time": "2022-11-10T14:55:55Z"}, {"author": "Martin Thomson", "text": "

@Alan Frindell \"Thanks, Roberto Peon\"

", "time": "2022-11-10T14:56:36Z"}, {"author": "Eric Kinnear", "text": "

@Alan Frindell Would we call that a \"session\" layer :D

", "time": "2022-11-10T14:56:37Z"}, {"author": "Eric Kinnear", "text": "

Heh

", "time": "2022-11-10T14:56:41Z"}, {"author": "Ian Swett", "text": "

+1 to Alan's point

", "time": "2022-11-10T14:56:43Z"}, {"author": "Kazuho Oku", "text": "

+1 to Alan.And I think a stream group extension is easier to implement than this.

", "time": "2022-11-10T14:57:31Z"}, {"author": "Alan Frindell", "text": "

I didn't say session layer, overlay, or \"consider a proxy\"

", "time": "2022-11-10T14:58:48Z"}, {"author": "Luke Curley", "text": "

SUB_STREAM

", "time": "2022-11-10T14:59:06Z"}, {"author": "Martin Thomson", "text": "

I'm OK with stream groupings, maybe, but this design has utility too.

", "time": "2022-11-10T14:59:13Z"}, {"author": "Martin Thomson", "text": "

Also regarding stream grouping vs. partial delivery (or reset with metadata): image.png

\n
", "time": "2022-11-10T14:59:42Z"}, {"author": "Luke Curley", "text": "

also to bikeshed, I would call it RESET_STREAM_OFFSET

", "time": "2022-11-10T15:00:01Z"}, {"author": "Kazuho Oku", "text": "

stream groups would solve the H3 bidirectional stream type bikeshed as well?

", "time": "2022-11-10T15:00:02Z"}, {"author": "Luke Curley", "text": "

the receiver really just saves the RESET_STREAM until the provided offset is reached

", "time": "2022-11-10T15:00:33Z"}, {"author": "Martin Thomson", "text": "

@Kazuho Oku can we prioritize a group?

", "time": "2022-11-10T15:00:38Z"}, {"author": "Francesca Palombini", "text": "

thank you! see you on the list

", "time": "2022-11-10T15:00:57Z"}]