Re: [tcpm] RACK - variable explanation

Felix Weinrank <weinrank@fh-muenster.de> Thu, 22 November 2018 15:28 UTC

Return-Path: <weinrank@fh-muenster.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688A5129533 for <tcpm@ietfa.amsl.com>; Thu, 22 Nov 2018 07:28:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yv2Jk1wjv_Mm for <tcpm@ietfa.amsl.com>; Thu, 22 Nov 2018 07:28:29 -0800 (PST)
Received: from mail.fh-muenster.de (mail.fh-muenster.de [212.201.120.190]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE861292AD for <tcpm@ietf.org>; Thu, 22 Nov 2018 07:28:28 -0800 (PST)
Received: from Idefix4.local (unknown [212.201.121.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fw153970) by mail.fh-muenster.de (Postfix) with ESMTPSA id 4C20B2848DB for <tcpm@ietf.org>; Thu, 22 Nov 2018 16:28:27 +0100 (CET)
To: tcpm@ietf.org
References: <8d43389c-93c1-899d-37ab-808c471eed47@fh-muenster.de> <CADVnQymCDpqTxwVLv0WYZvj84msfXf7OzfHYfj=d7Uj-pCHmFQ@mail.gmail.com>
From: Felix Weinrank <weinrank@fh-muenster.de>
Message-ID: <632bc671-4294-5eb3-ff8a-8c7dd492beb1@fh-muenster.de>
Date: Thu, 22 Nov 2018 16:28:26 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <CADVnQymCDpqTxwVLv0WYZvj84msfXf7OzfHYfj=d7Uj-pCHmFQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/3vTq8cSQAZRpt-8pJgqX4sF5SiA>
Subject: Re: [tcpm] RACK - variable explanation
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Nov 2018 15:28:31 -0000

On 22.11.18 15:58, Neal Cardwell wrote:
> On Thu, Nov 22, 2018 at 7:25 AM Felix Weinrank <weinrank@fh-muenster.de> 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

Best regards
Felix

>
>> 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