Draft: draft-ietf-quic-recovery

Commentary: The spec says that " congestion avoidance " after " slow start " . However , it seems to me that pseudocode enters " recovery " after " slow start " . When packets are lost , is called : This function sets if the state is not " recovery " , which means either " slow start " or " congestion avoidance " . So , " recovery " starts after " slow start " . 
 : you are right ; perhaps this could be made part of ? 
 Better definition of each state is welcome . But I 'm talking about the pseudocode . My implementation based on the pseudocode enters " recovery " after " slow start " . That 's why I noticed this issue . We should fix the pseudocode somehow . ( To fix this bug , I introduced a variable to hold the state explicitly in Haskell quic . ) 
 Entering recovery after slow start is correct . The language in the draft was confusing . Hopefully helps there . 
 Indeed ... 
 After merging , the pseudocode matches the language . Let 's close this . 
 Let 's leave this open until merges then . 
 Looks good , but it 's a bit change , so I 'd like review as well .
Paragraph (version A):
MUST ignore the ACK Delay field of the ACK frame for packets sent
in the Initial and Handshake packet number space.
Paragraph (version A):
MUST use the lesser of the value reported in ACK Delay field of
the ACK frame and the peer's max_ack_delay transport parameter.
Paragraph (version A):
MUST NOT apply the adjustment if the resulting RTT sample is
smaller than the min_rtt.  This limits the underestimation that a
misreporting peer can cause to the smoothed_rtt.
Paragraph (version B):
As with loss detection, the probe timeout is per packet number space.
That is, a PTO value is computed per packet number space.
Paragraph (version B):
The PTO algorithm used in QUIC implements the reliability functions
of Tail Loss Probe RACK, RTO RFC5681, and F-RTO algorithms for TCP
RFC5682.  The timeout computation is based on TCP's retransmission
timeout period RFC6298.
Paragraph (version A):
The PTO value MUST be set to at least kGranularity, to avoid the
timer expiring immediately.
Paragraph (version B):
The PTO period MUST be at least kGranularity, to avoid the timer
expiring immediately.
Paragraph (version B):
When ack-eliciting packets in multiple packet number spaces are in
flight, the timer MUST be set to the earlier value of the Initial and
Handshake packet number spaces.
Paragraph (version A):
The recovery period aims to limit congestion window reduction to once
per round trip.  Therefore during recovery, the congestion window
remains unchanged irrespective of new losses or increases in the ECN-
CE counter.
Paragraph (version B):
The NewReno congestion controller described in this document has
three distinct states, as shown in fig-cc-fsm.
Paragraph (version B):
These states and the transitions between them are described in
subsequent sections.
Paragraph (version B):
A NewReno sender is in slow start any time the congestion window is
below the slow start threshold.  A sender begins in slow start
because the slow start threshold is initialized to an infinite value.
Paragraph (version B):
While a sender is in slow start, the congestion window increases by
the number of bytes acknowledged when each acknowledgment is
processed.  This results in exponential growth of the congestion
window.
Paragraph (version B):
The sender MUST exit slow start and enter a recovery period when a
packet is lost or when the ECN-CE count reported by its peer
increases.
Paragraph (version B):
A NewReno sender enters a recovery period when it detects the loss of
a packet or the ECN-CE count reported by its peer increases.  A
sender that is already in a recovery period stays in it and does not
re-enter it.
Paragraph (version B):
On entering a recovery period, a sender MUST set the slow start
threshold to half the value of the congestion window when loss is
detected.  The congestion window MUST be set to the reduced value of
the slow start threshold before exiting the recovery period.
Paragraph (version B):
Implementations MAY reduce the congestion window immediately upon
entering a recovery period or use other mechanisms, such as
Proportional Rate Reduction (PRR), to reduce the congestion window
more gradually.  If the congestion window is reduced immediately, a
single packet can be sent prior to reduction.  This speeds up loss
recovery if the data in the lost packet is retransmitted and is
similar to TCP as described in Section 5 of RFC6675.
Paragraph (version B):
The recovery period aims to limit congestion window reduction to once
per round trip.  Therefore during a recovery period, the congestion
window does not change in response to new losses or increases in the
ECN-CE count.
Paragraph (version B):
A recovery period ends and the sender enters congestion avoidance
when a packet sent during the recovery period is acknowledged.  This
is slightly different from TCP's definition of recovery, which ends
when the lost segment that started recovery is acknowledged
(RFC5681).
Paragraph (version B):
A NewReno sender is in congestion avoidance any time the congestion
window is at or above the slow start threshold and not in a recovery
period.
Paragraph (version B):
A sender in congestion avoidance uses an Additive Increase
Multiplicative Decrease (AIMD) approach that MUST limit the increase
to the congestion window to at most one maximum datagram size for
each congestion window that is acknowledged.
Paragraph (version B):
The sender exits congestion avoidance and enters a recovery period
when a packet is lost or when the ECN-CE count reported by its peer
increases.