Re: [tcpm] rto-consider: "regularly" taking RTT samples

G Fairhurst <gorry@erg.abdn.ac.uk> Sat, 23 November 2019 01:31 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 DEE1C1200B7 for <tcpm@ietfa.amsl.com>; Fri, 22 Nov 2019 17:31:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 7-KYcOSjIVp7 for <tcpm@ietfa.amsl.com>; Fri, 22 Nov 2019 17:31:23 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id B2F311200B6 for <tcpm@ietf.org>; Fri, 22 Nov 2019 17:31:23 -0800 (PST)
Received: from G-MacBook.local (unknown [132.147.98.37]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id C9D001B001FC; Sat, 23 Nov 2019 01:31:17 +0000 (GMT)
Message-ID: <5DD88BE2.8090604@erg.abdn.ac.uk>
Date: Sat, 23 Nov 2019 09:31:14 +0800
From: G Fairhurst <gorry@erg.abdn.ac.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Mark Allman <mallman@icir.org>
CC: Extensions <tcpm@ietf.org>
References: <BF311E1F-39E9-4719-A1B3-5A596F87D599@icir.org>
In-Reply-To: <BF311E1F-39E9-4719-A1B3-5A596F87D599@icir.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/qTN6cu1FMLnOUh5pwrYfqRHtlKw>
Subject: Re: [tcpm] rto-consider: "regularly" taking RTT samples
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, 23 Nov 2019 01:31:26 -0000

Hi Mark!

On 22/11/2019, 21:45, Mark Allman wrote:
> Hi Gorry!
>
> Thanks for all the comments.  I am going to work through them and
> hack on the document.  I am addressing a couple of the easier
> comments today.  But, will address them all soon.
>
> I-D>>  In steady state the RTO SHOULD be set based on recent
> I-D>>  observations of both the FT and the variance of the FT.
>
> Gorry>  - I don’t think these are wrong, but I think the advice is
> Gorry>    not very crisp for a BCP - how recent? How does this relate
> Gorry>    to Comment 3?
>
> The "recent" here is defined in requirement (2b), as you note.  So,
> it isn't meant to be crisp here.  I can see two paths:
>
> (1) Remove the word "recent" from here.  The overall point of
>      guideline (2a) is really that the RTO SHOULD be based on
>      observations---i.e., not statically set.  The notion of "recent"
>      isn't hugely important here as it is concretely developed in
>      (2b).
>
> OR,
>
> (2) We could leave the "recent" in (2a) with a forward reference to
>      indicate we are not leaving this as nebulous somehow.  E.g.,
>      "... recent observations---as defined below---of both ..." if
>      folks think keeping this notion (colloquially) in (2a) is a good
>      idea.
>
> I am pretty indifferent to both options.
Omitting the word (a) is indeed easy. I suspect the new formulation of 
(b) effectively defines regularly, so a recent sample should be available.
> I-D>>  FT observations SHOULD be taken regularly ...
> I-D>>
> I-D>>  The notion of "regularly" SHOULD be defined as at least once
> I-D>>  per RTT or as frequently as data is exchanged in cases where
> I-D>>  that happens less frequently than once per RTT.
>
> Gorry>  - To me, reads as impossible RFC2119 text, is this a
> Gorry>    definition or something else? or Designs are REQUIRED to
> Gorry>    define ... etc.
>
> I really can't parse the complaint here (which is probably because
> you well explained it, but since I wasn't there the slide isn't
> conveying that to me).  I don't see this impossibility you are
> suggesting.
Sorry, happy to explain why I thiunk this can be misread, but reading-on 
we already have a solution that works for me.
> That said,
>
> Gorry>  I hope this actually is intended to be:
> Gorry>  FT observations SHOULD be taken be at least once
> Gorry>  per RTT or as frequently as data is exchanged in cases where
> Gorry>  that happens less frequently than once per RTT.
>
> This is in fact the intent and I am happy to use those words.
Then let's do that.
> allman
Gorry