Pith. sign in

REVIEW 4 major objections 5 minor 53 references

FlexNGIA 2.0: Redesigning the Internet with Agentic AI -- Protocols, Services, and Traffic Engineering Designed, Deployed, and Managed by AI

T0 review · 4 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read AI agents write and deploy network code at runtime

desk verdict A plausible architecture with three real but unreplicated proof-of-concept demos; the evidence is too thin for the full autonomous-design claim, but it deserves peer review. read the letter →

arxiv 2509.02124 v2 pith:XSJS6OAQ submitted 2025-09-02 cs.NI cs.ET

Mohamed Faten Zhani , Younes Korbi , Yamen Mkadem This is my paper
classification cs.NIcs.ET
keywords AgenticAILLM-basedagentsInternetarchitectureServicefunctionchainingProtocoldesignCongestioncontrolResourceallocationNetworksoftwarization
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that the next Internet can be run by LLM-based AI agents that do what network engineers and static algorithms do today: analyze application requirements, design service function chains and network functions, write transport protocols, pick or invent congestion control schemes, and decide how to allocate resources, all at runtime rather than at design time. It proposes a concrete architecture, FlexNGIA 2.0, in which specialized agents perceive network state through a unified report and act by generating code and configuration. The proof-of-concept experiments are the load-bearing part: an agent designed and deployed a complete service function chain with a custom UDP-based transport protocol that met selective-reliability and stable-throughput requirements where TCP and UDP each missed one requirement, and another agent generated new Linux congestion-control modules at runtime that stabilized throughput near 12 Mbps under a 90 ms delay target. A third agent dynamically reweighted a multi-objective resource allocation function, cutting green-energy penalty by up to 20% in the first phase and 9.6% under doubled load while keeping profit nearly intact. If these results generalize, network protocols and management algorithms stop being fixed standard artifacts and become a continuously synthesized layer.

What carries the argument

The load-bearing mechanism is the structured system prompt combined with a runtime feedback loop. Each agent's prompt fixes a role, its inputs (the IFA report, the network function catalog, the resource allocation report), a decision space (use, adapt, or generate), and a step-by-step reasoning process, making the LLM's output predictable enough to compile and deploy. Three technical templates carry the code generation: the magic-field custom header over UDP, so intermediate network functions can parse the new protocol; the Linux tcp_congestion_ops kernel-module template, so generated congestion control code plugs into the kernel without resetting live connections; and the normalized multi-o

What would settle it

Run the same agents repeatedly across varied topologies, loss rates, and workloads and check whether generated code always meets the stated QoS targets without kernel crashes or protocol misbehavior; a single failure mode, such as a generated CC module that panics the kernel or a custom protocol that fails to interoperate with standard UDP, would falsify the claim that runtime synthesis is reliable. A concrete benchmark would test LLM-Proto under high random loss or behind a NAT and show whether the approach generalizes beyond the reported conditions.

Watch

Extended reading notes

Core claim

On its own terms, the paper's central claim is that protocol and network-management logic can be treated as a deployable artifact produced by a prompted LLM within a closed loop: measure, reason, generate, deploy, then re-measure and adapt. The SFC & Protocol Agent's output, a four-function chain operating over LLM-Proto, a custom header on top of UDP with a magic field and selective-reliability flags, is presented as a fully functional SFC that delivers 100% of reliability-marked packets, roughly 79% of best-effort packets, a stable 1 Mbps rate, and lower flow completion time than TCP. The Congestion Control Agent generated and loaded two successive kernel modules, replacing TCP Reno at run

Load-bearing premise

The paper assumes that code written by an LLM can be trusted to be correct, safe, and performant in real deployment; the authors note that robust verification mechanisms for LLM-designed components do not yet exist, and the experiments are single successful runs in an emulator with no formal or runtime verification.

Editorial extensions

