Draft: draft-ietf-quic-recovery

Commentary: Follow - up from 
 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 spurious RTO detection calls an RTO spurious if any unacked packets sent prior to the RTO are acked after the RTO . The implication here is that any packet that was received but not acked can cause the RTO to be labeled spurious , even if there were more packets that were in fact lost . This is not always right . Consider the following example : Packets 5 , 6 , 7 are sent Packet 5 is received , but 6 and 7 are dropped Ack of 5 is dropped TLPs ( packets 8 and 9 ) are sent and dropped RTO ( packet 10 ) is sent and received ACK acks 10 and 5 Since 5 was sent prior to RTO , RTO is marked spurious . A crisp definition of spurious RTO may be useful to continue . Here 's what I think is sensible : A spurious RTO is an unnecessary RTO . If the RTO timer had not gone off , things would have been fine . Based on this definition , clearly the RTO was necessary in the example , and therefore not spurious . We need to change the mechanism for detecting spurious RTOs , and I 'll propose the following . An RTO is spurious if an ack is received after the RTO fires that acks only packets sent prior to the RTO . In other words , RTO is spurious if ack is received after the RTO , and ( instead of , as the draft currently states ) . 
 This was recently changed because  ran into an issue ( ) where the RTO'd packet was acknowledged for the first time in the same ACK as the pre - RTO packets . In that case , I think it was due to an overly aggressive MinRTO and some pretty coarse grained timers , but I think we want to declare that RTO spurious , since everything would have been fine if it had n't been sent ? 
 : does not change the semantics substantively of what was in the draft . The intent was always to declare spurious RTO if ( packet prior to RTO was newly acked ) . I 'm proposing that we change that to ( no packet sent after RTO was newly acked ) . 
 In light of , I think this is OBE ? 
 Yes , this is OBE . Closing .
Paragraph (version A):
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 B):
When an ACK frame is received that establishes loss of all in-flight
packets sent prior to 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.