You mentioned BRIGHT handles bursty traffic well. However, Bayesian updates and Bandit decisions take time. Is there a lag time between the start of a sudden traffic burst and the systems adaptation? If so, how do you mitigate data loss during that lag?
This is a valid and insightful concern. Based on the paper, there is indeed an inherent lag, and here is an honest assessment:
Yes, a lag exists. BRIGHT operates in discrete time slots, meaning the system can only react to a burst at the earliest in the slot after it is first detected. The Bayesian update must observe new measurements, the evaluator must compute the reward, and the bandit must update and select a new template — all of which happen within the closed loop and cannot take effect instantaneously.
How BRIGHT partially mitigates this:
First, the stability score and entropy rise quickly once a burst begins affecting observations, so the spatio-temporal scheduler can start increasing probing frequency for affected flows within the same or next slot, even before the bandit selects a new global template.
Second, the event flag mechanism provides a faster local response — when a flows observation deviates significantly from its historical posterior mean, it is immediately flagged as an event flow and given the highest probing priority in the current scheduling round.
Third, the bandits contextual input includes the proportion of unstable and event flows, so it can detect a deteriorating situation and switch to a more aggressive monitoring template relatively quickly.
However, the paper does not explicitly quantify this lag or propose a dedicated mechanism to prevent data loss during the transition period. This remains a genuine limitation. In practice, the severity of the lag depends on slot length — a shorter slot reduces reaction time but increases overhead. This trade-off is not deeply analyzed in the paper, and could be considered a direction for future work.
