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

Theresa Enghardt <ietf@tenghardt.net> Sat, 25 July 2020 00:10 UTC

Return-Path: <ietf@tenghardt.net>
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 570FD3A0C9F for <tcpm@ietfa.amsl.com>; Fri, 24 Jul 2020 17:10:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tenghardt.net
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 VaGO26UwfZR5 for <tcpm@ietfa.amsl.com>; Fri, 24 Jul 2020 17:10:05 -0700 (PDT)
Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77683A0878 for <tcpm@ietf.org>; Fri, 24 Jul 2020 17:10:05 -0700 (PDT)
Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 0F963AA; Sat, 25 Jul 2020 02:10:04 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tenghardt.net; s=20170414; t=1595635804; bh=pf+itzR30J3D6KarsIbxIJYFsKK16HmoQjqRLA3S8/o=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BbSoYLHjsQBAdes1MaWn48i1ZgFsuZi1hknOQLwmpxNL5NQ5mJ6i/D7Fx5ZUra1nk kIw+0lEtf/8Y3G9WTxjqdgSW6S/1Hhqn6b7qgFLoo0DWzm8WaaSYS/bKhZ/dBP3EI3 4q4lP6QVEN3toqR2XnPGUm1UqfuZTsCUFSRpDgaDPYwrTgAdnceTXu8bj0Pg7/U9BI G9qLoBrLQGF4pdEyNKUQ9836nxabm0Ra72M0RbkkjqwVK4U+tSD8/w8MVlgoCjV7h/ mcXFQk5Vk2s+GDBMIMftgo8l9OdkIRnWjX9yLd5tDvmgDlu3QTbZUs8svpm9rXUZ9L MOtIQ4z1gcidw==
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Fri, 24 Jul 2020 17:10:04 -0700
From: Theresa Enghardt <ietf@tenghardt.net>
To: Yuchung Cheng <ycheng@google.com>
Cc: tcpm IETF list <tcpm@ietf.org>
In-Reply-To: <CAK6E8=eD_N4H2AEsJ6b_25UEug-kkOAwhb3OsK7vuAne8PWpJQ@mail.gmail.com>
References: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> <2c0558c37ec99da2b98f73eb5a79d8e6@tenghardt.net> <CAK6E8=dPsV_ADZ9iADLo32aPA=g1FZH2g9c1VSjPU8nk7QQOpg@mail.gmail.com> <d1cd209fb2bb803c7f69b81dfbf29880@tenghardt.net> <CAK6E8=eD_N4H2AEsJ6b_25UEug-kkOAwhb3OsK7vuAne8PWpJQ@mail.gmail.com>
Message-ID: <34f124c361b7c3e6c20f543b604f67c3@tenghardt.net>
X-Sender: ietf@tenghardt.net
User-Agent: Roundcube Webmail/1.3.14
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/BEdgG_JNHjgb1NGH4SLxhYHc_Wc>
Subject: Re: [tcpm] Review (Re: WGLC for draft-ietf-tcpm-rack-08)
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: Sat, 25 Jul 2020 00:10:07 -0000

Hi Yuchung,

See inline:

On 2020-07-24 16:45, Yuchung Cheng wrote:

>> On 2020-07-13 15:06, Yuchung Cheng wrote:
>> […]
>> 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?
> yes
> 
>> 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).

This is much clearer, thanks!

Additionally, I suggest to change "The reordering window SHOULD be zero" 
to "The reordering window SHOULD be set to zero", or to prefix the 
entire list with a sentence like "More specifically, the sender sets the 
reordering window as follows:".


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

Yes, this is clearer to me now.

I would suggest the following slight changes to this sentence though:

OLD:
"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."

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

Best,
Theresa