Re: [tcpm] RACK - variable explanation

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

Hi Neal,


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. 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) :)

> 
> One way to think about it would be: if a receiver selectively
> acknowledges a data sequence range, then that means there is an
> unacknowledged "hole" in the sequence space below the selectively
> acknowledged range.  There are two main possibilities for this hole:
> (1) That unacknowledged hole will stay unacknowledged indefinitely,
> suggesting that the original packets containing that data were
> permanently lost, and need to be retransmitted (which this algorithm
> triggers). (2) That unacknowledged hole will be acknowledged later,
> which would suggest that the network reordered the data somewhere in
> transit, delaying the earlier data and causing it to arrive after the
> later data. Waiting for three data segments to be selectively
> acknowledged allows extra "settling" time for that reordered packet to
> make it to the receiver and fill that hole; this implicit settling
> delay helps avoid spurious retransmits in cases where the network has
> started to reorder packets but the sender has not had a chance to
> observe the reordering yet. For cases where the sender has observed
> reordering (RACK.reord is true) then the sender maintains (in
> RACK.reo_wnd) an explicit estimate of how long (in time) it should
> wait for such reordering to settle, before triggering a fast
> retransmit.
>