Düşük gecikme, düşük kayıp ve ölçeklenebilir throughput için L4S internet hizmeti: RFC 9330
(datatracker.ietf.org)- RFC 9330, internet uygulamalarında kuyruk gecikmesi ve tıkanıklık kaynaklı kaybı azaltmak için L4S mimarisini tanımlar ve gecikmenin temel nedenini kuyruğun kendisinden çok göndericinin kapasite arayıcı tıkanıklık kontrolünde görür
- L4S, gönderici ana makinedeki Scalable congestion control, darboğaz noktasındaki AQM ve ECN tabanlı protokolleri birleştirir; L4S paketlerini tanımlamak için IP-ECN alanındaki ECT(1) codepoint'ini kullanır
- Hedef kuyruk gecikmesi ortalamada 1 ms'nin altında, 99. persentilde yaklaşık 2 ms'nin altındadır; DCTCP ve Dual-Queue Coupled AQM örneklerinde aşırı yük altında bile 99. persentil kuyruk gecikmesi yaklaşık 1~2 ms düzeyindedir
- Mevcut Reno/CUBIC ailesi Classic tıkanıklık kontrolü ile birlikte var olabilmek için L4S, Classic trafik ile L4S trafiğinin gecikmesini ayırırken bant genişliğini sabit bölmez; uzun vadede paylaşılacak şekilde tasarlanmıştır
- L4S, Diffserv, FQ-CoDel, PIE ve BBR'nin yerine geçmekten çok onları tamamlar; TCP için AccECN gibi hassas geri bildirim gerekirken QUIC ve DCCP, L4S'nin ihtiyaç duyduğu ECN geri bildirimini zaten sağlar
L4S'nin çözmeyi hedeflediği gecikme sorunu
- Web, ses, video konferans, oyun, uzak masaüstü, bulut uygulamaları, AR/VR ve uzaktan kontrol gibi düşük gecikmeyi tercih eden trafiğin darboğaz bağlantısını doldurduğu durumlar artıyor
- Önbellekler ve sunucular kullanıcıya daha yakın yerleştirilerek yayılım gecikmesi azaltıldı, ancak kuyruklama hâlâ gecikmenin başlıca ve aralıklı bileşenlerinden biri olmaya devam ediyor
- Modern AQM olsa bile yüzlerce ms'lik gecikme sıçramaları nadir değil
- Classic AQM, çoğu zaman tek bir uzun ömürlü akışın testere dişi biçimindeki kuyruk dalgalanmasını tamponlayacak şekilde ayarlanır; bu yüzden uzun ömürlü akış sırasında tüm ağ gecikmesinin zirvesi, temel yol gecikmesinin yaklaşık iki katına çıkabilir
- L4S'nin hedefi çok düşük kuyruk gecikmesi, çok düşük kayıp ve ölçeklenebilir throughput'tur
- Çok düşük kuyruk gecikmesi, ortalamada 1 ms'nin altı ve 99. persentilde yaklaşık 2 ms'nin altı anlamına gelir
- Daha hassas etkileşimli uygulamalar, uçtan uca gecikme 50 ms ya da 20 ms'yi aştığında doğal olmayan bir his vermeye başlar
- Kayıp, etkileşimli uygulamalarda yeniden iletim gecikmesine yol açtığı için düşük kayıp da temel hedeftir
Gecikmenin nedeni: kuyruktan çok Classic tıkanıklık kontrolü
- L4S, kuyruk gecikmesinin temel nedenini kuyruğun kendisinden çok göndericinin kapasite arayıcı tıkanıklık kontrolünde görür
- Reno ve CUBIC gibi Classic tıkanıklık kontrolleri, kuyruk doluluğunu büyük testere dişi biçiminde değiştirir
- AQM kuyruğu fazla sığ tutarsa Classic tıkanıklık kontrolü testere dişinin dip noktalarında bağlantıyı yeterince kullanamaz
- Akış hızı arttıkça Classic tıkanıklık kontrolünün toparlanma süresi uzar ve kuyruk ile kullanım oranı kontrolü gevşer
- Scalable congestion control, akış hızı artsa bile tıkanıklık sinyalleri arasındaki ortalama süreyi, yani toparlanma süresini, sabit tutar
- DCTCP, kontrollü ortamlarda yaygın kullanılan bir örnektir
- Windows Server Editions, Linux ve FreeBSD'de uygulanmış ve dağıtılmıştır
- TCP/QUIC üzerinde Prague, L4S için SCReAM ve BBRv2'nin L4S ECN kısmı da Scalable congestion control örnekleri arasında yer alır
L4S mimarisinin üç bileşeni
- L4S üç bileşenden oluşur
- Gönderici ana makinedeki Scalable congestion control
- Ağ darboğazındaki AQM
- Bu ikisi arasında paket tanımlama ve tıkanıklık sinyallemesini üstlenen ECN tabanlı protokol
- Düşük gecikme doğrudan ağ tarafından sağlanmaz; L4S göndericisinin dikkatli Scalable congestion control davranışından doğar
- Ağın ana rolü, L4S trafiğinin düşük gecikmesini, Classic trafiğin ihtiyaç duyduğu daha büyük kuyruk gecikmesinden yalıtmaktır
- Ağ, ECN kullanarak kuyruk büyümesinin en erken işaretlerini taşıma katmanına hemen bildirir
- Classic AQM'deki gibi kuyruk dalgalanmasını büyük ölçüde yumuşattıktan sonra sinyal vermez
- ECN desteği L4S için zorunludur
- Gönderici, ECN alanını kullanarak ağın L4S paketleri ile Classic paketleri ayırt etmesini sağlar
ECN ve ECT(1) codepoint'i
- L4S, Classic ECN'deki “ECN sinyali düşürmeyle eşdeğer kabul edilmelidir” kısıtının ötesine geçen, daha ayrıntılı bir tıkanıklık sinyali gerektirir
- Sinyalin daha sık oluşabilmesi gerekir
- Kuyruk dalgalanmasını yumuşatmak için büyük gecikmeler eklenmeden hemen sinyal verilebilmelidir
- RFC8311, RFC3168'in bazı gereksinimlerini gevşeterek L4S deneylerini mümkün kılar
- RFC9331, ECT(1)'in L4S paket tanımlayıcısı olarak kullanılmasını tanımlar
- CE codepoint'i, hem L4S hem de Classic işlemede Congestion Experienced göstermek için kullanılır
- Yolun üst kısmındaki bir Classic AQM, ECT(0) paketlerini CE olarak işaretlerse bunların yanlışlıkla L4S kuyruğuna sınıflandırılması riski vardır
- RFC9331 Ek B'ye göre zararlı bir etkinin ortaya çıkması için beş nadir koşulun da aynı anda gerçekleşmesi gerekir; bu durumda bile yanlış yeniden iletim olasılığı son derece küçüktür
- İşletmeciler, kuyruk oluşturmayacak kadar düşük ve düzgün seyreden L4S dışı trafiği L4S kuyruğuna almak isteyebilir
- Örnekler arasında VoIP, çevrim içi oyun senkronizasyonu için düşük hızlı datagram'lar, DNS ve LDAP bulunur
- Bu durumda EF, NQB veya işletmeciye özgü tanımlayıcılar gibi ayrı işaretlemeler gerekir
Dual-Queue Coupled AQM
- L4S, ağ bileşeninin akış başına işlem yapmasını zorunlu kılmadan düşük gecikme sağlamayı hedefler
- Temsilî tasarım olan Dual-Queue Coupled AQM, iki kuyruk kullanır
- L4S kuyruğu düşük gecikmeyi korur
- Classic kuyruğu, Classic trafiğin bağlantı kullanım oranını korumak için ihtiyaç duyduğu daha büyük kuyruğa sahip olabilir
- DualQ, gecikmeyi ayırıp bant genişliğini sabit bölmeyen yarı geçirgen bir zar gibi davranacak şekilde tasarlanmıştır
- Classic AQM, kendi kuyruk tıkanıklığına dayalı drop/marking olasılığını üretir ve bunu Classic kuyruğu ile L4S kuyruğunun sinyallerine bağlar
- Birleştirilmiş tıkanıklık sinyali, L4S akışlarının hızını Classic akışların ihtiyaç duyduğu kapasiteyi bırakacak şekilde düşürmesini sağlar
- Zamanlayıcı L4S kuyruğuna öncelik verebilir
- Kısa zaman ölçeğinde L4S burst'lerini hızla boşaltarak düşük gecikmeyi korur
- RTT'den uzun zaman ölçeklerinde Classic kuyruğunun tıkanıklık sinyali bağlaması, bant genişliği önceliğini dengeleyerek yaklaşık akış başına adalet üretir
- Yalnızca L4S trafiği olduğunda L4S kuyruğunun AQM'si, çok sığ bir kuyrukta tıkanıklık işaretlemeye başlayarak düşük kuyruk gecikmesini sürdürür
Akış başına kuyruk yöntemleri ile DualQ arasındaki fark
- FQ-CoDel ve FQ-PIE gibi akış başına kuyruklama da L4S için kullanılabilir
- Linux'ta, sığ ECN işaretleme eşiğinin yalnızca ECT(1) paketlerine uygulanabilmesi için değişiklik yapılmıştır
- Not-ECT veya ECT(0) akışlarına Classic AQM uygulanırken, ECT(1) akışlarına genellikle 1 ms'nin altında sığ bir eşik uygulanır
- Akış başına yaklaşım, her akışın kuyruğunu ayırır ancak akışın kendisinin oluşturduğu kuyruklamayı ortadan kaldıramaz
- DualQ yaklaşımı, L4S tanımlayıcısı IP-ECN alanında olduğu için IP katmanından daha derin inceleme gerektirmez
- IPsec veya şifrelenmiş VPN tünelleri gibi taşıma katmanı tanımlayıcılarının şifrelendiği ortamlarda da kullanılabilir
- Akış başına yöntemlerde ağ, uygulama akışları arasındaki göreli hız kontrolünü üstlenmiş olur
- DualQ, düşük gecikme sağlama ile akış hızı kontrolü sorununu birbirinden ayırır ve gerekirse buna ek olarak ayrı akış hızı policing uygulanabilir
Ana makine tarafı gereksinimleri
- Gönderici Scalable congestion control uygulamalıdır
- DCTCP en yaygın örnek olsa da genel internet üzerinde kullanılabilmesi için güvenlik ve performans iyileştirmeleri gerekir
- Prague L4S gereksinimlerinin başkalarına zarar verme riskiyle ilgili kısmı, RFC9331'in normatif gereksinimlerine dâhil edilmiştir
- TCP Prague, Linux'ta referans uygulama olarak gerçekleştirilmiştir
- TCP dışındaki taşıma protokollerinin de L4S hizmetini kullanmak için Scalable tıkanıklık tepkisini uygulaması ve bunu ECT(1) codepoint'i ile işaretlemesi gerekir
- QUIC için Scalable varyantlar değerlendirilmektedir
- BBRv2'nin L4S ECN kısmı, TCP ve QUIC gibi protokoller için Scalable congestion control olarak sunulur
- RTP medya için SCReAM'in L4S varyantı da uygulanmıştır
- ECN geri bildiriminin durumu protokole göre değişir
- DCCP ve QUIC, L4S için yeterince ayrıntılı ECN geri bildirimi sağlar
- TCP'nin mevcut ECN geri bildirimi, ECN işaretlerini drop ile eşdeğer gören varsayıma dayandığı için Scalable TCP'de kullanılamaz
- TCP alıcısının, daha doğru ECN geri bildirimi olan AccECN desteğine ihtiyacı vardır
- SCTP'nin L4S'yi desteklemesi için yeni bir ECN tasarımının uygulanması ve dağıtılması gerekir
- RTP için yeterli ECN geri bildirimi RFC6679 ve RFC8888'de tanımlanmıştır
Neden açık tıkanıklık sinyali gerekiyor
- L4S, kayıp yerine açık tıkanıklık sinyalini temel araç olarak kullanır
- Drop, hem performans kaybı hem de sinyal olduğu için “az olması iyi hasar” ile “çok olması iyi sinyal” arasında bir gerilim yaratır
- ECN tabanlı açık sinyal, hasar oluşturmadan RTT başına birden fazla kez kullanılabildiği için kuyruğu kısa tutmada avantaj sağlar
- L4S, yumuşatmayı ağdan ana makineye taşır
- Ağ her akışın RTT'sini bilmediği için Classic yaklaşımda en kötü RTT'yi varsaymak zorundadır
- Bu nedenle Classic tıkanıklık sinyali 100~200 ms gecikebilir
- Her ana makine kendi RTT'sini bildiğinden yalnızca gerektiği kadar, genellikle birkaç ms düzeyinde yumuşatma yapabilir
- L4S kuyruğu, drop ile eşdeğer olmayan yeni bir L4S ECN varyantı kullanırken Classic kuyruğu Classic ECN veya drop kullanır
Throughput ölçeklenebilirliğinin dayanağı
- Classic Reno tıkanıklık kontrolünde toparlanma süresi, yüksek bant genişliği-gecikme çarpımı ortamlarına gidildikçe uzar
- Örnek koşullarda testere dişi zirvesindeki azami RTT 30 ms'dir
- Reno paket oranı 1.250 packet/s'den 10.000 packet/s'ye 8 kat çıktığında, 1500B paket temelinde yaklaşık 15 Mb/s'den 120 Mb/s'ye yükselir ve toparlanma süresi 422 ms'den 3,38 s'ye çıkar
- CUBIC, 120 Mb/s'de Reno-friendly modda çalışır ve toparlanması yaklaşık 4,3 s sürer
- 960 Mb/s'de true CUBIC moduna geçer ve toparlanma süresi 12,2 s olur
- 7,68 Gb/s'de toparlanma süresi 24,3 s'ye kadar çıkar
- DCTCP veya Prague gibi Scalable congestion control yaklaşımları ortalamada RTT başına 2 tıkanıklık sinyali üretir ve bu özellik akış hızından bağımsız olarak korunur
- 2020'de dünya genelinde ortalama sabit erişim kapasitesi 103 Mb/s, 2019'da CDN'e kadar ortalama temel RTT ise 25~34 ms idi
- Tek bir CUBIC indirme akışı, tıkanıklık penceresi düşüşünden sonra toparlanmak için en iyi durumda bile yaklaşık 200 RTT, yani 5 saniye gerektirebilir
Mevcut teknolojilerle ilişkisi
- Diffserv, önemli trafiğin bant genişliği tahsisini ve gecikmeye duyarlı trafiğin kuyruk gecikmesini ele alırken L4S yalnızca kuyruk gecikmesi sorununa odaklanır
- Diffserv, darboğazda trafiğin yalnızca bir kısmı düşük gecikme gerektirdiğinde etkilidir
- Darboğazdaki tüm trafik düşük gecikme istediğinde Diffserv'in ayrım avantajı ortadan kalkar
- L4S tanımlayıcısı bir kalite gereksinimini değil, Scalable tıkanıklık tepkisine yönelik bir davranış taahhüdünü ifade eder
- PIE ve FQ-CoDel gibi Classic AQM yaklaşımları, hiç AQM olmayan duruma kıyasla kuyruk gecikmesini büyük ölçüde azaltır
- L4S bunları tamamlar; yaygın biçimde dağıtılmaları gereğini ortadan kaldırmaz
- Yalnızca AQM ile, Classic tıkanıklık kontrolünün büyük testere dişi davranışı yüzünden gecikim ile bağlantı kullanım oranı arasındaki gerilimi gidermek zordur
- ABE, ECN işaretlemesine verilen ana makine tepkisini değiştirerek bağlantı kullanım oranını ve ECN akışı throughput'unu artırır; ancak ağın ECN ile drop'u hâlâ aynı kabul ettiğini varsayar
- BBR, özel ağ mantığı olmadan uçtan uca kuyruk gecikmesini kontrol eder
- BBR kuyruk gecikmesini makul düzeyde düşük tutar ama L4S kadar düşük değildir
- BBRv2, mümkün olduğunda L4S ECN ve Scalable L4S tıkanıklık kontrolü davranışını kullanabilir
Uygulanabilir uygulamalar
- L4S, yük altında mevcut uygulamaların kalitesini büyük ölçüde iyileştirebilir
- Oyun ve bulut oyun
- VoIP
- Video konferans
- Web gezintisi
- Uyarlamalı video akışı
- Anlık mesajlaşma
- Daha düşük kuyruk gecikmesi, bulut tabanlı etkileşimli video ve bulut tabanlı VR/AR gibi yetenekleri mümkün kılar
- L4S demolarında, 40 Mb/s geniş bant erişim bağlantısında birden fazla gecikmeye duyarlı uygulama ve indirmelerin aynı darboğaz kuyruğunu paylaştığı durumda bulut tabanlı etkileşimli video ile VR birlikte çalıştı
- Uçtan uca 7 ms temel gecikmede ek kuyruk gecikmesi yaklaşık 1 ms düzeyindeydi
- Alternatif AQM'de videonun parmak hareketi ve baş hareketini gözle görülür biçimde geriden takip ettiği görüldü
- Parmak kaydırma ya da baş hareketiyle videoyu kaydırma görevi, VoIP'ten çok daha katı gecikme gereksinimlerine sahiptir
- Etkileşimli uzaktan telepresence, makine ve endüstriyel süreçlerin video destekli uzaktan kontrolü, çok düşük kuyruk gecikmesi olmadan güvenilir sayılmaz
Dağıtım modeli ve kademeli devreye alma
- L4S AQM, etkili olabilmek için internetin tamamına dağıtılması gereken bir yapı değildir
- Genel internet erişim ağları genellikle darboğazın site başına bilinen tek bir mantıksal bağlantıda oluşacağı şekilde tasarlanır
- Siteler; evleri, mobil cihazları, küçük ve orta ölçekli kampüsleri ve kurumsal ağları kapsar
- Bu, xDSL, kablo, PON, hücresel, kablosuz ve uydu gibi çeşitli erişim teknolojileri için geçerli genel bir yaklaşımdır
- Downstream'de, darboğaz bağlantısının giriş noktasına L4S AQM yerleştirmek faydanın çoğunu sağlar; upstream için de upstream bağlantı girişinde aynı şekilde geçerlidir
- Bir L4S akışının fayda görmesi için genellikle üç unsur gerekir
- Göndericinin tıkanıklık kontrolü
- Darboğazdaki AQM
- TCP gibi eski taşımalarda yükseltilmiş alıcı geri bildirimi
- Dağıtım sırası farklı olabilir
- Hâlihazırda mevcut DCTCP, kontrollü test ortamlarında kullanılabilir
- TCP Prague ve AccECN dağıtılırsa genel internet ortamında L4S kullanılabilir
- QUIC, L4S için gereken ECN geri bildirimini baştan desteklediği için gönderici tarafında Prague tıkanıklık kontrolünün dağıtımı daha basittir
Bağlantı teknolojilerine göre kısıtlar
- Wi-Fi, PON ve kablo birden fazla paket verisini burst hâlinde toplar ve burst oluşturulurken gelen paketleri tamponlar
- Ethernet ve DSL böyle bir paket toplulaştırması yapmaz
- Bu toplulaştırma tamponlaması gönderici tarafından azaltılamaz; bu yüzden AQM'nin kontrol ettiği kuyruk olarak sayılmamalıdır
- Hücresel, Wi-Fi ve uydu gibi kablosuz bağlantılarda kapasite hızlı ve büyük ölçüde değişebilir; bu yüzden ani kapasite artışlarını kullanmak için sürekli bir kuyruğun bulunması arzu edilir görülür
- Hücresel ağlar, handover'ı fark edilmez kılmak için gereken tamponlama yüzünden daha karmaşıktır
- L4S, bu tür tamponlama ihtiyaçlarının tümünü ortadan kaldıramaz
- Classic tıkanıklık kontrolünün büyük testere dişi davranışı için gereken tamponlamayı, yani “en uzun direği” kaldırmak; paket toplulaştırma burst boyutu veya MAC zamanlama aralığı gibi diğer tamponlama unsurlarını da daha fazla azaltma motivasyonu yaratır
L4S dışı darboğazlar ve kayıp işleme
- L4S iki ana makine arasında etkin olsa bile darboğaz ECN desteklemiyorsa L4S göndericisi, drop karşısında Reno ile güvenli biçimde birlikte var olabilmelidir
- Bu kural Classic trafiği korur ama kayıp olduğunda L4S hizmetini zayıflatır
- Sığ kuyruk burst'lerinden kaynaklanan geçici darboğaz kaybı
- Elektriksel parazit gibi iletim hataları
- Hız policing'i
- Bunları ele almak için üç yaklaşım şu anda araştırma konusudur
- Prague tıkanıklık kontrolünde, tıkanıklık kaynaklı olma olasılığı düşük bazı kayıpların göz ardı edilmesi
- RACK, L4S ve yeniden sıralama olmayan bağlantı yeniden iletiminin birleşimiyle iletim hatalarının telafisi
- Hibrit ECN/drop hız policer'ı
- Kablolu ağlar gibi bu sorunların daha az görüldüğü dağıtım senaryoları, ilgili araştırmalarla paralel olarak ilerleyebilir
Güvenlik ve trafik policing'i
- Bugünün internetinde genellikle siteler arası paylaşılan bağlantı kapasitesinin ayrımı zamanlayıcılarla yapılır; tek tek uygulama akışlarının hızı yaygın biçimde policing'e tabi tutulmaz
- L4S, bu durumu bozmamak için tasarlanmıştır
- DualQ, yanıt vermeyen akışlara tek kuyruklu AQM'den daha büyük bir hız avantajı vermeyecek şekilde tasarlanmıştır
- Akış başına hız policing'i gerekirse L4S/Classic ayrımından bağımsız olarak eklenebilir
- L4S, Classic trafiğin gecikmesine veya hızına zarar vermeden gecikmeyi azaltacak şekilde tasarlandığı için yalnızca Classic'i korumak amacıyla L4S hizmetine erişimi hız policing'i ile sınırlamak gerekmez
- Bazı işletmeciler L4S hizmetini yalnızca premium müşteriler gibi sınırlı gruplara sunmak isteyebilir
- Bu durumda ECN alanının yanı sıra kaynak adres aralığı gibi yerel tanımlayıcılar da birlikte kullanılabilir
- Yerel tanımlayıcı uyuşmuyorsa ECT(1) olsa bile trafik Classic kuyruğa gönderilebilir
- L4S hizmeti yalnızca hızda değil burst davranışında da ölçülülük gerektirir
- DOCSIS için düşük gecikmeli kuyruk koruma işlevi, kuyruk oluşturan akışların bir kısmını Classic kuyruğa yeniden yönlendirerek düşük gecikmeyi korur
- Tek kuyruk koruma özelliği L4S mimarisinin zorunlu parçası değildir; L4S deneylerinin bir kısmı da bu tür bir özelliğin gerekli olup olmadığını belirlemeyi amaçlar
Tüneller ve gizlilik
- L4S AQM, tıkanıklığı ECN alanı üzerinden sinyallediği için tünel içinde veya alt katmanda çalışırken ECN alanının katmanlar arasında standartlara uygun şekilde aktarılması gerekir
- L4S mimarisi, taşıma katmanı tanımlayıcılarını inceleyen yöntemleri dışlamaz
- Buna örnek olarak L4S desteği eklenmiş FQ-CoDel verilebilir
- Temel yenilik olan DualQ AQM, en dış IP başlığından daha derin inceleme gerektirmez
- Kullanıcılar, IPsec veya şifreli VPN tünelleriyle uygulama akışı tanımlayıcılarını şifrelese bile düşük gecikmeden vazgeçmek zorunda kalmaz
- L4S, geniş bir uygulama kümesine düşük gecikme sağlayabildiği için ağ üzerinden geçerken tek tek uygulamaların veya ayrıntılı sınıfların ayırt edilmesi ihtiyacını azaltır
1 yorum
Hacker News yorumları
Bu gerçekten harika. Geçen ay Prag’daki IETF 118’de canlı demosunu gördüm; bufferbloat’ı tamamen ortadan kaldırdığı için görüntülü sohbet için çok iyi görünüyordu.
IP paketlerine, tamponun dolu olup olmadığı gibi bilgileri taşımak için ek bir bit koymak gerekiyor gibi görünüyor ama gerçekten çalıştı ve “bunun mümkün olabileceğini bilmiyordum” hissi verdi.
Zaman bağlantısı çalışmayanlar için 1 saat 21 dakika civarı. Düzeltme: Değilmiş; bu hackathon özetiydi ve sunumu bulmak kolay değil.
Alıcının gönderene tıkanıklığı nasıl bildirdiğini merak edip araştırdım ama bulmak beklediğimden zor oldu. Esas kısım https://www.rfc-editor.org/info/rfc3168 içinde belgelenmiş.
Basitçe söylemek gerekirse tek bir bayrak değil, yaklaşık üç bayrak var. Gönderenin yönlendiriciye ECN desteği var dediği bir bayrak, yönlendiricinin alıcıya tıkanıklığı bildirdiği bir bayrak ve alıcının ACK paketi gönderirken ayarladığı bir bayrak var.
Gönderen, ECT kod noktasıyla ECN desteğini belirtir; ECN destekli yönlendirici ise paketi düşürmek yerine IP başlığında CE kod noktasını ayarlayıp iletir. Alıcı bir sonraki TCP ACK içinde ECN-Echo’yu ayarlar; gönderen de tıkanıklığa paket kaybı varmış gibi tepki verdikten sonra bir sonraki paketin TCP başlığında CWR bayrağını ayarlar.
Bob Briscoe bu yönde uzun zamandır düşünüyor. İlgili klasikler olarak aşağıdaki yazıları öneririm.
http://www.sigcomm.org/sites/default/files/ccr/papers/2007/A...
https://dl.acm.org/doi/pdf/10.1145/1080091.1080124
Comcast kablo ağında bazı testler yapıldı; aşağıdaki slaytlar bunu açıklıyor.
https://datatracker.ietf.org/meeting/118/materials/slides-11...
Nereye varacağını bilmiyorum ama ISP’lerin hızlı şerit için geçiş ücreti almaya başlayabileceğini düşündürüyor.
Kişisel görüşüm; Comcast’te çalışıyorum.
L4S hakkında daha fazla bilgi edinmek istiyorsanız understandinglatency.com’da bugün bir webinar serisi başlıyor. L4S yazarlarından bazıları, Comcast’in L4S saha denemesi sorumlusu ve eleştirel sesler de sunum yapacak.
RC araba video akışıyla gerçek kullanımını gösteren kısa bir demo buldum: https://www.youtube.com/watch?v=RZmS10djDEg
Doğru yönde bir ilerleme olsa da, tıkanıklık geri bildirimini görmezden gelip yalnızca daha büyük bant genişliği payı isteyen tek bir kötü niyetli katılımcı bile sorun yaratır. O zaman diğer katılımcılar geri çekilir ve adil olmayan taraf istediğini alır.
İyi niyetli bir katılımcının, diğer katılımcıların kurallara uyup uymadığını bilmesi zordur; L4S’nin adil davranacağına güvenebilmesi için fair queuing olduğunu bilmesi gerekir.
Bu sorun, L4S’yi fq_codel gibi fair queuing ile tamamlayarak ve tıkanıklık kontrolünün fair queuing’in varlığını algılayabilmesini sağlayarak çözülebilir: https://github.com/muxamilian/fair-queuing-aware-congestion-...
Fair queuing tartışması daha büyük bir tartışmanın parçası. Fair queuing yoksa, L4S’den bağımsız olarak adalet zaten uç ana bilgisayarlar tarafından uygulanır; sunucular gibi uç ana bilgisayarlar da tıkanıklık tepkisini görmezden gelip adil paylarından fazlasını alabilir. Bu L4S’nin yeni yarattığı bir sorun değil; ancak bazıları L4S’nin daha büyük pay almayı kolaylaştırdığını düşünüyor.
Fair queuing savunucuları ağın adil paylaşımı garanti etmesi gerektiğini savunur, fakat herkes onların seçtiği adalet ölçütüyle hemfikir değildir. Özellikle L4S’nin başlıca destekçilerinden biri hemfikir değil; bunu burada bağlantısı verilen makalede görebilirsiniz: https://news.ycombinator.com/item?id=38598023
Kullanıcı açısından gerçekte neyin değişeceğini merak ediyorum. Örneğin görüntülü aramalar daha gerçek zamana yakın mı olacak? Genelde 0,5–1 saniye kadar gecikme oluyor; bu da konuşurken çok fazla kesilme ve araya girme yaratıyor. Başka hangi uygulamalar büyük ölçüde iyileşir?
3 Mbps altı bit hızına uymak için kalite, bit hızı, CPU zamanı ve gecikme arasında zor ödünleşimler gerekiyor. Sıradan dizüstülerde CPU yavaş olabiliyor ya da 6 çekirdekli CPU olsa bile pildeyken saat hızını düşük tutuyor. Donanım hızlandırmalı video kodlama da yaygın olmadığı için kalite ve gecikme feda ediliyor.
Wi‑Fi de gecikme ekler; özellikle dizüstü bilgisayar pilde çalışırken. NAT işlemleri için birçok görüntülü sohbet servisi bulut sunucularını röle olarak kullanır ve bu da gecikme ekler.
https://hpbn.co/wifi/#measuring-and-optimizing-wifi-performa...
Oyunlar ve video konferans gibi yüksek etkileşimli işlevler de gecikme olmadan çok daha iyi hâle gelir. Web sayfası oluşturmak, video akışı yapmak ya da Alexa gibi yapay zeka asistanı etkileşimlerini işlemek bugün çok sayıda gidiş-dönüş gerektirdiğinden, kullanıcı ile cihazın etkileşime girdiği neredeyse her şey iyileşebilir.
Özünde L4S, gecikme süresi geri bildirim döngüsünü kısaltan bir teknoloji. Bu videonun ikinci yarısı bunu oldukça iyi açıklıyor: https://youtu.be/tAVwmUG21OY?si=lydbqfNL80Y8Uxvp