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
Merged
Changes from 1 commit
Commits
Show all changes
24 commits
Select commit Hold shift + click to select a range
61a3725
Idle timeout indicates you will timeout then
ianswett Oct 16, 2019
dc5b220
Update draft-ietf-quic-transport.md
ianswett Oct 16, 2019
2537a1a
Martin's suggestion and some reordering
ianswett Oct 29, 2019
61dcaad
Update draft-ietf-quic-transport.md
ianswett Oct 29, 2019
6fd0ac8
Update draft-ietf-quic-transport.md
ianswett Oct 29, 2019
e4dd819
Kazuho's suggestions
ianswett Oct 29, 2019
2234623
Update draft-ietf-quic-transport.md
ianswett Nov 1, 2019
11d8da8
Update draft-ietf-quic-transport.md
ianswett Nov 1, 2019
508413d
Update draft-ietf-quic-transport.md
ianswett Nov 1, 2019
e0d76ce
Update draft-ietf-quic-transport.md
ianswett Nov 1, 2019
48f04d6
Update draft-ietf-quic-transport.md
ianswett Nov 1, 2019
a7232f1
Update draft-ietf-quic-transport.md
ianswett Nov 2, 2019
ec80c86
Update draft-ietf-quic-transport.md
ianswett Nov 2, 2019
cd47d62
Update draft-ietf-quic-transport.md
ianswett Nov 2, 2019
7a6d513
Update draft-ietf-quic-transport.md
ianswett Nov 2, 2019
0bfcf11
Update draft-ietf-quic-transport.md
ianswett Nov 2, 2019
210821b
Merge branch 'master' into ianswett-symmetric-timeout
ianswett Nov 2, 2019
07d63d9
Jana's comment
ianswett Nov 3, 2019
e74856d
Update draft-ietf-quic-transport.md
ianswett Nov 18, 2019
581a368
Marten's suggestion
ianswett Nov 20, 2019
875de3f
Rebuild
ianswett Nov 20, 2019
774bc68
Use idle timer more directly
martinthomson Dec 11, 2019
c559540
wrap
martinthomson Dec 11, 2019
a203af6
Merge branch 'master' into ianswett-symmetric-timeout
martinthomson Jan 21, 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
2 changes: 1 addition & 1 deletion draft-ietf-quic-transport.md
Expand Up @@ -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
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?

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.


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

(PTO; see Section 6.2.2 of {{QUIC-RECOVERY}}), it is advisable to test for
Expand Down