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

[[e-mail]]

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: [e-mail] 
www.zte.com.cn






Original Mail



Sender: AnoopGhanwani
To: gregory mirsky10211915;
CC: [e-mail];
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 <[e-mail]> 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: [e-mail] 
www.zte.com.cn





_______________________________________________
 Lsr mailing list
 [e-mail]
 https://www.ietf.org/mailman/listinfo/lsr