कम लेटेंसी, कम लॉस और स्केलेबल थ्रूपुट के लिए L4S इंटरनेट सेवा: RFC 9330

 (datatracker.ietf.org)
1 पॉइंट द्वारा GN⁺ 2023-12-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • RFC 9330 इंटरनेट एप्लिकेशन में queuing delay और congestion loss घटाने के लिए L4S architecture को परिभाषित करता है, और delay की मूल वजह queue से ज़्यादा sender के capacity-seeking congestion control में देखता है
  • L4S sender host के Scalable congestion control, bottleneck पर AQM, और ECN-आधारित protocol को जोड़ता है, और L4S packets की पहचान के लिए IP-ECN field के ECT(1) codepoint का उपयोग करता है
  • target queuing delay औसतन 1ms से कम और 99th percentile में लगभग 2ms से कम है; DCTCP और Dual-Queue Coupled AQM के उदाहरण में overload के दौरान भी 99th percentile queuing delay लगभग 1~2ms के स्तर पर है
  • मौजूदा Reno/CUBIC family के Classic congestion control के साथ coexist करने के लिए L4S को इस तरह design किया गया है कि Classic traffic और L4S traffic की delay अलग रहे, लेकिन bandwidth को fixed partition में न बाँटा जाए और long term में share किया जाए
  • L4S Diffserv, FQ-CoDel, PIE, BBR को replace करने के बजाय complement करता है; TCP को AccECN जैसे precise feedback की ज़रूरत होती है, और QUIC·DCCP पहले से ही L4S के लिए आवश्यक ECN feedback देते हैं

L4S जिस delay problem को हल करना चाहता है

  • web, voice, video conferencing, gaming, remote desktop, cloud applications, AR/VR, remote control जैसे low delay पसंद करने वाले traffic के bottleneck link भर देने की स्थितियाँ बढ़ रही हैं
  • caches और servers को users के करीब रखने से propagation delay कम हुआ है, लेकिन queuing अब भी delay का एक प्रमुख और intermittent component बना हुआ है
    • latest AQM होने पर भी सैकड़ों ms के delay spikes uncommon नहीं हैं
    • Classic AQM को अक्सर single long-running flow के sawtooth-shaped queue variation को buffer करने के लिए set किया जाता है, जिससे long-running flows के दौरान पूरे network का delay peak basic path delay की तुलना में लगभग दोगुना हो सकता है
  • L4S का लक्ष्य बहुत कम queuing delay, बहुत कम loss, और scalable throughput है
    • बहुत कम queuing delay का अर्थ है औसतन 1ms से कम, 99th percentile में लगभग 2ms से कम
    • अधिक demanding interactive applications में end-to-end delay 50ms या 20ms से ऊपर जाते ही experience unnatural लगने लगता है
  • loss interactive applications में retransmission delay की ओर ले जाता है, इसलिए low loss भी core goal है

delay की वजह: queue से ज़्यादा Classic congestion control

  • L4S queuing delay की मूल वजह queue itself से ज़्यादा sender के capacity-seeking congestion control में देखता है
  • Reno, CUBIC जैसे Classic congestion control queue occupancy को बड़े sawtooth pattern में बदलते हैं
    • अगर AQM queue को बहुत shallow रखता है, तो Classic congestion control sawtooth के हर low point पर link का सही उपयोग नहीं कर पाता
    • flow rate बढ़ने पर Classic congestion control का recovery time लंबा हो जाता है, जिससे queue और utilization control loose हो जाते हैं
  • Scalable congestion control में flow rate बढ़ने पर भी congestion signals के बीच average time, यानी recovery time, constant रहता है
    • DCTCP controlled environments में व्यापक रूप से उपयोग किया जाने वाला example है
    • यह Windows Server Editions, Linux, FreeBSD में implemented और deployed है
    • Prague over TCP/QUIC, L4S के लिए SCReAM, और BBRv2 के L4S ECN parts भी Scalable congestion control के examples में शामिल हैं

