{"draft":"draft-ietf-tsvwg-l4s-arch-20","doc_id":"RFC9330","title":"Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture","authors":["B. Briscoe, Ed.","K. De Schepper","M. Bagnulo","G. White"],"format":["HTML","TEXT","PDF","XML"],"page_count":"36","pub_status":"INFORMATIONAL","status":"INFORMATIONAL","source":"Transport and Services Working Group","abstract":"This document describes the L4S architecture, which enables Internet\r\napplications to achieve low queuing latency, low congestion loss, and\r\nscalable throughput control. L4S is based on the insight that the\r\nroot cause of queuing delay is in the capacity-seeking congestion\r\ncontrollers of senders, not in the queue itself. With the L4S\r\narchitecture, all Internet applications could (but do not have to)\r\ntransition away from congestion control algorithms that cause\r\nsubstantial queuing delay and instead adopt a new class of congestion\r\ncontrols that can seek capacity with very little queuing. These are\r\naided by a modified form of Explicit Congestion Notification (ECN)\r\nfrom the network. With this new architecture, applications can have\r\nboth low latency and high throughput.\r\n\r\nThe architecture primarily concerns incremental deployment. It\r\ndefines mechanisms that allow the new class of L4S congestion\r\ncontrols to coexist with 'Classic' congestion controls in a shared\r\nnetwork. The aim is for L4S latency and throughput to be usually much\r\nbetter (and rarely worse) while typically not impacting Classic\r\nperformance.","pub_date":"January 2023","keywords":["Performance","Queuing Delay","One Way Delay","Round-Trip Time","RTT","Jitter","Congestion Control","Congestion Avoidance","Quality of Service","QoS","Quality of Experience","QoE","Active Queue Management","AQM","Explicit Congestion Notification","ECN","Pacing","Burstiness"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC9330","errata_url":null}