Re: [tcpm] I-D Action: draft-ietf-tcpm-prr-rfc6937bis-02.txt

["Scheffenegger, Richard" <[e-mail]>]

Hi Yuchung,

>> The forced fast retransmit may not be reflected in the PRR packet 
>> diagram - unless I didn't quite understand the values there...
>
> The examples do not include force retransmit examples. We'd clarify that in the description of the examples to clarify.
>> PRR
>>     ack#   X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19
>>     cwnd:    20 20 19 19 18 17 17 16 16 15 15 14 14 13 13 12 12 11 10
>>     pipe:    19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10
>>     sent:     N  N  R  N        N     N     N     N     N     N     N
>
> no because forced retransmit only applies when the fast recovery starts (i.e. prr_out = 0). by ack #4, prr_out is already 1 due to the first "R".

Ah, clear now with your explanation.

>> Sec 9 - SafeAck seems to indicate, when SACK is in use, that no new 
>> SACK range is included (adding a new hole to the scoreboard). However, 
>> in a non-SACK case, due to the lack of this knowledge, wouldn't be all 
>> partial ACKs be considered to be SafeACKs?
>
> Yes when SACK is not used SafeACK will be true for all partial ACKs.
> To clarify better, we'd add LRD requirement on SACK and non-SACK sup
>
> The current wording in the section "Changes from RFC 6937 is less clear.
> We'd revise from "For TCP, when the latest ACK advances snd.una and
> does not indicate prior fast retransmit has been lost"
> to
> "For TCP, when the latest ACK advances snd.una and does not indicate
>  further new packet losses on both SACK and NonSACK"
>
> And we'd change the SafeACK descriptions accordingly so they are
> consistent across the draft. How to detect packet losses (including
> retransmission) is out of scope of PRR (eg sack blocks changes). PRR
> recommends RACK-TLP but does not want to mandate a particular
> loss detection.
>
> Does that answer your question?


I wonder if a simplistic detection logic like I mentioned (e.g. w/ SACK, a partial ACK which does not shrink any scoreboard holes, or a DupACK where holes only shrink from the left (but not from the right, or get split) is good enough. I think it should be - but then again I understand now your reasoning of not including a concrete example. But for stacks not featuring LRD, alluding to how an ACK would need to look like, may be beneficial to an implementer.

Thanks for the detailed explanations!

Best regards,
 Richard