Re: [tcpm] Review (Re: WGLC for draft-ietf-tcpm-rack-08)

Theresa Enghardt <> Fri, 24 July 2020 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 616923A0B24 for <>; Fri, 24 Jul 2020 13:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IKT2m_NmiYRo for <>; Fri, 24 Jul 2020 13:16:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7CB5B3A0B23 for <>; Fri, 24 Jul 2020 13:16:07 -0700 (PDT)
Received: from user.client.invalid (localhost []) by (Postfix) with ESMTPSA id 7C7BBAA; Fri, 24 Jul 2020 22:16:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=20170414; t=1595621765; bh=pfxcmo4GBx43oXCzpK3PnSb36C9MCdLAKzl6HSneoKo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bxM7BIePfqlE2ZgeGUGhArIPk2Vp8JwFG0XvWig4716w7g6rfi4AQ3RNVegwO6U3E 021Vy94sYLwJvd+oYKryLVxeODNLX8da2zCw9uEsNgKb17/a2VS2Ja7n6oaW1tyeH3 ZOVl6URFjfwpKdSw7RafZTZg2paBRH1ziHITEtXKvYCSXqb1ST3/n260/GTgl75Syl L3xPW/FE2bQOt4KMARt9GvndcqRZKz77+LQWhNuI6H4lCP30ye34gGDqDENnDjZFlD ctQ3YGKxXUOKvngfsAjTxtuWJ5QF4vkUlmosDpMlQHxYKjrEhJTqKn8Jhe7w2UDo9V WR9LuZvC9qbNQ==
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Fri, 24 Jul 2020 13:16:05 -0700
From: Theresa Enghardt <>
To: Yuchung Cheng <>
Cc: tcpm IETF list <>
In-Reply-To: <>
References: <> <> <>
Message-ID: <>
User-Agent: Roundcube Webmail/1.3.14
Archived-At: <>
Subject: Re: [tcpm] Review (Re: WGLC for draft-ietf-tcpm-rack-08)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Jul 2020 20:16:09 -0000

Dear Yuchung,

Thank you for the reply and for posting a new draft.

I read the current version -09 and find that it has greatly improved 
clarity and readability.

This resolves most of my comments.

Just one reply and a few additional minor comments:

On 2020-07-13 15:06, Yuchung Cheng wrote:

> […] The new
> subsection 'RACK reordering window adaptation explicitly lists the
> rules of 3-dupacks and reordering window.
> When the reordering window is zero, RACK will mark the first unacked
> packet lost on the first DUPACK. The rule is to hold up until the
> third DUPACK (or 3 MSS worth of bytes been sacked).

This helps, thanks.

Reading the new Section 3.3.2, I'm wondering about the following though:

"If the sender has not observed any reordering since the
        connection was established, then the RACK reordering window
        SHOULD be zero in either of the following cases: […]

        1.  After learning that three segments have been delivered out of
            order (e.g. receiving 3 DUPACKs per [RFC5681]); in turn, this
            will cause the RACK loss detection logic to trigger fast

        2.  During fast recovery or RTO recovery."

Does this SHOULD mean that the implementation should set the reordering 
window to 0 under either of the listed conditions?
Because I fail to see how the two listed conditions mean that that "the 
sender has not observed any reordering".
Or SHOULD the sender set the reordering window to 0 if either it hasn't 
observed any reordering, or one of the listed conditions are true.

An alternative (and probably false) way of reading this would be that 
the SHOULD just means that the sender should expect the reordering 
window to be 0.
But it doesn't seem logical to me to use SHOULD in this way.

(This is probably clarified later in the detailed algorithm, but it 
would be nice to have this phrased clearly in this Section as well.)

In Section 3.3.2, I fail to understand or parse the following sentence:
             The RACK reordering window SHOULD leverage that to 
             estimate the duration of reordering events, if the receiver 
             Duplicate Selective Acknowledgement (DSACK) [RFC2883].

The RACK reordering window SHOULD leverage what? (If "that" refers to 
the sentence before, SRTT, then the connection to DSACK is not obvious 
to me. So I think it's good to substitute "that" here.)

Nits / Editorial comments:

In Section 2.2 and Section 3.3.2., the numbered list goes "1.", "1.", 
"2.", but should be "1.", "2.", "3.".

In Section 4, list item 2. might have an unnecessary "that":
"[…] timestamp whose granularity that is finer than 1/4 of the minimum 
RTT of the connection."