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

Cleanup packet number text #288

Merged
merged 3 commits into from Feb 17, 2017
Merged

Cleanup packet number text #288

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
c8972c6
Random initial packet number
martinthomson Feb 10, 2017
467b6a4
Rewrite text on packet numbers
martinthomson Feb 10, 2017
49c2f4a
Ian had some comments
martinthomson Feb 13, 2017
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
13 changes: 7 additions & 6 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -505,7 +505,7 @@ The fields in a Regular packet past the Common Header are the following:
The packet number is a 64-bit unsigned number and is used as part of a
cryptographic nonce for packet encryption. Each endpoint maintains a separate
packet number for sending and receiving. The packet number for sending MUST
increase by one after sending any packet.
increase by at least one after sending any packet.

A QUIC endpoint MUST NOT reuse a packet number within the same connection (that
is, under the same cryptographic keys). If the packet number for sending
Expand All @@ -529,8 +529,8 @@ To enable unambiguous reconstruction of the packet number, an endpoint MUST use
a packet number size that is able to represent 4 times more packet numbers than
the endpoint has currently outstanding. A packet is outstanding if it sent but
has neither been acknowledged nor been marked as lost (see {{QUIC-RECOVERY}}).
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we really want to define "outstanding" by the number of packets w/o ACKs? I'd rather define it by the number of packet numbers between the current packet number and the earliest packet w/o ACKs.

For a high bandwidth, high latency connection, if I have packet 10 "delayed", but packets 11-1033 have been acked, do I really only have 1 packet "outstanding" and therefore can use the smallest number of bits to encode the following packet number?

Copy link
Member Author

Choose a reason for hiding this comment

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

@igorlord, I agree, as does Ryan. But I'm trying to keep this PR strictly editorial and I think that this is what the original text is trying to say. I will create a follow-up PR that makes the change you suggest.

As a result, the size of the packet number encoding is at least two more than
the base 2 logarithm of the number of outstanding packets, rounded up. For
As a result, the size of the packet number encoding is at least two more bits
than the base 2 logarithm of the number of outstanding packets, rounded up. For
example, if an endpoint has 14,389 packets outstanding, the next packet uses a
16-bit or larger packet number encoding; a 32-bit packet number is needed if
there are 20,000 packets outstanding.
Expand Down Expand Up @@ -658,9 +658,10 @@ that the client selected.
When the client receives a Version Negotiation packet from the server, it should
select an acceptable protocol version. If the server lists an acceptable
version, the client selects that version and reattempts to created a connection
using that version. The client MUST update packet numbers when attempting to
connect with the updated version. Packets MUST continue to have the VERSION
flag set and MUST include the new negotiated protocol version.
using that version. Though the contents of a packet might not change in
response to version negotiation, a client MUST increase the packet number it
uses on every packet it sends. Packets MUST continue to have the VERSION flag
set and MUST include the new negotiated protocol version.

The client MUST set the VERSION flag and include its selected version on all
packets until it has 1-RTT keys and it has received a packet from the server
Expand Down