L4S architecture के तीन components

  • L4S तीन components से बना है
    • sender host का Scalable congestion control
    • network bottleneck का AQM
    • इनके बीच packet identification और congestion signaling संभालने वाला ECN-based protocol
  • low delay network द्वारा directly provided नहीं होता, बल्कि L4S sender के careful Scalable congestion control behavior से आता है
  • network की मुख्य भूमिका L4S traffic की low delay को Classic traffic के लिए required बड़े queuing delay से isolate करना है
  • network ECN का उपयोग करके queue growth के बहुत शुरुआती संकेतों को तुरंत transport layer तक बताता है
    • Classic AQM की तरह queue variation को बहुत smooth करने के बाद signal नहीं करता
    • ECN support L4S के लिए essential है
  • sender ECN field का उपयोग करके network को L4S packets और Classic packets में फर्क करने देता है

ECN और ECT(1) codepoint

  • L4S को Classic ECN की “ECN signal को drop के बराबर treat करना चाहिए” वाली constraint से आगे बढ़कर more fine-grained congestion signal की ज़रूरत होती है
    • signals अधिक बार हो सकने चाहिए
    • queue variation को smooth करने के लिए बड़े delay के बिना तुरंत signal कर सकना चाहिए
  • RFC8311 RFC3168 की कुछ requirements को relax करके L4S experiments को possible बनाता है
  • RFC9331 ECT(1) को L4S packet identifier के रूप में use करने के लिए specify करता है
  • CE codepoint L4S और Classic processing दोनों में Congestion Experienced दिखाने के लिए use होता है
    • अगर path के आगे के हिस्से में Classic AQM ने ECT(0) packet को CE के रूप में mark किया हो, तो उसे L4S queue में गलत classify किए जाने की आशंका होती है
    • RFC9331 Appendix B के अनुसार harmful impact के लिए पाँच rare conditions का एक साथ होना ज़रूरी है, और उस स्थिति में भी incorrect retransmission की संभावना बेहद कम है
  • operators ऐसा low और smooth non-L4S traffic L4S queue में डालना चाह सकते हैं जो queue न बनाए
    • examples हैं VoIP, online game synchronization के लिए low-rate datagrams, DNS, LDAP आदि
    • इस स्थिति में EF, NQB, operator-specific identifiers जैसे अलग marks चाहिए

Dual-Queue Coupled AQM

  • L4S का लक्ष्य है कि network component को ज़रूरी तौर पर per-flow processing किए बिना low delay मिल सके
  • representative design Dual-Queue Coupled AQM दो queues का उपयोग करता है
    • L4S queue low delay बनाए रखती है
    • Classic queue में Classic traffic के link utilization बनाए रखने के लिए required larger queue हो सकती है
  • DualQ को ऐसा design किया गया है कि यह delay को अलग करे लेकिन bandwidth को fixed partition में न बाँटे, यानी semi-permeable membrane की तरह काम करे
    • Classic AQM अपनी queue congestion-based drop/marking probability बनाता है और इसे Classic queue और L4S queue के signals से couple करता है
    • coupled congestion signal L4S flows की speed कम करवाता है ताकि Classic flows के लिए required capacity बची रहे
  • scheduler L4S queue को priority दे सकता है
    • short time scale पर L4S bursts को जल्दी clear करके low delay को protect करता है
    • round-trip time से अधिक long-term time scale पर Classic queue के congestion signal coupling से bandwidth priority offset हो जाती है और approximate per-flow fairness बनती है
  • जब केवल L4S traffic हो, तो L4S queue का AQM बहुत shallow queue पर congestion marking शुरू करके low queuing delay बनाए रखता है

per-flow queue methods और DualQ का अंतर

  • FQ-CoDel, FQ-PIE जैसी per-flow queues भी L4S के लिए use हो सकती हैं
    • Linux में shallow ECN marking threshold को सिर्फ ECT(1) packets पर apply करने के लिए modify किया गया है
    • Not-ECT या ECT(0) flows पर Classic AQM apply होता है, और ECT(1) flows पर आम तौर पर sub-ms shallow threshold apply होता है
  • per-flow approach हर flow की queue अलग करता है, लेकिन flow itself द्वारा बनाई queuing को खत्म नहीं कर पाता
  • DualQ approach में L4S identifier IP-ECN field में होने के कारण IP layer से गहरी inspection की ज़रूरत नहीं होती
    • इसे IPsec या encrypted VPN tunnel जैसे environments में भी use किया जा सकता है जहाँ transport layer identifiers encrypted होते हैं
  • per-flow approach में network applications flows के बीच relative rate control की जिम्मेदारी लेता है
  • DualQ low delay provide करने और flow rate control problems को अलग करता है, और ज़रूरत पड़ने पर अलग flow rate policing जोड़ी जा सकती है

host-side requirements

  • sender को Scalable congestion control implement करना होगा
    • DCTCP सबसे व्यापक रूप से used example है, लेकिन public Internet पर use के लिए safety और performance improvements चाहिए
    • Prague L4S requirements के वे parts जो दूसरों को नुकसान पहुँचाने के risk से जुड़े हैं, RFC9331 की normative requirements में शामिल हैं
    • TCP Prague Linux में reference implementation के रूप में implemented है
  • TCP के अलावा transport protocols को भी L4S service use करने के लिए Scalable congestion response implement करना और ECT(1) codepoint से उसे mark करना होगा
    • QUIC के लिए Scalable variant review में है
    • BBRv2 का L4S ECN part TCP और QUIC आदि के लिए Scalable congestion control के रूप में presented है
    • RTP media के लिए SCReAM का L4S variant भी implemented है
  • ECN feedback की स्थिति protocol के अनुसार अलग है
    • DCCP और QUIC L4S के लिए पर्याप्त fine-grained ECN feedback provide करते हैं
    • TCP का existing ECN feedback इस assumption पर आधारित है कि ECN mark को drop के बराबर माना जाता है, इसलिए Scalable TCP के लिए use नहीं किया जा सकता
    • TCP receiver को अधिक accurate ECN feedback यानी AccECN support चाहिए
    • SCTP को L4S support करने के लिए नए ECN design की implementation और deployment चाहिए
    • RTP के लिए RFC6679 और RFC8888 में sufficient ECN feedback defined है

explicit congestion signal क्यों चाहिए

  • L4S loss के बजाय explicit congestion signal को core mechanism के रूप में use करता है
  • drop performance degradation भी है और signal भी, इसलिए “कम हो तो बेहतर damage” और “ज़्यादा हो तो बेहतर signal” के बीच tension बनता है
  • ECN-based explicit signal बिना damage के प्रति round-trip time कई बार use हो सकता है, इसलिए queue को छोटा रखने में फायदेमंद है
  • L4S smoothing को network से host में shift करता है
    • network हर flow का RTT नहीं जानता, इसलिए Classic method में worst-case RTT assume करना पड़ता है
    • इस वजह से Classic congestion signal 100~200ms delay हो सकता है
    • हर host अपना RTT जानता है, इसलिए जितनी जरूरत हो उतनी ही smoothing कर सकता है, आम तौर पर कुछ ms के स्तर पर
  • L4S queue drop के बराबर न होने वाले नए L4S ECN variant का उपयोग करती है, और Classic queue Classic ECN या drop का उपयोग करती है

throughput scalability का आधार

  • Classic Reno congestion control में high bandwidth-delay product environment की ओर जाने पर recovery time लंबा हो जाता है
  • example condition sawtooth peak पर maximum RTT 30ms है
    • Reno packet rate 1,250packet/s से 10,000packet/s तक 8x बढ़ने पर, 1500B packet के आधार पर लगभग 15Mb/s से 120Mb/s तक बढ़ता है और recovery time 422ms से 3.38s तक बढ़ जाता है
    • CUBIC 120Mb/s पर Reno-friendly mode में काम करता है और recovery में लगभग 4.3s लगते हैं
    • 960Mb/s पर true CUBIC mode में चला जाता है और recovery time 12.2s हो जाता है
    • 7.68Gb/s पर recovery time 24.3s तक बढ़ जाता है
  • DCTCP या Prague जैसे Scalable congestion control औसतन प्रति RTT 2 congestion signals induce करते हैं, और यह property flow rate से independent रहती है
  • 2020 में global average fixed access capacity 103Mb/s थी, और 2019 में CDN तक average base RTT 25~34ms था
  • single CUBIC download flow को congestion window reduction के बाद recover करने में best case में भी लगभग 200 RTT, यानी 5 seconds लग सकते हैं