If this is right

  • Applications can receive per-application service function chains and transport protocols, such as selective reliability for marked packets only, instead of a fixed protocol stack.
  • Congestion control can be switched or newly synthesized at runtime, without interrupting live TCP connections, responding to measured QoS and QoE rather than a static default.
  • Resource allocation can continuously rebalance cost, profit, fairness, and green-energy penalties as workload changes.
  • Networks gain a design loop: generated components are deployed, measured, and revised, so behavior can evolve with conditions.
  • The catalog of existing network functions, protocol templates, and evaluation tools becomes as important as the LLM itself; prompts and templates are effectively the new standard.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If LLM-generated code is validated in a simulated or digital-twin sandbox before kernel loading, the same agents could be used in production with bounded risk; the paper leaves this as future work.
  • The reported success may depend on the stability of the prompt and the particular LLM; a natural test is to rerun the same pipeline across multiple seeds and models and measure the distribution of outcomes rather than a single run.
  • The multi-agent coordination shown here is minimal, agent-to-agent message passing plus a shared report; scaling to many competing applications may require an explicit mechanism to prevent conflicting decisions.
  • The magic-field custom header protocol inherits UDP's lack of encryption and NAT-friendliness, so LLM-designed protocols would need to address middlebox traversal and security before real deployment.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes FlexNGIA 2.0, an agentic-AI Internet architecture in which LLM-based agents perceive, reason, and coordinate to autonomously design, implement, deploy, and adapt service function chains (SFCs), network functions (NFs), transport protocols, congestion control (CC) schemes, and resource allocation strategies at runtime. The paper details the architecture, agent building blocks, prompt structures, inter-agent coordination, and proof-of-concept experiments. In Section IV-B, a GPT-5 Thinking agent generates a custom UDP-based transport protocol (LLM-Proto), a tailored SFC, and C code for NFs that are evaluated in Mininet-WiFi against TCP and UDP. In Section IV-C, a DeepSeek-R1-powered CC agent generates and loads two Linux kernel CC modules, LLM_CC_V1 and LLM_CC_V2, during a 200 s run. In Section IV-D, a GPT-5 Thinking-powered Resource Allocation agent adjusts weights α1–α4 of a fixed multi-objective function every 24 h over a six-day simulation. The paper concludes that these agents can automate network protocol, SFC, CC, and resource-allocation design, and identifies key research challenges, including verification.

Significance. If the capability claim is substantiated, the paper charts a genuinely new direction: runtime synthesis of protocols, network functions, and control algorithms by LLM agents instead of design-time human specification. The architecture is clearly presented, the prompts are concrete, and the integration with FlexNGIA 1.0 is coherent. The proof-of-concept demonstrations are useful existence proofs, and the authors candidly acknowledge that robust verification mechanisms do not yet exist. However, the evidence is preliminary, single-run, and not independently reproducible because the code is not released. The central claim—that LLM agents can autonomously and dependably design, implement, and deploy network components—goes beyond what the current experiments establish.

major comments (4)
  1. [IV-B, Fig. 9 and Fig. 12] The central capability claim rests on a single successful run. The text states 'the C code generated by GPT-5 Thinking ran successfully without any errors' but reports no number of repetitions, no seeds/temperatures, and no confidence intervals. LLM outputs are stochastic; a single success is an existence proof, not evidence of a dependable autonomous design capability. The code is only 'available upon request' (footnote 1), preventing independent verification. Please provide repeated independent runs (with success rates and performance variance), and release code, prompts, and scripts so reviewers and the community can reproduce the results.
  2. [IV-C, Figs. 16 and 17; V-A] The CC-agent demonstration contains only two decision points in a single 200-second run, with no repetitions or statistical analysis. More importantly, the LLM-generated kernel modules LLM_CC_V1 and LLM_CC_V2 are loaded into the kernel without any verification layer, while Section V-A acknowledges that robust verification mechanisms 'do not yet exist.' For safety-critical kernel code, the claim of autonomous deployment requires at least compile-time and bounded-runtime validation before loading. Please add repeated trials, quantitative comparison against static CC baselines, and a description of any safety checks actually performed.
  3. [IV-D, Eq. (1) and Fig. 19] The RA experiment only tunes weights α1–α4 of a fixed objective function; it does not demonstrate design of a new resource allocation algorithm, despite the paper claiming agents can 'design' resource allocation strategies. The evaluation metrics (cost, profit, utilization, fairness, green penalty) are the same terms as the objective in Eq. (1), so observed improvements under weight adaptation are partly by construction. Either scope the claim to 'weight adaptation' or include an experiment where the agent synthesizes a new allocation policy. In either case, multiple simulation runs with confidence intervals are needed to support the conclusions.
  4. [IV-B and V-C] The paper states the LLM-generated SFC/protocol 'outperform[s] legacy protocols in terms of all requirements,' but the only baselines are TCP and UDP. There is no comparison against a hand-designed selective-reliability protocol or a static SFC using the same NFs. Without such a baseline, the improvement may be due to the inherent design of the protocol (selective reliability) rather than to the LLM's generation capability. Please add a human-designed baseline or explicitly limit the claim to demonstrating that an LLM can generate a working artifact, not that the artifact is superior in a way that is attributable to the AI-driven process.
