-
Notifications
You must be signed in to change notification settings - Fork 35
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
Retiring the initial connection ID #77
Comments
Thanks for the report! Most stacks haven't been sending I recently fixed a bug related to Regarding |
Also, do you have a way for me to reproduce this locally? |
Thanks Lars! The server I was testing with is not yet compatible with the Draft 33 initial salt used by Quant, so I was testing against a version from prior to this commit: 6570d70 I do see the recent msquic runs against Quant showing rpt=1 and it seems to be working, so perhaps that bug fix may have already fixed it. Unfortunately I don't have a way for you to reproduce this locally or to try against more recent versions of Quant. If you have an ability to create an integration test for this that would be best to ensure it works and doesn't regress in the future.
Using a new connection ID is a requirement of connection migration, but it's not the only reason an endpoint may wish to rotate connection IDs and there is no requirement to migrate connections when new connection IDs are issued or retired. I had a similar discussion with Picoquic on this topic: private-octopus/picoquic#1151 |
OK, I'll leave this open until your code is on draft -34 and you can re-test? I unfortunately don't have a test suite - quant will get archived when the RFCs are out, it served as research code and not for any sort of deployment. So I cut lots of corners. Regarding |
@WesleyRosenblum have you had a chance to test this again? |
Hi Lars. We haven't updated to draft 34 yet and it may still be a little while longer. If you'd prefer you can close this and I can reopen it if necessary when we get to updating and testing this out. |
We've updated to QUIC v1, and this does seem to still be a problem, both for Quant client and server. Here is a recent log output:
|
Thanks! I'll take a look. (But quant has sort of outlived its usefulness as a test implementation now that v1 is done, so this is not high priority for me at then moment.) |
We do have a public QNS image you can use to reproduce this now: public.ecr.aws/s2n/s2n-quic-qns:latest |
While testing interoperability of the Quant client, we've encountered an issue related to Quant's handling of NEW_CONNECTION_ID frames.
One scenario that triggers these issues involves a peer that issues a NEW_CONNECTION_ID frame that requests to retire all previously issued connection IDs. This should be allowed by the following from QUIC Transport §5.1.2:
Let's say Quant has just completed a handshake with a peer. At this point, Quant has a single connection ID (with sequence ID 0) to communicate with the peer and the Retire Prior To value is 0.
Now, say the following NEW_CONNECTION_ID frames, which indicates the peer no longer wants to use the connection ID used during the handshake, are received by Quant:
As soon as Quant processes this frame and attempts to retire the initial connection ID, the following assertion failure occurs:
I believe this may be happening due to
cid.available
being initialized totrue
for the first connection ID in use (link).I also noticed several uses of the
NO_MIGRATION
directives in parts of the code dealing handling NEW_CONNECTION_ID frames and sending RETIRE_CONNECTION_ID frames (for example). A peer should be able to issue NEW_CONNECTION_IDs without actually performing or allowing connection migrations. This may be done, for example, because the peer may only wish to use a given connection ID for a limited amount of time.Thanks for considering this issue and let me know if you need any further information!
The text was updated successfully, but these errors were encountered: