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

Amplification limit in recovery #1862

Merged
merged 10 commits into from
Oct 21, 2018
Merged

Amplification limit in recovery #1862

Changes from 1 commit
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
d2c9ae5
Amplification limit in recovery
ianswett Oct 17, 2018
0cc808b
Update draft-ietf-quic-recovery.md
ianswett Oct 17, 2018
1730b2d
Update draft-ietf-quic-recovery.md
martinthomson Oct 17, 2018
e7c83d2
Crypto retransmission timer
ianswett Oct 17, 2018
360869e
Update draft-ietf-quic-recovery.md
ianswett Oct 17, 2018
97f8bf2
Update draft-ietf-quic-recovery.md
ianswett Oct 17, 2018
b523410
Client always sends
ianswett Oct 18, 2018
289a942
Update draft-ietf-quic-recovery.md
martinthomson Oct 19, 2018
d2f45ff
Update draft-ietf-quic-recovery.md
martinthomson Oct 19, 2018
dd7fc95
Update draft-ietf-quic-recovery.md
martinthomson Oct 19, 2018
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
16 changes: 12 additions & 4 deletions draft-ietf-quic-recovery.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -318,15 +318,23 @@ is available, or if the network changes, the initial RTT SHOULD be set to 100ms.
When an acknowledgement is received, a new RTT is computed and the timer
SHOULD be set for twice the newly computed smoothed RTT.

When crypto packets are sent, the sender SHOULD set a timer for the crypto
When crypto packets are sent, the sender MUST set a timer for the crypto
timeout period. Upon timeout, the sender MUST retransmit all unacknowledged
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
timeout period. Upon timeout, the sender MUST retransmit all unacknowledged
retransmission interval. Upon timeout, the sender MUST retransmit all unacknowledged

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This doc uses timeout and timeout period fairly consistently, so I'd like to keep it as is.

CRYPTO data if possible.

Until the server has validated the client's address on the path, the number of
bytes it can send is limited, as specified in {{QUIC-TRANSPORT}}.
If not all unacknowledged CRYPTO data can be sent, then all CRYPTO data sent
in Initial packets should be retransmitted. If no bytes may be sent,
then no alarm should be armed until bytes have been received by the peer.
If not all unacknowledged CRYPTO data can be sent, then all unacknowledged
Copy link
Member

Choose a reason for hiding this comment

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

I think that you mean to say instead

If all CRYPTO data is acknowledged, and there is nothing for the client to send, then it sends another Initial packet.

What that packet contains clearly doesn't matter (though an ACK would be perfectly OK, as would repeating information that the server already has), so I don't think we need to stipulate that explicitly. Otherwise, this is a little ambiguous - and maybe in conflict with what we did in #1843 and the next paragraph.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This paragraph talks about the server's behavior, not the client's?

CRYPTO data sent in Initial packets should be retransmitted. If no bytes
may be sent, then no alarm should be armed until bytes have been received from
ianswett marked this conversation as resolved.
Show resolved Hide resolved
the client.

Because the server may be blocked until more packets are received, the
ianswett marked this conversation as resolved.
Show resolved Hide resolved
client MUST arm the crypto retransmission alarm even if there is no
ianswett marked this conversation as resolved.
Show resolved Hide resolved
unacknowledged CRYPTO data. If the timer expires and the client has no
CRYPTO data to retransmit and does not have Handshake keys, it SHOULD send
an Initial packet in a UDP datagram of at least 1200 octets.
If the client has Handshake keys, it SHOULD send a Handshake packet.

On each consecutive expiration of the crypto timer without receiving an
acknowledgement for a new packet, the sender SHOULD double the crypto
Expand Down