-
Notifications
You must be signed in to change notification settings - Fork 1
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
Simpler negotiation #41
Comments
I wonder whether tracking "did the peer send a frame" is simpler than "did the peer set the bit in the TP". If we follow your design, we need to add some text such as "if the peer accepts address discovery frames and the local endpoint supports them, it should send an address discovery frame promptly after the beginning of the connection." And deal with the morass hiding behind "promptly". |
Yes, "promptly". (I would prioritize this lower than some of the other frame types, which might mean that "prompt" means "eventually". We have a similar concern with HANDSHAKE_DONE and we somehow muddle through, so that wouldn't bother me even if it was "eventually" in practice. I'd have said that if you are tracking the observed/reflexive addresses you have received, then you have the information you need if you care about receiving that information if another path opened up. |
This change would make it a bit annoying to figure out when to give up on a peer if you only connect because you want to get an address. "promptly" or "eventually" are... vague. The original design makes it very simple to make that decision and you can disconnect if the peer does not want to send you the discovered address. |
I seriously doubt that this is how you would operate in practice. Peers who support this will likely indicate a willingness to receive the frame. Separately, many of the deployments that I would consider useful here are essentially static. That is, you know that this particular server supports the feature, therefore you integrate it into your process for managing NAT traversal. |
Of course, even if a server sets a bit to promise that it will send discovery frames, that does not mean that it will actually do it "immediately". But then, not setting the bit means that there is no point waiting for the frame, and that's valuable information. |
I see @martinthomson’s concern about the added complexity, but I’m curious how significant it is in practice. For those who’ve implemented the draft: What complexity did you encounter beyond simply replacing a bool with an enum? |
I did not find that overly complex. Here is the actual code in picoquic:
But yes, a boolean is simpler. See for example the equivalent code for enabling greasing of the Quic bit:
|
I like the design overall, but I find the transport parameter needlessly complex.
Here's a simpler design proposal:
That's it.
Looking at the existing proposal:
I understand that endpoints might want to know in advance whether a peer is going to send the frame to them. The design I propose doesn't achieve that. Receiving the frame does. If endpoints that are willing to send the frame send the frame (which can be done as soon as application data keys are available) that uncertainty goes away.
The text was updated successfully, but these errors were encountered: