- RFC 9330 mendefinisikan arsitektur L4S untuk mengurangi latensi antrean dan loss akibat kongesti pada aplikasi Internet, dan melihat akar penyebab latensi bukan pada antrean itu sendiri, melainkan pada congestion control pengirim yang bersifat mencari kapasitas
- L4S menggabungkan Scalable congestion control pada host pengirim, AQM di titik bottleneck, dan protokol berbasis ECN; untuk identifikasi paket L4S digunakan codepoint ECT(1) pada field IP-ECN
- Target latensi antrean adalah rata-rata di bawah 1 ms dan persentil ke-99 sekitar di bawah 2 ms; pada contoh DCTCP dan Dual-Queue Coupled AQM, bahkan saat overload, latensi antrean persentil ke-99 berada di kisaran sekitar 1–2 ms
- Agar dapat hidup berdampingan dengan Classic congestion control seperti Reno/CUBIC yang sudah ada, L4S memisahkan latensi trafik Classic dan trafik L4S, tetapi dirancang agar bandwidth tidak dibagi secara tetap dan tetap berbagi dalam jangka panjang
- L4S bukan pengganti Diffserv, FQ-CoDel, PIE, atau BBR, melainkan pelengkap; TCP membutuhkan umpan balik presisi seperti AccECN, sementara QUIC dan DCCP sudah menyediakan umpan balik ECN yang dibutuhkan L4S
Masalah latensi yang ingin diselesaikan L4S
- Semakin banyak trafik yang mengutamakan latensi rendah mengisi link bottleneck, seperti web, suara, konferensi video, game, remote desktop, aplikasi cloud, AR/VR, dan remote control
- Cache dan server telah ditempatkan lebih dekat ke pengguna sehingga latensi propagasi berkurang, tetapi antrean masih menjadi komponen utama dan sporadis dari latensi
- Bahkan dengan AQM modern, lonjakan latensi ratusan ms masih tidak jarang terjadi
- Classic AQM sering dikonfigurasi untuk menyangga variasi antrean berbentuk gigi gergaji dari satu flow jangka panjang, sehingga puncak latensi jaringan keseluruhan selama flow jangka panjang dapat menjadi kira-kira dua kali latensi dasar rute
- Tujuan L4S adalah latensi antrean yang sangat rendah, loss yang sangat rendah, dan throughput yang skalabel
- Latensi antrean yang sangat rendah berarti rata-rata di bawah 1 ms dan persentil ke-99 sekitar di bawah 2 ms
- Aplikasi interaktif yang lebih menuntut mulai terasa tidak natural jika latensi end-to-end melebihi 50 ms atau 20 ms
- Karena loss pada aplikasi interaktif berujung pada latensi retransmisi, loss rendah juga menjadi tujuan utama
Penyebab latensi: Classic congestion control, bukan antrean
- L4S melihat akar penyebab latensi antrean bukan pada antrean itu sendiri, melainkan pada congestion control yang mencari kapasitas di sisi pengirim
- Classic congestion control seperti Reno dan CUBIC mengubah okupansi antrean dalam bentuk gigi gergaji besar
- Jika AQM membuat antrean terlalu dangkal, Classic congestion control tidak dapat memanfaatkan link dengan baik pada setiap titik rendah gigi gergaji
- Semakin tinggi laju flow, semakin lama waktu pemulihan Classic congestion control, sehingga kontrol antrean dan utilisasi menjadi longgar
- Scalable congestion control menjaga waktu rata-rata antar sinyal kongesti, yaitu waktu pemulihan, tetap konstan meskipun laju flow meningkat
- DCTCP adalah contoh yang banyak digunakan di lingkungan terkontrol
- Telah diimplementasikan dan dideploy di Windows Server Editions, Linux, dan FreeBSD
- Prague over TCP/QUIC, SCReAM untuk L4S, serta bagian L4S ECN dari BBRv2 juga termasuk contoh Scalable congestion control
Tiga komponen arsitektur L4S
- L4S terdiri dari tiga komponen
- Scalable congestion control pada host pengirim
- AQM pada bottleneck jaringan
- Protokol berbasis ECN yang menangani identifikasi paket dan sinyal kongesti di antara keduanya
- Latensi rendah tidak diberikan langsung oleh jaringan, melainkan berasal dari perilaku Scalable congestion control yang hati-hati pada pengirim L4S
- Peran utama jaringan adalah mengisolasi latensi rendah trafik L4S dari latensi antrean yang lebih besar yang dibutuhkan trafik Classic
- Jaringan menggunakan ECN untuk segera memberi tahu lapisan transport tentang tanda-tanda paling awal pertumbuhan antrean
- Tidak seperti Classic AQM, sinyal tidak diberikan setelah variasi antrean dihaluskan secara besar-besaran
- Dukungan ECN wajib untuk L4S
- Pengirim menggunakan field ECN agar jaringan dapat membedakan paket L4S dan paket Classic
ECN dan codepoint ECT(1)
- L4S membutuhkan sinyal kongesti yang lebih halus yang keluar dari batasan Classic ECN bahwa “sinyal ECN harus diperlakukan setara dengan drop”
- Sinyal harus dapat muncul lebih sering
- Sinyal harus dapat diberikan segera tanpa latensi besar untuk menghaluskan variasi antrean
- RFC8311 melonggarkan sebagian persyaratan RFC3168 sehingga eksperimen L4S dimungkinkan
- RFC9331 menetapkan ECT(1) untuk digunakan sebagai pengenal paket L4S
- Codepoint CE digunakan untuk menandai Congestion Experienced baik pada pemrosesan L4S maupun Classic
- Jika Classic AQM di bagian awal jalur menandai paket ECT(0) sebagai CE, ada risiko paket itu salah diklasifikasikan ke antrean L4S
- Menurut Lampiran B RFC9331, agar dampak merugikan terjadi, lima kondisi langka harus terjadi bersamaan, dan bahkan dalam kasus itu kemungkinan retransmisi yang salah sangat kecil
- Operator mungkin ingin memasukkan trafik non-L4S yang rendah dan mulus sehingga tidak membuat antrean ke antrean L4S
- Contohnya VoIP, datagram berkecepatan rendah untuk sinkronisasi game online, DNS, LDAP, dan lainnya
- Dalam kasus ini diperlukan penanda terpisah seperti EF, NQB, atau pengenal khusus operator
Dual-Queue Coupled AQM
- L4S bertujuan menyediakan latensi rendah tanpa mengharuskan komponen jaringan melakukan pemrosesan per-flow
- Desain perwakilannya, Dual-Queue Coupled AQM, menggunakan dua antrean
- Antrean L4S mempertahankan latensi rendah
- Antrean Classic dapat memiliki antrean yang lebih besar yang dibutuhkan trafik Classic untuk menjaga utilisasi link
- DualQ dirancang agar berperilaku seperti membran semipermeabel yang memisahkan latensi tetapi tidak membagi bandwidth secara tetap
- Classic AQM membuat probabilitas drop/marking berdasarkan kongesti antreannya sendiri, lalu menggabungkannya dengan sinyal dari antrean Classic dan antrean L4S
- Sinyal kongesti gabungan membuat flow L4S menurunkan kecepatan agar menyisakan kapasitas yang dibutuhkan flow Classic
- Scheduler dapat memberi prioritas ke antrean L4S
- Pada skala waktu pendek, burst L4S cepat diselesaikan untuk melindungi latensi rendah
- Pada skala waktu jangka panjang di atas round-trip time, penggabungan sinyal kongesti dari antrean Classic mengimbangi prioritas bandwidth dan menghasilkan fairness kira-kira per-flow
- Saat hanya ada trafik L4S, AQM pada antrean L4S mulai melakukan marking kongesti pada antrean yang sangat dangkal untuk mempertahankan latensi antrean rendah
Perbedaan antara pendekatan antrean per-flow dan DualQ
- Antrean per-flow seperti FQ-CoDel dan FQ-PIE juga dapat digunakan untuk L4S
- Di Linux, ini dimodifikasi agar ambang marking ECN yang dangkal hanya diterapkan pada paket ECT(1)
- Classic AQM diterapkan pada flow Not-ECT atau ECT(0), sedangkan ambang dangkal yang biasanya di bawah ms diterapkan pada flow ECT(1)
- Pendekatan per-flow memisahkan antrean setiap flow, tetapi tidak menghilangkan antrean yang dibuat oleh flow itu sendiri
- Pada pendekatan DualQ, pengenal L4S berada di field IP-ECN sehingga tidak membutuhkan inspeksi yang lebih dalam dari lapisan IP
- Dapat digunakan bahkan di lingkungan tempat pengenal lapisan transport dienkripsi, seperti IPsec atau tunnel VPN terenkripsi
- Pendekatan per-flow membuat jaringan mengambil alih kontrol kecepatan relatif antar-flow aplikasi
- DualQ memisahkan penyediaan latensi rendah dari masalah kontrol laju flow, dan jika perlu dapat ditambahkan policing laju flow secara terpisah
Persyaratan di sisi host
- Pengirim harus mengimplementasikan Scalable congestion control
- DCTCP adalah contoh yang paling banyak digunakan, tetapi untuk digunakan di Internet publik diperlukan peningkatan keamanan dan performa
- Bagian persyaratan Prague L4S yang terkait dengan risiko merugikan pihak lain dimasukkan sebagai persyaratan normatif dalam RFC9331
- TCP Prague diimplementasikan sebagai implementasi referensi di Linux
- Protokol transport selain TCP juga harus mengimplementasikan respons kongesti Scalable dan menandainya dengan codepoint ECT(1) agar dapat menggunakan layanan L4S
- Varian Scalable untuk QUIC sedang dikaji
- Bagian L4S ECN dari BBRv2 diajukan sebagai Scalable congestion control untuk TCP, QUIC, dan lainnya
- Varian L4S dari SCReAM untuk media RTP juga telah diimplementasikan
- Status umpan balik ECN berbeda-beda menurut protokol
- DCCP dan QUIC menyediakan umpan balik ECN yang cukup rinci untuk L4S
- Umpan balik ECN TCP yang ada berasumsi bahwa mark ECN setara dengan drop, sehingga tidak dapat digunakan untuk Scalable TCP
- Penerima TCP membutuhkan dukungan AccECN, yaitu umpan balik ECN yang lebih akurat
- SCTP membutuhkan implementasi dan deployment desain ECN baru agar mendukung L4S
- Untuk RTP, umpan balik ECN yang memadai didefinisikan dalam RFC6679 dan RFC8888
Mengapa sinyal kongesti eksplisit diperlukan
- L4S menggunakan sinyal kongesti eksplisit sebagai sarana utama, bukan loss
- Drop adalah penurunan performa sekaligus sinyal, sehingga menciptakan ketegangan antara “kerusakan yang semakin sedikit semakin baik” dan “sinyal yang semakin banyak semakin baik”
- Sinyal eksplisit berbasis ECN dapat digunakan beberapa kali per round-trip time tanpa kerusakan, sehingga menguntungkan untuk menjaga antrean tetap pendek
- L4S memindahkan penghalusan dari jaringan ke host
- Karena jaringan tidak mengetahui RTT setiap flow, pendekatan Classic harus mengasumsikan RTT terburuk
- Akibatnya, sinyal kongesti Classic dapat tertunda 100–200 ms
- Karena setiap host mengetahui RTT-nya sendiri, host dapat melakukan penghalusan secukupnya saja, biasanya pada level beberapa ms
- Antrean L4S menggunakan varian ECN L4S baru yang tidak setara dengan drop, sedangkan antrean Classic menggunakan Classic ECN atau drop
Dasar skalabilitas throughput
- Classic Reno congestion control memiliki waktu pemulihan yang semakin panjang pada lingkungan dengan produk bandwidth-latency yang tinggi
- Contoh kondisinya adalah RTT maksimum 30 ms pada puncak gigi gergaji
- Jika laju paket Reno meningkat 8 kali dari 1.250 packet/s menjadi 10.000 packet/s, dari sekitar 15 Mb/s menjadi 120 Mb/s dengan paket 1500B, waktu pemulihan meningkat dari 422 ms menjadi 3,38 s
- CUBIC beroperasi dalam mode Reno-friendly pada 120 Mb/s dan membutuhkan sekitar 4,3 s untuk pemulihan
- Pada 960 Mb/s, CUBIC masuk ke mode true CUBIC dan waktu pemulihan menjadi 12,2 s
- Pada 7,68 Gb/s, waktu pemulihan meningkat hingga 24,3 s
- Scalable congestion control seperti DCTCP atau Prague rata-rata memicu 2 sinyal kongesti per RTT, dan sifat ini tetap terjaga terlepas dari laju flow
- Pada 2020, kapasitas akses tetap rata-rata global adalah 103 Mb/s, dan pada 2019 RTT dasar rata-rata ke CDN adalah 25–34 ms
- Satu flow unduhan CUBIC dapat membutuhkan sekitar 200 RTT, yaitu 5 detik, untuk pulih setelah penurunan congestion window bahkan dalam kondisi terbaik
Hubungan dengan teknologi yang sudah ada
- Diffserv menangani alokasi bandwidth untuk trafik penting dan latensi antrean untuk trafik yang sensitif terhadap latensi, tetapi L4S hanya menangani masalah latensi antrean
- Diffserv efektif ketika hanya sebagian trafik di bottleneck yang membutuhkan latensi rendah
- Jika semua trafik di bottleneck menginginkan latensi rendah, manfaat diferensiasi Diffserv hilang
- Pengenal L4S tidak menunjukkan kebutuhan kualitas, melainkan komitmen perilaku berupa respons kongesti Scalable
- Classic AQM seperti PIE dan FQ-CoDel mengurangi latensi antrean secara signifikan dibandingkan tanpa AQM sama sekali
- L4S melengkapinya dan tidak menggantikan kebutuhan deployment luas teknologi tersebut
- Dengan AQM saja, sulit menghilangkan ketegangan antara latensi dan utilisasi link karena gigi gergaji besar Classic congestion control
- ABE mengubah respons host terhadap marking ECN untuk meningkatkan utilisasi link dan throughput flow ECN, tetapi mengasumsikan jaringan masih memperlakukan ECN dan drop secara sama
- BBR mengontrol latensi antrean secara end-to-end tanpa logika jaringan khusus
- BBR menjaga latensi antrean cukup rendah, tetapi tidak serendah L4S
- BBRv2 dapat menggunakan L4S ECN dan perilaku Scalable L4S congestion control jika memungkinkan
Aplikasi yang dapat diterapkan
- L4S dapat sangat meningkatkan kualitas aplikasi yang sudah ada dalam kondisi berbeban
- Game dan cloud gaming
- VoIP
- Konferensi video
- Penjelajahan web
- Streaming video adaptif
- Pesan instan
- Latensi antrean yang lebih rendah memungkinkan fitur seperti video interaktif berbasis cloud dan VR/AR berbasis cloud
- Dalam demo L4S, video interaktif berbasis cloud dan VR berjalan bersamaan dalam situasi beberapa aplikasi sensitif latensi dan unduhan berbagi antrean bottleneck yang sama pada link akses broadband 40 Mb/s
- Dari latensi dasar end-to-end 7 ms, latensi antrean tambahan berada di kisaran sekitar 1 ms
- Pada AQM alternatif, video terlihat jelas tertinggal dari gestur jari dan gerakan kepala
- Tugas seperti menggeser video dengan swipe jari atau gerakan kepala memiliki persyaratan latensi yang jauh lebih ketat daripada VoIP
- Telepresence jarak jauh interaktif serta kendali jarak jauh berbantuan video untuk mesin dan proses industri sulit dipercaya tanpa latensi antrean yang sangat rendah
Model deployment dan adopsi bertahap
- L4S AQM tidak dirancang harus dideploy di seluruh Internet agar efektif
- Jaringan akses Internet publik biasanya dirancang agar bottleneck terjadi pada satu link logis yang diketahui per situs
- Situs mencakup rumah, perangkat mobile, kampus kecil-menengah, jaringan perusahaan, dan sebagainya
- Ini adalah generalisasi yang berlaku pada berbagai teknologi akses seperti xDSL, kabel, PON, seluler, nirkabel, dan satelit
- Untuk downstream, sebagian besar manfaat dapat diperoleh dengan mendeploy L4S AQM di titik masuk link bottleneck, dan untuk upstream hal yang sama berlaku jika dideploy di titik masuk link upstream
- Agar satu flow L4S mendapat manfaat, biasanya dibutuhkan tiga elemen
- Congestion control pada pengirim
- AQM pada bottleneck
- Umpan balik penerima yang ditingkatkan pada transport lama seperti TCP
- Urutan deployment dapat bervariasi
- DCTCP yang sudah ada dapat digunakan di lingkungan uji coba terkontrol
- Dengan mendeploy TCP Prague dan AccECN, L4S dapat digunakan di lingkungan Internet publik
- Karena QUIC sejak awal mendukung umpan balik ECN yang dibutuhkan L4S, deployment Prague congestion control di sisi pengirim menjadi sederhana
Batasan menurut teknologi link
- Wi-Fi, PON, dan kabel mengagregasi data beberapa paket menjadi burst, lalu menyangga paket yang masuk selama burst dibuat
- Ethernet dan DSL tidak melakukan agregasi paket semacam ini
- Buffering untuk agregasi ini tidak dapat dikurangi oleh pengirim, sehingga tidak boleh dihitung sebagai antrean yang dikendalikan AQM
- Link nirkabel seperti seluler, Wi-Fi, dan satelit dapat mengalami perubahan kapasitas yang cepat dan besar, sehingga antrean yang menetap dianggap diinginkan untuk memanfaatkan peningkatan kapasitas mendadak
- Jaringan seluler lebih kompleks karena kebutuhan buffering agar handover tidak terasa
- L4S tidak dapat menghilangkan semua kebutuhan buffering semacam ini
- Jika “tiang terpanjang” berupa buffering untuk gigi gergaji besar Classic congestion control dihilangkan, muncul insentif untuk lebih mengurangi faktor buffering lain seperti ukuran burst agregasi paket atau interval penjadwalan MAC
Bottleneck non-L4S dan penanganan loss
- Meskipun L4S aktif di antara dua host, jika bottleneck tidak mendukung ECN, pengirim L4S harus tetap hidup berdampingan secara aman dengan Reno saat terjadi drop
- Aturan ini melindungi trafik Classic tetapi menurunkan layanan L4S saat ada loss
- Loss bottleneck sementara akibat burst pada antrean dangkal
- Error transmisi seperti interferensi listrik
- Policing kecepatan
- Tiga pendekatan untuk menanganinya saat ini masih menjadi area riset
- Mengabaikan sebagian loss yang kecil kemungkinannya disebabkan oleh kongesti dalam Prague congestion control
- Pemulihan error transmisi melalui kombinasi RACK, L4S, dan retransmisi link tanpa reordering
- Policer kecepatan hibrida ECN/drop
- Skenario deployment dengan sedikit masalah semacam ini, seperti jaringan kabel, dapat berjalan paralel dengan riset tersebut
Keamanan dan policing trafik
- Internet saat ini biasanya menangani pemisahan kapasitas link bersama antar-situs dengan scheduler, dan tidak secara universal mem-police kecepatan flow aplikasi individual
- L4S dirancang agar tidak merusak kondisi ini
- DualQ dirancang agar tidak memberi keuntungan kecepatan yang lebih besar kepada flow yang tidak merespons dibandingkan AQM antrean tunggal
- Jika policing laju per-flow diperlukan, itu dapat ditambahkan secara independen dari pemisahan L4S/Classic
- L4S dirancang untuk mengurangi latensi tanpa merusak latensi atau kecepatan trafik Classic, sehingga akses ke layanan L4S tidak perlu di-police kecepatannya hanya untuk melindungi Classic
- Sebagian operator dapat menyediakan layanan L4S hanya untuk kelompok terbatas seperti pelanggan premium
- Dalam kasus ini, selain field ECN, pengenal lokal seperti rentang alamat sumber dapat digunakan bersama
- Jika pengenal lokal tidak cocok, paket dapat dikirim ke antrean Classic meskipun memiliki ECT(1)
- Layanan L4S membutuhkan kendali diri bukan hanya terhadap kecepatan, tetapi juga terhadap burstiness
- Fungsi perlindungan antrean latensi rendah untuk DOCSIS bekerja dengan mengalihkan sebagian flow yang membuat antrean ke antrean Classic untuk menjaga latensi rendah
- Fungsi perlindungan antrean tunggal bukan elemen wajib arsitektur L4S, dan sebagian eksperimen L4S bertujuan memastikan apakah fungsi semacam ini diperlukan
Tunnel dan privasi
- Karena L4S AQM memberi sinyal kongesti melalui field ECN, ketika beroperasi di dalam tunnel atau di lapisan bawah, field ECN harus dipropagasikan antar-lapisan sesuai standar
- Arsitektur L4S tidak menyingkirkan pendekatan yang memeriksa pengenal lapisan transport
- Contohnya FQ-CoDel yang ditambahkan dukungan L4S
- Inovasi utama, DualQ AQM, tidak membutuhkan inspeksi lebih dalam dari header IP terluar
- Meskipun pengguna mengenkripsi pengenal flow aplikasi dengan IPsec atau tunnel VPN terenkripsi, mereka tidak perlu menyerah pada latensi rendah
- Karena L4S dapat menyediakan latensi rendah untuk kumpulan aplikasi yang luas, kebutuhan untuk membedakan aplikasi individual atau kelas detail saat melewati jaringan menjadi berkurang
1 komentar
Komentar Hacker News
Ini benar-benar keren. Bulan lalu saya melihat demo langsung di IETF 118 di Prague, dan tampaknya sangat bagus untuk obrolan video karena bufferbloat dihilangkan sepenuhnya
Sepertinya perlu menambahkan bit ekstra ke paket IP untuk memuat informasi seperti apakah buffer sudah penuh, tetapi itu benar-benar bekerja, dan rasanya seperti, “Saya tidak menyangka ini bisa dilakukan”
Untuk yang tautan waktu tidak berfungsi, itu ada di menit 1 jam 21. Sunting: ternyata bukan, ini ringkasan hackathon, dan presentasinya tidak mudah ditemukan
Saya penasaran bagaimana penerima memberi tahu pengirim soal kemacetan, jadi saya coba cari, dan ternyata tidak semudah yang saya kira. Intinya didokumentasikan di https://www.rfc-editor.org/info/rfc3168
Sederhananya, yang ada bukan satu flag melainkan kira-kira tiga. Ada flag agar pengirim memberi tahu router bahwa ia mendukung ECN, ada flag agar router memberi tahu penerima tentang kemacetan, dan ada flag yang disetel penerima saat mengirim paket ACK
Pengirim menandai dukungan ECN dengan codepoint ECT, router yang mendukung ECN lalu meneruskan paket dengan menyetel codepoint CE di header IP alih-alih membuang paket. Penerima menyetel ECN-Echo pada TCP ACK berikutnya, dan pengirim merespons kemacetan seperti halnya kehilangan paket, lalu menyetel flag CWR di header TCP paket berikutnya
Bob Briscoe sudah lama memikirkan arah ini. Saya merekomendasikan tulisan-tulisan klasik terkait berikut
http://www.sigcomm.org/sites/default/files/ccr/papers/2007/A...
https://dl.acm.org/doi/pdf/10.1145/1080091.1080124
Beberapa pengujian dilakukan di jaringan kabel Comcast, dan slide berikut menjelaskannya
https://datatracker.ietf.org/meeting/118/materials/slides-11...
Saya tidak tahu ini akan mengarah ke mana, tetapi saya sempat berpikir ISP mungkin akan mulai mengenakan tarif untuk jalur cepat
Pendapat pribadi, tetapi saya bekerja di Comcast
Jika ingin memahami L4S lebih jauh, serial webinar dimulai hari ini di understandinglatency.com. Beberapa penulis L4S, penanggung jawab uji lapangan L4S dari Comcast, dan juga suara-suara kritis ikut presentasi
Saya menemukan demo singkat penggunaan nyata dengan feed video mobil RC: https://www.youtube.com/watch?v=RZmS10djDEg
Ini memang kemajuan ke arah yang benar, tetapi akan bermasalah jika ada satu saja pelaku jahat yang mengabaikan umpan balik kemacetan dan hanya ingin mengambil porsi bandwidth lebih besar. Kalau begitu peserta lain akan mundur, dan pihak yang tidak adil akan mendapatkan apa yang diinginkannya
Peserta yang berperilaku baik sulit mengetahui apakah peserta lain mematuhi aturan, dan harus tahu bahwa ada fair queuing agar bisa percaya L4S akan menangani semuanya secara adil
Masalah ini bisa diatasi dengan melengkapi L4S menggunakan fair queuing seperti fq_codel, dan membuat pengendalian kemacetan bisa mendeteksi keberadaan fair queuing: https://github.com/muxamilian/fair-queuing-aware-congestion-...
Perdebatan fair queuing adalah bagian dari perdebatan yang lebih besar. Tanpa fair queuing, terlepas dari L4S, keadilan pada dasarnya sudah diimplementasikan oleh host ujung, dan host ujung seperti server bisa mengabaikan respons kemacetan untuk mengambil lebih banyak dari jatah yang adil. Ini bukan masalah baru yang diciptakan L4S, tetapi ada yang berpendapat L4S membuat pengambilan jatah lebih besar menjadi lebih mudah
Pendukung fair queuing melihat bahwa jaringan seharusnya menjamin pembagian yang adil, tetapi tidak semua orang setuju dengan ukuran keadilan yang mereka pilih. Salah satu pendukung utama L4S khususnya tidak setuju, dan itu bisa dilihat di makalah yang ditautkan di sini: https://news.ycombinator.com/item?id=38598023
Saya penasaran apa yang benar-benar berubah dari sudut pandang pengguna. Misalnya, apakah panggilan video jadi lebih mendekati real-time? Biasanya ada latensi sekitar 0,5–1 detik, jadi sering terjadi saling potong dan tumpang tindih saat berbicara. Aplikasi apa lagi yang akan sangat diuntungkan?
Untuk menjaga bitrate di bawah 3Mbps, perlu kompromi sulit antara kualitas, bitrate, waktu CPU, dan latensi. Laptop biasa CPU-nya lambat, atau meskipun punya CPU 6-core, saat menggunakan baterai clock-nya tetap rendah. Encoding video dengan akselerasi perangkat keras juga belum universal, sehingga kualitas dan latensi ikut dikorbankan
Wi-Fi juga menambah latensi, terutama saat laptop berjalan dengan baterai. Banyak layanan obrolan video memakai server cloud sebagai relay untuk menangani NAT, yang menambah latensi lagi
https://hpbn.co/wifi/#measuring-and-optimizing-wifi-performa...
Fitur yang sangat interaktif seperti game dan konferensi video juga akan jadi jauh lebih baik tanpa latensi. Saat ini perlu banyak perjalanan bolak-balik untuk merender halaman web, streaming video, atau menangani interaksi dengan asisten AI seperti Alexa, jadi hampir semua hal yang melibatkan interaksi antara pengguna dan perangkat bisa menjadi lebih baik
Pada dasarnya L4S adalah teknologi untuk mengurangi loop umpan balik latensi. Bagian akhir video ini menjelaskannya dengan cukup baik: https://youtu.be/tAVwmUG21OY?si=lydbqfNL80Y8Uxvp