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.
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
Stream0 dt output for merge #1450
Changes from all commits
42f55df
cab8295
984ecc8
36899e5
f8f172f
70b26e8
af70f23
aa1b683
927cf12
74300a1
04fd321
bf9c62c
77155f9
779b3a0
d3b055a
48c9b9f
396c318
777114a
a4ad49b
6b36300
0cfdf67
4065266
954c585
d814642
da0d8ec
89c45a6
daea861
3aea50d
bd5f9ff
e2ed4db
7a780db
4db5568
8d57711
a2aabfe
2473966
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -89,12 +89,16 @@ when, and only when, they appear in all capitals, as shown here. | |
|
||
# Design of the QUIC Transmission Machinery | ||
|
||
All transmissions in QUIC are sent with a packet-level header, which includes a | ||
packet sequence number (referred to below as a packet number). These packet | ||
numbers never repeat in the lifetime of a connection, and are monotonically | ||
increasing, which prevents ambiguity. This fundamental design decision | ||
obviates the need for disambiguating between transmissions and | ||
retransmissions and eliminates significant complexity from QUIC's | ||
All transmissions in QUIC are sent with a packet-level header, which indicates | ||
the encryption level and includes a packet sequence number | ||
(referred to below as a packet number). The encryption level indicates the | ||
packet number space, as described in {{QUIC-TRANSPORT}}. Packet | ||
numbers never repeat within a packet number space for the lifetime of a | ||
connection. Packet numbers monotonically increase within a space, | ||
preventing ambiguity. | ||
|
||
This design obviates the need for disambiguating between transmissions | ||
and retransmissions and eliminates significant complexity from QUIC's | ||
interpretation of TCP loss detection mechanisms. | ||
|
||
Every packet may contain several frames. We outline the frames that are | ||
|
@@ -107,7 +111,7 @@ important to the loss detection and congestion control machinery below. | |
* Retransmittable packets are those that contain at least one | ||
retransmittable frame. | ||
|
||
* Crypto handshake data is sent on stream 0, and uses the reliability | ||
* Crypto handshake data is sent in CRYPTO_HS frames, and uses the reliability | ||
machinery of QUIC underneath. | ||
|
||
* ACK frames contain acknowledgment information. ACK frames contain one or more | ||
|
@@ -120,6 +124,15 @@ algorithms here that parallel well-known TCP ones. Protocol differences between | |
QUIC and TCP however contribute to algorithmic differences. We briefly describe | ||
these protocol differences below. | ||
|
||
### Separate Packet Number Spaces | ||
|
||
QUIC uses separate packet number spaces for each encryption level, except | ||
0-RTT and all generations of 1-RTT keys use the same packet number space. | ||
Separate packet number spaces ensures acknowledgement of packets sent | ||
with one level of encryption will not cause spurious retransmission of packets | ||
sent with a different encryption level. Congestion control and RTT measurement | ||
are unified across packet number spaces. | ||
|
||
### Monotonically Increasing Packet Numbers | ||
|
||
TCP conflates transmission sequence number at the sender with delivery sequence | ||
|
@@ -259,17 +272,18 @@ prone to spurious retransmissions due to its reduced reordering resilence | |
without the alarm. This observation led Linux TCP implementers to implement an | ||
alarm for TCP as well, and this document incorporates this advancement. | ||
|
||
|
||
## Timer-based Detection | ||
|
||
Timer-based loss detection implements a handshake retransmission timer that | ||
is optimized for QUIC as well as the spirit of TCP's Tail Loss Probe | ||
and Retransmission Timeout mechanisms. | ||
|
||
### Handshake Timeout | ||
### Crypto Handshake Timeout | ||
|
||
Handshake packets, which contain STREAM frames for stream 0, are critical to | ||
QUIC transport and crypto negotiation, so a separate alarm is used for them. | ||
Data in CRYPTO_HS frames is critical to QUIC transport and crypto negotiation, | ||
so a more aggressive timeout is used to retransmit it. Below, the word | ||
handshake packet is used to refer to packets containing CRYPTO_HS frames, | ||
not packets with the specific long header packet type Handshake. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This h/H thing is not ideal, but we don't need to fix it before landing this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Leaving as-is |
||
|
||
The initial handshake timeout SHOULD be set to twice the initial RTT. | ||
|
||
|
@@ -280,23 +294,28 @@ connection's final smoothed RTT value as the resumed connection's initial RTT. | |
If no previous RTT is available, or if the network changes, the initial RTT | ||
SHOULD be set to 100ms. | ||
|
||
When a handshake packet is sent, the sender SHOULD set an alarm for the | ||
handshake timeout period. | ||
When CRYPTO_HS frames are sent, the sender SHOULD set an alarm for the | ||
handshake timeout period. When the alarm fires, the sender MUST retransmit | ||
all unacknowledged CRYPTO_HS data by calling | ||
RetransmitAllUnackedHandshakeData(). On each consecutive firing of the | ||
handshake alarm without receiving an acknowledgement for a new packet, | ||
the sender SHOULD double the handshake timeout and set an alarm for this | ||
period. | ||
|
||
When the alarm fires, the sender MUST retransmit all unacknowledged handshake | ||
data, by calling RetransmitAllUnackedHandshakeData(). On each consecutive | ||
firing of the handshake alarm, the sender SHOULD double the handshake timeout | ||
and set an alarm for this period. | ||
When CRYPTO_HS frames are outstanding, the TLP and RTO timers are not active | ||
unless the CRYPTO_HS frames were sent at 1RTT encryption. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this encryption level or packet number space? Also, the first SHOULD in the previous paragraph needs at least one caveat for this case. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @ianswett: ^^? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was intending it to be encryption level, since I thought it was necessary to send end of early data in a timely manner? But maybe it doesn't matter that much? It's possible a signal that the handshake is complete would be preferable to monitoring what encryption level CRYPTO_HS is sent at, but I'll just make it consistent for now. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds reasonable. I just wanted to check. And yeah, we probably need to send EndOfEarlyData quickly. It blocks access to 1-RTT data just like Finished. |
||
|
||
When an acknowledgement is received for a handshake packet, the new RTT is | ||
computed and the alarm SHOULD be set for twice the newly computed smoothed RTT. | ||
|
||
Handshake data may be cancelled by handshake state transitions. In particular, | ||
all non-protected data SHOULD no longer be transmitted once packet protection | ||
is available. | ||
#### Retry | ||
|
||
A Retry packet causes the content of the client's Initial packet to be | ||
immediately retransmitted along with the token present in the Retry. | ||
|
||
(TODO: Work this section some more. Add text on client vs. server, and on | ||
stateless retry.) | ||
The Retry indicates that the Initial was received but not processed. | ||
It MUST NOT be treated as an acknowledgment for the Initial, | ||
but it MAY be used for an RTT measurement. | ||
|
||
### Tail Loss Probe {#tlp} | ||
|
||
|
@@ -422,6 +441,14 @@ sending any ACK frames in response. In this case they can determine | |
whether an immediate or delayed acknowledgement should be generated | ||
after processing incoming packets. | ||
|
||
### Crypto Handshake Data | ||
|
||
In order to quickly complete the handshake and avoid spurious | ||
retransmissions due to handshake alarm timeouts, handshake packets | ||
SHOULD use a very short ack delay, such as 1ms. ACK frames MAY be | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The MAY is weird. ACK can always be sent immediately. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It does seem like this should be a SHOULD |
||
sent immediately when the crypto stack indicates all data for that | ||
encryption level has been received. | ||
|
||
### ACK Ranges | ||
|
||
When an ACK frame is sent, one or more ranges of acknowledged packets are | ||
|
@@ -514,7 +541,7 @@ time_of_last_sent_retransmittable_packet: | |
: The time the most recent retransmittable packet was sent. | ||
|
||
time_of_last_sent_handshake_packet: | ||
: The time the most recent packet containing handshake data was sent. | ||
: The time the most recent packet containing a CRYPTO_HS frame was sent. | ||
|
||
largest_sent_packet: | ||
: The packet number of the most recently sent packet. | ||
|
@@ -559,6 +586,8 @@ sent_packets: | |
was sent, a boolean indicating whether the packet is ack only, and a bytes | ||
field indicating the packet's size. sent_packets is ordered by packet | ||
number, and packets remain in sent_packets until acknowledged or lost. | ||
A sent_packets data structure is maintained per packet number space, and ACK | ||
processing only applies to a single space. | ||
|
||
### Initialization | ||
|
||
|
@@ -711,7 +740,7 @@ closed once a reject is sent, so no timer is set to retransmit the reject. | |
|
||
Version negotiation packets are always stateless, and MUST be sent once per | ||
handshake packet that uses an unsupported QUIC version, and MAY be sent in | ||
response to 0RTT packets. | ||
response to 0-RTT packets. | ||
|
||
#### Tail Loss Probe and Retransmission Alarm | ||
|
||
|
@@ -807,18 +836,11 @@ Pseudocode for OnLossDetectionAlarm follows: | |
|
||
### Detecting Lost Packets | ||
|
||
Packets in QUIC are only considered lost once a larger packet number is | ||
acknowledged. DetectLostPackets is called every time an ack is received. | ||
If the loss detection alarm fires and the loss_time is set, the previous | ||
largest acked packet is supplied. | ||
|
||
#### Handshake Packets | ||
|
||
The receiver MUST close the connection with an error of type OPTIMISTIC_ACK | ||
when receiving an unprotected packet that acks protected packets. | ||
The receiver MUST trust protected acks for unprotected packets, however. Aside | ||
from this, loss detection for handshake packets when an ack is processed is | ||
identical to other packets. | ||
Packets in QUIC are only considered lost once a larger packet number in | ||
the same packet number space is acknowledged. DetectLostPackets is called | ||
every time an ack is received and operates on the sent_packets for that | ||
packet number space. If the loss detection alarm fires and the loss_time | ||
is set, the previous largest acked packet is supplied. | ||
|
||
#### Pseudocode | ||
|
||
|
@@ -1084,6 +1106,15 @@ This document has no IANA actions. Yet. | |
> **RFC Editor's Note:** Please remove this section prior to | ||
> publication of a final version of this document. | ||
|
||
## Since draft-ietf-quic-recovery-12 | ||
|
||
- Updated to match the Stream0 design team proposal. | ||
- Text on multiple packet number spaces. | ||
|
||
## Since draft-ietf-quic-recovery-11 | ||
|
||
No significant changes. | ||
|
||
## Since draft-ietf-quic-recovery-10 | ||
|
||
- Improved text on ack generation (#1139, #1159) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/CRYPTO_HS/CRYPTO/g
Yes, I understand that there is a message that carries a TLS alert, but I don't think that's ideal. If we want to carry alerts, we can pack the range of cryptographic alerts into the CONNECTION_CLOSE space, or recommend that the reason phrase start with the alert.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am going to hold this for now. It's a simple sed script once we decide what this should say and CRYPTO_HS is easier to sed.
I disagree with you about the alerts, so let's pick that up on-list.