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 1 commit
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.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
4 changes: 2 additions & 2 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -2714,10 +2714,10 @@ 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 ({{frame-ping}}) periodically, which will cause
the peer to restart its idle timeout period. Sending a packet containing a PING
frame also restarts the idle timeout for the endpoint if this is the first
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.
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