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

Yuchung Cheng <> Fri, 24 July 2020 23:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53FCC3A082F for <>; Fri, 24 Jul 2020 16:46:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 Qhk1YsEMNnaG for <>; Fri, 24 Jul 2020 16:46:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D32643A082C for <>; Fri, 24 Jul 2020 16:46:30 -0700 (PDT)
Received: by with SMTP id b26so1219313vsa.13 for <>; Fri, 24 Jul 2020 16:46:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ythRF765DPqf60ZnCDs4XvgRxzAjuezDLkyDzdpP5Lk=; b=VxS5Oug0FEL6yHyqC/RVgBL2Q6hN5pOAOZ7904abtqCD9AaXHK1gXhSvL+6G/jd69J /TtVOA415RSD54nYizDcenZilF+GXteU5a19UQNyocI6+dNGu5BYIEEiqh4U4jwItu5C 2HBW/ntamC0SCzYXLuch1BCZpbK7zJ/YwJlLGDdiLzFG5VKGlMine/XNEzgkQvZIU5f0 ukZKtHBXwoKzhWl3sCHQlVX8IYNiMwh/kNhZpk4vypW6TMMSOl+tSCd2glDhs114f2Q+ dVw5byPleLev2DuFOVwD4aXLEEzPlKg0MZyBARlBA+/X2B7NZZZD6oiNFTeuueJQZ3l6 ON0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ythRF765DPqf60ZnCDs4XvgRxzAjuezDLkyDzdpP5Lk=; b=gV+cpabj8Rl/lscLtDfWgHDrwD7EnsHD0//PFWbMPDu8ln9lfGbuwUGncSJXA7K0C+ cgdLR1nTwYWC/BkT8phjjvleXFxRdxE6C8v1VTH62TfUtMAaIdEZtuSdF0Z7qEqg66Dd fa5cIwo0BkMZT8zi7bsMW32A/XxJV6RnmOggoSCx2yrNzWr8RclfL4wNnPr7QqKhIrGb EDhGcqtQeCz5b6NHJ880nQckd3kvJBFVLkCtce7z1o4lYYjf6BXXZhYP4Mn0Cknxp30n /cY8TZy6MNYMEnK0w9G/oDv9X+MF6H1axSyt9CVLM4npwFEMWptkjTqx9p/VK0qFeXwv oQdg==
X-Gm-Message-State: AOAM533G1Xj4tb3TiKjMwn+ac4FeEF2SCXNcQAHoyzlrlu8WjKhbr9Y3 4ffyt9Z7IBgDBVabNhoPaKPbLlHDm8pYNh82vlLGL0VN
X-Google-Smtp-Source: ABdhPJwF5T4JOOI73q8MrnEvJnyXrIegtRasSSuhfUTEW4Am+XrO5HgvxViI2Ut7A4uVD9eQFbplNoCLNae0FjggItU=
X-Received: by 2002:a67:f87:: with SMTP id 129mr9822104vsp.134.1595634389511; Fri, 24 Jul 2020 16:46:29 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Yuchung Cheng <>
Date: Fri, 24 Jul 2020 16:45:53 -0700
Message-ID: <>
To: Theresa Enghardt <>
Cc: tcpm IETF list <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 23:46:32 -0000

On Fri, Jul 24, 2020 at 1:16 PM Theresa Enghardt <> wrote:
> 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.
thanks for taking another look!

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

agree this can be better clarified. do you think the following is more clear:

1. The reordering window SHOULD be zero if no reordering has been
    observed on the connection so far, plus either (a)
    three segments have been delivered out of order since the last
    recovery or (b) the sender is already in fast or RTO recovery.
   Otherwise the reordering window SHOULD start from a small fraction of the
    round trip time, or zero if no round trip time estimate is available.

2.  The RACK reordering window SHOULD adaptively increase if the
     sender receives the Duplicate Selective Acknowledgement (DSACK) [RFC2883],
     suggesting the window is too small which causes spurious retransmission.

3.  The RACK reordering window MUST be bounded and this bound SHOULD
     be SRTT.

(The text after this needs to be adjusted for the new bullet numbers).

> 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
> adaptively
>              estimate the duration of reordering events, if the receiver
> uses
>              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.)
sorry that=DSACK. sentence got cut out accidentally. Does the proposed
new text in my earlier comment look better?

> 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.".
will fix
> 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."
will fix.
> Best,
> Theresa