Draft: draft-ietf-quic-recovery

Commentary: This PR is also a good spot to comment on my accidental commit ( ) to master . I can make any changes to that in this PR . 
 This was filed a while ago ( before WGLC ended ) , did n't want to drop it . 
 Editorial , design ? 
 There is a design issue here regarding the initial congestion window that I would like to see split out into a new issue ( which can be marked design ) . The rest appear to be things we can address with editorial changes . 
 I moved the IW text into , though I 'm not sure I think it 's worth revisiting . 
 Thanks :) I agree that it is n't worth re - opening , but we did sign on to at least discuss whether it is worth discussing . 
 Do we have a plan for this one ? 
 So , is there a plan ? ( Is there even anything left to do ? ) 
 Some of these are addressed already , others are in an accidental commit ( ) , and for some there 's no need to address them in the text . The rest are in 
 Some suggestions only . One nit , but LGTM .
Paragraph (version A):
Some networks may exhibit higher degrees of packet reordering,
causing a sender to detect spurious losses.  Additionally, packet
reordering could be more common with QUIC than TCP, because network
elements that could observe and reorder out-of-order TCP packets
cannot do that for QUIC, because packet numbers are encrypted.
Algorithms that increase the reordering threshold after spuriously
detecting losses, such as RACK RACK, have proven to be useful in TCP
and are expected to be at least as useful in QUIC.
Paragraph (version B):
Some networks may exhibit higher degrees of packet reordering,
causing a sender to detect spurious losses.  Additionally, packet
reordering could be more common with QUIC than TCP, because network
elements that could observe and reorder TCP packets cannot do that
for QUIC, because QUIC packet numbers are encrypted.  Algorithms that
increase the reordering threshold after spuriously detecting losses,
such as RACK RACK, have proven to be useful in TCP and are expected
to be at least as useful in QUIC.
Paragraph (version A):
The time length of a connection that is experiencing consecutive PTOs
is limited by the endpoint's idle timeout.
Paragraph (version B):
The total length of time over which consecutive PTOs expire is
limited by the idle timeout.
Paragraph (version A):
Since the server could be blocked until more datagrams are received
from the client, it is the client's responsibility to send packets to
unblock the server until it is certain that the server has finished
its address validation (see Section 8 of QUIC-TRANSPORT).  That is,
the client MUST set the probe timer if the client has not received an
acknowledgement for one of its Handshake packets and the handshake is
not confirmed (see Section 4.1.2 of QUIC-TLS), even if there are no
packets in flight.  When the PTO fires, the client MUST send a
Handshake packet if it has Handshake keys, otherwise it MUST send an
Initial packet in a UDP datagram of at least 1200 bytes.
Paragraph (version B):
Since the server could be blocked until more datagrams are received
from the client, it is the client's responsibility to send packets to
unblock the server until it is certain that the server has finished
its address validation (see Section 8 of QUIC-TRANSPORT).  That is,
the client MUST set the probe timer if the client has not received an
acknowledgement for one of its Handshake packets and the handshake is
not confirmed (see Section 4.1.2 of QUIC-TLS), even if there are no
packets in flight.  When the PTO fires, the client MUST send a
Handshake packet if it has Handshake keys, otherwise it MUST send an
Initial packet in a UDP datagram with a payload of at least 1200
bytes.
Paragraph (version A):
Endpoints can also use coalesced packets to ensure that each datagram
elicits at least one acknowledgement.  For example, a client can
coalesce an Initial packet containing PING and PADDING frames with a
0-RTT data packet and a server can coalesce an Initial packet
containing a PING frame with one or more packets in its first flight.
Paragraph (version B):
Endpoints can also use coalesced packets (see Section 12.2 of QUIC-
TRANSPORT) to ensure that each datagram elicits at least one
acknowledgement.  For example, a client can coalesce an Initial
packet containing PING and PADDING frames with a 0-RTT data packet
and a server can coalesce an Initial packet containing a PING frame
with one or more packets in its first flight.
Paragraph (version A):
QUIC begins every connection in slow start with the congestion window
set to an initial value.  Endpoints SHOULD use an initial congestion
window of 10 times the maximum datagram size (max_datagram_size),
limited to the larger of 14720 or twice the maximum datagram size.
This follows the analysis and recommendations in RFC6928, increasing
the byte limit to account for the smaller 8 byte overhead of UDP
compared to the 20 byte overhead for TCP.
Paragraph (version B):
QUIC begins every connection in slow start with the congestion window
set to an initial value.  Endpoints SHOULD use an initial congestion
window of 10 times the maximum datagram size (max_datagram_size),
limited to the larger of 14720 bytes or twice the maximum datagram
size.  This follows the analysis and recommendations in RFC6928,
increasing the byte limit to account for the smaller 8 byte overhead
of UDP compared to the 20 byte overhead for TCP.