From pascal.thubert@gmail.com Fri Apr 19 00:12:31 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 15944C14F69D for ; Fri, 19 Apr 2024 00:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 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, FREEMAIL_FROM=0.001, GB_SUMOF=5, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LphNPlg-PJC2 for ; Fri, 19 Apr 2024 00:12:29 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35F9C14F602 for ; Fri, 19 Apr 2024 00:12:28 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4187c47405aso11371785e9.3 for ; Fri, 19 Apr 2024 00:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713510747; x=1714115547; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=i522K6o1T6Q3yDs3QKGOS7C1rZvdQQsptK165UwiVFk=; b=KhZY/JT+XVVA8rcSwZA8FI4kCL5WMAkuwlztWIi90cakltZawDCOFe8D7pYQHGWSQl Q7djV2tj8cP9UJ1FFklwHyPpC9BaZ/ynh/vGlr9XLp13K+JaKGedrPMa7nnxEgVcTLyP cxyL9rGKwH7cU/or6LrBWVb9k+N5CKqH/r8i6cazOAoDsOrd1U7mUyVe6kZc+Nwu+zQF JYB9v2hCrksiMWsgsREOKADsf4/GmL5Lh0AnWNsAT0NnR86nd/S6bPJVwtMSW5gMGivj OMZnCCuDNPzSRN60v5GglI/EbyOCWoiOemkYfaJP0DcgFzcgfGyDrahFCa708N3FQvkx Kp1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713510747; x=1714115547; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=i522K6o1T6Q3yDs3QKGOS7C1rZvdQQsptK165UwiVFk=; b=PqB6R+f42+eecKDPyf8T8TWI4GAoOz41XosZ7QfBJfXQ+XioYwJyn+XU4Zo916TMPD As142tpFoKWVvxdGLWFhE2ZSCZQQLRzWEvn+3SeoCPcmJ/6EA49EW0p3FrtZBI0H8Iap Eet5APzqDBMJgK5U+Tr2ubmu3oQ33aI6S1er9CaV1RmFM7wBP9G8C8TW39lGtFxzh49w Iqhxwd1EUH3y8xDL9GHtuqqhfnBSZVMVpxtiZMPFQ8rLPaJGIjRTQ2Of8OnH1wqBi0XL iWgIWNIf8Pdr9n4V6rQkwTjkewRd1pIQIqcrFHt/VY5xsUbYjsGdc7jsv+SZ84SErO3W 7ffA== X-Forwarded-Encrypted: i=1; AJvYcCVfERw9uX0pLTgBa/zoZXXEScVjYFvZ7DMkb1K+t8h0HfcdWN5MwG40B8vxCj86HTdqHeYhIYDxGhfogpo67Q== X-Gm-Message-State: AOJu0Yz99udT2sr5rkTAb1vuiqZut199uTRqHRKXSrv+kaoaZBoj3KDa S4kjuMLrMuBI6kZvIXOv0x2KDS4iznEEfdCVqRpYqhqKBVjsRpJ8 X-Google-Smtp-Source: AGHT+IFgGmvkgRJK3WORAR6Rz5quykPdGkWW0zo7yDPeSroVSh4xffiP8FDNEMHp7Qp90Al8Yc4gpw== X-Received: by 2002:a05:600c:4587:b0:417:d43e:8372 with SMTP id r7-20020a05600c458700b00417d43e8372mr743439wmo.16.1713510746580; Fri, 19 Apr 2024 00:12:26 -0700 (PDT) Received: from smtpclient.apple ([2a09:bac5:321d:16a0::241:e]) by smtp.gmail.com with ESMTPSA id u18-20020a05600c19d200b0041896d2a05fsm5339367wmq.5.2024.04.19.00.12.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Apr 2024 00:12:25 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B0594CDD-CD1C-48A3-BA1E-663FA443133B Content-Transfer-Encoding: 7bit From: Pascal Thubert Mime-Version: 1.0 (1.0) Date: Fri, 19 Apr 2024 09:12:15 +0200 Message-Id: References: Cc: Juliusz Chroboczek , =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , babel@ietf.org In-Reply-To: To: David Schinazi X-Mailer: iPhone Mail (21E236) 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: Fri, 19 Apr 2024 07:12:31 -0000 --Apple-Mail-B0594CDD-CD1C-48A3-BA1E-663FA443133B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello all

I=E2=80=99m go= od with either. 

Most OSes we deal with are no= n deterministic meaning that scheduling the packet (handling is not within i= nterrupt) happens when possible but not at a fixed duration after reception.=

 Unless the OS is consistently overloaded thi= s should be negligible vs transfer latency and filtered out during consecuti= ve tries; but certainly this is asymmetrical. 

The usual caveat with time measurement is that the return path might differ= from the way in. Even what seems direct at L3 can be tunnels underneath. Bu= t we divide by 2 the round trip meaning that we are probably pessimistic one= way and optimistic the other.

But does any of that= matter? If the metric is roughly constant over time and noise is filtered w= e can certainly route with it. 

Now, If there=E2= =80=99s a huge lower layer path assymetry then we will not get the =E2=80=9C= best=E2=80=9C path for routes that use this segment but should not when we a= re optimistic and routes that should have used it when we are pessimistic.

I thought all this could be discussed but none of th= is impacts the protocol operations. It=E2=80=99s more about setting the expe= ctations correctly.

A bient=C3=B4t;

Pascal
<= div dir=3D"ltr">
Le 18 avr. 2024 =C3=A0 16:57, D= avid Schinazi <dschinazi.ietf@gmail.com> a =C3=A9crit :

=EF=BB=BF
Thanks Juliusz, this helps.

First, to set the s= tage - I'll be happy with any option you select, this is just to assuage&nbs= p;my curiosity.

In terms of the differences between= the various options:

1) ease/possibility of implem= entation
This one is important, but - if we assume that all implem= entations don't need to match - then we can just say "SHOULD implement as lo= w in the stack as you can" and everyone can do that on whatever platform the= y are

2) symmetry
As you point out, since= RTT is the sum of both one-way delays, it will always be symmetric :-)

3) scheduling jitter
I would assume that it's= best to not count scheduling jitter since that'll most likely pollute = the measurements and not impact the actual flow of packets along this route<= /div>

I guess the bit I'm not sure about is the assumptio= n that I mentioned above: the fact that implementations don't need to match.= Is there any reason why we'd want them to match?

D= avid


On Thu, Apr 18, 2024 at 7:41=E2=80=AFAM Juliusz Chro= boczek <jch@irif.fr> wrote:
> Properties of =CE=B4= :

>   - it's not symmetric (it only includes local queueing delay= );

> Properties of =CE=B7:

>   - it's not symmetric;

Sorry, that's not correct.  All three measures are symmetric.  Mil= ls'
algorithm is just too brilliant for my small brain to encompass.

-- Juliusz
= --Apple-Mail-B0594CDD-CD1C-48A3-BA1E-663FA443133B--