existing technologies से संबंध

  • Diffserv important traffic की bandwidth allocation और delay-sensitive traffic की queuing delay को handle करता है, लेकिन L4S केवल queuing delay problem को handle करता है
    • Diffserv तब effective होता है जब bottleneck पर केवल कुछ traffic low delay माँगता है
    • अगर bottleneck का सारा traffic low delay चाहता है, तो Diffserv का differentiation benefit गायब हो जाता है
    • L4S identifier quality requirement नहीं, बल्कि Scalable congestion response का behavioral promise दिखाता है
  • PIE, FQ-CoDel जैसे Classic AQM AQM न होने की स्थिति की तुलना में queuing delay को काफी घटाते हैं
    • L4S इन्हें complement करता है और इनके broad deployment की आवश्यकता को replace नहीं करता
    • सिर्फ AQM से Classic congestion control के बड़े sawtooth के कारण delay और link utilization के बीच tension खत्म करना मुश्किल है
  • ABE ECN marking पर host reaction बदलकर link utilization और ECN flow throughput बढ़ाता है, लेकिन यह assume करता है कि network ECN और drop को अब भी same treat करता है
  • BBR बिना special network logic के end-to-end तरीके से queuing delay control करता है
    • BBR queuing delay को reasonably low रखता है, लेकिन L4S जितना low नहीं
    • BBRv2 संभव हो तो L4S ECN और Scalable L4S congestion control behavior use कर सकता है

applicable applications

  • L4S load की स्थिति में existing applications की quality को significantly improve कर सकता है
    • gaming और cloud gaming
    • VoIP
    • video conferencing
    • web browsing
    • adaptive video streaming
    • instant messaging
  • lower queuing delay cloud-based interactive video और cloud-based VR/AR जैसी capabilities को possible बनाता है
  • L4S demo में 40Mb/s broadband access link पर, जहाँ कई delay-sensitive applications और downloads एक ही bottleneck queue share करते हैं, cloud-based interactive video और VR साथ में काम करते हैं
    • end-to-end base delay 7ms पर additional queuing delay लगभग 1ms level था
    • alternative AQM में video finger gestures और head movement के बाद visibly lag कर रहा था
  • finger swipe या head movement से video pan करने का काम VoIP की तुलना में बहुत stricter delay requirement रखता है
  • interactive remote presence, मशीनों और industrial processes का video-assisted remote control बहुत कम queuing delay के बिना भरोसेमंद बनाना मुश्किल है

deployment model और incremental adoption

  • L4S AQM का structure ऐसा नहीं है कि effective होने के लिए इसे पूरे Internet में deploy करना ही पड़े
  • public Internet access networks आम तौर पर इस तरह design होते हैं कि bottleneck site-wise known एक logical link पर हो
    • sites में homes, mobile devices, small and medium campuses और enterprise networks आदि शामिल हैं
    • यह xDSL, cable, PON, cellular, wireless, satellite जैसी विभिन्न access technologies पर लागू generalization है
  • downstream में bottleneck link entry point पर L4S AQM deploy करने से most benefits मिल सकते हैं, और upstream में भी upstream link entry point पर deploy करने से यही लागू होता है
  • एक L4S flow को benefit पाने के लिए आम तौर पर तीन elements चाहिए
    • sender का congestion control
    • bottleneck का AQM
    • TCP जैसे पुराने transport में upgraded receiver feedback
  • deployment order अलग-अलग हो सकता है
    • existing DCTCP को controlled test environment में use किया जा सकता है
    • TCP Prague और AccECN deploy करने पर public Internet environment में L4S use किया जा सकता है
    • QUIC शुरुआत से ही L4S के लिए आवश्यक ECN feedback support करता है, इसलिए sender-side Prague congestion control deployment सरल है

