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
Conversation
draft-ietf-quic-transport.md
Outdated
shorter period advertised by the peer. By announcing an idle timeout, | ||
an endpoint commits to initiating an immediate close ({{immediate-close}}) | ||
if it abandons a connection prior to both its peers and its own idle timeout | ||
expiring. |
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.
I don't think I follow this sentence. What is the endpoint committing to? To closing the connection at min(local_timeout, remote_timeout)?
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.
It's committing to explicitly closing(and not silently closing) if it's before min(local_timeout, remote_timeout). This was adapted from MT's PR.
Co-Authored-By: Jana Iyengar <jri.ietf@gmail.com>
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.
This doesn't read particularly well as written. I've suggested something, but I'm not entirely sure that it works.
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.
I have suggestions for parts that did not read well to me, but otherwise LGTM.
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.
Thanks for doing this.
I wonder if we have any place where we can state the principle that drives this. That is, "after the time indicated in max_idle_timeout, the endpoint will no longer send nor accept packets."
draft-ietf-quic-transport.md
Outdated
a packet containing frames other than ACK or PADDING (an ack-eliciting packet; | ||
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 comment
The 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 comment
The reason will be displayed to describe this comment to others. Learn more.
Also pre-existing.
Co-Authored-By: Martin Thomson <mt@lowentropy.net>
Co-Authored-By: Martin Thomson <mt@lowentropy.net>
Co-Authored-By: Martin Thomson <mt@lowentropy.net>
Co-Authored-By: Martin Thomson <mt@lowentropy.net>
Co-Authored-By: Martin Thomson <mt@lowentropy.net>
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.
A few comments. I think it would help readability immensely if you could articulate a new timeout period, Idle Timeout (ITO) explicitly.
Also, can you change the title of the PR? It's not particularly clarifying.
draft-ietf-quic-transport.md
Outdated
Each endpoint advertises a different max_idle_timeout, but the effective value | ||
is determined by taking the minimum of the two advertised values. By announcing | ||
a max_idle_timeout, endpoints commit to initiating an immediate close | ||
({{immediate-close}}) if it abandons a connection prior to the effective value. |
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.
I don't understand this sentence... what does it mean for an endpoint to initiate an immediate close if it abandons the connection prior to the min? I thought that the endpoint was to initiate an immediate close at the min. Why are we talking about abandoning?
draft-ietf-quic-transport.md
Outdated
received and processed successfully. The timer is also restarted when sending | ||
a packet containing frames other than ACK or PADDING (an ack-eliciting packet; | ||
see {{QUIC-RECOVERY}}), but only if no other ack-eliciting packets have been | ||
sent since last receiving a packet. Restarting when sending packets ensures |
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?
draft-ietf-quic-transport.md
Outdated
|
||
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 comment
The 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 comment
The 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 comment
The 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 comment
The 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.
Co-Authored-By: Jana Iyengar <jri.ietf@gmail.com>
Co-Authored-By: Jana Iyengar <jri.ietf@gmail.com>
Co-Authored-By: Jana Iyengar <jri.ietf@gmail.com>
Co-Authored-By: Jana Iyengar <jri.ietf@gmail.com>
Co-Authored-By: Jana Iyengar <jri.ietf@gmail.com>
@MikeBishop and @janaiyengar I filed a new issue(#3184) for your comments on the existing idle timeout text. I hope all of those comments can be addressed in an editorial PR. |
draft-ietf-quic-transport.md
Outdated
processed successfully. The timer is also restarted when sending an | ||
Each endpoint advertises a max_idle_timeout, but the effective value | ||
at an endpoint is computed as the minimum of the two advertised values. By announcing | ||
a max_idle_timeout, an endpoint commits to initiating an immediate close |
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.
a max_idle_timeout, an endpoint declares that after being idle for longer than the advertised time it will not send any packets and it could generate a stateless reset ({{stateless-reset}}) in reaction to any received packet. An endpoint commits to initiating an immediate close [...]
This is failing due to a QPACK error, but I believe the PR is done. As noted above, I opened #3184 for the many comments about the existing text. I can take a stab at this, but I'd like to do that separately from this design change. |
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.
One more comment
risks having those packets discarded if its peer enters the draining state | ||
before the packets arrive. If a peer could time out within a Probe Timeout | ||
(PTO; see Section 6.2.2 of {{QUIC-RECOVERY}}), it is advisable to test for | ||
liveness before sending any data that cannot be retried safely. Note that it |
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.
What does it mean to test for liveness? Can you make this more explicit?
From @janaiyengar and @MikeBishop comments on #3099 Fixes #3184
This makes idle timeout symmetric by stating that a peer will close the connection at or soon after the idle timeout expires, creating clear expectations of idle timeout behavior. This also renames the transport parameter idle_timeout to max_idle_timeout for clarity.
Fixes #2602
Takes some of the improved text from #2745