WGLC review of draft-ietf-quic-recovery-29

[Praveen Balasubramanian <[e-mail]>]

This is a WGLC review of draft-ietf-quic-recovery-29. Mostly editorial but some issues.


Section 2
" are not acknowledged, declared lost, or abandoned along with old keys." -->  are not acknowledged, declared lost, or discarded along with old keys."
Discarding is the term used in the rest of the doc notably in section 2.4. I see some reference to "abandon packets" in the transport draft as well. Would be good to use the same term for consistency everywhere.

Section 4.4.
 "does not allow any acked packet to be reneged" --> "does not allow any acknowledged packet to be reneged"

Section 4.7
"QUIC uses a probe timeout (see Section 6.2)," --> "QUIC uses a Probe Timeout (PTO) (see Section 6.2),"

Section 5.2 "If the path's actual RTT increases, the min_rtt will not adapt to it, allowing future RTT samples that are smaller than the  new RTT be included in smoothed_rtt."
Would it safer to reset min_rtt after persistent congestion is declared. This is important so we can adapt to a consistent spike in RTT as a result of a path change.

Section 6.1.1

"Algorithms that increase the reordering threshold after spuriously detecting losses, such as TCP-NCR [RFC4653], have proven to be useful in TCP and are expected to at least as useful in QUIC."
It might be better to refer to RACK here which has an optional feature to increase reorder threshold in time. I don't know of any major implementations that do TCP-NCR but maybe I am mistaken.

Section 6.2.1
"time threshold Section 6.1.2" --> time threshold (Section 6.1.2)

"The life of a connection that is experiencing consecutive PTOs is limited by the endpoint's idle timeout."
Is there any specification of recommended values for idle timeout? Any values lower than 9 seconds could adversely impact preserving of connectivity during VM live migration.

Section 6.2.4
"If the sender wants to elicit a faster acknowledgement on PTO, it can skip a packet number to eliminate the ack delay."
This adds some unnecessary complexity. Given that endpoint MAY send two full-sized datagrams, isn't that a better technique than skipping packet numbers?

Section 7.8
"The congestion period is calculated as the time between the oldest and newest lost packets: (3 - 0) = 3." --> "The congestion period is calculated as the sent time difference between the oldest and newest lost packets: (3 - 0) = 3."
It might be worth noting that persistent congestion can be declared without sending a PTO. Particularly because the example assumes PTOs. In the case where app kept on periodically sending new data and no ACKs came back for the threshold and then an ACK came back and declared all packets sent before it as lost.

Section 7.9
"Implementations MUST either use pacing or another method to limit such bursts to the initial congestion window; see Section 7.2."
This seems to preclude use of segmentation offload of sizes greater than IW. In datacenters we routinely send bursts that are higher without causing loss. The MUST here seems unnecessary. It also conflicts with the RECOMMENDED in an earlier sentence.

Section 8.2
"Endpoints can use PADDING frames or bundle acknowledgments with other frames to reduce leaked information."
A reminder should be added here that PADDING counts towards in-flight so there is a possible impact on performance.

Section B.8
The function AreAllPacketsLost does not have any pseudocode.


Thanks