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
Robert Wilton Invariants Discuss 1 #4468
Comments
I think that Rob's suggestion to remove the "SHOULD" is ideal. |
Does someone remember why this SHOULD was added? The fixed bit is useful in the client-to-server direction because it allows servers to demultiplex QUIC with other protocols, but I don't remember what benefit it provided in the server-to-client direction. |
I believe there 'could' be applications(ie: WebRTC) which share a port with QUIC and might want to use this bit to demux even on the client side, but that's seems like a pretty theoretical problem, so I'd be inclined to drop the SHOULD. |
In a p2p setup, you might run QUIC clients and servers on the same port (in fact, that's what we're doing in libp2p), so demultiplexing might be important for both sides in that case. |
Yes, this was to avoid collision with p2p protocols. As I recall, we had decided that this would be something we would recommend for v1, but not require this for future versions... and that if both endpoints agreed, then they could set the bit to something other than 1. I don't see why we should change this. |
In a P2P setup where we're demultiplexing with another bootstrapping protocol over UDP, is there a need for version negotiation packets at all? I'd expect the bootstrapping protocol to convey the supported QUIC versions, and at that point you don't need version negotiation. I'm in favor of removing the SHOULD on VN packets. |
My thinking is along the lines of @DavidSchinazi but I also don't care much about whether we remove this or not. |
The VN packet is version-independent. v1 shouldn't be constraining its contents. However, implementations are free to select the value they put there any way they wish, so if they find it useful to always set that bit, they may. |
This isn't constraining the contents of a VN packet broadly, it is constraining what a v1 sender sends in a VN packet. And, I don't think it's reasonable to require that P2P protocols shouldn't need to use VN. My high-level point is this: IIRC, we had this SHOULD for co-existence with P2P protocols, and we went through a lot of discussion, especially with ART folks on this. Do we really want to re-litigate this point at this stage in the process? Maybe I'm mis-remembering. If I am, and this SHOULD was there for a different reason that is no longer valid (or never was important), I'm happy to remove this. |
That's right. Maybe we should have been more studious in capturing reasons. I think that for those P2P applications that care about multiplexing, this is a non-issue. Those applications can use their signaling channel to ensure that version negotiation does not happen. If things get badly out of hand, endpoints can ensure that Version Negotiation packets are sent with the bit set to conform to other constraints. |
That applies to peers discovered during the execution of the p2p protocol. Every p2p network has some hard-coded bootstrap nodes though, for which the QUIC version might not be known in advance. |
@marten-seemann are those hard-coded bootstrap nodes QUIC clients or servers? We're only talking about receipt of VN packets here. |
I think that we can keep the inconsistency, but we need someone (@janaiyengar) to follow up with Rob. |
@rgwilton: At this point, I'd rather not change what was a design decision made by the wg, so I propose close with no action to this issue (not merge #4471). Can you see if the explanation above is satisfactory to you? |
To check that my understanding is correct:
This behaviour is consistent, but the documents need to explain this more clearly. Particularly, because the the first sentence of section 17.2.1 states: " A Version Negotiation packet is inherently not version-specific," and yet the value set in this field might be version specific. Hence, I would suggest that you expand the description in the transport draft to explain that it SHOULD be set for QUIC version 1, but that other versions of QUIC may relax this requirement. Noting that the transport draft already talks about future versions having different requirements on the length of connection ids. |
Just to close the loop here. I've added an explanation of two things to the draft that is about to go out: that this recommendation is to allow for multiplexing, and that this recommendation is not guaranteed to apply when other QUIC versions are in use. I think that is in line with what @rgwilton suggests. If you disagree, we might be able to tweak this more later, but I need to publish -34 so that the wheels of the process can continue to turn. |
Just to confirm that I am happy with the committed text change. Thanks for accommodating. |
Robert Wilton said:
The text was updated successfully, but these errors were encountered: