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
Idempotency of Frame Types #1424
Comments
I once had a discussion with a well-known danish physicist who seriously argued that it might be possible to receive data before they were transmitted and he had been contemplating putting up an experiment. |
This seems like an important property to capture. Some of the HTTP/QUIC text sort of falls into this category but would benefit from clearer language in the transport. The only question I have is: is this an invariant? |
Agreed this would be useful to explicitly state. I don't think we'd benefit from making this an invariant, though I would expect it to continue to be true in future versions. |
Can't be an invariant; the existence of frames isn't an invariant, so their properties are even less so. But yes, this is a property that we'd likely retain in future versions. |
Understood, thanks. |
In the repeated discussions of duplicated packets and what happens if an implementation accidentally processes them, it has become clear that an important property of QUIC in this respect is that every frame type is idempotent. It doesn't matter if you receive them once or a dozen times, nor how they are reordered (only provided they're not received before they're sent, of course). All that matters is that each reliable frame, or the information it carries, is received.
This is perhaps an important property to document, both for future iterations of the WG who are expanding QUIC, and for extension frames as they will need to have this property as well.
The text was updated successfully, but these errors were encountered: