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

Two idle timeout corrections #3983

Merged
merged 5 commits into from
Aug 12, 2020
Merged

Two idle timeout corrections #3983

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
7045117
Idle timeout doesn't drain
martinthomson Aug 4, 2020
1d16c41
Sending PING will reset both idle timeouts
martinthomson Aug 4, 2020
5fa5301
Split sentence
martinthomson Aug 11, 2020
396f64e
Take two
martinthomson Aug 11, 2020
da6ebb5
Reword restarting on ACK
martinthomson Aug 11, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 8 additions & 4 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2692,8 +2692,8 @@ idle timeout period to be at least three times the current Probe Timeout (PTO).
### Liveness Testing

An endpoint that sends packets close to the effective timeout risks having
them be discarded at the peer, since the peer might enter its draining state
before these packets arrive.
them be discarded at the peer, since the idle timeout period might have expired
at the peer before these packets arrive.

An endpoint can send a PING or another ack-eliciting frame to test the
connection for liveness if the peer could time out soon, such as within a PTO;
Expand All @@ -2712,8 +2712,12 @@ An implementation of QUIC might provide applications with an option to defer an
idle timeout. This facility could be used when the application wishes to avoid
losing state that has been associated with an open connection, but does not
expect to exchange application data for some time. With this option, an
endpoint could send a PING frame periodically to defer an idle timeout; see
{{frame-ping}}.
endpoint could send a PING frame ({{frame-ping}}) periodically, which will cause
the peer to restart its idle timeout period. Sending a packet containing a PING
frame restarts the idle timeout for this endpoint also if this is the first
ack-eliciting packet sent since receiving a packet. Sending a PING frame causes
the peer to respond with an acknowledgment, which also restarts the idle
timeout for the endpoint.

Application protocols that use QUIC SHOULD provide guidance on when deferring an
idle timeout is appropriate. Unnecessary sending of PING frames could have a
Expand Down