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
Change idle_timeout to max_idle_timeout #3099
Changes from 1 commit
61a3725
dc5b220
2537a1a
61dcaad
6fd0ac8
e4dd819
2234623
11d8da8
508413d
e0d76ce
48f04d6
a7232f1
ec80c86
cd47d62
7a6d513
0bfcf11
210821b
07d63d9
e74856d
581a368
875de3f
774bc68
c559540
a203af6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2361,7 +2361,7 @@ see {{QUIC-RECOVERY}}), but only if no other ack-eliciting packets have been | |
sent since last receiving a packet. Restarting when sending packets ensures | ||
that connections do not prematurely time out when initiating new activity. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If you're going to explain why you restart when sending, you might need to explain why you don't restart when sending subsequent packets. Perhaps "when sending one or more packets" might help point this explanation at bursts, rather than at individual packets? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also pre-existing. |
||
|
||
An endpoint that sends packets near the end of its peer's idle timeout period | ||
An endpoint that sends packets near the end of the idle timeout period | ||
risks having those packets discarded if its peer enters the draining state | ||
before the packets arrive. If a peer could time out within an Probe Timeout | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is not a great construction: "If a peer could time out within a Probe Timeout". It's also confusing ... maybe change this to "When an endpoint is about to send data that cannot be retried safely, it is possible that the peer may have reached the end of its idle timeout period before this data arrives at the peer. To avoid such situations, it is recommended that an endpoint test for liveness when it expects that the peer might be close, within a Probe Timeout (PTO; see Section ...) period for instance, to the end of its idle timeout period." There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed, I'll file an issue to address your and Mike's comments. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the text should be fixed here... why introduce text here and then fix it in a new PR? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not introducing this text, it just moved, hence the different PR, which is editorial. |
||
(PTO; see Section 6.2.2 of {{QUIC-RECOVERY}}), it is advisable to test for | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you write some rationale for these restarting rules?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also pre-existing text, so maybe in a different PR?