minor comments (5)
  1. [Fig. 15] The claimed 'minimal yet valid' kernel template contains apparent typos: `tcp_register_congestion_pontrol` should be `tcp_register_congestion_control`, and `_init`/`_exit` should be `__init`/`__exit`. Please correct the figure or state that the tested prompt used a corrected template.
  2. [IV-D vs Fig. 19] Eq. (1) in the text defines the utilization/fairness term as α3·[Utilization + (1−FairnessIndex)], whereas the prompt in Fig. 19 lists α3 twice: 'α3 * normalizedUtilization' and 'α3 * (1 - UtilizationFairness)'. Make the two formulations consistent.
  3. [References] References [23] and [44] are duplicate entries for 'Introducing GPT-5'; consolidate. Also, the heading 'Ressource Allocation Agent System Prompt' in Fig. 19 contains a typo.
  4. [IV-B] Minor grammar/typo: 'the the source UE' appears in the experimental setup paragraph. Also, use consistent naming for Mininet-WiFi (vs. 'mininet-wifi') and for the generated CC modules (`llm_cc_v1` vs. `llm cc v(i)`).
  5. [V-B] The claim that structured prompts make LLMs 'deliver more reliable and higher-quality algorithms' is stated without direct evidence in the paper. Consider softening or citing a systematic prompt-ablation study.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: demonstrations are empirical runs of LLM-generated code and closed-loop control, not fitted predictions.

full rationale

FlexNGIA 2.0 is an architecture/proof-of-concept paper; its central claims are supported by empirical demonstrations rather than by derivations that reduce to their inputs. (1) SFC & Protocol Agent: the LLM generated C code for LLM-Proto and NFs; the paper reports that the code 'ran successfully without any errors' and compares measured reliability, completion time, and rate against TCP/UDP (Section IV-B, Fig. 12). This is an external run-time evaluation, not a reconstruction of the prompt or template. (2) CC Agent: the generated kernel modules were loaded and metrics (cwnd, throughput, RTT, loss) were measured over 200 s (Section IV-C, Fig. 16); the improvement is an observed outcome, not an artifact of the 8-step prompt. The use of a kernel template is implementation scaffolding, not a fitted parameter. (3) RA Agent: adjusting α1-α4 in Eq. (1) is a control action; the subsequent simulation metrics (green penalty, profit, etc.) are measured outcomes under the modified objective. The fact that the same objective function guides allocation is a closed-loop design, not circular reasoning. Self-citations (FlexNGIA 1.0 [14], [15]; CC survey [4]; SFCaaS code [25]) are background or baseline and are not used as proof of the paper's new claims. The paper explicitly flags open challenges (Section V-A: 'robust mechanisms to verify ... do not yet exist'), which is a limitation, not circularity. No step in the derivation chain is equivalent to its input by construction.

Assumptions & free parameters 3 free parameters · 4 assumptions · 2 invented entities

The central claim rests on the assumption that LLM-generated code is reliable, that emulation reflects reality, and that the chosen objective function captures operator goals. Free parameters are mainly the RA objective weights and evaluation intervals, which are chosen heuristically by the LLM or the authors; no fitted constants are used in protocol or CC generation, but the absent code leaves many generated parameters undisclosed.

free parameters (3)
  • RA objective weights α1-α4 = α4 raised to 0.60 at the 96h update (Fig. 20d)
    Weights in Eq. 1 are selected by the LLM from 24h statistics and directly determine which SFCs are mapped; they are heuristic choices, not derived quantities.
  • Evaluation intervals (60s for CC, 24h for RA) = 60 s / 24 h
    These intervals are chosen by the authors and affect how quickly agents adapt; they are not justified by data.
  • LLM-generated CC parameters (thresholds inside LLM_CC_V1/V2) = not disclosed
    The generated kernel modules are shown only as black boxes in Figs. 16-17; their internal constants are undisclosed and were not independently evaluated.
assumptions (4)
  • domain assumption LLM-generated C code (NFs, client/server, kernel modules) is correct and safe enough to run
    All demos depend on this; the paper reports one successful run and lists verification as future work (Section V-A).
  • domain assumption Mininet-WiFi emulation is representative of real 802.11g wireless behavior
    All SFC/CC experiments use Mininet-WiFi with interference similar to that reported in [4]; no real-hardware validation is provided.
  • domain assumption The multi-objective function (Eq. 1) with min-max normalization captures the operator's true goals
    RA agent performance is evaluated on metrics from this same objective, so improvement is defined within the authors' chosen formulation.
  • standard math Jain's fairness index is an appropriate fairness measure
    Used in Eq. 1 and in fairness evaluation (Section IV-D).
