Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Tony Li <> Tue, 25 May 2021 16:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7BDA03A15F8 for <>; Tue, 25 May 2021 09:52:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dFltqhNJorCi for <>; Tue, 25 May 2021 09:52:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 268323A15AF for <>; Tue, 25 May 2021 09:52:12 -0700 (PDT)
Received: by with SMTP id v12so16648605plo.10 for <>; Tue, 25 May 2021 09:52:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iZZZCDWuoIt+YYzQ/VDP34gl0wVBmK8Z7CcS9eM/syA=; b=B1fvdhQLwl4EDO0ar7qWUVrNsLQtI5WtlJYH9FwpYJ1eFhMcXZARxgAOINPizm0TBv AXSDWVWoH1pNujQiT3i/inT9qJSr+U8G3Gyz4LFkO6wj5ZZjIsaA3aVa/NUL2vOKIsoo FFB140Hc6moyfQyDAkSPkt5GUB+4/6pswjGRHWWiOtZSWN5dc8QVRKWnb+xZFBL7Ie8S N/duAahuSG9tLC0akHg17An6uVt8NbndBok5765P9ZoKbos+NABzYpsBAstoaqXYwF5L MOgKHU0e1Z2K+OSNSMOWGHWK93+63KlEMTPAM1Yv5TmMbXTSw9/20bi5scYYw0O3pvdm 4QOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iZZZCDWuoIt+YYzQ/VDP34gl0wVBmK8Z7CcS9eM/syA=; b=Kn2hAcMxiPK0wHxLQHjWjjrquU9RvwVS4h5wLhR4MJUAPUFR+x4Wth8mNOXPL8ZTCH WZlmlx8BgDcrhkIUWDLSQ74Y5y476uN/CA61IJAeie+6fIa6vATyajaSo7T+HD4aUeud Z+qDb2+lAdXrEPY1/Zc6G4oEqZwvo4mthLLXgaaoOXVh2aSlP79xrkM0hAGuqGSwlPmD RVEjKrsPD7Sa/8/tuTjHCMoEXePx/UTiBzn4xAiYahSJ5lBa7I/qrnh2IwkzkBv85XkW FQZ46snghfaRYU5V2XUq6AczeBFyoahbRMksvVP+LGM0rjwGSxwLh1wSZzyVveiUnU4A gWmg==
X-Gm-Message-State: AOAM532QrHOjnQ9EabYLXDm390DnbbmPMApNY6X3JlQaBknpj+jppRpT t0vlBxHTnxFzjRpR7G5XewkMGRvFLaw=
X-Google-Smtp-Source: ABdhPJxnohs16WAAeBDv/A0+20WDs/9BwgKOkwiFfjmKcITqNSlny7Q+zWgbG4pg3OejesyLjzrsoA==
X-Received: by 2002:a17:902:6b8c:b029:ea:f54f:c330 with SMTP id p12-20020a1709026b8cb02900eaf54fc330mr31517498plk.10.1621961530869; Tue, 25 May 2021 09:52:10 -0700 (PDT)
Received: from ( []) by with ESMTPSA id w189sm12639014pfb.46.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 May 2021 09:52:10 -0700 (PDT)
Sender: Tony Li <>
From: Tony Li <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EA03D834-5C45-444F-80FE-41D2B8F0F62E"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Tue, 25 May 2021 09:52:08 -0700
In-Reply-To: <>
Cc: lsr <>
References: <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 May 2021 16:52:40 -0000

Hi Greg,
> Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, 10 nanoseconds or 100 nanoseconds.

Ok.  The specific precision isn’t particularly relevant to me.  The real questions are whether microseconds are the right base or not, and whether we should shift to floating point for additional range or add more bits.

> To Tony's question, the delay is usually calculated from the timestamps collected at measurement points (MP). Several formats of a timestamp, but most protocols I'm familiar with, use 64 bit-long, e.g., NTP or PTP, where 32 bits represent seconds and 32 bits - a fraction of a second. As you can see, the nanosecond-level resolution is well within the capability of protocols like OWAMP/TWAMP/STAMP. As for use cases that may benefit from higher resolution of the packet delay metric, I can think of URLLC in the MEC environment. I was told that some applications have an RTT budget of in the tens microseconds range.

It’s very true that folks have carried around nanosecond timestamps for a long time now.  No question there. My question is whether it is actually useful. While NTP has that precision in its timestamps, the actual precision  of NTP’s synchronization algorithms aren’t quite that strong.  In effect, many of those low order bits are wasted.

That’s not a big deal, but when we make the base more precise, we lose range.  If we go with 32 bits of nanoseconds, we limit ourselves to a link delay of ~4 seconds. Tolerable, but it will certainly disappoint Vint and his inter-planetary Internet. :-)

We could go with 64 bits of nanoseconds, but then we’ll probably only rarely use the high order bits, so that seems wasteful of bandwidth.

Or we can go to floating point. This will greatly increase the range, at the expense of having fewer significant bits in the mantissa.

Personally, I would prefer to stay with 32 bits, but I’m flexible after that.