Re: [blink-dev] Re: Intent to extend the origin trial: WebTransport over HTTP/3

[Yutaka Hirano]

bcc: blink-dev

cc: web-transport-dev

Hi, web-tran...@chromium.org is a better place for this kind of discussion.

On Thu, Jan 20, 2022 at 3:47 PM kk as <kmsli...@gmail.com> wrote:

Hi

  Can you please let me know  what transport protocol  do the Streams API use in WebTransport over http3/quic.  

I am assuming the datagram API uses the UDP protocol for transport .   Can you also please let me know what is the difference in latency

when you send data using Streams API vs Datagram API ?

Reg: protocol, we use WebTransport over HTTP/3.

We expect Datagrams is better than Streams in terms of latency, but actual number depends on the network environment, server and client implementation.

Our client implementation is not (at all) perfect, so we'll appreciate your performance feedback!

 

thanks

On Wednesday, October 27, 2021 at 10:34:56 PM UTC-7 Yutaka Hirano wrote:

On Thu, Oct 28, 2021 at 2:38 AM Joe Medley <jme...@google.com> wrote:

Hi,

Can I get some clarification?

So this extends the origin trial through 96, but you don't know yet whether it will ship in 97? Is this correct?

We're shipping WebTransport over HTTP/3 in 97.

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

On Mon, Oct 25, 2021 at 1:00 AM Mike West <mk...@chromium.org> wrote:

LGTM3.

-mike

On Thu, Oct 21, 2021 at 9:58 PM Daniel Bratell <brat...@gmail.com> wrote:

For a gapless origin trial->shipping it is important to be sure we don't overlook any feedback in the race to shipping. The normal process has gaps built in which form natural points to do that final polish based on received feedback and that will be missing here.

It does sound like the feedback has been positive though and that there are no known problems that can't be fixed after shipping, and with that in mind:

LGTM2

On 2021-10-21 21:53, Yoav Weiss wrote:

Discussing amongst the API owners (Alex, Daniel, Rego and myself), this is essentially a request for a gapless OT, only that the would-be-gap is slightly longer than usual. Given the evidence of developer feedback presented in the I2S, that seems like a reasonable request.

LGTM1 (as gapless OT requests require 3 LGTMs)

On Monday, October 18, 2021 at 10:39:14 AM UTC+2 Yutaka Hirano wrote:

Contact emails

yhi...@chromium.org,vas...@chromium.org

Explainer

https://github.com/w3c/webtransport/blob/main/explainer.md

Design docs/spec

Specification: https://w3c.github.io/webtransport/#web-transport

https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit

TAG review

https://github.com/w3ctag/design-reviews/issues/669

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.

Note that we were developing QuicTransport a.k.a. WebTransport over QUIC and we ran an origin trial M84 through M90. It uses the same interface WebTransport, but because of the protocol difference ("quic-transport" vs. "https") it is difficult for web developers to be confused by them.

new WebTransport("quic-transport://example.com:9922")

represents a WebTransport over QUIC connection, and

new WebTransport("https://example.com:9922")

represents a WebTransport over HTTP/3 connection.

Goals for experimentation

We're shipping the API in M97. Twitch, one of our partners, wants to continue their experiment until the API is fully shipped. I think this is a reasonable request given we originally aimed to ship the feature in M96 but we missed the branch point.

The original goals follow:

To see whether the API (and the implementation) is useful in various circumstances.

Our partners want to evaluate this API on various network circumstances (i.e., lab environments are not enough) to see its effectiveness.

We also expect feedback for performance.

Experimental timeline

M95 and M96

Ongoing technical constraints

None

Debuggability

The devtools support is under development.

Just like with regular HTTP/3 traffic, the detailed information about the connection can be obtained via chrome://net-export interface.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,

Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No

We have browser tests, but we are going to port them to WPT.

Link to entry on the Chrome Platform Status

https://www.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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9ffa05b8-fbbf-4f2a-975d-be72a1089ebcn%40chromium.org.

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a2d36d19-d8dd-20e2-638a-001304d9a8c9%40gmail.com.

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DfwHejzJF2a8st5OZ5zEjutAWEHrxoUVD6q40yneSzXUg%40mail.gmail.com.

[Bernard Aboba]

Yutaka said: 

"Reg: protocol, we use WebTransport over HTTP/3.

We expect Datagrams is better than Streams in terms of latency, but actual number depends on the network environment, server and client implementation.

Our client implementation is not (at all) perfect, so we'll appreciate your performance feedback!"

[BA] Recent work has confirmed that WebTransport with BBRv1/v2 congestion control is not suitable for applications requiring low or ultra-low latency, such as media transport.   This problem exists for both datagram and streams.  To enable applications requiring low latency, a different congestion control algorithm is required, such as Google CC, SCREAM or NADA.  

See the discussion in this Issue: Pluggable Congestion Control · Issue #365 · w3c/webtransport · GitHub

You received this message because you are subscribed to the Google Groups "web-transport-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-transport-...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/web-transport-dev/CABihn6G8cJ7n88kJK0rXOLpnmNHYVPyXA5zAns-%2BpcxbeewRVA%40mail.gmail.com.

[guest271314]

Based on my testing it is not possible to stream (media, or anything else) using WebTransport with aioquic library (what GoogleChrome/samples uses). That is a severe limitation. 

[guest271314]

I suggest WebTransport developers/specification authors/implmenters test WebTransport until it breaks. The WPT tests are quite tame. None even try to live stream without a definitiv end with either streams or datagrams, and aioquic maintainers are not Chromium engineers https://github.com/aiortc/aioquic/issues/242 and Chromium engineers have not even fixed aioquic implementation to match GoogleChrome/samples implementation which uses aioquic! (Don't take my word for it https://github.com/aiortc/aioquic/issues/237, test live-streaming (media) yourself.)

At least demonstrate live-streaming is possible using the public sample provided at GoogleChrome/samples https://github.com/GoogleChrome/samples/issues/756. 

When I try to stream live audio (that has no definitive end) the stream simply stops transmitting to the browser, and Task Manager reports RAM/CPU increasing exponentially. Not the case with fetch().

[kk as]

Hi 

 Thanks for the reply.. Yes can let you know the performance difference between streams and datagrams.. Have'nt gotten to that point yet.

My question also was abot which transport protocol streams API uses.  Is it TCP or QUIC's transport protocol derived from UDP?

Also is the datagram API always implemented over UDP or they implementation specific ?  

thanks