[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
- [tcpm] rto-consider: "regularly" taking RTT sampl… Mark Allman
- Re: [tcpm] rto-consider: "regularly" taking RTT s… G Fairhurst
- Re: [tcpm] rto-consider: "regularly" taking RTT s… Mark Allman
- Re: [tcpm] rto-consider: "regularly" taking RTT s… Gorry (erg)