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

PTO MUST send new data or retransmit data if possible #3057

Merged
merged 7 commits into from Oct 30, 2019
Merged

PTO MUST send new data or retransmit data if possible #3057

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
295e0c9
MUST send new data or retransmit data if possible
ianswett Sep 23, 2019
409286b
Update draft-ietf-quic-recovery.md
ianswett Sep 23, 2019
df8c4fe
unacknowledged data
ianswett Sep 24, 2019
0236874
Update draft-ietf-quic-recovery.md
ianswett Sep 24, 2019
3662405
Update draft-ietf-quic-recovery.md
ianswett Oct 24, 2019
6a225b8
Update draft-ietf-quic-recovery.md
ianswett Oct 24, 2019
886db2a
Update draft-ietf-quic-recovery.md
ianswett Oct 24, 2019
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
6 changes: 3 additions & 3 deletions draft-ietf-quic-recovery.md
View file
Open in desktop
Expand Up @@ -495,9 +495,9 @@ a PATH_RESPONSE to seed initial_rtt for a new path, but the delay SHOULD NOT
be considered an RTT sample.

Until the server has validated the client's address on the path, the amount of
data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.
If no data can be sent, then the PTO alarm MUST NOT be armed until data has
been received from the client.
data it can send is limited to three times the amount of data received,
as specified in Section 8.1 of {{QUIC-TRANSPORT}}. If no data can be sent,
Copy link
Contributor

Choose a reason for hiding this comment

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

You want to allow PINGs. "... and no other ack-eliciting packet is sent".

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Are you suggesting we always arm the PTO and if we've hit the amplification factor, the server should send a PING-only packet? That actually sounds easier than not arming it and prompts the client to send a padded Initial ACK, but I'm not sure if that's what you're suggesting?

Copy link
Contributor Author

@ianswett ianswett Oct 28, 2019 •
edited

Choose a reason for hiding this comment

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

I created #3161 to discuss whether we want to make a design change around the server's response to reaching the amplification limit, FYI.

then the PTO alarm MUST NOT be armed.

Since the server could be blocked until more packets are received from the
client, it is the client's responsibility to send packets to unblock the server
Expand Down