Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

s2n-quic server fails resumption interop test with neqo client #2192

Open
goatgoose opened this issue Apr 26, 2024 · 5 comments
Open

s2n-quic server fails resumption interop test with neqo client #2192

goatgoose opened this issue Apr 26, 2024 · 5 comments

Comments

@goatgoose
Copy link
Contributor

Problem:

The resumption interop test has recently started failing with the neqo client and s2n-quic server. neqo has released a fix related to this issue (mozilla/neqo#1837), but the interop test is still failing with neqo and s2n-quic.

Solution:

We should investigate the cause of this test failure. If the issue can be addressed in s2n-quic, we should resolve it and revert #2191 to enforce the resumption test with neqo and s2n-quic in CI.

@mxinden
Copy link

mxinden commented Apr 29, 2024

Sorry for the trouble here @goatgoose.

mozilla/neqo#1837 fixed the issue.

The resumption testcase using neqo client s2n-quic server is no longer failing. See e.g. recent CI run:

mozilla/neqo#1857 (comment)

The neqo-qns Docker image is published nightly, thus reverting #2191 should succeed now.

@goatgoose
Copy link
Contributor Author

Hi @mxinden, it appears that even after the mozilla/neqo#1837 fix, the neqo client and s2n-quic server still fail the resumption test. From mozilla/neqo#1857 (comment):

Failed Interop Tests
neqo-latest vs. s2n-quic: R A

However, looking at the interop runner, it seems like mozilla/neqo#1837 fixed the issue for all implementations except for s2n-quic:
resumption_interop

So we plan to investigate this to see if s2n-quic is causing this issue.

@larseggert
Copy link

I'm looking at the download of the second URL in https://interop.seemann.io/logs/2024-07-25T16:32/s2n-quic_neqo/resumption/output.txt.

One thing that looks odd from neqo's perspective is that we're receving HandshakeDone from the server many times after ACK'ing it in our packet 3.

Otherwise, I can't tell from the log why we wouldn't send a ConnectionClose. Is there any chance you can make a linux/arm64 docker image available? I unfortunately can't run amd64 locally.

@WesleyRosenblum
Copy link
Contributor

One thing that looks odd from neqo's perspective is that we're receving HandshakeDone from the server many times after ACK'ing it in our packet 3.

This is expected. s2n-quic sends the HandshakeDone very aggressively (with every outgoing packet) until it has received acknowledgement it was received, so as to ensure the client is not blocked on the handshake.

Is there any chance you can make a linux/arm64 docker image available? I unfortunately can't run amd64 locally.

I'm currently having some trouble building on arm64 so this might take some time.

@larseggert
Copy link

This was a neqo bug: mozilla/neqo#2067

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants