WebTransport

[vasilvv]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: WebTransport
• Specification or proposal URL (W3C): https://github.com/WICG/web-transport
• Specification or proposal URL (IETF): https://tools.ietf.org/html/draft-vvv-webtransport-overview-00
• Mozillians who can provide input (optional): @martinthomson @ekr @annevk

Other information

I wrote a little bit more about the motivation behind this proposal in https://mailarchive.ietf.org/arch/msg/dispatch/sIih9gBhJ4_faoN0GrQ9Xweue2w

I know MT provided detailed feedback on the previous iteration of this proposal (RtcQuicTransport) back when it was in W3C TAG in September 2018. I would be interested to hear his opinion on the new revision.

[ddragana]

Hi,
I am going to write down some thoughts about this. They are mainly about the API, because getting the right API will influence what we need from the transport.

One of the things I would like to be better define is the support for bandwidth/network stats. There is an open issue and it looks like opinions are different regardings this topic. I think the subject is even more difficult if Http3Transport is used. Also priorities and scheduling of regular http3 streams vs http3Transport stream on one connection are difficult. This leads me to think about requirements.
It would be useful to have a good description of requirements before starting with API. For example, let’s look into what applications need/want to know about network stats and whether plugable congestion control is a requirement (in my opinion this is not acceptable). This is also going to help to decide if we want a bit higher API than it is now.

Also there is WebSocketStreams API proposal. If we decide to go for WebTransport making these two looking similar or maybe have common element would be useful.

[vasilvv]

Network stats and bandwidth prediction are very much open questions right now. I do not expect us to ship the initial version of WebTransport with any API doing more than some basic stats (open PR). I don't think we will end up supporting stats for Http3Transport, since it's not exactly clear what those would even mean.

My colleague @steveanton has been working on documenting requirements some of the potential API customers would have with respect to priorities and congestion control. My impression is that for the initial version, most of our applications are heavier on server-to-client traffic, so there isn't much needed from the browser side besides creating the connection in first place.

[ekr]

I'm generally positive on this as a concept, but I'm not sure it's baked enough to be "worth-prototyping". Perhaps either "non-harmful"? @martinthomson

[martinthomson]

I would probably go with worth prototyping. I think that the multiplexing piece needs a fair bit of work, but the fundamentals are sound.

[ddragana]

I was looking into this I was going to mark it worth prototyping. I do have some comments.

I would like see the new WebSocketStream and WebTransport stream API to be developed together so that that can share as much as possible.
Drafts needs some work and the multiplexing is a bit tricky and as Martin comment ed it will need some work.

I would like to see the doc @vasilvv mentioned above.

[adamroach]

Proposed resolution: worth prototyping, with a position detail of:

We are generally in support of a mechanism that addresses the use cases implied by this solution document. While major questions remain open at this time -- notably, multiplexing, the API surface, and available statistics -- we think that prototyping the proposed solution as details become more firm would be worthwhile.

Any objections? @annevk -- do you want to weigh in before I close the issue?

[nils-ohlmeier]

My only concern right now is that the Readme of the W3C proposal talks very generically about network connections, in other places about client connections. The IETF drafts appears to be targeting only client to server connections.
Trying to solve the client to server problem makes sense to me. I'm concerned that if this should turn into a generic transport between any nodes, e.g. P2P, that it would make the problem space so much bigger and more complex that I would prefer to stay away from it.

As long as everyone agrees that this only aims at the client to server space I agree with worth prototyping.

[martinthomson]

The proposed charter for IETF work is very clearly constrained to client-server interactions. I know that proponents have far grander aspirations for this, but what is on the table currently isn't nearly so open-ended as all that.

[annevk]

I'm happy with @ddragana's analysis and recommendation. I'll note that she asked for the requirements document that @vasilvv mentioned, but maybe that doesn't need to be blocking.

[kenchris]

I don't find the proposed resolution on the dashboard: https://mozilla.github.io/standards-positions/

[update] Sorry, I see that this is about Web Transport, but I followed the link from the TAG design review for WebSocketStreams. The TAG is wondering about your position about that? w3ctag/design-reviews#394

[annevk]

@kenchris if you want anything beyond the above comments, could you open a new issue please?

[kenchris]

I just wanted to know if the "worth prototyping" applies to WebSocketStreams as well, or not. If not, we will ask the spec authors to open an issue here

[annevk]

While I would expect a similar position, at least my read of this issue is that it's only about WebTransport.

[nidhijaju]

FYI: We are currently going through the intent process of adding a WritableStream controller AbortSignal, which will will be used for WebTransport SendStream's close and write operations.

Intent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/T6B5czAke1I

[annevk]

Thanks @nidhijaju, I believe Mozilla already expressed support for that as part of it merging into the Streams standard.

[Chaz6]

WebTransport will ship in Chrome 97.

https://blog.chromium.org/2021/11/chrome-97-webtransport-new-array-static.html

[vasilvv]

As a follow-up to this request, I would like to request the Mozilla position for the serverCertificateHashes parameter of the API with properties/constraints described in w3c/webtransport#375.

I believe @martinthomson should be able to provide input on this issue.

[martinthomson]

Victor, this is part of the specification, so the existing position covers it. Consider it "worth prototyping" along with the rest.

[fluffy]

Any update on status of this ?

[annevk]

This is resolved as worth prototyping. We don't use this repository for tracking the implementation of features. If you're interested in that you can add yourself to https://bugzilla.mozilla.org/show_bug.cgi?id=1709355 (or keep an eye out for an "intent to ship" on the dev-platform list).