invented entities (2)
  • LLM-Proto (custom UDP-based transport protocol)
    purpose: Demonstrate the SFC & Protocol Agent generating a custom selective-reliability protocol
    Tested only inside the paper's emulator; code not released, so no external falsifiable handle.
  • LLM_CC_V1 and LLM_CC_V2 (LLM-generated Linux TCP congestion control modules)
    purpose: Demonstrate runtime design and deployment of congestion control schemes
    Metrics are shown in one 200s run; underlying constants are undisclosed and code is unavailable.

how reviews work

0 comments
Cite this review

Pith. "Pith review of FlexNGIA 2.0: Redesigning the Internet with Agentic AI -- Protocols, Services, and Traffic Engineering Designed, Deployed, and Managed by AI." pith.science (2026). https://pith.science/paper/XSJS6OAQ

@misc{pith2026250902124,
  author       = {Pith},
  title        = {Pith review of: FlexNGIA 2.0: Redesigning the Internet with Agentic AI -- Protocols, Services, and Traffic Engineering Designed, Deployed, and Managed by AI},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XSJS6OAQ}},
  note         = {Machine review of arXiv:2509.02124}
}
read the original abstract

The escalating demands of immersive communications, alongside advances in network softwarization and AI-driven cognition and generative reasoning, create a pivotal opportunity to rethink and reshape the future Internet. In this context, we introduce in this paper, FlexNGIA 2.0, an Agentic AI-driven Internet architecture that leverages LLM-based AI agents to autonomously orchestrate, configure, and evolve the network. These agents can, at runtime, perceive, reason, coordinate among themselves to dynamically design, implement, deploy, and adapt communication protocols, Service Function Chains (SFCs), network functions, resource allocation strategies, congestion control, and traffic engineering schemes, thereby ensuring optimal performance, reliability, and efficiency under evolving conditions. The paper first outlines the overall architecture of FlexNGIA 2.0 and its constituent LLM-Based AI agents. For each agent, we detail its design, implementation, inputs and outputs, prompt structures, interactions with tools and other agents, followed by preliminary proof-of-concept experiments demonstrating its operation and potential. The results clearly highlight the ability of these LLM-based AI agents to automate the design, the implementation, the deployment, and the performance evaluation of transport protocols, service function chains, network functions, congestion control schemes, and resource allocation strategies. FlexNGIA 2.0 paves the way for a new class of Agentic AI-Driven networks, where fully cognitive, self-evolving AI agents can autonomously design, implement, adapt and optimize the network's protocols, algorithms, and behaviors to efficiently operate across complex, dynamic, and heterogeneous environments. To bring this vision to reality, we also identify key research challenges toward achieving fully autonomous, adaptive, and agentic AI-driven networks.

Figures

Figures reproduced from arXiv: 2509.02124 by the authors.

Figure 1
Figure 1. FlexNGIA 1.0 management framework. proposes a management framework comprising several core modules ( [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Building Blocks of an LLM-Based Agent and Its Interaction with External Tools. Among the above components, the planning module is crucial as it establishes the strategy and the steps that direct the agent toward achieving its intended objective. A key part of this planning involves prompt engineering: designing and refining the instructions, known as prompts, provided to the agent. In the following, we present a mor… view at source ↗
Figure 3
Figure 3. FlexNGIA 2.0 - Agentic AI-based Management Framework. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (15 more)
Figure 4
Figure 4. Figure 4: Template of the IFA report generated by the Information Fusion Agent. from other agents ( [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 7
Figure 7. Figure 7: Example of a custom header generated by the SFC & Protocol Agent then checks whether available NFs and protocols fit to these requirements. It then decides to use them or design and implement new ones, and predicts the impact of the chosen solution on performance metri…
Figure 8
Figure 8. Figure 8: Coordination Messages Between the SFC & Protocol [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]
Figure 9
Figure 9. Figure 9: Inputs and Outputs of the SFC & Protocol Agent in our experiments. [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]
Figure 10
Figure 10. Figure 10: Description of the generated SFC and custom protocol [PITH_FULL_IMAGE:figures/full_fig_p011_10.png]
Figure 11
Figure 11. Figure 11: Experimental network topology. (a) Packets received (b) Flow completion time (c) Sending/Receiving rate (Mbps) [PITH_FULL_IMAGE:figures/full_fig_p011_11.png]
Figure 14
Figure 14. Figure 14: System prompt of the Congestion Control Agent. [PITH_FULL_IMAGE:figures/full_fig_p012_14.png]
Figure 13
Figure 13. Figure 13: Operation of the Congestion Control Agent integrated [PITH_FULL_IMAGE:figures/full_fig_p012_13.png]
Figure 16
Figure 16. Figure 16: Performance metrics over time showing the CC agent’s decisions to switch between an existing CC scheme (TCP Reno) and the generated schemes LLM_CC_V1 and LLM_CC_V2, all at runtime. The red bullets indicate the times at which the CC agent performed an evaluation of the…
Figure 15
Figure 15. Figure 15: Template for a pluggable Linux CC module (in C). [PITH_FULL_IMAGE:figures/full_fig_p013_15.png]
Figure 17
Figure 17. Figure 17: IFA Reports and their corresponding CC Agent’s decision reports. [PITH_FULL_IMAGE:figures/full_fig_p014_17.png]
Figure 18
Figure 18. Figure 18: Operation of the Resource Allocation Agent. [PITH_FULL_IMAGE:figures/full_fig_p014_18.png]
Figure 19
Figure 19. Figure 19: System prompt of the Ressource Allocation Agent. [PITH_FULL_IMAGE:figures/full_fig_p015_19.png]
Figure 20
Figure 20. Figure 20: Decision reports of the Resource Allocation Agent across five evaluation cycles. [PITH_FULL_IMAGE:figures/full_fig_p016_20.png]
Figure 21
Figure 21. Figure 21: Comparison of resource allocation metrics with static weights and with RA agent-managed weights. The red bullets [PITH_FULL_IMAGE:figures/full_fig_p016_21.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

53 extracted references · 39 canonical work pages

  1. [1]

    Transmission Control Protocol (TCP),

    “Transmission Control Protocol (TCP),” RFC 793, Sep. 1981. [Online]. Available: https://rfc-editor.org/rfc/rfc793.txt

    work page 1981

  2. [2]

    QUIC: A UDP-Based Multiplexed and Secure Transport,

    J. Iyengar and M. Thomson, “QUIC: A UDP-Based Multiplexed and Secure Transport,” Oct. 2018, work in Progress. [Online]. Available: https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-16

    work page 2018

  3. [3]

    Stream Control Transmission Protocol (SCTP),

    “Stream Control Transmission Protocol (SCTP),” RFC 4960, Sep. 2007. [Online]. Available: https://rfc-editor.org/rfc/rfc4960.txt

    work page 2007

  4. [4]

    Congestion Control in Wi-Fi Networks - State of the Art, Performance Evaluation, and Key Research Directions,

    Y . Korbi, M. F. Zhani, and J. Kaippallimalil, “Congestion Control in Wi-Fi Networks - State of the Art, Performance Evaluation, and Key Research Directions,” IEEE Access , vol. 12, 2024. [Online]. Available: https://doi.org/10.1109/ACCESS.2024.3425271

    work page arXiv 2024

  5. [5]

    Congestion Avoidance and Control,

    V . Jacobson, “Congestion Avoidance and Control,” in ACM Conference on Communications Architectures and Protocols (SIGCOMM) , August

    work page

  6. [6]

    CUBIC: A New TCP-Friendly High-Speed TCP Variant,

    S. Ha, I. Rhee, and L. Xu, “CUBIC: A New TCP-Friendly High-Speed TCP Variant,” ACM SIGOPS Operating Systems Review , vol. 42, no. 5,

    work page

  7. [7]

    BBR: Congestion-Based Congestion Control,

    N. Cardwell, Y . Cheng, C. S. Gunn, S. H. Yeganeh, and V . Jacobson, “BBR: Congestion-Based Congestion Control,” Communications of the ACM , vol. 60, no. 2, January 2017. [Online]. Available: https://doi.org/10.1145/3009824

    doi:10.1145/3009824 2017

  8. [8]

    TCP Westwood: End-to-End Congestion Control for Wired/Wireless Networks,

    C. Casetti, M. Gerla, S. Mascolo, M. Sanadidi, and R. Wang, “TCP Westwood: End-to-End Congestion Control for Wired/Wireless Networks,” Wireless Networks, vol. 8, no. 5, September 2002. [Online]. Available: https://doi.org/10.1023/A:1016590112381

    work page doi:10.1023/a:1016590112381 2002

Show all 53 references
  1. [9]

    Bridging the Gap between QoE and QoS in Congestion Control: A Large-scale Mobile Web Service Perspective,

    J. Zhang, Y . Zhang, E. Dong, Y . Zhang, S. Ren, Z. Meng, M. Xu, X. Li, Z. Hou, Z. Yang, and X. Fu, “Bridging the Gap between QoE and QoS in Congestion Control: A Large-scale Mobile Web Service Perspective,” in USENIX Annual Technical Conference (USENIX ATC) , Jul. 2023

    2023

  2. [10]

    Linux Kernel Source: TCP CONG ADV ANCED in net/ipv4/Kconfig (v6.15.9), Linux Kernel Git Repository,

    “Linux Kernel Source: TCP CONG ADV ANCED in net/ipv4/Kconfig (v6.15.9), Linux Kernel Git Repository,” 2025, accessed: 2025-08-07. [Online]. Available: https://git.kernel.org/pub/scm/linux/kernel/git/ stable/linux.git/tree/net/ipv4/Kconfig?h=v6.15.9#n469

    2025

  3. [11]

    Set-NetTCPSetting (NetTCPIP),

    Microsoft, “Set-NetTCPSetting (NetTCPIP),” 2025, accessed: 2025-08-21. [Online]. Available: https : / / learn . microsoft . com / en - us / powershell / module / nettcpip / set - nettcpsetting ? view = windowsserver2025-ps#-congestionprovider

    2025

  4. [12]

    Top 10 Networking Features in Windows Server 2019 #8: A Faster, Safer Internet,

    M. N. Team, “Top 10 Networking Features in Windows Server 2019 #8: A Faster, Safer Internet,” 2019, accessed: 2025-08-07. [Online]. Available: https://techcommunity.microsoft.com/blog/networkingblog/ top-10-networking-features-in-windows-server-2019-8-a-faster-safer- internet/...

    2019

  5. [13]

    [Online]

    ns-3 project, “CUBIC,” 2022, accessed: 2025-08-07. [Online]. Available: https://www.nsnam.org/docs/release/3.36/models/html/tcp.html#cubic

    2022

  6. [14]

    FlexNGIA: A Flexible Internet Architecture for the Next-Generation Tactile Internet,

    M. F. Zhani and H. Elbakoury, “FlexNGIA: A Flexible Internet Architecture for the Next-Generation Tactile Internet,” Journal of Network and Systems Management (JNSM), Springer , 2020. [Online]. Available: https://doi.org/10.1007/s10922-020-09525-0

    2020 doi

  7. [15]

    FlexNGIA Project, https://www.FlexNGIA.net/, accessed: 2025-08-11

    2025

  8. [16]

    An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,

    D. Harrington, B. Wijnen, and R. Presuhn, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,” RFC 3411, Dec. 2002. [Online]. Available: https://www.rfc-editor.org/info/rfc3411

    2002

  9. [17]

    OpenStack: Open Source Cloud Computing Software,

    “OpenStack: Open Source Cloud Computing Software,” https://www. openstack.org/, 2025, accessed: 2025-08-08

    2025

  10. [18]

    OpenDaylight: A Linux Foundation Collaborative Project to Advance Software-Defined Networking,

    “OpenDaylight: A Linux Foundation Collaborative Project to Advance Software-Defined Networking,” https://www.opendaylight.org/, 2025, accessed: 2025-08-08

    2025

  11. [19]

    Tungsten Fabric: Open Source Network Virtualization and Cloud Networking,

    “Tungsten Fabric: Open Source Network Virtualization and Cloud Networking,” https://tungsten.io/, 2025, accessed: 2025-08-08

    2025

  12. [20]

    Open Network Automation Platform (ONAP),

    “Open Network Automation Platform (ONAP),” https://www.onap.org/, 2025, accessed: 2025-08-08

    2025

  13. [21]

    Agentic AI Frameworks: Architectures, Protocols, and Design Challenges,

    H. Derouiche, Z. Brahmi, and H. Mazeni, “Agentic AI Frameworks: Architectures, Protocols, and Design Challenges,” 2025. [Online]. Available: https://arxiv.org/abs/2508.10146

    2025 arXiv

  14. [22]

    Bornet, J

    P. Bornet, J. Wirtz, T. H. Davenport, D. De Cremer, B. Evergreen, P. Fersht, R. Gohel, S. Khiyara, N. Mullakara, and P. Sund, Agentic Artificial Intelligence: Harnessing AI Agents to Reinvent Business, Work and Life. Singapore?: Irreplaceable Publishing, 2025

    2025

  15. [23]

    Introducing GPT-5,

    OpenAI, “Introducing GPT-5,” 2025, accessed: 2025-08-18. [Online]. Available: https://openai.com/index/introducing-gpt-5/

    2025

  16. [24]

    DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning,

    DeepSeek-AI, “DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning,” arXiv preprint arXiv:2501.12948 ,

    arXiv

  17. [25]

    SFCaaS: Service function chains as a service in NFV environments,

    T. Moufakir, M. F. Zhani, A. Gherbi, M. Aloqaily, and N. Ghrada, “SFCaaS: Service function chains as a service in NFV environments,” ITU Journal on Future and Evolving Technologies , vol. 3, no. 3, 2022. [Online]. Available: https://doi.org/10.52953/ZPDB8065

    2022 doi

  18. [26]

    Profit-driven resource provisioning in NFV-based environments,

    W. Racheg, N. Ghrada, and M. F. Zhani, “Profit-driven resource provisioning in NFV-based environments,” in IEEE International Conference on Communications (ICC), Paris, France, May 21-25, 2017

    2017

  19. [27]

    CoDeC: A cost-effective and delay-aware SFC deployment,

    F. Tashtarian, M. F. Zhani, B. Fatemipour, and D. Yazdani, “CoDeC: A cost-effective and delay-aware SFC deployment,” IEEE Transactions on Network and Service Management (TNSM) , vol. 17, no. 2, 2020. [Online]. Available: https://doi.org/10.1109/TNSM.2019.2949753

    2020

  20. [28]

    On satisfying green SLAs in distributed clouds,

    A. Amokrane, M. F. Zhani, Q. Zhang, R. Langar, R. Boutaba, and G. Pujolle, “On satisfying green SLAs in distributed clouds,” in IEEE/ACM/IFIP International Conference on Network and Service Management (CNSM), Rio de Janeiro, Brazil, Nov. 17-21, 2014

    2014

  21. [29]

    Towards optimal synchronization in NFV-based environments,

    Z. Alomari, M. F. Zhani, M. Aloqaily, and O. Bouachir, “Towards optimal synchronization in NFV-based environments,” Wiley International Journal of Network Management (IJNM) , vol. 33, no. 1, 2023. [Online]. Available: https://doi.org/10.1002/nem.2218

    2023 doi

  22. [30]

    On improving service chains survivability through efficient backup provisioning,

    S. Aidi, M. F. Zhani, and Y . Elkhatib, “On improving service chains survivability through efficient backup provisioning,” in IEEE/ACM/IFIP International Conference on Network and Service Management (CNSM), Rome, Italy, Nov. 5-9, 2018

    2018

  23. [31]

    On Ensuring Full Yet Cost-Efficient Survivability of Service Function Chains in NFV Environments,

    Z. Alomari, M. F. Zhani, M. Aloqaily, and O. Bouachir, “On Ensuring Full Yet Cost-Efficient Survivability of Service Function Chains in NFV Environments,” Journal of Network and Systems Management (JNSM), Springer , vol. 31, no. 3, apr 2023. [Online]. Available: https://doi.or...

    2023 doi

  24. [32]

    Attention Is All You Need,

    A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, L. Kaiser, and I. Polosukhin, “Attention Is All You Need,” arXiv preprint arXiv:1706.03762 , 2017. [Online]. Available: https://arxiv.org/abs/1706.03762

    2017 arXiv

  25. [33]

    BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding,

    J. Devlin, M.-W. Chang, K. Lee, and K. Toutanova, “BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding,” arXiv preprint arXiv:1810.04805 , 2019. [Online]. Available: https: //arxiv.org/abs/1810.04805

    2019 arXiv

  26. [34]

    A Survey on Large Language Model based Autonomous Agents,

    Q. Wang, Z. Chen, Z. Li, Y . Huang, L. Bing, and L. Si, “A Survey on Large Language Model based Autonomous Agents,” arXiv preprint arXiv:2308.11432 , 2023. [Online]. Available: https: //arxiv.org/abs/2308.11432

    2023 arXiv

  27. [35]

    LLM agents: The ultimate guide 2025,

    SuperAnnotate, “LLM agents: The ultimate guide 2025,” https://www. superannotate.com/blog/llm-agents, Mar. 2025, accessed: 2025-08-11

    2025

  28. [37]

    Chain-of-Thought Prompting Elicits Reasoning in Large Language Models,

    J. Wei, X. Wang, D. Schuurmans, M. Bosma, B. Ichter, F. Xia, E. Chi, Q. Le, and D. Zhou, “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models,” arXiv preprint arXiv:2201.11903 , 2022. [Online]. Available: https://doi.org/10.48550/arXiv.2201.11903

    2022 doi arXiv

  29. [38]

    Tree of Thoughts: Deliberate Problem Solving with Large Language Models,

    S. Yao, D. Yu, J. Zhao, I. Shafran, T. L. Griffiths, Y . Cao, and K. Narasimhan, “Tree of Thoughts: Deliberate Problem Solving with Large Language Models,” arXiv preprint arXiv:2305.10601 , 2023. [Online]. Available: https://arxiv.org/abs/2305.10601

    2023 arXiv

  30. [39]

    Large Language Models are Zero-Shot Reasoners ,

    T. Kojima, S. S. Gu, M. Reid, Y . Matsuo, and Y . Iwasawa, “Large Language Models are Zero-Shot Reasoners ,” 2023. [Online]. Available: https://arxiv.org/abs/2205.11916

    2023 arXiv

  31. [40]

    Announcing the agent2agent protocol (a2a),

    Google Developers Blog, “Announcing the agent2agent protocol (a2a),” https : / / developers . googleblog . com / en / a2a - a - new - era - of - agent - interoperability/, Apr. 2025, accessed: 2025-08-24

    2025

  32. [41]

    (2024) Agent communication protocol (acp)

    IBM Research. (2024) Agent communication protocol (acp). Accessed: 2025-08-24. [Online]. Available: https://research.ibm.com/projects/ agent-communication-protocol

    2024

  33. [42]

    (2024, Dec.) Model context protocol (mcp)

    Anthropic. (2024, Dec.) Model context protocol (mcp). Accessed: 2025-08-24. [Online]. Available: https://www.anthropic.com/news/ model-context-protocol

    2024

  34. [43]

    UDP Magic Numbers,

    T. Herbert and L. Yong, “UDP Magic Numbers,” Internet Engineering Task Force (IETF), Internet-Draft draft-herbert-udp-magic-numbers-00,

  35. [44]

    Introducing GPT-5,

    OpenAI, “Introducing GPT-5,” 2025, accessed: 2025-08-18. [Online]. Available: https://academy.openai.com/public/resources/intro-gpt-5

    2025

  36. [45]

    Mininet-WiFi: A Platform for Hybrid Physical-Virtual Software-Defined Wireless Networking Research,

    R. Fontes and C. E. Rothenberg, “Mininet-WiFi: A Platform for Hybrid Physical-Virtual Software-Defined Wireless Networking Research,” in ACM SIGCOMM Conference , 2016

    2016

  37. [46]

    Linux Kernel Project,

    “Linux Kernel Project,” accessed: 2025-08-24. [Online]. Available: https://elixir.bootlin.com/linux/v6.16.3/source/include/net/tcp.h#L1221

    2025

  38. [47]

    Next-Gen Service Function Chain Deployment: Combining Multi-Objective Optimization With AI Large Language Models,

    Y . Li, Q. Zhang, H. Yao, R. Gao, X. Xin, and M. Guizani, “Next-Gen Service Function Chain Deployment: Combining Multi-Objective Optimization With AI Large Language Models,” IEEE Network, vol. 39, no. 3, 2025

    2025

  39. [48]

    A quantitative measure of fairness and discrimination for resource allocation in shared computer systems,

    R. Jain, D.-M. Chiu, and W. Hawe, “A quantitative measure of fairness and discrimination for resource allocation in shared computer systems,” DEC Research Report TR-301 , 1984

    1984

  40. [49]

    TelecomGPT: A Framework to Build Telecom-Specific Large Language Models,

    H. Zou, Q. Zhao, Y . Tian, L. Bariah, F. Bader, T. Lestable, and M. Debbah, “TelecomGPT: A Framework to Build Telecom-Specific Large Language Models,” arXiv preprint arXiv:2407.09424 , Jul 2024. [Online]. Available: https://arxiv.org/abs/2407.09424

    2024 arXiv

  41. [1988]

    Available: https://doi.org/10.1145/52324.52356

    [Online]. Available: https://doi.org/10.1145/52324.52356

  42. [2008]

    Available: https://doi.org/10.1145/1400097.1400105

    [Online]. Available: https://doi.org/10.1145/1400097.1400105

  43. [2015]

    Available: https://datatracker.ietf.org/doc/html/draft- herbert-udp-magic-numbers-00

    [Online]. Available: https://datatracker.ietf.org/doc/html/draft- herbert-udp-magic-numbers-00

  44. [2023]

    Available: https://arxiv.org/abs/2302.04761

    [Online]. Available: https://arxiv.org/abs/2302.04761

    arXiv

  45. [2025]

    Available: https://doi.org/10.48550/arXiv.2501.12948

    [Online]. Available: https://doi.org/10.48550/arXiv.2501.12948

    doi arXiv

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.