Hi Shraddha,
thank you for pointing out the text. Though it mentions that the value is the
average delay calculated over configured, i.e., pre-defined interval, that
seems it leaves out some important aspects of the measurement method, e.g.,
number of measurements in the set over which the average is calculated. Also,
I'd note that the average is not the most informative and robust metric as it
is more sensitive to extremes (spikes and drops) than, for example, median and
percentile (the most often used are 95, 99, and 99.9).
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D
Institute/Wireline Product Operation Division
E: gregory.mir...@ztetx.com
www.zte.com.cn
Original Mail
Sender: ShraddhaHegde
To: gregory mirsky10211915;lsr@ietf.org;
Date: 2021/05/25 02:46
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Snipped …
>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?
Pls refer RFC 8570 sec 4.1. The link delay is encoded in microseconds
“ Delay: This 24-bit field carries the average link delay over a
configurable interval in microseconds, encoded as an integer
value. When set to the maximum value 16,777,215
(16.777215 seconds), then the delay is at least that value and may
be larger.
“
Exact same text can be found in OSPF RFC 7471 sec 4.1.5 as well.
Rgds
Shraddha
Juniper Business Use Only
From: Lsr <lsr-boun...@ietf.org> On Behalf Of gregory.mir...@ztetx.com
Sent: Tuesday, May 25, 2021 8:03 AM
To: lsr@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
[External Email. Be cautious of content]
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.mir...@ztetx.com
www.zte.com.cn_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
