Now 5228 visitors
Today:0 Yesterday:0
Total: 147753 212S 50P 4R
2026-10-20, Week 43
Member Login
TACT Journal Homepage
Call for Paper
Committee
Find My Paper
Author Homepage
Statistics & History
Welcome Message
Paper Procedure
FAQ
Paper Archives
Outstanding Papers
Program & Proceedings
Presentation Platform
Hotel & Travel Info
Photo Gallery
Scheduler Login
Seminar
Archives Login
Sponsors


















Online Q&A Session
Paper Number Author:
Paper Title
Keyword
Q&A Number **Select your question number !!
Questioner eMail:
Question
Answer
by
Author
Save Q&A

* Edit or answer any Q&A by selecting Q&A number Hyper Link below + Write button (Save)
ICACT20260358 Question.1
Questioner: pangb@dsp.ac.cn    2026-02-23 오후 10:53:25 		ICACT20260358 Answer.1
Answer by Auhor gonghao23@mails.ucas.ac.cn   2026-02-23 오후 10:53:25
Chrome Click!!
In the Bayesian reinforcement learning network measurement framework, what are the "Actions" considered by the agent? Also, in the proposed reward function, what does the switch monitoring load actually mean? 1.Actions The agents action is selecting a monitoring template, which specifies: - Base probing periods per flow class (stable/unstable/event flows) - Maximum number of flows K(a)to probe per slot The spatio-temporal scheduler then translates this coarse template into concrete per-flow decisions. --- ## Switch Monitoring Load $\text{Var}(\text{load}_t)$ measures how unevenly OpenFlow stats queries are distributed across switches. A high variance means some switches are flooded with polling requests (monitoring hotspots) while others are underutilized. Penalizing this variance forces the scheduler to spread the query burden evenly, preventing individual switches from being overloaded and degrading forwarding performance.
ICACT20260358 Question.2
Questioner: pangb@dsp.ac.cn    2026-02-23 오후 10:53:54 		ICACT20260358 Answer.2
Answer by Auhor gonghao23@mails.ucas.ac.cn   2026-02-23 오후 10:53:54
Chrome Click!!
In the experimental evaluation, is the implementation based on a simulation platform, or is it conducted in a real network environment? If it’s simulation-based, which simulator did you use? The experiments are simulation-based, not conducted in a real network environment. Specifically, the authors use Mininet, a network emulator that runs on a commodity Linux server. Mininet emulates the GÉANT backbone topology (23 nodes, 74 directed links) in software, and the Ryu SDN framework serves as the controller platform. BRIGHT and all baseline algorithms are implemented as Ryu controller applications running on top of this emulated environment. While Mininet provides realistic SDN behavior including actual OpenFlow message exchanges, it is still an emulation rather than a true physical network deployment. The authors acknowledge this limitation and mention validating on larger-scale testbeds and real controllers (ONOS, OpenDaylight) as future work.
ICACT20260358 Question.3
Questioner: tanghr@dsp.ac.cn    2026-02-23 오후 10:55:14 		ICACT20260358 Answer.3
Answer by Auhor gonghao23@mails.ucas.ac.cn   2026-02-23 오후 10:55:14
Chrome Click!!
What is the primary function of the Flow State & Uncertainty Manager in BRIGHT? Its primary function is to track the estimated rate and uncertainty of each active flow using a lightweight Bayesian model. Specifically, it does three things: Bayesian update: whenever a flow is probed, it updates the flows estimated rate and confidence based on the new observation. Uncertainty quantification: computes an entropy-based metric to measure how uncertain the current estimate is. Stability scoring and flow classification: assesses short-term traffic volatility for each flow and categorizes it into one of four classes — stable elephant, stable mouse, unstable, or event flow. These outputs feed into the spatio-temporal scheduler (to prioritize probing) and the policy module (as contextual input for template selection).
ICACT20260358 Question.4
Questioner: wangsy@dsp.ac.cn    2026-02-23 오후 10:55:43 		ICACT20260358 Answer.4
Answer by Auhor gonghao23@mails.ucas.ac.cn   2026-02-23 오후 10:55:43
Chrome Click!!
What main problems does BRIGHT aim to solve in the OpenFlow/SDN traffic monitoring? (Budget constraints, high costs, inaccurate estimations, etc.) BRIGHT targets three core problems in SDN/OpenFlow traffic monitoring: Tight monitoring budget constraints: In large networks, polling all flows at high frequency is infeasible due to limited control-plane bandwidth and switch/controller CPU capacity. BRIGHT must deliver accurate traffic matrix estimates while keeping monitoring overhead within budget. Lack of adaptive monitoring: Existing methods rely on static heuristics or fixed polling periods and cannot dynamically adjust monitoring intensity in response to traffic dynamics, especially under bursty conditions. Weak coupling between monitoring and inference: Prior approaches do not maintain explicit per-flow uncertainty models, making it difficult to know which flows actually need more frequent probing and which can be safely compressed. Unbalanced and costly spatio-temporal scheduling: Existing systems treat spatial (which switch) and temporal (how often) decisions separately, ignoring heterogeneous switch costs and leading to monitoring hotspots, excessive control-plane overhead, and uneven load distribution. In short, BRIGHT aims to jointly solve the problem of doing more with less — achieving accurate traffic matrix estimation under strict resource constraints, while continuously adapting to changing network conditions.
ICACT20260358 Question.5
Questioner: wangsy@dsp.ac.cn    2026-02-23 오후 10:56:40 		ICACT20260358 Answer.5
Answer by Auhor gonghao23@mails.ucas.ac.cn   2026-02-23 오후 10:56:40
Chrome Click!!
How does BRIGHT determine the monitoring intensity based on "uncertainty"? (For example, allocating more detection quotas to which streams?) BRIGHT uses uncertainty to guide monitoring intensity in the following way: Flows with high uncertainty get probed more frequently. Uncertainty is measured by the posterior entropy of each flows Gaussian model — a larger variance means the controller is less confident about the flows true rate, so it deserves more attention. Flows that have not been observed recently naturally accumulate higher uncertainty over time. Stability further refines probing frequency. Beyond entropy, BRIGHT computes a stability score reflecting short-term traffic volatility. Flows with poor stability (i.e., highly variable behavior) receive shorter probing periods, meaning they are polled more aggressively. Conversely, flows that remain stable over time are probed more sparsely, freeing up budget for uncertain or volatile ones. Flow classification translates uncertainty into priority. Based on entropy and stability, each flow is assigned to one of four categories — stable elephant, stable mouse, unstable, or event flow — each with different default probing periods and priority levels. Event flows (detected anomalies) receive the highest priority boost via the event flag in the scoring function. Within each slot, a composite score determines who gets probed. When the available budget cannot cover all due flows, BRIGHT ranks them by a score combining normalized entropy, temporal urgency (how overdue the flow is), and the event flag. Only the top-ranked flows are actually polled. In essence, BRIGHT continuously concentrates its limited monitoring budget on flows where measurement would reduce uncertainty the most, while leaving well-understood stable flows largely unattended.
ICACT20260358 Question.6
Questioner: hhl9438@chungbuk.ac.kr    2026-02-23 오후 10:57:16 		ICACT20260358 Answer.6
Answer by Auhor gonghao23@mails.ucas.ac.cn   2026-02-23 오후 10:57:16
Chrome Click!!
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.
ICACT20260358 Question.7
Questioner: abdelhadi.belfadel@irt-systemx.fr    2026-02-23 오후 10:57:54 		ICACT20260358 Answer.7
Answer by Auhor gonghao23@mails.ucas.ac.cn   2026-02-23 오후 10:57:54
Chrome Click!!
from a security perspective: Could an attacker exploit BRIGHTs adaptive nature by generating stable-looking malicious traffic to trick the Bayesian model into lowering its monitoring intensity, thereby hiding a slow-rate attack? This is an excellent and practically important security concern. The short answer is yes, such an attack is theoretically feasible, and the paper does not address this threat at all. How the attack would work. BRIGHTs core logic is that stable, low-variance flows get probed less frequently. An attacker who understands this could deliberately craft malicious traffic to mimic a stable mouse flow — maintaining a steady, low rate over time to build up a trustworthy posterior in the Bayesian model. Once the stability score is high and entropy is low, BRIGHT would naturally reduce the probing frequency for that flow, creating a window during which slow-rate malicious activity (such as data exfiltration, slow port scanning, or covert channel communication) could proceed with minimal monitoring scrutiny. Why BRIGHT is particularly vulnerable. The Bayesian model is designed to trust historical observations — that is its strength for efficiency, but also its weakness against adversarial manipulation. A patient attacker who operates below the burst detection threshold would never trigger the event flag, never elevate their stability score, and never appear in the high-priority probing queue. The system would essentially learn to ignore them. What the paper offers as partial protection. The temporal urgency component of the scoring function ensures that even stable flows are eventually revisited after sufficient time has passed. So a flow can never be permanently ignored — but the probing interval could be stretched long enough to make detection practically difficult. What is missing. BRIGHT has no adversarial awareness whatsoever. It lacks mechanisms such as randomized probing to prevent predictable blind spots, anomaly detection based on cumulative behavioral patterns rather than short-term variance, or any notion of a minimum probing floor for security-sensitive flows regardless of their apparent stability. In summary, BRIGHTs adaptive efficiency and its security robustness are in direct tension, and this represents a meaningful gap that future work would need to address, perhaps by incorporating a security-aware probing floor or integrating with dedicated intrusion detection systems.