%% You should probably cite rfc9332 instead of this I-D.
@techreport{ietf-tsvwg-aqm-dualq-coupled-12,
    number =    {draft-ietf-tsvwg-aqm-dualq-coupled-12},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/12/},
    author =    {Koen De Schepper and Bob Briscoe and Greg White},
    title =     {{DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S)}},
    pagetotal = 53,
    year =      2020,
    month =     jul,
    day =       27,
    abstract =  {The Low Latency Low Loss Scalable Throughput (L4S) architecture allows data flows over the public Internet to achieve consistent low queuing latency, generally zero congestion loss and scaling of per- flow throughput without the scaling problems of standard TCP Reno- friendly congestion controls. To achieve this, L4S data flows have to use one of the family of 'Scalable' congestion controls (TCP Prague and Data Center TCP are examples) and a form of Explicit Congestion Notification (ECN) with modified behaviour. However, until now, Scalable congestion controls did not co-exist with existing Reno/Cubic traffic --- Scalable controls are so aggressive that 'Classic' (e.g. Reno-friendly) algorithms sharing an ECN- capable queue would drive themselves to a small capacity share. Therefore, until now, L4S controls could only be deployed where a clean-slate environment could be arranged, such as in private data centres (hence the name DCTCP). This specification defines {}`DualQ Coupled Active Queue Management (AQM)', which enables Scalable congestion controls that comply with the Prague L4S requirements to co-exist safely with Classic Internet traffic. Analytical study and implementation testing of the Coupled AQM have shown that Scalable and Classic flows competing under similar conditions run at roughly the same rate. It achieves this indirectly, without having to inspect transport layer flow identifiers. When tested in a residential broadband setting, DCTCP also achieves sub-millisecond average queuing delay and zero congestion loss under a wide range of mixes of DCTCP and {}`Classic' broadband Internet traffic, without compromising the performance of the Classic traffic. The solution has low complexity and requires no configuration for the public Internet.},
}