Hi Anoop,
thank you for sharing your thoughts. I agree, it is very likely that in most
cases, the potential inaccuracy of 1 usec per link would not affect the
construction of a route. But for cases that require very low bounded latency,
e.g., DetNet, such a level of uncertainty about the actual value of the delay
might fail to find a route altogether. Consider a case where the measured e2e
delay is N usec is well within the required level. But the sum of the
advertised Maximum Link Delays is above that threshold.
I think that using 100 nsec as the unit of the Maximum Link Delay is a
reasonable compromise between that scale and accuracy.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D
Institute/Wireline Product Operation Division
E: [email protected]
www.zte.com.cn
Original Mail
Sender: AnoopGhanwani
To: gregory mirsky10211915;
CC: [email protected];
Date: 2021/05/25 00:11
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
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 <[email protected]> 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: [email protected]
www.zte.com.cn
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
