search

quic-interop / quic-network-simulator

ns3-based network simulator for QUIC testing
Other
145 stars 44 forks source link

wait-for-it: Update the Initial packet that will elicit a Version Negotiation packet #112

Closed iyangsj closed 6 months ago

iyangsj commented 6 months ago

RFC 9000 Section 7.2

When an Initial packet is sent by a client that has not previously received an Initial or Retry packet from the server, the client populates the Destination Connection ID field with an unpredictable value. This Destination Connection ID MUST be at least 8 bytes in length.

The QUIC server, which strictly adheres to RFC 9000, may simply discard an invalid Initial packet instead of sending a Version Negotiation packet.

marten-seemann commented 6 months ago

The sentence you're quoting applies to QUIC v1. It does not apply to other QUIC versions, hence discarding such an Initial packet would be incorrect behavior.

iyangsj commented 6 months ago

@marten-seemann Thank you for taking the time to review the pull request. I understand your concerns and you are right.

I'd like to clarify my reasoning behind these changes.

marten-seemann commented 6 months ago
  • The wait-for-it tool seems to be used primarily to check if the QUIC server has started, rather than strictly checking its compliance with the QUIC protocol.

Well, yes and no. We have to assume at least some level of compliance, otherwise we wouldn't be able to elicit a Version Negotiation packet in the first place.

  • For some implementations that are still under development, if wait-for-it fails, we currently cannot execute test cases as much as possible, nor can we intuitively know what the cause of the failure is. Try to allow the server to pass the 'wait-for-it' check as much as possible and then using the test cases to verify its behavior against the protocol specifications can directly highlight any existing issues.

If you don't understand the QUIC version, you can't make any assumptions beyond what's documented in RFC 8999. Specifically, you MUST NOT assume that any behavior of QUIC v1 (RFC 9000) holds true for any future version of QUIC.

This means that your implementation is behaving incorrectly. Instead of asking other people to change their tooling in order to accommodate your non-compliant QUIC stack, may I suggest you fix your QUIC stack instead?

iyangsj commented 6 months ago

Instead of asking other people to change their tooling in order to accommodate your non-compliant QUIC stack, may I suggest you fix your QUIC stack instead?

I'm also fixing the issue in lsquic. I noticed that the maintainer of lsquic has also submitted a similar PR .

marten-seemann commented 6 months ago

I noticed that the maintainer of lsquic has also submitted a similar PR .

And his PR is incorrect for exactly the same reasons. Thanks for the link, I've closed that PR.