Robert,
On 03/03/2021 20:57, Robert Raszuk wrote:
Peter,
> that differ by few microsecond
Really you normalize only single digit microseconds ???
What if link delay changes in milliseconds scale ? Do you want to
compute new topology every few milliseconds ?
let me repeat again.
Min delay is not something that changes every few milliseconds
significantly. It's a semi static variable that reflects the property of
the underlying physical path. It only changes when the physical path
properties changes - e.g. the optical path reroutes, etc. We
deliberately picked Min delay for flex-algo purposes for this semi
static property.
The small, non significant changes can be filtered by the normalization.
If the min delay changes significantly every few milliseconds there's
something wrong with the link itself - we have standard dampening
mechanisms in LS protocols to deal with unstable links that would kick
in. Similar to what we do if the link flaps every few milliseconds.
Out of curiosity as this is not a secret - What are your default min
delay normalization timers (if user does not overwrite with their own).
there is no timer needed for the normalization itself.
You are likely referring TWAMP computation interval which is 30 sec,
with probes being sent every 3 seconds in our implementation by default,
if I'm not mistaken.
Normalization is applied to the value that come from the above.
thanks,
Peter
Likewise how Junos or Arista normalizes it today ?
Thx,
R.
On Wed, Mar 3, 2021 at 7:41 PM Peter Psenak <[email protected]
<mailto:[email protected]>> wrote:
Tony,
On 03/03/2021 19:14, Tony Li wrote:
>
> Peter,
>
>>> 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.
>
>
> It can also negate the benefits of the feature. One might well
imagine that Starlink would want to follow a min-delay path for
optimality. If the delay variations are “normalized” out of
existence, then the benefits are lost. The whole point is to track
the dynamics.
for all practical purposes that we use it for, the two values of min
delay that differ by few microsecond can be treated as same without any
loss of functionality. So it's about the required normalization
interval
- something that can be controlled by the user.
thanks,
Peter
>
>
>>> 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.
>
>
> Any oscillation is difficult to solve. Positive feedback
certainly can exacerbate the problem. But solving hard problems is
why we are here.
>
> Yours in control theory,
> Tony
>
>
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
