Max Inden

Sorry for the trouble @kershawchang. Do I understand correctly, that the failing tests all use https://searchfox.org/mozilla-central/source/netwerk/test/http3server/src/main.rs?

> I believe that a better approach would be not to double the window, but to increase the window by an amount equal to the amount consumed since the last...

If I understand correctly the GitHub HTTP3 server implementation (`neqo-bin/server/mod.rs`) and the mozilla-central HTTP3 server implementation have a lot in common, e.g.: - wrapper logic around `neqo-http3` driving `neqo_http3::Http3Server` -...

> Good topic to discuss on the next call. Added to the agenda document :heavy_check_mark:.

With https://github.com/mozilla/neqo/pull/1878 merged and https://bugzilla.mozilla.org/show_bug.cgi?id=1895319 closed, this issue can be closed as well. Would you mind @larseggert?

I am afraid we can not "mark" the test as unsupported, i.e. `exit(127)`. Both client and server do not know the concrete testcase, but instead are told by the Interop...

I am unable to reproduce this failure locally, neither randomly running in a loop (`while cargo test -p neqo-transport --test network -- idle_timeout_crazy_rtt --nocapture; do :; done`), nor with the...

@p-shahi can you share more information? Can you provide any logs? Has the relay discovered its IPv6 address?

> Note: This isn't release yet so we'd have to work with Git dependencies for now. Soon: https://github.com/libp2p/rust-libp2p/pull/4537

For the sake of completeness, adding to the latest comment, the referenced `/ipfs/0.1.0` is not the *libp2p identify* multistream-select protool name, but the general *libp2p Protocol Version*, see https://github.com/libp2p/specs/tree/master/identify#protocolversion.