## 3 Research Design and Methodology
### Using DualPi2 as an AQM in FreeBSD-L4S  
The coupled dual-queue AQM (or DualPi2) [18; 19] operates like a semi-permeable membrane, effectively maintaining the sub-millisecond average queuing delay characteristics of L4S while isolating it from classic traffic latency by maintaining separate queues for each type. This configuration ensures that capacity-seeking algorithms achieve approximately equivalent throughput per flow, regardless of the queue they utilize. However, unlike single-queue frameworks, DualQ does not require examination of the transport-layer flow iD nor compromise classic traffic performance, and it requires no new configuration for public internet deployment [18; 19]. Latency is not L4S's sole focus. The \"Low Loss and Scalable\" aspect of its name indicates its other functions. Traditional scalable congestion control algorithms like DCTCP and Prague encounter compatibility issues with classic congestion controls. Even if they are sharing an ECN-capable queue, the classic algorithms limit their capacity due to the aggressive nature of scalable congestion controls. Unlike Diffserv EF, which limits high-priority traffic to a small percentage of bandwidth capacity to maintain low delay, L4S leverages ECN and DualQ's isolating and coupling effect to achieve very low latency while also achieving zero % loss and retain its ability to scale rapidly without majorly affecting its throughput. Rigorous testing has been conducted in residential network setups, varying the base RTT up to 100 ms and link rates up to 200 Mb/s between the data center and home network to evaluate the effectiveness of L4S AQMs. The experiments discovered that L4S AQMs maintained an average queuing delay below 1 ms for each of their packets, with the 99 th percentile delay not exceeding 2 ms. The L4S AQM introduced no packet loss to the network. The extensive tests are detailed in [18; 28]. The comprehensive L4S framework [29] offers more insights on advanced deployment features like ensuring backward compatibility with scalable congestion controls in network bottlenecks lacking DualQ coupled AQM implementation. Additional publications [18; 28; 30; 31] provide more detailed justification through discourse and precise mathematical formulas, accompanied by empirical performance evaluations. **Modified DualQ Coupled L4S AQM:** The coupled AQM mechanism ensures harmonious coexistence by setting the classic drop probability \(p_{c}\) proportional to the square of the coupled L4S probability \(p_{cl}\). Here, \(p_{cl}\) influences the immediate L4S drop probability \(p_{l}\), changing at a similar pace to \(p_{c}\). The square of \(p_{cl}\) offsets the square root of \(p_{c}\) in the TCP formula used by classic Reno congestion management. As a consequence of this, the flow rate of Reno now approximates that of DCTCP. The correlation between the L4S probability, \(p_{-}cl\), and the classic drop probability, \(p_{c}\), needs to be expressed as the following formula:  
\[p_{c}=(p_{cl}/k)^{2} \tag{1}\]  
where k is referred to as the proportionality constant, known as the 'coupling factor'. Any DualQ Coupled AQM likely has a general structure similar to Figure 1. The classifier at the ingress segregates the incoming traffic into two distinct queues: the L4S and classic queues. Each queue is governed by the probability of marking (or dropping) packets denoted by \(p_{l}\) and \(p_{c}l\), respectively. In managing Reno traffic, which varies the traffic load relative to the square root of observed drops, research such as [PI2][30] has shown that employing a linear controller to regulate load, squaring the resultant output, and using it as the classic drop probability in traffic compatible with Reno yields favorable results.