Hi Robert,
> On Apr 2, 2023, at 6:21 AM, Robert Raszuk <[email protected]> wrote: >> The former is a local event and link/node failures are an isolated events. >> > >> <cb> Can you point us to the source of this assumption? >> > > You mean the above ? Does it require a source of this "assumption" ? To me > this is a basic fact. I would definitely like to understand it. To my mind, link/node failures have at least an area-wide impact. The scope of a congestion event and failures are extremely similar to my mind. >> That is actually one question I forgot to ask .. when or based on what >> network event do you "deactivate" TTE ? >> >> >> >> <cb> It’s described in the draft (or should be). In summary, when the >> cumulative byte rate across the newly formed ECMP falls below the low >> threshold for some consecutive number of traffic samples TTE activated >> prefixes are deactivated according to the prefix selection technique. >> > > Wait ? What newly formed ECMP ??? So the FRR is not a unicast bypass ? As discussed in the presentation and in the draft, when a prefix is activated, TTE shifts the backup paths to be in ECMP with the primary path. This shifts a portion of the traffic for the affected prefix onto the bypass path. > Also let's consider that FRR techniques used in networks do not rightfully > allow for nested protection. So by using them to avoid congestion one could > argue that you are actually making network weaker as bypasses will be subject > to drops when link or node fails on the paths. Yes, that’s a fair point. Again, that seems preferable to congestive loss. > Also not sure what you call "cumulative rates". Congestion can very well as > Jim said be caused by short lived traffic bursts. TTE is attempting to deal with congestion events that have durations in the tens of seconds. The default (de)activation timers are set at 10s. >> We’re not suggesting that a network need to handle multiple simultaneous >> correlated failures. > > Congestion if long lived by its nature is a corelleted event across N nodes. That seems like it is possible, but not strictly mandatory. >> If congestion is network wide, then yes, TTE will not help. Again, capacity >> is a zero-sum game. We can only shed load and we need capacity to redirect >> it to. > > How can congestion not be a network wide (from ingress to egress) event ? I > am assuming we are talking about unicast. Yes, we are only discussing unicast. Congestion can be a local phenomenon. 101Gb of traffic funneled into a 100Gb link that drops the excess 1Gb of traffic will effectively ‘protect’ the downstream 100Gb links. >> If there are many links along a path that are congested, then TTE may help. >> It can activate prefixes on each of the congested links, thereby alleviating >> congestion along the path. > > By shifting the traffic to other possibly also congested links ? FRR like > various LFA algorithms do not consider congestion when computing backup > bypass paths. Exactly. Since repair requires that you provision bandwidth for failures, their assumption is that bypass links are not completely congested. If all of your links are totally saturated, then FRR does not help at all and neither does TTE. That’s not a use case that’s interesting to address. >> Both link failure and TTE activation are going to shift traffic onto the >> bypass path. If your network can’t support that, then the use of bypass >> paths is not recommended. > > Since congestion is an unexpected network event how can you (or anyone know) > if a given network is ready for it ? Proper engineering for bypass links allows for bandwidth on the bypass for the traffic load. >>> That is actually one question I forgot to ask .. when or based on what >>> network event do you "deactivate" TTE ? >> When the utilization on the protected link falls below the low threshold, >> then TTE will redirect traffic to the protected link. > > Well the moment you apply a bypass to a subset of traffic the utilization of > such a link will immediately fall below the threshold. So if you remove TTE > you will get congestion again. Please recall that there are two thresholds: high and low. Activating a prefix may shift some traffic to the bypass. Typically, we would expect that after a few prefixes are shifted, enough load would be shed so that utilization lies between the low and high thresholds. TTE is iterative and continuous: if flow selection does not alleviate congestion, more flows will be selected in the next iteration. Similarly, if flow selection overshoots, it will self-correct by deactivating prefixes until utilization lies between thresholds. >> Some people choose to act prior to queue build up. As you know, traffic is >> bursty. Queues can wax and wane very rapidly. Responding to just queue >> depth would result in a very high frequency oscillation which would be an >> inappropriate time frame for traffic redirection. > > This is not what I meant. In all cases the trigger to start bypass should > consider crossing the threshold of X for time T. This should be done in the > same way when looking at the interface or queue. That’s what we’re doing: we look for capacity to exceed the high threshold for a multiple samples. >> Further, we want to be able to address congestion before there is >> significant queue occupancy. Using TTE, an operator could, for example, >> start to redirect traffic when a link exceeds an unusual traffic level but >> well before there was significant queuing. > > If so this is not a "congestion", but increased load of a link. Those two are > completely different things. > REF: https://en.wikipedia.org/wiki/Network_congestion ? Wikipedia is hardly authoritative. As you well know, traffic is highly fractal. There are high frequency traffic bursts that can cause queue utilization even when overall link utilization is not 100%. In my experience, a link that is at 99% utilization (in production, not in lab situations) is already quite congested and is almost certainly dropping a significant amount of traffic. Congestion happens well before 100% utilization. >> If you have massive congestion and QoS, then you could have TTE redirect >> your BE flows, keeping your priority flows on the primary link. > > Maybe ... I would just allow for BE applications to slow down. Again, that’s your choice. Some people make their money delivering BE traffic. Dropping it would be unacceptable to them. Tony
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
