From jch@irif.fr Thu Apr 18 07:25:14 2024 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39916C14F6EC for ; Thu, 18 Apr 2024 07:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=irif.fr Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RixZVO6BzUXx for ; Thu, 18 Apr 2024 07:25:09 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0ADC14F69A for ; Thu, 18 Apr 2024 07:25:08 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 43IEP6fT028121; Thu, 18 Apr 2024 16:25:06 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E0B0767562; Thu, 18 Apr 2024 16:25:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=irif.fr; h= content-transfer-encoding:content-type:content-type:mime-version :user-agent:references:in-reply-to:subject:subject:from:from :message-id:date:date:received:received; s=dkim-irif; t= 1713450297; x=1714314298; bh=M/S7XyYC7/4uBc5+2olOk21FhZN0JGBNxac ZwJE9A1Q=; b=JITXF7PszPddLDrBLaNjBfLUN8iqhJ2r7S/Q9VceWLDaep6Llj6 LnpXjidSqDEr66iqO+DrmV86FvkBwzVFc7vgbsuDSYf8U2c9mgOtOLGha1sUyvU8 lztas0yDLO/VBoolrBxBTdcfy/WRLR4CcXXADgMImJivgUnQlj15EHvFQOVX7m0a /0ZQkJDQXW70hEjbjhUw6ya6x7xo/gwWxJ5sZBz88KVyvu6UGJupbDRYqsj+xpC3 MOqmY2MFnSSwMyY3cRllZkK8QeAgMA4yxsPI9mAAyO/CQwanHgyBJdCd2jABX6/D dUX42ksZefCaeU7q6crVyfnaTuehEWOEPXg== X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ldp4QHDfXzKN; Thu, 18 Apr 2024 16:24:57 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 15123675D5; Thu, 18 Apr 2024 16:24:55 +0200 (CEST) Date: Thu, 18 Apr 2024 16:24:55 +0200 Message-ID: <87o7a6n3yg.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , babel@ietf.org, Pascal Thubert In-Reply-To: References: <171328574275.28898.9111599332162642753@ietfa.amsl.com> <87v84h5k56.wl-jch@irif.fr> <87r0f5urqv.fsf@toke.dk> <87sezki0w2.wl-jch@irif.fr> <87y19bu70m.fsf@toke.dk> <87bk67ixr9.wl-jch@irif.fr> <87plunu5nb.fsf@toke.dk> <87a5lritwi.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/29.3 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 18 Apr 2024 16:25:06 +0200 (CEST) X-Miltered: at korolev with ID 66212D42.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 66212D42.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 66212D42.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] New Version Notification for draft-ietf-babel-rtt-extension-06.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2024 14:25:14 -0000 CC-ing Pascal, since his review is what prompted the discussion. Pascal, please feel free to chime in if I say something stupid. > Juliusz, can you elaborate on "Well, we want the timestamping to be consistent > between implementations." ? I'm not sure I completely follow why we want that. > If two implementations differ, then the one with the closer-to-the-hardware > timestamp might appear to be a better route than it is in practice, which > doesn't sound like a really bad issue? My gut feeling is that we should > recommend the measurement to be as close to the hardware as possible to make > the RTT samples as accurate as possible. But maybe I'm missing something. There are three distinct measures of RTT in this discussion: - Δ: measured at the top of the stack (between layers 7 and 4), which includes the local queueing delay; - δ: measured at the bottom of the stack (somewhere around layer 2), which does not include local in-kernel queueing delay (but might include hardware queueing in the network interface); - η: hybrid RTT, where outgoing packets are measured at the top of the stack, and incoming packets are measured at the bottom of the stack. I am arguing in favour of Δ. Toke is arguing in favour of η. Nobody is arguing in favour of δ, because you guys are growing old and reasonable. Properties of Δ: - it's easy to implement on all reasonable systems; - it's been deployed for 7 years, with no ill effects; - it's symmetric (it includes both local and remote queueing delay, so two peers are going to calculate roughly the same Δ); - it includes scheduling jitter. Properties of δ: - it's impossible to implement without either very specific kernel support or interleaved encoding (see draft-ietf-ntp-interleaved-modes); - it's not symmetric (it only includes local queueing delay); - it does not include scheduling jitter. Properties of η: - it can be implemented with existing kernel interfaces, at least on Linux; - it's not symmetric; - it does not include scheduling jitter if implemented right; - it's likely to be very close to Δ (since it includes queueing delay). Here are the current opinions: - Pascal, if I read him correctly, is happy with either measure as long as we specify clearly which one is being used; - Toke is going to implement η, but he's okay if I specify Δ, since the two values are very close in practice; - I've specified Δ in the current draft, but I'm fine with Toke implementing η instead, since the two values are very close in practice. By the way, if people are interested in implementing δ, then it would require an all-new protocol extension, one that does interleaved encoding. So I suggest we leave this for potential future work, together with one-way delay measurements. -- Juliusz