Skip to content
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

Closed
MikeBishop opened this issue Jun 6, 2018 · 5 comments
Closed

Idempotency of Frame Types #1424

MikeBishop opened this issue Jun 6, 2018 · 5 comments
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.

Comments

@MikeBishop
Copy link
Contributor

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.

@MikeBishop MikeBishop added editorial An issue that does not affect the design of the protocol; does not require consensus. -transport labels Jun 6, 2018
@mikkelfj
Copy link
Contributor

mikkelfj commented Jun 6, 2018

(only provided they're not received before they're sent, of course)

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.

@LPardue
Copy link
Member

LPardue commented Jun 11, 2018

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?

@ianswett
Copy link
Contributor

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.

@MikeBishop
Copy link
Contributor Author

MikeBishop commented Jun 11, 2018

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.

@LPardue
Copy link
Member

LPardue commented Jun 12, 2018

Understood, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
None yet
Development

No branches or pull requests

4 participants