Düşük gecikme, düşük kayıp ve ölçeklenebilir iş hacmi sunan L4S İnternet Hizmetleri: RFC 9330

L4S İnternet Hizmeti Mimarisi Genel Bakış

• L4S mimarisinin hedefi: İnternet uygulamaları için düşük gecikme, düşük tıkanıklık kaybı ve ölçeklenebilir iş hacmi kontrolü sağlamak
• Temel içgörü: Gecikmenin temel nedeni kuyruğun kendisi değil, göndericinin kapasite arayan tıkanıklık kontrolcüsüdür
• Yeni tıkanıklık kontrol algoritması: Mevcut büyük gecikmelere yol açan tıkanıklık kontrol algoritmalarından uzaklaşılarak, kapasiteyi çok az gecikmeyle keşfedebilen yeni tıkanıklık kontrol algoritmalarının benimsenmesi mümkün
• ECN'nin değiştirilmiş biçimi: Ağda açık tıkanıklık bildirimi (ECN) için değiştirilmiş bir biçimle desteklenir; böylece düşük gecikme ve yüksek iş hacmi aynı anda elde edilebilir
• Kademeli dağıtım odağı: Yeni tıkanıklık kontrol sınıfı ile 'klasik' tıkanıklık kontrolünün paylaşılan ağlarda birlikte var olabilmesini sağlayan mekanizmalar tanımlar

L4S mimarisinin bileşenleri

• Hostlar: Ölçeklenebilir tıkanıklık kontrol algoritmaları zaten mevcuttur ve mevcut klasik tıkanıklık kontrol algoritmalarından farklı olarak, akış hızı artsa bile toparlanma süresi sabit kalır
• Ağ: L4S trafiğinin klasik trafiğin gecikmesinden yalıtılmasını sağlar; gecikmeyi ayırmak için iki kuyruk kullanır ancak bant genişliğini ayırmaz
• Protokol: Hostların L4S ve klasik paketleri ayırt edebilmesi için tanımlayıcılar kullanır ve ağın her bir paket türünü ayrı şekilde işlemesini sağlar

GN⁺ görüşü

Bu yazıdaki en önemli nokta, L4S mimarisinin internet hizmetlerinde düşük gecikme, düşük kayıp ve ölçeklenebilir iş hacmi elde etmek için yeni bir yaklaşım sunmasıdır. Bu mimari, mevcut tıkanıklık kontrol algoritmalarının sınırlamalarını aşar ve ECN'yi kullanarak verimli iletişimi mümkün kılar. Bu, ağ tasarımcıları, operatörler ve kullanıcılar için ilgi çekici bir konu olabilir ve internetin gelecekteki gelişimi üzerinde önemli bir etkiye sahip olabilir.

[GN⁺]

Hacker News yorumları

• Alıcının ağ tıkanıklığını göndericiye nasıl bildirdiğine dair merak

  • Ayrıntılı bilgi için RFC 3168 belgesine bakılabilir
  • ECN(Efficient Congestion Notification) destekleyen üç bayrak bulunuyor
    • Göndericinin ECN desteği sunduğunu bildiren ECT(Echo Congestion Experienced) bayrağı
    • Yönlendiricinin alıcıya tıkanıklık olduğunu bildiren CE(Congestion Experienced) bayrağı
    • Alıcının göndericiye ACK paketi gönderirken ayarladığı ECN-Echo bayrağı
    • Gönderici, ECN-Echo bayrağını alınca paket kaybı yaşandığını varsayıp tıkanıklığa buna göre tepki veriyor
    • Gönderici, ECN-Echo bayrağını fark ettiğini ve buna yanıt verdiğini alıcıya bildirmek için CWR(Congestion Window Reduced) bayrağını ayarlıyor

• ECN teknolojisinin gerçek bir demosunu izleme deneyimi

  • IETF 118'de ECN teknolojisinin canlı demosu izlendi
  • Buffer bloat'ı tamamen ortadan kaldırdığı için görüntülü sohbet için çok faydalı
  • IP paketlerine, buffer'ın dolduğunu bildiren ek bitler yerleştiren bir teknoloji olması nedeniyle oldukça fütüristik hissettiriyor

• Bob Briscoe'nin ilgili çalışmalarının önerilmesi

  • ECN ile ilgili araştırmalara uzun zaman ayıran Bob Briscoe'nin klasik makaleleri öneriliyor

• Comcast ağında L4S testi

  • Kablo altyapısında yapılan L4S testlerinin sonuçlarını içeren slayt destesi paylaşılıyor
  • ISP'nin hızlı şerit için ücret talep edebileceğine dair tahmin yürütülüyor

• L4S teknolojisini kullanan RC araba video akışı demosunun bulunması

  • RC arabanın video akışında L4S teknolojisinin kullanıldığı demo videosunun bağlantısı paylaşılıyor

• L4S hakkında webinar serisinin tanıtılması

  • L4S hakkında daha fazla öğrenmek isteyenler için understandinglatency.com'dan başlayan bir webinar serisi tanıtılıyor
  • L4S'in yazarları, Comcast'in sahadaki L4S denemelerinin sorumlusu ve eleştirel görüşlere sahip kişiler konuşmacı olarak yer alıyor

• L4S'in telaffuzuna dair esprili öneri

  • Bir yorumda L4S'in "L-Force" diye telaffuz edilmesi isteniyor

• L4S'in adillik sorunu ve çözüm yolu

  • Tıkanıklık geri bildirimini görmezden gelip bant genişliğinin daha büyük kısmını almaya çalışan 'kötü niyetli' aktörler varsa sorun ortaya çıkıyor
  • Çözüm olarak, adil kuyruklama(fair queuing) ve tıkanıklık kontrolünün adil kuyruklamayı algılayabilmesini sağlayacak şekilde L4S'in tamamlanması öneriliyor
  • Adil kuyruklama farkındalığı olan tıkanıklık kontrolüne dair GitHub bağlantısı paylaşılıyor

• L4S'in gecikme geri bildirim döngüsünü küçültme biçiminin açıklanması

  • L4S'in gecikme geri bildirim döngüsünü nasıl azalttığını anlatan bir video bağlantısı paylaşılıyor

• Görüntülü konferans ve streaming iyileştirmesine dair kafa karışıklığı

  • Görüntülü konferans ve streaming UDP kullanırken, TCP tabanlı L4S'in buna nasıl katkı sağladığı konusunda kafa karışıklığı dile getiriliyor