Re: [tcpm] RACK - variable explanation

[Yuchung Cheng <[e-mail]>]

On Wed, Nov 28, 2018 at 7:56 AM, Ilpo Järvinen
<[e-mail]> wrote:
> 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.
>
>> That is, RFC6675 allows
>> entering Loss Recovery on the first ACK(SACK), without waiting for any
>> duplicate ACKs at all... Thus it is much more "aggressive", and I've seen two
>> independent examples recently, where Receivers exploit this capability (and
>> don't work well against a RFC3517 sender).
>>
>> Earlier 3517 still needed 3 duplicate ACKs.
>>
>> In that context, RACK takes a middle ground, as the receiver has to have seen
>> dupthresh data segments, but the sender can enter loss recovery already, even
>> when ACK loss, ACK compression or ACK thinning are prevalent in the return
>> path.
>>
>> (A single ACK, with an appropriate SACK block(s) is still sufficient to enter
>> LR with RACK, but unlike 6675, positive proof that 3 packets got delivered is
>> required).
>>
>> Which is a Good Thing (TM) :)
>
> 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?
This is to echo Ilpo's question that RFC6675 requires 3 OOO pkts to trigger.

>
> --
>  i.
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm