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

"Mark Allman" <mallman@icir.org> Fri, 22 November 2019 13:45 UTC

Return-Path: <mallman@icir.org>
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 7462112084E for <tcpm@ietfa.amsl.com>; Fri, 22 Nov 2019 05:45:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Xz6gBQF0B3o6 for <tcpm@ietfa.amsl.com>; Fri, 22 Nov 2019 05:45:36 -0800 (PST)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B60C12081A for <tcpm@ietf.org>; Fri, 22 Nov 2019 05:45:36 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id E3FB82C4058; Fri, 22 Nov 2019 05:45:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g+6LxG4XzlE1; Fri, 22 Nov 2019 05:45:35 -0800 (PST)
Received: from lawyers.icir.org (envoy.ICIR.org [192.150.187.30]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 77DC92C404F; Fri, 22 Nov 2019 05:45:35 -0800 (PST)
Received: from [192.168.1.244] (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 26D081E87D67; Fri, 22 Nov 2019 08:45:35 -0500 (EST)
From: Mark Allman <mallman@icir.org>
To: G Fairhurst <gorry@erg.abdn.ac.uk>
Cc: Extensions <tcpm@ietf.org>
Date: Fri, 22 Nov 2019 08:45:34 -0500
X-Mailer: MailMate (1.13r5655)
Message-ID: <BF311E1F-39E9-4719-A1B3-5A596F87D599@icir.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/uVVv9jdtOalZyjMMhXdaLINnvmM>
Subject: [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: Fri, 22 Nov 2019 13:45:38 -0000

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.

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.

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.

allman