IETF Logo Mail Archive

Re: [babel] New Version Notification for draft-ietf-babel-rtt-extension-06.txt

Juliusz Chroboczek <jch@irif.fr> Wed, 17 April 2024 13:18 UTC

Return-Path: <jch@irif.fr>
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 38A82C14F60E for <babel@ietfa.amsl.com>; Wed, 17 Apr 2024 06:18:03 -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 0-0ez4yko43g for <babel@ietfa.amsl.com>; Wed, 17 Apr 2024 06:17:57 -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 9F380C14F602 for <babel@ietf.org>; Wed, 17 Apr 2024 06:17:56 -0700 (PDT)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 43HDHqdE010244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Apr 2024 15:17:52 +0200
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 43HDHqmN007000; Wed, 17 Apr 2024 15:17:52 +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 DE331576AE; Wed, 17 Apr 2024 15:17:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=irif.fr; h= 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=1713359870; x=1714223871; bh= jXoma93Dc1cMKeWUHhbH5SyEjis3gQLnLIZCPeG03JU=; b=jdnECPsHfbSaspSY M/ofEwE5rpex0ci4PR26awcnXeda/8HkyZD77WaFz82Wa+1G8S7X7TBA+dcociLS wYk7ITFmJlP7Lci2LYg969PVQgHiAjgXbJ7K+gfZktBXM+YKAaPWq3HCZnwtGlcl +qjDO6lP7XYZgl493o+msME5CSIJoV2eLa2Qv5/QED8vRl4+wP44nr8d2K1r0OF/ udETiRUYgzKaPKH/MGkmN/3IFCftJgzdBVD8wR9pzNm+Vn7ba4QKj08dt4+l5FkW ITFkZ2JvYRSqIOt2FYKKkU8ov4NguTi3kqdUlEHeeb8lWYyRzMX2V3KWw89tufYG Tj7OLw==
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 l8sq2ocOmY2F; Wed, 17 Apr 2024 15:17:50 +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 D8C2A57A55; Wed, 17 Apr 2024 15:17:49 +0200 (CEST)
Date: Wed, 17 Apr 2024 15:17:49 +0200
Message-ID: <87sezki0w2.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Toke Høiland-Jørgensen <toke@toke.dk>
Cc: babel@ietf.org
In-Reply-To: <87r0f5urqv.fsf@toke.dk>
References: <171328574275.28898.9111599332162642753@ietfa.amsl.com> <87v84h5k56.wl-jch@irif.fr> <87r0f5urqv.fsf@toke.dk>
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="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 17 Apr 2024 15:17:52 +0200 (CEST)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 17 Apr 2024 15:17:52 +0200 (CEST)
X-Miltered: at korolev with ID 661FCC00.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 661FCC00.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 661FCC00.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/<jch@irif.fr>
X-j-chkmail-Enveloppe: 661FCC00.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 661FCC00.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 661FCC00.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/j6o5md-PZCtBlv4PVaawVNNZEW8>
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." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2024 13:18:03 -0000

> The Bird implementation is compliant with section 3.2, although that may
> change in favour of asking the kernel to timestamp incoming packets:
> 
> https://bird.network.cz/pipermail/bird-users/2024-April/017592.html
> 
> Using kernel (or hardware) timestamps is a better solution anyway, IMO,
> so maybe that particular recommendation needs rethinking?

Well, we want the timestamping to be consistent between implementations.
I'm sure we can all agree that the procedure that's recommended by the
document, while not optimal, is implementable on all systems.

Timestamping in the kernel on Linux BIRD but not on other platforms means
that we get different delay measures depending on the implementation,
which I'm sure you'll agree is suboptimal.

It won't matter much in practice, though, which is why the recommendation
is just a SHOULD.

> We don't explicitly expire RTT state if the sanity checks keep failing,
> so I don't believe we're compliant with the last paragraph of section
> 3.3.

I have misgivings about this paragraph myself.  Shall I remove it?

-- Juliusz

v2.23.0 | Report a Bug | By Email