%% You should probably cite rfc9330 instead of this I-D.
@techreport{ietf-tsvwg-l4s-arch-20,
    number =    {draft-ietf-tsvwg-l4s-arch-20},
    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-l4s-arch/20/},
    author =    {Bob Briscoe and Koen De Schepper and Marcelo Bagnulo and Greg White},
    title =     {{Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture}},
    pagetotal = 36,
    year =      2022,
    month =     aug,
    day =       29,
    abstract =  {This document describes the L4S architecture, which enables Internet applications to achieve low queuing latency, low congestion loss, and scalable throughput control. L4S is based on the insight that the root cause of queuing delay is in the capacity-seeking congestion controllers of senders, not in the queue itself. With the L4S architecture, all Internet applications could (but do not have to) transition away from congestion control algorithms that cause substantial queuing delay and instead adopt a new class of congestion controls that can seek capacity with very little queuing. These are aided by a modified form of Explicit Congestion Notification (ECN) from the network. With this new architecture, applications can have both low latency and high throughput. The architecture primarily concerns incremental deployment. It defines mechanisms that allow the new class of L4S congestion controls to coexist with 'Classic' congestion controls in a shared network. The aim is for L4S latency and throughput to be usually much better (and rarely worse) while typically not impacting Classic performance.},
}