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

Retransmit server initial upon second Initial #3080

Merged
merged 21 commits into from
Mar 13, 2020
Merged

Retransmit server initial upon second Initial #3080

Changes from 1 commit
Commits
Show all changes
21 commits
Select commit Hold shift + click to select a range
f51a23e
Retransmit server initial upon second Initial
ianswett Oct 7, 2019
2e7bff7
Update draft-ietf-quic-recovery.md
ianswett Oct 7, 2019
18c9bba
Update draft-ietf-quic-recovery.md
ianswett Oct 7, 2019
ebb8543
Reword the paragraph
ianswett Oct 11, 2019
20435cf
Update draft-ietf-quic-recovery.md
ianswett Oct 22, 2019
02080b7
Update based on interim feedback
ianswett Oct 22, 2019
f1c94bf
Update draft-ietf-quic-recovery.md
ianswett Oct 22, 2019
40cc163
line lengths
ianswett Oct 24, 2019
b9c8423
Update draft-ietf-quic-recovery.md
ianswett Oct 24, 2019
6851dbb
Update draft-ietf-quic-recovery.md
ianswett Oct 24, 2019
bdcd8c7
Update draft-ietf-quic-recovery.md
ianswett Oct 28, 2019
1ae9869
Update draft-ietf-quic-recovery.md
ianswett Oct 28, 2019
91ced9e
Kazuho comments and remove one sentence
ianswett Feb 11, 2020
fcfa095
Update draft-ietf-quic-recovery.md
ianswett Feb 15, 2020
e3b814d
Update draft-ietf-quic-recovery.md
ianswett Feb 15, 2020
0c9c2f7
Update draft-ietf-quic-recovery.md
ianswett Feb 15, 2020
2274b69
Update draft-ietf-quic-recovery.md
ianswett Feb 15, 2020
acd4454
Jana's suggestions
ianswett Feb 15, 2020
3b52d6f
Reflow Jana's suggestions
ianswett Feb 15, 2020
da00548
More like Jana's first suggestion
ianswett Feb 15, 2020
28959f9
Update draft-ietf-quic-recovery.md
ianswett Feb 27, 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
2 changes: 1 addition & 1 deletion draft-ietf-quic-recovery.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -511,7 +511,7 @@ Handshake or 1-RTT packets.
When a server receives duplicate CRYPTO data in an Initial packet after sending
its Initial flight, it can assume the client did not receive all Initial CRYPTO
data. To speed handshake completion, it SHOULD retransmit all unacknowledged
Initial data subject to the path validation limits. After doing so,
Initial CRYPTO data subject to the path validation limits. After doing so,
the PTO is re-armed.
Copy link
Member

Choose a reason for hiding this comment

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

The server can't arm the PTO prior to confirming that the path is valid.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The server can't send if it's limited by the amplification factor, but the PTO can be armed otherwise.

Copy link
Member

Choose a reason for hiding this comment

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

The way I read this, it says that you retransmit then you re-arm the PTO timer.

I think that you mean to say that when the path is validated, you can re-arm the PTO timer after retransmitting the CRYPTO data, but that's not what it says.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The PTO can be armed prior to path validation, but the text said it always was, which is wrong, so I reworded the paragraph.


Copy link
Contributor

Choose a reason for hiding this comment

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

Can we formulate duplicate crypto a bit more precise? Does it mean a valid crypto packet with the same packet number as seen before?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

By CRYPTO data, I meant data sent in CRYPTO frames, which is why I used uppercase for CRYPTO.

Copy link
Contributor

Choose a reason for hiding this comment

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

There should never be a duplicate packet number unless the network duplicates packets. That's not a signal of anything on the client. I think the intent here is to act if the server receives CRYPTO frames that restate one or more already-received bytes.

Prior to handshake completion, when few to none RTT samples have been
Expand Down