link technologies के हिसाब से constraints

  • Wi-Fi, PON, cable कई packets data को bursts में aggregate करते हैं, और burst बनाने के दौरान आने वाले packets को buffer करते हैं
    • Ethernet और DSL ऐसी packet aggregation नहीं करते
    • इस aggregation buffering को sender reduce नहीं कर सकता, इसलिए इसे AQM-controlled queue में नहीं गिनना चाहिए
  • cellular, Wi-Fi, satellite जैसे wireless links में capacity तेजी से काफी बदल सकती है, इसलिए अचानक capacity increase का लाभ लेने के लिए standing queue desirable मानी जाती है
  • cellular networks handover को seamless बनाने के लिए buffering requirements के कारण और जटिल हैं
  • L4S ऐसी सभी buffering needs को खत्म नहीं कर सकता
  • Classic congestion control के बड़े sawtooth के लिए buffering नाम की “सबसे लंबी pole” हटाने से packet aggregation burst size या MAC scheduling interval जैसे दूसरे buffering elements को और reduce करने की motivation मिलती है

non-L4S bottlenecks और loss handling

  • भले ही दो hosts के बीच L4S active हो, अगर bottleneck ECN support नहीं करता, तो L4S sender को drops के लिए Reno के साथ safely coexist करना होगा
  • यह rule Classic traffic को protect करता है, लेकिन loss होने पर L4S service को degrade करता है
    • shallow queue के bursts से temporary bottleneck loss
    • electrical interference जैसे transmission errors
    • rate policing
  • इसे handle करने के तीन approaches अभी research area हैं
    • Prague congestion control में congestion के कारण होने की संभावना कम वाले कुछ losses ignore करना
    • RACK, L4S, और बिना reordering वाली link retransmission के combination से transmission errors recover करना
    • hybrid ECN/drop rate policer
  • wired networks जैसे deployment scenarios जहाँ ये issues कम हैं, इस research के साथ parallel में आगे बढ़ सकते हैं

security और traffic policing

  • current Internet में आम तौर पर sites के बीच shared link capacity separation scheduler से handle होता है, और individual application flows की speed universally police नहीं की जाती
  • L4S को इस state को न तोड़ने के लिए design किया गया है
    • DualQ को single-queue AQM की तुलना में non-responsive flows को अधिक rate advantage न देने के लिए design किया गया है
    • अगर per-flow rate policing चाहिए, तो L4S/Classic distinction से independent रूप से add की जा सकती है
  • L4S को Classic traffic की delay या rate को नुकसान पहुँचाए बिना delay reduce करने के लिए design किया गया है, इसलिए सिर्फ Classic protection के लिए L4S service access पर rate policing की जरूरत नहीं है
  • कुछ operators premium customers जैसे limited group को ही L4S service provide कर सकते हैं
    • ऐसी स्थिति में ECN field के साथ source address range जैसे local identifiers भी use किए जा सकते हैं
    • अगर local identifier match नहीं करता, तो ECT(1) होने पर भी packet को Classic queue में भेजा जा सकता है
  • L4S service को rate के साथ-साथ burstiness पर भी restraint चाहिए
    • DOCSIS के लिए low-latency queue protection function queue बनाने वाले flows को partially Classic queue में redirect करके low delay preserve करता है
    • single-queue protection feature L4S architecture का essential element नहीं है, और L4S experiments का एक हिस्सा यह देखना है कि ऐसी feature जरूरी है या नहीं

tunnels और privacy

  • L4S AQM ECN field से congestion signal करता है, इसलिए tunnel के अंदर या lower layer में operate करते समय ECN field को layers के बीच standards के अनुसार propagate होना चाहिए
  • L4S architecture transport layer identifiers inspect करने वाले methods को exclude नहीं करता
    • example है L4S support added FQ-CoDel
  • core innovation DualQ AQM को सबसे बाहरी IP header से गहरी inspection की जरूरत नहीं होती
  • अगर user IPsec या encrypted VPN tunnel से application flow identifiers encrypt करता है, तब भी low delay छोड़ने की जरूरत नहीं है
  • L4S applications के broad set को low delay दे सकता है, इसलिए network से गुजरते समय individual applications या detailed classes को distinguish करने की जरूरत कम हो जाती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-12-12
