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

2022-01-20 Thread kk as 
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 ?


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  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 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Mon, Oct 25, 2021 at 1:00 AM Mike West  wrote:
>>
>>> LGTM3.
>>>
>>> -mike
>>>
>>>
>>> On Thu, Oct 21, 2021 at 9:58 PM Daniel Bratell  
>>> 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 
> 
> ?

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

2022-01-19 Thread 'Yutaka Hirano' via blink-dev 
bcc: blink-dev
cc: web-transport-dev

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

On Thu, Jan 20, 2022 at 3:47 PM kk as  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  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 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Mon, Oct 25, 2021 at 1:00 AM Mike West  wrote:
>>>
 LGTM3.

 -mike


 On Thu, Oct 21, 2021 at 9:58 PM Daniel Bratell 
 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

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

2021-10-27 Thread 'Yutaka Hirano' via blink-dev 
On Thu, Oct 28, 2021 at 2:38 AM Joe Medley  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 | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Oct 25, 2021 at 1:00 AM Mike West  wrote:
>
>> LGTM3.
>>
>> -mike
>>
>>
>> On Thu, Oct 21, 2021 at 9:58 PM Daniel Bratell 
>> 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

 yhir...@chromium.org,vasi...@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+unsubscr...@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
>>>

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

2021-10-27 Thread 'Joe Medley' via blink-dev 
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?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@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  wrote:

> LGTM3.
>
> -mike
>
>
> On Thu, Oct 21, 2021 at 9:58 PM Daniel Bratell 
> 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
>>>
>>> yhir...@chromium.org,vasi...@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+unsubscr...@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

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

2021-10-25 Thread Mike West 
LGTM3.

-mike


On Thu, Oct 21, 2021 at 9:58 PM Daniel Bratell  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
>>
>> yhir...@chromium.org,vasi...@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+unsubscr...@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+unsubscr...@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

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

2021-10-21 Thread Daniel Bratell 
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

yhir...@chromium.org,vasi...@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 byweb-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+unsubscr...@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+unsubscr...@chromium.org.
To view this discussion on the web visit

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

2021-10-21 Thread Yoav Weiss 
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
>
> yhir...@chromium.org,vasi...@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+unsubscr...@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.