Re: [tcpm] RACK - variable explanation

[Felix Weinrank <[e-mail]>]

Thank you very much for the explanation, this helps a lot! :)

Felix

On 22.11.18 17:16, Neal Cardwell wrote:
> On Thu, Nov 22, 2018 at 10:28 AM Felix Weinrank <[e-mail]> wrote:
>>
>> On 22.11.18 15:58, Neal Cardwell wrote:
>>> On Thu, Nov 22, 2018 at 7:25 AM Felix Weinrank <[e-mail]> wrote:
>>>> Hey RACK authors,
>>>>
>>>> we're evaluating the nuts and bolts of RACK in its current version and
>>>> we are missing variable explanations.
>>>> Most of the variables are listed and explained in section 5 (Definitions
>>>> of variables) but at least two are missing.
>>> Thanks for pointing these out! We'll add these in the next draft.
>>>
>>>> SND.UNA
>>> The RACK draft uses the SND.UNA and SND.NXT notations from the TCP RFC
>>> (from https://tools.ietf.org/html/rfc793#section-3.3 on page 25):
>>>
>>>      SND.UNA = oldest unacknowledged sequence number
>>>
>>>      SND.NXT = next sequence number to be sent
>>>
>>>> RACK.dupthresh << This is where we're stuck
>>> This is using the DupThresh term from RFC 6675, "A Conservative Loss
>>> Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP"
>>> (from https://tools.ietf.org/html/rfc6675 on page 4):
>>>
>>>      We define a variable "DupThresh" that holds the number of duplicate
>>>      acknowledgments required to trigger a retransmission.  Per [RFC5681],
>>>      this threshold is defined to be 3 duplicate acknowledgments.
>> Thanks for the explanation.
>>
>> 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.
>
> 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.
>
> BTW, for consistency, the line that says:
>
>     If RACK.reordering_seen is FALSE:
>
> should use the "RACK.reord" name, and should be:
>
>     If RACK.reord is FALSE:
>
> That will be fixed in the next rev.
>
> thanks,
> neal