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

Fix two instances of "between when" in the transport draft #3379

Merged
merged 3 commits into from Jan 22, 2020
Merged

Fix two instances of "between when" in the transport draft #3379

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
1c5b9e0
Fix two instances of "between when" in the transport draft
Jan 22, 2020
61298e6
Update draft-ietf-quic-transport.md
dtikhonov Jan 22, 2020
32496fc
Update draft-ietf-quic-transport.md
dtikhonov Jan 22, 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
30 changes: 15 additions & 15 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -1722,12 +1722,12 @@ one. The client MUST NOT use the token provided in a Retry for future
connections. Servers MAY discard any Initial packet that does not carry the
expected token.

Unlike the token that is created for a Retry packet, there might be some time
between when the token is created and when the token is subsequently used.
Thus, a token SHOULD have an expiration time, which could be either an explicit
expiration time or an issued timestamp that can be used to dynamically calculate
the expiration time. A server can store the expiration time or include it in an
encrypted form in the token.
Unlike the token that is created for a Retry packet, which is used immediately,
the token sent in the NEW_TOKEN frame might be used after some period of
time has passed. Thus, a token SHOULD have an expiration time, which could
be either an explicit expiration time or an issued timestamp that can be
used to dynamically calculate the expiration time. A server can store the
expiration time or include it in an encrypted form in the token.

A token issued with NEW_TOKEN MUST NOT include information that would allow
values to be linked by an on-path observer to the connection on which it was
Expand Down Expand Up @@ -3250,15 +3250,15 @@ received packets in preference to packets received in the past.

### Measuring and Reporting Host Delay {#host-delay}

An endpoint measures the delays intentionally introduced between when the
packet with the largest packet number is received and an acknowledgment is sent.
The endpoint encodes this delay in the Ack Delay field of an ACK frame
(see {{frame-ack}}). This allows the receiver of the ACK to adjust for any
intentional delays, which is important for getting a better estimate of the path
RTT when acknowledgments are delayed. A packet might be held in the OS kernel or
elsewhere on the host before being processed. An endpoint MUST NOT include
delays that it does not control when populating the Ack Delay field in an
ACK frame.
An endpoint measures the delays intentionally introduced between the time
the packet with the largest packet number is received and the time an
acknowledgment is sent. The endpoint encodes this delay in the Ack Delay
field of an ACK frame (see {{frame-ack}}). This allows the receiver of the ACK
to adjust for any intentional delays, which is important for getting a better
estimate of the path RTT when acknowledgments are delayed. A packet might
be held in the OS kernel or elsewhere on the host before being processed.
An endpoint MUST NOT include delays that it does not control when populating
the Ack Delay field in an ACK frame.

### ACK Frames and Packet Protection

Expand Down