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 07:11 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 EEB7E3A1850 for <lsr@ietfa.amsl.com>; Tue, 25 May 2021 00:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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_FONT_FACE_BAD=0.001, 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 F6XuHiPZkVwa for <lsr@ietfa.amsl.com>; Tue, 25 May 2021 00:11:14 -0700 (PDT)
Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44]) (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 6FF203A184D for <lsr@ietf.org>; Tue, 25 May 2021 00:11:14 -0700 (PDT)
Received: by mail-vs1-f44.google.com with SMTP id j12so10510744vsq.9 for <lsr@ietf.org>; Tue, 25 May 2021 00:11:14 -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=vyTpBJmRDhXFCXl/tKwz/P7YZ3oSFu8sTjloZ4MuK5c=; b=WhfEBvWiiS1o9HRqjNZ/yR6aaurykVFK5yKaRigBDDN+pRBNqdmogXBArvxf41Me3G SjBmd+yf6XbvsJUpXzqfggWmVKZO5ppNSK7UBtxRgrBP1ItAUE09bRucnW7EMlWQlrnD LVeUAGItEfMM7WVq1viZGeAChgI0AeIhPpX0V4Uma5hWBawN8hQQyzXvU9OU4f1CMBP7 V8t8yhUJqn2pMZVPmtjNqRmkuktkKZ++Jw6VfTjK2FFDIhOKFwACSKfYJ6xDCpQJ7IZQ XEQZjUXe5qKFFzdrtOB7V3r4heoOg9ymOVw0xMSIKTnpriubfaRxeOoO4ZsfB/y/S9fn Fx2Q==
X-Gm-Message-State: AOAM531aNx3LkHIfcIwuf022tylFmkztlAWyQwKhx+bb+6YYofzTcVmR R4KlQ2TeNeuU1MG2AvsjgesAF+SdE5x36jjYGuSeJRvt
X-Google-Smtp-Source: ABdhPJxhPpUJKmfiQhPSpDVchqnSsoQfhrNJ23cG9WsaojZ05xVp+fi1tWo0IHDZIPGoJ6wjlTO6d+Jm9jEaSfdhl7A=
X-Received: by 2002:a67:14c1:: with SMTP id 184mr25069447vsu.38.1621926673219; Tue, 25 May 2021 00:11:13 -0700 (PDT)
MIME-Version: 1.0
References: <202105251032405928718@zte.com.cn>
In-Reply-To: <202105251032405928718@zte.com.cn>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Tue, 25 May 2021 00:11:01 -0700
Message-ID: <CA+-tSzxsGNhwHy3QOVt=j6x=DmMX=j5Biry3dqLmRjkUz0DNbA@mail.gmail.com>
To: gregory.mirsky@ztetx.com
Cc: lsr@ietf.org
Content-Type: multipart/related; boundary="00000000000035c89505c3223b70"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Jv5gvoeJOvwTrv058UbsgjoJNMM>
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 07:11:19 -0000

Greg,

One thing to keep in mind is that even though we can measure latency at a
precision of 10's or 100's of nanoseconds, does it hurt to round the link
delay up to the nearest microsecond?  One way to look at this is that by
doing such rounding up, we add at most 1 usec worth of additional delay per
hop.  That was my rationale for thinking it's probably OK to leave the
resolution at 1 usec.

I don't have a strong opinion either way.

Anoop

On Mon, May 24, 2021 at 7:32 PM <gregory.mirsky@ztetx.com> wrote:

> Dear All,
>
> thank you for the discussion of my question on the unit of the Maximum
> Link Delay parameter.
>
> Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps,
> 10 nanoseconds or 100 nanoseconds.
>
> 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.
>
>
> Shraddha, you've said
>
> "The measurement mechanisms and advertisements in ISIS support
> micro-second granularity (RFC 8570)."
>
> Could you direct me to the text in RFC 8570 that defines the measurement
> method, protocol that limits the resolution to a microsecond?
>
>
> To Acee, I think that
>
> "Any measurement of delay would include the both components of delay"
>
> it depends on where the MP is located (yes, it is another "It depends"
> situation).
>
>
> I agree with Anoop that it could be beneficial to have a text in the draft
> that explains three types of delays a packet experiences and how the
> location of an MP affects the accuracy of the measurement and the metric.
>
>
> Best regards,
>
> Greg Mirsky
>
>
> Sr. Standardization Expert
> 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D
> Institute/Wireline Product Operation Division
>
>
>
> E: gregory.mirsky@ztetx.com
> www.zte.com.cn
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>