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.

Sign up for GitHub

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

Jump to bottom

Stateless reset detection should be datagram-based #3085

Closed
martinthomson opened this issue Oct 9, 2019 · 2 comments
Closed

Stateless reset detection should be datagram-based #3085

martinthomson opened this issue Oct 9, 2019 · 2 comments
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.

Comments

@martinthomson
Copy link
Member

This will make the process more robust, as the process of splitting a datagram into packets could cause the token to be split. We recommend sending a packet (and one that can't be coalesced to boot). This was always going to be a single packet datagram anyway, so this shouldn't affect implementations much.
@martinthomson
Copy link
Member Author

Not sure if this is editorial or not. We already require sending to be a whole datagram:

A stateless reset uses an entire UDP datagram, [...]

So this could be seen to match things up. But it could require code changes in implementations, so I'm leaning toward design.

martinthomson added a commit that referenced this issue Oct 9, 2019
@martinthomson
Fix stateless reset ordering; use datagrams
a5671a8 
This removes the strict requirement on processing order for stateless
reset.  This allows endpoints to decide whether to process every packet
this way or to just treat those that fail to be processed for other
reasons.

This also switches to detection on a *datagram* basis.

Closes #3085.
@larseggert larseggert added the design An issue that affects the design of the protocol; resolution requires consensus. label Oct 14, 2019
@larseggert
Copy link
Member

Discussed in Cupertino. #2993 to be merged following consensus call.

@larseggert larseggert added the proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. label Oct 16, 2019
@mnot mnot added has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. and removed proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. labels Oct 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@martinthomson @mnot @larseggert