Siva Kesava Reddy Kakarla’s research while affiliated with Microsoft and other places

... Classical algorithms such as FanOut [7] and Spread-Out [33] are simple approaches to scheduling that take 2.5-91× longer to complete All-to-All transfers than a theoretical optimum ( §6). A modern line of research (such as TE-CCL [29] and TACCL [48]) uses computationally complex algorithms to compute optimized schedules; the transfers they compute for balanced workloads (i.e., those without skew) complete near-optimally. However, the time to compute one schedule ranges from minutes to days, all for an All-to-All transfer, which itself completes in milliseconds! ...

Reference:

FLASH: Fast All-to-All Communication in GPU Clusters

... Model checkers [1,3,4,14,18,36,39,43,54,57] model a network's routing and forwarding behaviors based on protocol semantics and device configurations, and check whether engineerspecified reachability and resilience policies are satisfied. Consistency checkers [13,19,20,[22][23][24]45] compare configurations within and across devices and flag inconsistencies and deviations from best practices. LLM-based Q&A tools [7,11,29,32,50,51] parse configuration files and query pre-trained sequential transformer models through prompts to detect syntax and subtle semantic issues. ...

Reference:

CAIP: Detecting Router Misconfigurations with Context-Aware Iterative Prompting of LLMs

... Second, the recent rise of Large Language Models (LLMs) has provided increasingly sophisticated automatic coding and code understanding tools, and ways for operators to interact with their system at a higher level of abstraction. This has the potential to reduce the significant manual effort usually required by operators for tasks such as incident detection [38], incident management and mitigation [3,17,19,23,39], and root cause analysis [3,6,9,35,42,43]. ...

Reference:

Intent-based System Design and Operation

... However, this approach faces two major challenges: first, the need for real-time collection of network-wide demand information to compute a schedule of switch configurations and the long reconfiguration times of commercial OCSes result in significant overhead when frequently reconfiguring networks at scale [33]; second, the collected traffic may not accurately predict future communication demands, leading to potential mismatches between switch configurations and actual application requirements. Current CCLs [21,[49][50][51] for model training are primarily designed for static topologies, whereas in reconfigurable networks, the topology may continuously change. To address this, we propose a novel strategy that reconfigures the communication patterns of collective algorithms to adapt to dynamically changing network topologies, thereby optimizing overall performance. ...

Reference:

RECCL: optimizing collective algorithms for reconfigurable optical networks

... B is expected to have enough expertise to solve the task, but also could be the adversary that performs malicious operations. For the rest of the paper, we focus on tasks related to router configuration troubleshooting (such as OSPF, BGP, and filter configurations) due to their high frequency (Table I) and significance [72], [44], [55], [35], [36]. Our primary focus is ensuring the network's correctness, specifically maintaining the reachability between network devices. ...

Reference:

Heimdall: Towards Risk-Aware Network Management Outsourcing

... The state of these heuristic analyzers today is reminiscent of the early days of our community's exploration of network verifiers and their potential to help network operators configure and manage their networks. In the same way that network verifiers enabled operators to identify bugs in their configurations [10,14,15,19,22,24,28,29,31,33,40,48,50], a heuristic analyzer can help them find the performance gap of the algorithms they deploy. Tools that allow operators to leverage heuristic analyzers more easily, identify why the heuristics underperform, and devise solutions to remediate the issue serve a similar purpose to the tools our community crafted that explained the impact of configuration bugs [23,25,40,41] (by producing all sets of packets that the bug impacted and the configuration lines that caused the impact). ...

Reference:

Towards Safer Heuristics With XPlain