Large or Many Writes on a Stream get blocked about webtransport-go HOT 5 CLOSED

Sounds like a Firefox issue then? Have you recorded a qlog and loaded it into qvis yet? That would allow you to see why exactly things are getting stuck.

from webtransport-go.

Well, this is fun ..
I am trying to capture a qlog by setting network.http.http3.enable_qlog in about:config .. and this generally works. Visiting Google produces a useful trace, too. But my application on localhost only seems to record the handshake for some reason. When I try to host the application on a Hetzner server, the issue does not appear at all; probably because the round-trip times are long enough to avoid whatever is going wrong here. I'll give it a few more attempts.

The qlog does record beyond the initial handshake but it's broken for some reason.

After quite the odyssey with Wireshark and pcap2qlog (+ PR 12, and another fix for padding packets) I've generated something that loads in qvis, although it looks really wild and I'm not sure if this is correctly converted. Attached here, if you want to take a look, too @marten-seemann: 97b1e85bb8a8870669739fc5b8f0c52e1665a0bf.qlog.txt

Now I noticed that if I initiate the stream in the client with await transport.createBidirectionalStream() (but still send the same data from the server!), the issue does not occur. Then the qlog saved by Firefox is not corrupted either and it loads fine in qvis. (Doesn't always work either.)

from webtransport-go.

I somehow managed to grab a successful qlog of a connection where this issue occured. In the visualization it looked like all data has been received successfully by Firefox this time (the "Packetization" tab showed the expected number of "Bytes received"). Yet the async iterator in Firefox was still stuck after about 1.2 MiB.

Two days ago I thought that maybe increasing the receive buffer size would help. But it turns out that decreasing it actually solved my issue.

The setting network.http.http3.recvBufferSize is set to 1048576 by default for me. I reduced this to 32768 (32 KiB) and all data was transmitted correctly. When network.http.http3.enable_qlog is also enabled, I can increase the receive buffer size further to 65536 (64 KiB). So it seems that I just need to "slow down" reception of frames somehow.

Anyway. This really seems like a Firefox issue to me, so I'm closing this issue. I have no idea how to debug this further but I'm happy to have found a way around it for now.

from webtransport-go.

You could also try recording a qlog from the quic-go side. Might be interesting to get the server's perspective on this.

from webtransport-go.

Sure. I've added a connection tracer to the reproducer per the example in quic-go and recorded a connection where this issue occured from "both sides". For this I reset the receive buffer size in Firefox to its default value.

• quic_server.qlog.txt
• quic_client.qlog.txt

You can see that the server hangs after 19 iterations (~ 1945600 bytes):

And the browser only "received" 889941 bytes. (The CHUNKs don't map cleanly to iterations because I am just sending zeroes and log the chunks as fast as they arrive in the async iterator.)

I haven't looked at the qvis of those two logs in detail yet but maybe you can find something interesting in them. Luckily, the client log is not corrupted this time; it apprears this also only happens sporadically.

I don't see anything "suspicious" around the 889941 byte mark (around packet 682 on stream 7).

However, there are a few max_stream_data and stream_data_blocked frames towards the end (e.g. packet 1295), which is probably the browser correctly applying back-pressure?

Also, 889941 (the bytes that showed up in the browser console) + 1048576 (default recvBufferSize) = 1938517 is eerily close to 1938520 (the limit in the last stream_data_blocked frame) ...

The more I look at it, the more I think that this is a Firefox issue somewhere between neqo and the ReadableStream API?

from webtransport-go.