Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
Merge branch 'master' into ianswett-pto-per-pn-space
  • Loading branch information
ianswett committed Oct 24, 2019
2 parents 3abb835 + f07c067 commit 33c994e
Show file tree
Hide file tree
Showing 6 changed files with 385 additions and 393 deletions.
301 changes: 134 additions & 167 deletions draft-ietf-quic-http.md

Large diffs are not rendered by default.

223 changes: 110 additions & 113 deletions draft-ietf-quic-qpack.md

Large diffs are not rendered by default.

55 changes: 30 additions & 25 deletions draft-ietf-quic-recovery.md
Expand Up @@ -410,19 +410,20 @@ early, this time threshold MUST be set to at least kGranularity. The time
threshold is:

~~~
kTimeThreshold * max(SRTT, latest_RTT, kGranularity)
kTimeThreshold * max(smoothed_rtt, latest_rtt, kGranularity)
~~~

If packets sent prior to the largest acknowledged packet cannot yet be declared
lost, then a timer SHOULD be set for the remaining time.

Using max(SRTT, latest_RTT) protects from the two following cases:
Using max(smoothed_rtt, latest_rtt) protects from the two following cases:

* the latest RTT sample is lower than the SRTT, perhaps due to reordering where
the acknowledgement encountered a shorter path;
* the latest RTT sample is lower than the smoothed RTT, perhaps due to
reordering where the acknowledgement encountered a shorter path;

* the latest RTT sample is higher than the SRTT, perhaps due to a sustained
increase in the actual RTT, but the smoothed SRTT has not yet caught up.
* the latest RTT sample is higher than the smoothed RTT, perhaps due to a
sustained increase in the actual RTT, but the smoothed RTT has not yet caught
up.

The RECOMMENDED time threshold (kTimeThreshold), expressed as a round-trip time
multiplier, is 9/8.
Expand All @@ -438,13 +439,13 @@ and larger thresholds increase loss detection delay.
A Probe Timeout (PTO) triggers sending one or two probe datagrams when
ack-eliciting packets are not acknowledged within the expected period of
time or the handshake has not been completed. A PTO enables a connection to
recover from loss of tail packets or acknowledgements. As with loss
detection, the probe timeout is per packet number space.
recover from loss of tail packets or acknowledgements.

As with loss detection, the probe timeout is per packet number space.
The PTO algorithm used in QUIC implements the reliability functions of
Tail Loss Probe {{?TLP=I-D.dukkipati-tcpm-tcp-loss-probe}} {{?RACK}},
RTO {{?RFC5681}} and F-RTO algorithms for TCP {{?RFC5682}}, and the timeout
computation is based on TCP's retransmission timeout period {{?RFC6298}}.
Tail Loss Probe {{?RACK}}, RTO {{?RFC5681}} and F-RTO algorithms for
TCP {{?RFC5682}}, and the timeout computation is based on TCP's
retransmission timeout period {{?RFC6298}}.

### Computing PTO

Expand Down Expand Up @@ -557,7 +558,7 @@ Probe packets sent on a PTO MUST be ack-eliciting. A probe packet SHOULD carry
new data when possible. A probe packet MAY carry retransmitted unacknowledged
data when new data is unavailable, when flow control does not permit new data to
be sent, or to opportunistically reduce loss recovery delay. Implementations
MAY use alternate strategies for determining the content of probe packets,
MAY use alternative strategies for determining the content of probe packets,
including sending new or retransmitted data based on the application's
priorities.

Expand Down Expand Up @@ -741,15 +742,15 @@ When persistent congestion is established, the sender's congestion window MUST
be reduced to the minimum congestion window (kMinimumWindow). This response of
collapsing the congestion window on persistent congestion is functionally
similar to a sender's response on a Retransmission Timeout (RTO) in TCP
{{RFC5681}} after Tail Loss Probes (TLP) {{TLP}}.
{{RFC5681}} after Tail Loss Probes (TLP) {{RACK}}.

## Pacing {#pacing}

This document does not specify a pacer, but it is RECOMMENDED that a sender pace
sending of all in-flight packets based on input from the congestion
controller. For example, a pacer might distribute the congestion window over
the SRTT when used with a window-based controller, and a pacer might use the
rate estimate of a rate-based controller.
the smoothed RTT when used with a window-based controller, and a pacer might use
the rate estimate of a rate-based controller.

An implementation should take care to architect its congestion controller to
work well with a pacer. For instance, a pacer might wrap the congestion
Expand All @@ -759,15 +760,23 @@ delivery of ACK frames is important for efficient loss recovery. Packets
containing only ACK frames should therefore not be paced, to avoid delaying
their delivery to the peer.

Sending multiple packets into the network without any delay between them
creates a packet burst that might cause short-term congestion and losses.
Implementations MUST either use pacing or limit such bursts to the minimum
of 10 * kMaxDatagramSize and max(2* kMaxDatagramSize, 14720)), the same
as the recommended initial congestion window.

As an example of a well-known and publicly available implementation of a flow
pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc)
in Linux (3.11 onwards).

## Under-utilizing the Congestion Window

A congestion window that is under-utilized SHOULD NOT be increased in either
slow start or congestion avoidance. This can happen due to insufficient
application data or flow control credit.
When bytes in flight is smaller than the congestion window and sending is not
pacing limited, the congestion window is under-utilized. When this occurs,
the congestion window SHOULD NOT be increased in either slow start or
congestion avoidance. This can happen due to insufficient application data
or flow control credit.

