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

Change idle_timeout to max_idle_timeout #3099

Merged
merged 24 commits into from Jan 21, 2020

Conversation

ianswett
Copy link
Contributor

@ianswett ianswett commented Oct 16, 2019

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

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.

Fixes #2602 
Takes some of the improved text from #2745
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.
Copy link
Contributor

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)?

Copy link
Contributor Author

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.

draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
Co-Authored-By: Jana Iyengar <jri.ietf@gmail.com>
Copy link
Member

@martinthomson martinthomson left a 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.

draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
Copy link
Member

@kazuho kazuho left a 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.

draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
Copy link
Member

@martinthomson martinthomson left a 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 Show resolved Hide resolved
draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
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.
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also pre-existing.

ianswett and others added 5 commits November 1, 2019 13:24
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>
Copy link
Contributor

@janaiyengar janaiyengar left a 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 Show resolved Hide resolved
draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
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.
Copy link
Contributor

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 Show resolved Hide resolved
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
Copy link
Contributor

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?

Copy link
Contributor Author

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?


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
Copy link
Contributor

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."

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
ianswett and others added 5 commits November 2, 2019 16:46
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>
@ianswett
Copy link
Contributor Author

ianswett commented Nov 2, 2019

@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.

@ianswett ianswett changed the title Idle timeout indicates you will timeout Change to max_idle_timeout Nov 2, 2019
@ianswett ianswett changed the title Change to max_idle_timeout Change idle_timeout to max_idle_timeout Nov 2, 2019
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
Copy link
Member

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 [...]

draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
@ianswett
Copy link
Contributor Author

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.

draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
draft-ietf-quic-transport.md Outdated Show resolved Hide resolved
Copy link
Contributor

@janaiyengar janaiyengar left a 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
Copy link
Contributor

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?

@martinthomson martinthomson added the design An issue that affects the design of the protocol; resolution requires consensus. label Jan 21, 2020
@martinthomson martinthomson merged commit 2432593 into master Jan 21, 2020
@martinthomson martinthomson deleted the ianswett-symmetric-timeout branch January 21, 2020 05:45
ianswett added a commit that referenced this pull request Feb 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Idle timeout needs more description and a recommendation
7 participants