Explicitly allow discard of packets <40 bytes #2864
Conversation
The stateless reset text implied a lot, but never really explicitly said what to do when going below the minimum recommended size. This is a design change to an issue marked editorial. Enjoy. Closes #2153.
martinthomson
added
design
| @@ -2525,9 +2526,6 @@ a small packet might result in Stateless Reset not being useful in detecting | |||
| cases of broken connections where only very small packets are sent; such | |||
| failures might only be detected by other means, such as timers. | |||
|
|
|||
| An endpoint can increase the odds that a packet will trigger a Stateless Reset | |||
There was a problem hiding this comment.
Why did you remove this sentence?
There was a problem hiding this comment.
See #2153. Or were you asking for it to be retained?
There was a problem hiding this comment.
Yes. I think it's a good idea to always send a packet padded to > 40 bytes after quiescence, so you'd be able to quickly recover by receiving the stateless reset.
There was a problem hiding this comment.
It might be nice to explicitly mention the packet after quiescence as part of this advice, and/or advise sending at least one 40+ byte packet in each flight.
|
This PR adds a recommendation involving the number 40 without explaining where that number comes from. It would be nice to include a reference to the section that explains the math. That said, I don't think this number should depend on the maximum connection ID length, as discussed here. But feel free to tell me that this PR is not the place to discuss that. |
|
If you want to talk about the idea that the connection ID might change in length, that's a separate issue, which you should feel free to open. I am fairly sure that I can show that this isn't a meaningful insight, but happy to discuss it there. |
|
@martinthomson filed #2869. |
| @@ -2510,7 +2510,8 @@ Reset in response, which could lead to an infinite exchange. | |||
| An endpoint MUST ensure that every Stateless Reset that it sends is smaller than | |||
| the packet which triggered it, unless it maintains state sufficient to prevent | |||
| looping. In the event of a loop, this results in packets eventually being too | |||
| small to trigger a response. | |||
| small to trigger a response. An endpoint MAY choose not to send a Stateless | |||
| Reset in response to a packet that is smaller than 40 bytes. | |||
There was a problem hiding this comment.
The existing text was confusing, but I don'd see how this text is relevant to looping?
There was a problem hiding this comment.
This provides the end condition to the loop.
| @@ -2510,7 +2510,8 @@ Reset in response, which could lead to an infinite exchange. | |||
| An endpoint MUST ensure that every Stateless Reset that it sends is smaller than | |||
| the packet which triggered it, unless it maintains state sufficient to prevent | |||
| looping. In the event of a loop, this results in packets eventually being too | |||
| small to trigger a response. | |||
| small to trigger a response. An endpoint MAY choose not to send a Stateless | |||
| Reset in response to a packet that is smaller than 40 bytes. | |||
There was a problem hiding this comment.
This provides the end condition to the loop.
| @@ -2525,9 +2526,6 @@ a small packet might result in Stateless Reset not being useful in detecting | |||
| cases of broken connections where only very small packets are sent; such | |||
| failures might only be detected by other means, such as timers. | |||
|
|
|||
| An endpoint can increase the odds that a packet will trigger a Stateless Reset | |||
There was a problem hiding this comment.
It might be nice to explicitly mention the packet after quiescence as part of this advice, and/or advise sending at least one 40+ byte packet in each flight.
|
We've moved on here, allowing smaller outbound packets. |
The stateless reset text implied a lot, but never really explicitly said
what to do when going below the minimum recommended size.
This is a design change to an issue marked editorial. Enjoy.
Closes #2153.