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

Anoop Ghanwani <anoop@alumni.duke.edu> Tue, 25 May 2021 22:07 UTC

Return-Path: <ghanwani@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB683A0E58 for <lsr@ietfa.amsl.com>; Tue, 25 May 2021 15:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 n64BtKyyhzQO for <lsr@ietfa.amsl.com>; Tue, 25 May 2021 15:07:43 -0700 (PDT)
Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1143A0E53 for <lsr@ietf.org>; Tue, 25 May 2021 15:07:42 -0700 (PDT)
Received: by mail-ua1-f45.google.com with SMTP id h26so4261497uab.13 for <lsr@ietf.org>; Tue, 25 May 2021 15:07:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iJvV61bHq9IqCgi+5ML1PdhAmX4tYZT/9wSKxITE5m0=; b=bcT5PqR44Y9wir8U+CH2odLTdoNT75RDCNMx0lnEq9tHg0Cyr+zsiE6pGR2VHDD8OG 3W/3fLvPVhhGe8bwhjYE09WRdo4dh8XEzaj3NqzRMrQAkAtQb2uqmPU5/boCnJMY0QEP ofN/EblSg/SwwiL5bsczBYq4g7J37kxRIlt11chz0RqyQZOvwSfz5kHpk4s3ANjZki/Y 6DSQjb8pQD67ZUF2zKAvsUZxfER+zyIIDvro6YXQS9/GdiC4ud+6i34/qEe6OUJqCygC aVytHKFXbvGfmTF47ov7cZz7jZiwJSGxLQo2Fu4kthANcSa4yMXeEvqS4IRQ+/ef6tLN bNDg==
X-Gm-Message-State: AOAM531Wa4lVxSxiiJBZFgc4AYDVa+JF8X9w9pLUzwRKxrlwz/uaKHsm sl2Cj4oxf1lakfSL4uqMYX7Mx7abSd0Zsqrjvx47dSjO
X-Google-Smtp-Source: ABdhPJyfoJzfwyOy8lBel4YTq65JM0CIMXO1+LNnmCkp9UfZDrmJeWFA0GLvuONdhAIlCD9cNgzAdsLC+MHY2HjKHpo=
X-Received: by 2002:a1f:6dc6:: with SMTP id i189mr28485163vkc.19.1621980461189; Tue, 25 May 2021 15:07:41 -0700 (PDT)
MIME-Version: 1.0
References: <202105251032405928718@zte.com.cn> <5988EFA2-CD6C-498B-9FB3-AE6E98D61A95@tony.li>
In-Reply-To: <5988EFA2-CD6C-498B-9FB3-AE6E98D61A95@tony.li>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Tue, 25 May 2021 15:07:30 -0700
Message-ID: <CA+-tSzxQAC0jEyKfStGmONH89Q_A=p5-b+OLhm9Qp+JExifhiQ@mail.gmail.com>
To: Tony Li <tony.li@tony.li>
Cc: gregory.mirsky@ztetx.com, lsr <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000038cfc605c32ec18b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/1josI3FpWfPWH4AewQGqSo1QsjE>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 May 2021 22:07:48 -0000

>>>
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. :-)
>>>
The current 24 bits of usec delay isn't that much better at ~16 sec.
(Unless there is a proposal to change that to 32 bits?)

On Tue, May 25, 2021 at 9:53 AM Tony Li <tony.li@tony.li> wrote:

>
> 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.
>
> Tony
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>