Re: [tcpm] RACK - variable explanation

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

Am 28.11.2018 um 16:56 schrieb Ilpo Järvinen:
> On Wed, 28 Nov 2018, Richard Scheffenegger wrote:
>> Am 22.11.2018 um 17:16 schrieb Neal Cardwell:
>>> On Thu, Nov 22, 2018 at 10:28 AM Felix Weinrank <[e-mail]>
>>> wrote:
>>>>
>>>> I don't completely understand the following check:
>>>>
>>>>           If RACK.reordering_seen is FALSE:
>>>>               If in loss recovery:  /* If in fast or timeout recovery */
>>>>                   RACK.reo_wnd = 0
>>>>                   Return
>>>>               Else if RACK.pkts_sacked >= RACK.dupthresh:
>>>>                   RACK.reo_wnd = 0
>>>>                   return
>>>>
>>>> The Draft says:
>>>> "RACK.pkts_sacked" returns the total number of packets selectively
>>>> acknowledged in the SACK scoreboard.
>>>>
>>>> Whats the purpose of this check: RACK.pkts_sacked >= RACK.dupthresh
>>>
>>> This is the traditional TCP Fast Retransmit heuristic, described in
>>> https://tools.ietf.org/html/rfc5681 in section 3.2, and
>>> https://tools.ietf.org/html/rfc6675 in section 5, and the older
>>> https://tools.ietf.org/html/rfc2001 in section 3.
>>
>> To be pedandic, only RFC3517 and RFC6675 would be applicable directly, as RACK
>> requires SACK support.
>>
>> Also, RFC6675 explicitly shortened the trigger condition from receiving 3
>> DupACKs down to FACK > (dupthresh - 1)*SMSS.
> 
> Where does that "FACK" part come from? Not from RFC6675 for sure. The
> condition given in RFC6675 requires at least that many bytes to be
> acknowledged by SACK blocks to trigger recovery, not just sequence
> distance like FACK does.
:
:
> 
> RFC6675 algorithm requires a positive proof that at least 3 MSS sized
> packets were delirered. The algorithm just doesn't use dup ACK as a proxy
> for that but bases the decision on scoreboard details only. Maybe you're
> misreading the RFC6675 somehow?

Indeed, sorry for my confusion. So to sum up, entering LR with RACK has 
the same trigger condition as RFC6675 SACK. I did misread the 
IsLost(SeqNum) description there.