A sender MAY use the pipeACK method described in section 4.3 of {{?RFC7661}}
to determine if the congestion window is sufficiently utilized.
Expand All @@ -777,11 +786,7 @@ and not fully utilize the congestion window due to this delay. A sender
should not consider itself application limited if it would have fully
utilized the congestion window without pacing delay.

Bursting more than an initial window's worth of data into the network might
cause short-term congestion and losses. Implemementations SHOULD either use
pacing or reduce their congestion window to limit such bursts.

A sender MAY implement alternate mechanisms to update its congestion window
A sender MAY implement alternative mechanisms to update its congestion window
after periods of under-utilization, such as those proposed for TCP in
{{?RFC7661}}.

Expand Down Expand Up @@ -1268,8 +1273,8 @@ kPersistentCongestionThreshold:
: Period of time for persistent congestion to be established, specified as a PTO
multiplier. The rationale for this threshold is to enable a sender to use
initial PTOs for aggressive probing, as TCP does with Tail Loss Probe (TLP)
{{TLP}} {{RACK}}, before establishing persistent congestion, as TCP does with
a Retransmission Timeout (RTO) {{?RFC5681}}. The RECOMMENDED value for
{{RACK}}, before establishing persistent congestion, as TCP does with a
Retransmission Timeout (RTO) {{?RFC5681}}. The RECOMMENDED value for
kPersistentCongestionThreshold is 3, which is approximately equivalent to
having two TLPs before an RTO in TCP.

Expand Down
51 changes: 40 additions & 11 deletions draft-ietf-quic-tls.md
Expand Up @@ -278,13 +278,14 @@ components:
protection being called out specially.

~~~
+------------+ +------------+
| |<- Handshake Messages ->| |
| |<---- 0-RTT Keys -------| |
| |<--- Handshake Keys-----| |
| QUIC |<---- 1-RTT Keys -------| TLS |
| |<--- Handshake Done ----| |
+------------+ +------------+
+------------+ +------------+
| |<---- Handshake Messages ----->| |
| |<- Validate 0-RTT parameters ->| |
| |<--------- 0-RTT Keys ---------| |
| QUIC |<------- Handshake Keys -------| TLS |
| |<--------- 1-RTT Keys ---------| |
| |<------- Handshake Done -------| |
+------------+ +------------+
| ^
| Protect | Protected
v | Packet
Expand Down Expand Up @@ -323,7 +324,7 @@ establishing the connection can usually appear at any encryption level, whereas
those associated with transferring data can only appear in the 0-RTT and 1-RTT
encryption levels:

- PADDING frames MAY appear in packets of any encryption level.
- PADDING and PING frames MAY appear in packets of any encryption level.

- CRYPTO and CONNECTION_CLOSE frames MAY appear in packets of any encryption
level except 0-RTT.
Expand Down Expand Up @@ -358,10 +359,12 @@ levels fit into the handshake process.

## Interface to TLS

As shown in {{schematic}}, the interface from QUIC to TLS consists of three
As shown in {{schematic}}, the interface from QUIC to TLS consists of four
primary functions:

- Sending and receiving handshake messages
- Processing stored transport and application state from a resumed session
and determining if it is valid to accept early data
- Rekeying (both transmit and receive)
- Handshake state updates

Expand Down Expand Up @@ -617,8 +620,13 @@ MAY refuse a connection if the client is unable to authenticate when requested.
The requirements for client authentication vary based on application protocol
and deployment.

A server MUST NOT use post-handshake client authentication (see Section 4.6.2 of
{{!TLS13}}).
A server MUST NOT use post-handshake client authentication (as defined in
Section 4.6.2 of {{!TLS13}}), because the multiplexing offered by QUIC prevents
clients from correlating the certificate request with the application-level
event that triggered it (see {{?HTTP2-TLS13=I-D.ietf-httpbis-http2-tls13}}).
More specifically, servers MUST NOT send post-handshake TLS CertificateRequest
messages and clients MUST treat receipt of such messages as a connection error
of type PROTOCOL_VIOLATION.


## Enabling 0-RTT {#enable-0rtt}
Expand Down Expand Up @@ -659,6 +667,27 @@ A client MAY attempt to send 0-RTT again if it receives a Retry or Version
Negotiation packet. These packets do not signify rejection of 0-RTT.


## Validating 0-RTT Configuration

When a server receives a ClientHello with the "early_data" extension, it has to
decide whether to accept or reject early data from the client. Some of this
decision is made by the TLS stack (e.g., checking that the cipher suite being
resumed was included in the ClientHello; see Section 4.2.10 of {{!TLS13}}). Even
when the TLS stack has no reason to reject early data, the QUIC stack or the
application protocol using QUIC might reject early data because the
configuration of the transport or application associated with the resumed
session is not compatible with the server's current configuration.

QUIC requires additional transport state to be associated with a 0-RTT session
ticket. One common way to implement this is using stateless session tickets and
storing this state in the session ticket. Application protocols that use QUIC
might have similar requirements regarding associating or storing state. This
associated state is used for deciding whether early data must be rejected. For
example, HTTP/3 ({{QUIC-HTTP}}) settings determine how early data from the
client is interpreted. Other applications using QUIC could have different
requirements for determining whether to accept or reject early data.


## HelloRetryRequest

In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of {{!TLS13}})
Expand Down

0 comments on commit 33c994e

Please sign in to comment.