Hi Philip, Sorry for the belated reply. Comments inline:
On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <foo...@chromium.org> wrote: > Hi again, > > I've made a full pass of the intent now. I have a lot of questions, but am > pretty convinced we should ship this, it's just a matter of what things > need to block that, and what things can be left until later. > > Comments inline... > > On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano <yhir...@chromium.org> > wrote: > >> Contact emails >> >> yhir...@chromium.org, vasi...@chromium.org >> >> Explainer >> >> https://github.com/w3c/webtransport/blob/main/explainer.md >> >> Specification >> >> https://w3c.github.io/webtransport >> >> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/ >> >> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/ >> > > I skimmed https://github.com/w3c/webtransport/issues/ and see multiple > issues filed by other browser vendors. Are any of the remaining issues ones > that could change the API's shape or behavior? It would be good to resolve > any such issues, since they won't be possible to address once the API is > locked in by sites depending on it. > > I believe we've addressed issues that may require breaking changes. You can see open <https://github.com/w3c/webtransport/milestone/1>/closed <https://github.com/w3c/webtransport/milestone/1?closed=1> issues for the initial launch (this intent). I shared our plan <https://docs.google.com/document/d/1X9-a03rtm0FqTW01nG6e7f91NAguGEv37mP964HrJlk/edit#heading=h.v9yxozj8naro> at a WG meeting in May <https://www.w3.org/wiki/WebTransport/Meetings#WebTransport_Bi-weekly_Virtual_Meeting_.2316_late_-_May_25.2C_2021> and we've been working to find and resolve such issues since then. > Design docs >> >> https://web.dev/webtransport/ >> >> >> https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit >> >> Summary >> >> WebTransport is an interface representing a set of reliable/unreliable >> streams to a server. The interface potentially supports multiple protocols, >> but based on discussions on the IETF webtrans working group, we are >> developing WebTransport over HTTP/3 which uses HTTP3 as the underlying >> protocol. >> >> This time, we want to ship the core part. The following features are >> excluded: >> >> - >> >> Connection sharing >> - >> >> Stream Prioritization >> - >> >> Statistics >> - >> >> WebTransport over HTTP/2 >> >> >> Blink component >> >> Blink>Network>WebTransport >> >> TAG review >> >> https://github.com/w3ctag/design-reviews/issues/669 >> >> TAG review status >> >> Pending >> > > Our launch process docs > <https://www.chromium.org/blink/launching-features> says "You should have > TAG sign-off on your API design by now" but I consider this a bug in the > process docs. The request was sent on Aug 19 and has no feedback yet, I > don't think we should block this intent on TAG review. If it happens soon > enough, it would of course still be important to take it into account and > possibly make adjustments before the feature reaches stable. > > Ack. > Risks >> >> Interoperability and Compatibility >> >> This is a new API and doesn’t change any existing behaviors. >> >> Gecko: Worth Prototyping >> <https://github.com/mozilla/standards-positions/issues/167>. They are >> actively involved in the specification effort. >> >> WebKit: No signal >> <https://lists.webkit.org/pipermail/webkit-dev/2021-September/031980.html> >> . >> > > How about the technologies that WebTransport depends on? Per > https://caniuse.com/http3, it's shipped in Firefox and experimental in > Safari. Are you aware of any likely problems getting HTTP/3 itself into all > browsers? If HTTP/3 is on a good track, that reduces the risk here. > > I'm not aware of any problems. With an HTTP/3 implementation (and Streams API) any browsers can implement the API in a reasonable timeframe I believe. > Web developers: Positive >> >> Twitch >> >> https://twitch.tv >> >> >> >> Twitch is using WebTransport to serve live video to our users with lower >> latency and higher quality. We plan on rolling out our new playback >> experience once it's fully available given our positive results. >> >> >> >> WebTransport offers all of the benefits of QUIC, but in a browser >> environment and without the constraints of HTTP semantics. Most notably we >> can push data over multiple streams, eliminating head-of-line blocking and >> enabling new functionality during congestion. This is not possible with >> existing browser standards such as WebSockets and WebRTC data channels. >> >> Google Stadia >> >> https://stadia.google.com/ >> >> “Google Stadia is using the WebTransport API in conjunction with the >> WebCodecs API for several use cases, both internally and with partners. The >> underlying WebTransport protocol, QUIC, has far greater throughput and >> resiliency characteristics than other mechanisms available, which enables >> use cases like webcams, and transmission of results of browser-based >> processing to applications and games in the cloud. The capability to >> transmit datagrams to cloud endpoints enables many new use cases for Stadia >> including communication with custom hardware endpoints. In the future we >> hope to explore using this API for other use cases.” >> > > This is great feedback, thank you for collecting it! It looks like both > Twitch and Stadia are looking at video, where I assume that avoiding > head-of-line blocking makes it possible to scale down quality faster when > network conditions go bad. Sounds like a win for end users, ultimately! > > >> Ergonomics >> >> The API is built around ReadableStream/WritableStream interfaces, which >> means that its core I/O principles would be familiar to the developers who >> had already used Streams via Fetch and other APIs. >> >> The API does not use cookies, HTTP authentication or socket pooling. >> This would help us avoid unexpected interactions with the other elements of >> the network stack. >> >> Activation >> >> Since UDP is often blocked on the network, the developers have to assume >> that the API often would not work even in the situations when it is >> implemented in the browser. >> > > This is interesting. How do web developers detect and deal with this > situation, and distinguish it from the network temporarily going down? I've > skimmed https://web.dev/webtransport/ and it doesn't mention this kind of > blocking, does this need to be highlighted in documentation and reference > docs for WebTransport? > For usual loading browsers detect the network conditions and choose the right version (HTTP/3, HTTP/2 and HTTP/1.1). We may be able to do similar things in the future (on the other hand, we may end up asking web developers to detect it). Some people are working on WebTransport over HTTP/2 <https://github.com/ietf-wg-webtrans/draft-webtransport-http2>. > > Speaking of reference docs... Getting a feature documented on MDN isn't > part of the Blink launch process, but are you working with anyone to get it > documented by the time the feature reaches Chrome stable? > > I haven't talked with anyone. Do you have a good idea? > Security >> >> See <https://wicg.github.io/web-transport/#privacy-security> for more >> info. >> >> >> >> We allow web developers to use an alternative certification verification >> method than the usual HTTPS way. We allow a web developer to connect to a >> WebTransport over HTTP/3 server when its certificate’s fingerprint matches >> with the developer provided fingerprint. This is discussed at >> https://github.com/w3c/webtransport/issues/349 and we will update the >> spec shortly. >> >> Debuggability >> >> Printing an error message with the reason when the opening handshake >> fails. >> >> We show outgoing WebTransport sessions in the “Network” section of >> DevTools, the same place where WebSocket connections are shown. Unlike >> WebSockets, we do not intend to show the actual contents of the >> WebTransport sessions, thus avoiding the performance decrease that would >> cause. >> >> Just like with regular HTTP/3-based QUIC traffic, detailed information >> about the connection can be obtained via chrome://net-export interface. >> >> Is this feature fully tested by web-platform-tests? >> >> Yes >> >> We are writing WPTs (/webtransport >> <https://wpt.fyi/results/webtransport?label=experimental&label=master&aligned>). >> We expect the task to be completed by the branch point. The WebTransport >> over HTTP/3 server for testing >> <https://github.com/web-platform-tests/wpt/tree/master/tools/webtransport> >> is running locally, but we need more time to run it on wpt.live or >> Chromium CI. >> > > Here I just want to say that the WPT work for this feature has been great > to see, adding new infrastructure and solving many small problems to make > it possible. Thank you, this is key to ensuring that other implementations > behave the same down the line. > > Thank you very much for your support! > Requires code in //chrome? >> >> False >> >> Tracking bug >> >> https://crbug.com/10111392 >> >> Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/4854144902889472 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6HZaCbG_q8wVv0ukaGRwir-%2BVr0yQTGy3nXH0Qwa1fe%3Dg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6HZaCbG_q8wVv0ukaGRwir-%2BVr0yQTGy3nXH0Qwa1fe%3Dg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6EGJxfapcbFZsWmjjXjY7fcnJL%2B%3DXUrD%2BXkS37eu%3Dot2g%40mail.gmail.com.
