Tony,
On 03/03/2021 18:21, Tony Li wrote:
Peter,
Link delay was dynamic before this draft. As William mentioned,
TWAMP can already be used to provide a dynamic measurement of link
delay. That, coupled with the link delay metric already gave us
dynamic path computation requirements and the possibilities of
oscillation and instability. We have chosen to charge ahead, without
addressing those concerns already.
TWAMP provided Min Unidirectional Link Delay is a dynamic one. On the
other side this value is calculated based on multiple measurements
over period of time and an average is used. Also, smart
implementations can normalize the value so that a small fluctuation of
the delay is not causing the traffic to shift or cause ECMP loss.
What is important here is that the Min Unidirectional Link Delay is a
link characteristic, not something that is affected by the amount of
traffic on the link or subject to queuing delay. Same applies to
Maximum link bandwidth.
I do understand that the minimum link delay is not meant to include
queuing delay. That, however, does NOT make it a constant.
I never claimed it is constant. It should not be affected though by the
amount of traffic on the link itself, but rather by the characteristics
of the underlying physical path.
There are several link types in use that exhibit variable delay:
satellite links (e.g., Starlink), microwave links, and ancient link
layers that deliver reliability through retransmission.
Any of these (and probably a lot more) can create a noticeable and
measurable difference in TWAMP. That would be reflected in an FA metric
change. If you imagine a situation with multiiple parallel paths with
nearly identical delays, you can easily imagine an oscillatory scenario.
IMHO, this is an outstanding concern with FA.
yes, and that is what I referred to as "delay normalization", which can
avoid that oscillation. There are implementations that do that today.
You normalize the measured value so that values that are close enough
are advertised as same value. That works well for min delay case, which
does not change significantly very often.
Please note that I’m NOT recommending that we back away. Rather, we
should seek to solve the long-standing issue of oscillatory routing.
not that I disagree. History tells us that the generic case of
oscillation which is caused by the traffic itself is a hard problem to
solve.
thanks,
Peter
Regards,
Tony
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