Hacker News टिप्पणियाँ

  • यह वाकई शानदार है। पिछले महीने Prague में IETF 118 में इसका लाइव डेमो देखा था; bufferbloat को पूरी तरह खत्म कर देने की वजह से यह वीडियो चैट के लिए बहुत अच्छा लगा
    लगता है IP packets में यह बताने के लिए अतिरिक्त bits डालनी पड़ती हैं कि buffer भर गया है या नहीं, लेकिन यह सच में काम कर रहा था, और महसूस हुआ कि “मुझे नहीं लगा था कि यह संभव है”

    • असल में इससे भी आगे जाकर, वीडियो encoder के rate control को सीधे adjust कराया जा सकता है। यानी सिर्फ bandwidth fairness नहीं, बल्कि perceived quality के आधार पर fairness मिलती है
    • वह bit पहले से मौजूद है। L4S उस bit का अर्थ बदलता है ताकि ज्यादा सटीक signal भेजा जा सके
    • थोड़ा खोजा तो लगता है यही सही है? https://youtube.com/watch?t=4900&v=RWjbrXxpzVU
      जिन्हें time link काम नहीं कर रहा, उनके लिए यह 1 घंटा 21 मिनट के आसपास है। सुधार: नहीं था, यह hackathon summary थी और presentation ढूंढना आसान नहीं है

  • मैं जानना चाहता था कि receiver sender को congestion कैसे बताता है, इसलिए खोजा, लेकिन यह उम्मीद से ज्यादा मुश्किल निकला। मुख्य बात https://www.rfc-editor.org/info/rfc3168 में documented है
    सरल शब्दों में, flag एक नहीं बल्कि करीब तीन हैं। एक flag sender द्वारा router को यह बताने के लिए कि ECN support संभव है, एक router द्वारा receiver को congestion बताने के लिए, और एक receiver द्वारा ACK packet भेजते समय set करने के लिए होता है
    sender ECT codepoint से ECN support दिखाता है, और ECN-supporting router packet drop करने के बजाय IP header में CE codepoint set करके आगे भेजता है। receiver अगले TCP ACK में ECN-Echo set करता है, और sender packet loss की तरह congestion पर react करने के बाद अगले packet के TCP header में CWR flag set करता है

  • Bob Briscoe इस दिशा में काफी समय से सोचते रहे हैं। संबंधित classics के तौर पर ये लेख सुझाऊंगा
    http://www.sigcomm.org/sites/default/files/ccr/papers/2007/A...
    https://dl.acm.org/doi/pdf/10.1145/1080091.1080124

  • Comcast के cable network पर कुछ tests हुए थे, और नीचे की slides इसे समझाती हैं
    https://datatracker.ietf.org/meeting/118/materials/slides-11...
    पता नहीं यह आगे कहां जाएगा, लेकिन लगता है ISP high-speed lane के लिए toll लेना शुरू कर सकते हैं

    • L4S असल में high-speed lane नहीं है। यह applications को बताता है कि उनका traffic congested है या नहीं, और उसी के हिसाब से traffic घटाकर congestion कम करने देता है। congestion घटता है तो latency भी घटती है
    • मुझे नहीं पता था कि dslreports में देखे गए low-latency test के पीछे यही था
    • मुझे संदेह है कि ISP high-speed lane toll वसूलने लगेंगे। लगता है latency आज throughput या speed की तरह एक और competitive differentiator बन जाएगी
      निजी राय है, लेकिन मैं Comcast में काम करता हूं

  • L4S के बारे में और जानना चाहते हैं तो understandinglatency.com पर आज से webinar series शुरू हो रही है। L4S के कुछ authors, Comcast के L4S field trial lead, और आलोचनात्मक आवाजें भी present करेंगी

  • RC car video feed में असल उपयोग का एक छोटा demo मिला: https://www.youtube.com/watch?v=RZmS10djDEg

  • यह सही दिशा में प्रगति जरूर है, लेकिन अगर कोई एक भी malicious participant congestion feedback को ignore करके बस bandwidth का बड़ा हिस्सा चाहता है, तो समस्या पैदा होती है। तब बाकी participants पीछे हटते हैं और unfair side जो चाहती है वह ले लेती है
    अच्छे participants के लिए यह जानना मुश्किल है कि बाकी लोग rules मान रहे हैं या नहीं, और उन्हें यह पता होना चाहिए कि fair queuing मौजूद है, तभी वे भरोसा कर सकते हैं कि L4S fair तरीके से handle करेगा
    इस समस्या को L4S को fq_codel जैसी fair queuing से complement करके, और congestion control को fair queuing की मौजूदगी detect करने लायक बनाकर हल किया जा सकता है: https://github.com/muxamilian/fair-queuing-aware-congestion-...

    • ज्यादातर ISP per-customer bandwidth allocation लागू करते हैं, इसलिए malicious participant के लिए दूसरे customer का हिस्सा लेना मुश्किल है
      fair queuing debate एक बड़ी debate का हिस्सा है। fair queuing न हो तो L4S से अलग भी fairness पहले से ही end hosts implement करते हैं, और server जैसे end hosts congestion response को ignore करके fair share से ज्यादा ले सकते हैं। यह L4S द्वारा बनाई गई नई समस्या नहीं है, हालांकि कुछ लोग मानते हैं कि L4S बड़ा हिस्सा लेना आसान बना देता है
      fair queuing समर्थक मानते हैं कि network को fair sharing guarantee करनी चाहिए, लेकिन हर कोई उनके चुने हुए fairness metric से सहमत नहीं है। खास तौर पर L4S के प्रमुख समर्थकों में से एक सहमत नहीं हैं, जैसा कि यहां linked paper में देखा जा सकता है: https://news.ycombinator.com/item?id=38598023

  • user के नजरिए से वास्तव में क्या बदलेगा, यह जानना चाहता हूं। उदाहरण के लिए, क्या video calls real-time के ज्यादा करीब हो जाएंगी? आम तौर पर 0.5~1 second की delay होती है, जिससे बातचीत में रुकावट और बीच में बोलना बहुत होता है। और कौन-सी applications में बड़ा सुधार होगा?

    • यह एक ISP network के अंदर latency के सिर्फ एक कारण को हल करता है। internet video chat जटिल है क्योंकि सभी layers best-effort approach पर हैं
      3Mbps से कम bitrate में फिट होने के लिए quality, bitrate, CPU time और latency के बीच कठिन trade-off चाहिए। आम laptops में CPU धीमा होता है, या 6-core CPU होने पर भी battery पर चलते समय clock कम रखते हैं। hardware-accelerated video encoding भी universal नहीं है, इसलिए quality और latency की बलि चढ़ती है
      Wi-Fi भी latency जोड़ता है, खासकर जब laptop battery पर चल रहा हो। NAT handling के लिए कई video chat services cloud servers को relay के रूप में इस्तेमाल करती हैं, जिससे latency बढ़ती है
      https://hpbn.co/wifi/#measuring-and-optimizing-wifi-performa...
    • यह नई cloud-based applications को व्यावहारिक और भरोसेमंद तरीके से काम करने लायक बनाता है। cloud gaming या cloud AR जैसी चीजों के बारे में सोचें
      gaming और video conferencing जैसी high-interactivity सुविधाएं भी बिना delay के काफी बेहतर हो जाती हैं। web pages render करने, video stream करने, या Alexa जैसे AI assistant interactions handle करने में अभी बहुत से round trips लगते हैं, इसलिए user और device के बीच होने वाली लगभग हर interaction बेहतर हो सकती है

  • मूल रूप से L4S latency feedback loop को घटाने की तकनीक है। इस video का दूसरा हिस्सा इसे काफी अच्छी तरह समझाता है: https://youtu.be/tAVwmUG21OY?si=lydbqfNL80Y8Uxvp