Draft: draft-ietf-quic-recovery

Commentary: I 've reworded and I think the wording is better now . I 'll merge , but do comment if you think the wording needs fixing . 
 Consider the following sequence of packets being sent In our old loss recovery code ( before unifying TLP and RTO , ) , we used the following logic for determining if an RTO was not spurious , which would then lead to collapse of the congestion window : In the example above would be packet 14 . This means that to count as a verified RTO , an ACK must acknowledge 15 or 16 , but not any packets smaller or equal than 14 . With , we now collapse the congestion window when is larger than 2 and we receive an ACK which leads us to declare any packet lost . In the example above this means any ACK received after sending packet 15 which declares a packet lost would suffice . Even worse , this logic already triggers if we receive the ACK immediately after sending 15 , i.e. when the peer did n't even have a chance to receive it . This seems a lot more aggressive than what we had before before . Is this intentional ? 
 This is unintentional . I belIeve  is intending to fix this in PR , so please take a look at that . 
 If I understand correctly , is a fix for and only makes the description of the constant and the pseudo code consistent . 
 I believe the text is now correct , but the pseudocode is still incorrect in the way you describe . I think we should introduce a largestsentbefore_congestion variable as a replacement , but I 'm open to other solutions . 
 I 'm removing design . I consider this a bug fix , but still very important . 
 See which I believe fixes the text . 
 I 've been using to mark things that will result in changes that affect implementations . This would seem to fit that description . Whether you consider it worth discussing is different . If it is n't worth discussing , maybe it will just be fixed by and everything will be fine without discussion in Tokyo . WIthout the label , this wo n't make the change log , and that might be a problem . 
 Fair point , I think fixes the text , but I 'll re - label this as design to ensure it 's included in the changelogs . 
 The text says Similar text exists for the description of kPersistentCongestionThreshold . We actually only collapse the congestion window when receiving an ACK for a probe packet , and only if this ACK leads us to declare any packet(s ) lost . Specifically , this means that ptocount may grow larger than kPersistentCongestionThreshold , if no acknowledgements are received . 
 Good point . Sent .
Paragraph (version A):
If a threshold number of consecutive PTOs have occurred (pto_count is
more than kPersistentCongestionThreshold, see cc-consts-of-interest),
the network is considered to be experiencing persistent congestion,
and the sender's congestion window MUST be reduced to the minimum
congestion window.
Paragraph (version B):
When an ACK frame is received that establishes loss after a threshold
number of consecutive PTOs (pto_count is more than
kPersistentCongestionThreshold, see cc-consts-of-interest), the
network is considered to be experiencing persistent congestion, and
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.
Paragraph (version A):
Number of consecutive PTOs after which network is considered to be
experiencing persistent congestion.  The rationale for this
threshold is to enable a sender to use initial PTOs for aggressive
probing, similar to Tail Loss Probe (TLP) in TCP TLP RACK.  Once
the number of consecutive PTOs reaches this threshold - that is,
persistent congestion is established - the sender responds by
collapsing its congestion window to kMinimumWindow, similar to a
Retransmission Timeout (RTO) in TCP RFC5681.  The RECOMMENDED
value for kPersistentCongestionThreshold is 2, which is equivalent
to having two TLPs before an RTO in TCP.
Paragraph (version B):
Number of consecutive PTOs required for persistent congestion to
be established.  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
kPersistentCongestionThreshold is 2, which is equivalent to having
two TLPs before an RTO in TCP.