Some initial bumps with http3.wtf

38 views
Skip to first unread message

lucaspar...@gmail.com

unread,
Aug 4, 2020, 8:04:49 PM8/4/20
to web-transport-dev
Hello folks,

Since IETF 106 in November 2019, I've been working on a side-project fork of Cloudflare quiche that adds Datagram frame support and QuicTransport.

Today, I'm please to say I deployed a quiche equivalent of the QuicTransport test server decribed on the web.dev blog [1] to quic-transport://http3.wtf:5020. For testing purposes, I host a very familiar looking test page at https://http3.wtf/quictransport/client.html. This zone has a publically-trusted certificate and is opted-in to the Origin Trial.

I've noticed some intial bumps when testing my server with the Chromium QuicTransport client in [whatever version of Chromium I downloaded this afternoon from appspot[2]].

1. If I send "hello" on a bidirectional stream, the server receives data in STREAM frames on stream id 0 with a total length of 5 (good). The server then receives a RESET_STREAM frame with stream id=0 error=10c and size=0. The final size is mismatched, which quiche detects, and thus responds with a CONNECTION_CLOSE.

2. After connecting to http3.wtf, the client will only sit around for 5 seconds before closing the connection with a message about lack of network activity.

3. Any form of connection errors renders the browser client unable to remake connections without a page reload. Sometimes even then it is unable to reestablish connection to the server (I think this might be a server-related issue to, in case anyone decides to test it)

Anyhow, looking forward to ironing things out and making this demo a bit more stable.

Cheers,
Lucas

Yutaka Hirano

unread,
Aug 6, 2020, 5:01:30 AM8/6/20
to lucaspar...@gmail.com, web-transport-dev
This is great!

On Wed, Aug 5, 2020 at 9:04 AM lucaspar...@gmail.com <lucaspar...@gmail.com> wrote:
Hello folks,

Since IETF 106 in November 2019, I've been working on a side-project fork of Cloudflare quiche that adds Datagram frame support and QuicTransport.

Today, I'm please to say I deployed a quiche equivalent of the QuicTransport test server decribed on the web.dev blog [1] to quic-transport://http3.wtf:5020. For testing purposes, I host a very familiar looking test page at https://http3.wtf/quictransport/client.html. This zone has a publically-trusted certificate and is opted-in to the Origin Trial.

I've noticed some intial bumps when testing my server with the Chromium QuicTransport client in [whatever version of Chromium I downloaded this afternoon from appspot[2]].

1. If I send "hello" on a bidirectional stream, the server receives data in STREAM frames on stream id 0 with a total length of 5 (good). The server then receives a RESET_STREAM frame with stream id=0 error=10c and size=0. The final size is mismatched, which quiche detects, and thus responds with a CONNECTION_CLOSE.

2. After connecting to http3.wtf, the client will only sit around for 5 seconds before closing the connection with a message about lack of network activity.

3. Any form of connection errors renders the browser client unable to remake connections without a page reload. Sometimes even then it is unable to reestablish connection to the server (I think this might be a server-related issue to, in case anyone decides to test it)


I'm interested in this issue. Is it possible to write a server that simulates the connection error and publish it? Then I will investigate the client-side problem.

 
Anyhow, looking forward to ironing things out and making this demo a bit more stable.

Cheers,
Lucas

--
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/797ea1a6-38b1-4bd9-a06c-9ecdb2e8a659n%40chromium.org.

Lucas Pardue

unread,
Aug 6, 2020, 5:58:39 AM8/6/20
to Yutaka Hirano, web-transport-dev
On Thu, Aug 6, 2020 at 10:01 AM Yutaka Hirano <yhi...@chromium.org> wrote:
This is great!

On Wed, Aug 5, 2020 at 9:04 AM lucaspar...@gmail.com <lucaspar...@gmail.com> wrote:

I've noticed some intial bumps when testing my server with the Chromium QuicTransport client in [whatever version of Chromium I downloaded this afternoon from appspot[2]].

1. If I send "hello" on a bidirectional stream, the server receives data in STREAM frames on stream id 0 with a total length of 5 (good). The server then receives a RESET_STREAM frame with stream id=0 error=10c and size=0. The final size is mismatched, which quiche detects, and thus responds with a CONNECTION_CLOSE.

2. After connecting to http3.wtf, the client will only sit around for 5 seconds before closing the connection with a message about lack of network activity.

3. Any form of connection errors renders the browser client unable to remake connections without a page reload. Sometimes even then it is unable to reestablish connection to the server (I think this might be a server-related issue to, in case anyone decides to test it)


After some more looking, I figured out that issue 2 is related to the server's idle timeout (advertised by QUIC Transport Parameter). This is simply fixed by increasing the value; it was 5000 milliseconds, it is now 60000 milliseconds.
 
I'm interested in this issue. Is it possible to write a server that simulates the connection error and publish it? Then I will investigate the client-side problem.

I realised my previous statement "renders the browser unable to remake connections without a page reload" was ambiguous. I think there are two factor here: first the server had a few bugs, which could cause it to crash. This has now been fixed. Secondly, the "connect" button on the test page becomes disabled after a successful connection but does not re-enable if the connection closes. This is most likely a UI issue, but I didn't look into it.

I've set up another test instance that keeps the 5000 milliseconds timeout at quic-transport://http3.wtf:5025, this triggers the connection error case.

Finally, sending a bidi stream triggers an error since AFAICT this is a Chrome behaviour with WebTransport. I don't see RESET_STREAM being sent when Chrome is used for standard HTTP/3.

Cheers
Lucas
 
Reply all
Reply to author
Forward
0 new messages