Re: [tcpm] RACK - variable explanation

[Michael Tuexen <[e-mail]>]

> On 22. Nov 2018, at 15:58, Neal Cardwell <ncardwell=[e-mail]> 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.
Please add such a description for RACK.dupthresh to Section 5.

Best regards
Michael
> 
>> And I think this paragraph from section 5 needs two cosmetic newlines:
>> "RACK.reo_wnd_persist" is the number of loss recoveries before
>> resetting RACK.reo_wnd "RACK.dsack" indicates if a DSACK option has
>> been received since last RACK.reo_wnd change "RACK.pkts_sacked"
>> returns the total number of packets selectively acknowledged in the
>> SACK scoreboard.
> 
> Thanks for pointing out the missing newlines! We will try to get that
> formatting cleaned up in the next rev.
> 
> thanks,
> neal
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm