## 4 Toward Cognitive Connectivity: The Case of Dynamic Bandwidth Management
### Proof of Concept for Bandwidth Management  
To exemplify the potential of BW management, a proof of concept (PoC) was developed where network (re)configurations were performed manually. Specifically, a cluster consisting of three interconnected VMs (hereafter referred to as _nodes_) was deployed using K3s [64], a lightweight and easy-to-install container orchestration platform based on Kubernetes, and Cilium [65], a network manager tool. In this setup, one node acted as the control plane node, and the other two acted as worker nodes. One worker node (i.e., _worker #1_) simulated an edge node generating both TCP and UDP traffic addressed to another worker node (i.e., _worker #2_) located in the cloud.  
Consider a use case in which all TCP traffic came from high-priority services, while UDP traffic corresponded to low-priority services. The data generation rates of applications over TCP and UDP were \(R_{\text{TCP}}~{}=~{}60\) Mbps and \(R_{\text{UDP}}~{}=~{}100\) Mbps, respectively. Additionally, the link capacity between worker nodes was artificially limited to \(C~{}=~{}100\) Mbps to explicitly simulate a potential situation where the link could not support the data transmission of both TCP and UDP applications simultaneously. TCP and UDP traffic were generated using iPerf3 3.1.3, which is a traffic generator and measurement tool [66]. Moreconcertely, two different iPerf3 client instances (i.e., _pods_) were deployed in worker #1. Similarly, worker #2 contained two different iPerf3 server pods that received the corresponding traffic (see Figure 4).  
The PoC was run over a \(T=6\) min period, divided into three distinct stages of 2 min each, with different network conditions:  
* **Stage 1** (minutes 0 to 2): Only TCP high-priority traffic was present on the link.
* **Stage 2** (minutes 2 to 4): TCP high-priority and UDP low-priority traffic were present on the link simultaneously.
* **Stage 3** (minutes 4 to 6): TCP high-priority and UDP low-priority traffic were present on the link simultaneously. However, the configuration of the iPerf3 pod handling UDP traffic was modified on-the-fly from the control plane node at minute 4 to limit its BW to 20 Mbps (i.e., \(B^{\prime}_{\text{UDP}}~{}=~{}20\) Mbps).  
Figure 5 illustrates the resulting throughput (\(S\)) for each type of traffic on the observed link during the three analyzed stages. As expected, \(S_{\text{TCP}}~{}\approx~{}R_{\text{TCP}}\) during Stage 1, as no other traffic is present on the link. However, when UDP traffic is introduced from minute 2 on, both types of traffic compete for the under-dimensioned capacity of the link, thus resulting in \(S_{\text{TCP}}~{}\approx~{}40\) Mbps (\(S_{\text{TCP}}~{}<~{}R_{\text{TCP}}\)) and \(S_{\text{UDP}}~{}\approx~{}40\) Mbps (\(S_{\text{UDP}}~{}\ll~{}R_{\text{UDP}}\)). Lastly, once the BW limitation of UDP traffic is activated from minute 4 on, high-priority TCP traffic effectively arrives at its destination (i.e., \(S_{\text{TCP}}~{}\approx~{}R_{\text{TCP}}\)) at the cost of degrading low-priority UDP traffic (i.e., \(S_{\text{UDP}}~{}\ll~{}R_{\text{UDP}}\), since \(S_{\text{UDP}}~{}\leq~{}B^{\prime}_{\text{UDP}}\)).