Bölüm 68: Tıkanıklık Denetimi

Kayıp toparlandı ve yanıt akmayı sürdürüyor. Peki gönderen saniyede kaç bayt basacağına nasıl karar veriyor?

Ağ ona bir hız söylemiyor. Gönderen kendi hızını, ağdan dolaylı yoldan sızan işaretlere bakarak seçiyor.

Elinde yalnızca iki belirti var

Tıkanıklığın gayriresmî bir tanımı var. Çok sayıda kaynak, ağın kaldırabileceğinden fazla veriyi, kaldırabileceğinden hızlı gönderiyor. Sorun tek bir kutuda durmuyor; paylaşılan kapasitede duruyor.

Bu sorun uca yalnızca iki belirtiyle iniyor. Birincisi gecikmenin uzaması. Paketler router tamponlarında kuyruklanıyor ve orada geçen bekleme senin gidiş-dönüş süreni uzatıyor. İkincisi paket kaybı olarak görünüyor: tampon taşınca gelen paket düşüyor. Gönderenin elindeki bütün kanıt bu ikisi.

2. bölümde düğüm gecikmesini ayırırken kuyruğun dolup paketin silindiğini söylemiş, gerisini bu durağa bırakmıştım; borcu burada ödüyorum. İşleme, iletim ve yayılım yükle bu kadar oynamıyor; trafikle birlikte oynayan tek bileşen kuyruk oluyor.

Sık karıştırılan bir ayrım daha var. Tıkanıklık denetimi çok sayıda göndericinin toplu olarak fazla hızlı göndermesini çözüyor. 67. bölümdeki flow control tek bir alıcıyı koruyordu ve alıcının ilan ettiği pencereyle çalışıyordu. İki mekanizma aynı bağlantıda, birbirinden habersiz ve aynı anda çalışıyor.

TCP’de gönderilebilir miktar iki pencerenin küçüğü. Biri ağın izin verdiği tıkanıklık penceresi. Öteki alıcının başlıkta ilan ettiği kredi; o alan 16 bit ve bayt sayıyor. Tıkanıklık penceresinin başlıkta hiçbir karşılığı yok. Yalnızca gönderenin belleğinde yaşıyor.

Bu yüzden onu telde göremezsin. Kuralları da TCP’nin ana belgesinde değil, ayrı bir metinde yazılı: RFC 5681.

Pencere katlanarak büyüyor, bir anda çöküyor

Bağlantı açıldığında tıkanıklık penceresi küçük bir değerle başlıyor, çünkü TCP ağ hakkında hiçbir şey bilmiyor. Ders kitaplarının klasik değeri tek segment; bugünkü Linux’un varsayılanı ise 2011’den beri 10 segment, yaklaşık 14,6 KB (RFC 6928).

Sonra slow start devreye giriyor. Gelen her onayda pencere bir segment artıyor, dolayısıyla her gidiş-dönüşte ikiye katlanıyor. Adı yavaş ama artış üstel ilerliyor; yavaş olan yalnızca başlangıç değeri.

Üstel artışın nerede duracağını bir eşik tutuyor. Eşiğin başlangıç değeri ders kitaplarında 64 KB diye geçiyor; RFC 5681 onu keyfî olarak yüksek tutmayı öneriyor ve Linux sonsuz başlatıyor, yani ilk kayba kadar slow start sürüyor. CUBIC’le birlikte gelen HyStart ise slow start’ı kayıp beklemeden, gecikmenin artmaya başladığı anda bitiriyor. Eşiğe varınca artış doğrusala dönüyor, TCP tıkanıklıktan kaçınma durumuna geçiyor ve her gidiş-dönüşte bir segment ekliyor. Testere dişi bu asimetriden doğuyor.

Kayıp görüldüğünde eşik, kayıptan hemen önceki pencerenin yarısına çekiliyor. Kuralın adı bu iki hareketten geliyor: toplamsal artış, çarpımsal azalış. Ağ bir kez ölçüldükten sonra bir daha sıfırdan yoklanmıyor. Pencerenin ne kadar düşeceğini ise kaybın nasıl saptandığı belirliyor.

Üç yinelenen onayla saptanan kayıpta pencere yarıya iniyor; Reno’nun katkısı bu. Zaman aşımıyla saptanan kayıpta tek segmente düşüyor. Tahoe ise kaybın türüne hiç bakmıyor, her seferinde tek segmente iniyordu.

Hızlı toparlanmaya girerken pencere eşiğin üç segment üstüne kuruluyor ve her ek yinelenen onay onu bir segment daha şişiriyor. Gerekçesi sağlam: yinelenen onay, ağdan bir paketin çıktığının kanıtı.

Testere dişinin faturası

Somut bir hat kur. Darboğaz 10 Mbit/s, en küçük RTT 40 ms, tam boy segment 1.460 bayt.

Bir bağlantının hatta tutması gereken ideal veri miktarı, darboğazdan aldığı pay ile en küçük RTT’nin çarpımı. Burada 50.000 bayt eder, yani yaklaşık 34 segment. Pencere tek segmentten başlasaydı ikiye katlanarak bu boruyu altı gidiş-dönüşte, yani 240 ms’de doldururdu; bugünkü 10 segmentlik başlangıçla iki turda, 80 ms’de doluyor.

Şimdi kayıp tam orada olsun. Pencere 17 segmente iniyor. Toplamsal artış her gidiş-dönüşte bir segment eklediği için eski değerine dönmesi 680 ms sürüyor. Yükselen kenar, düşen kenardan on yedi kat uzun.

Gönderim hızının kaba karşılığı, pencerenin RTT’ye bölümü. Bu dişin altında ortalama pencere, kaybın oluştuğu pencerenin dörtte üçü: 25,5 segment. Saniyelik karşılığı 930.750 bayt, yani 7,4 Mbit/s ediyor; darboğazın %74,5’ini kullanmış oluyorsun. Kalan dörtte bir, kayba dayalı denetimin faturası. Hesap darboğazda hiç tampon olmadığını varsayıyor. En az bir BDP’lik tampon varsa pencere yarılansa da kuyruk boşalana kadar hat dolu kalıyor; o zaman fatura hızdan değil, kuyrukta geçen gecikmeden ödeniyor.

Throughput hiçbir koşulda kapasiteyi aşamıyor. Uçtan uca hızı yol üstündeki en yavaş bağlantı belirliyor ve o bağlantı pratikte çoğu zaman omurgada değil, uçlardan birinde. Düşen paketin bedeli de bir paketten büyük: onu darboğaza kadar taşıyan her bağlantı, harcadığı kapasiteyi geri alamıyor.

Pencereyi ve eşiği kendi makinende de görebilirsin; gönderenin kaydı oradadır:

$ ss -ti
ESTAB 0 0 203.0.113.10:443 198.51.100.7:51844
      cubic wscale:7,7 rtt:40.1/1.2 mss:1460
      cwnd:34 ssthresh:17 bytes_retrans:5840

Çıktıdaki bytes_retrans hattın yaptığı fazladan işi gösteriyor. Taşımanın hatta koyduğu veri uygulamanın verdiğinden büyük, çünkü girdiye yeniden gönderimler de dahil. Erken bir zaman aşımı bu farkı boşuna büyütüyor: alıcının gördüğü throughput değişmiyor, hattın yaptığı iş artıyor.

Pencerenin büyüyüp yarılanma döngüsünü grafiğin üstünde görelim:

Kuyruk hiç boşalmıyor

Kayba dayalı denetimin kör noktası burada. Darboğaz kuyruğu neredeyse hiç boşalmıyor ve ara sıra taşıyor. Kayıp bir kaza sayılmıyor; algoritmanın çalışma noktası.

54. bölümdeki otoyol benzetmesiyle yolun en dar kesiti darboğaz hattı, giriş rampasındaki bekleme de kuyruk gecikmesi. Yalnız ağda rampa taşınca araç beklemiyor, siliniyor.

Bant genişliği-gecikme çarpımının altında kalırken hattaki veriyi artırmak gidiş-dönüş süresini yükseltmiyor. Üstüne çıkınca fazlalık kuyruğa yazılıyor, throughput’a değil.

O çarpımın kendisi tek satır ve her kapasite hesabının çıpası:

BDP = bant genişliği × RTT

Anlamı fiziksel: hattı tam dolu tutmak için aynı anda havada olması gereken veri miktarı. 1 Gbit/s’lik bir yol 40 ms gidiş-dönüşle çalışıyorsa BDP = 5 MB. Gönderen bu kadar veriyi onaysız yolda tutamıyorsa, kablonun hızı ne olursa olsun hat asla dolmuyor. 66. bölümde alıcı tamponunun neden megabaytlara kadar büyüdüğünün cevabı da bu çarpım.

Buradan sınır kendiliğinden çıkıyor. 67. bölümde pencere alanı 16 bitti ve ölçeklemesiz en büyük ilan 65.535 bayttı. Aynı 40 ms’lik yolda bu, 65.535 × 8 / 0,040 = 13,1 Mbit/s demek. Yani ölçekleme seçeneği olmadan gigabitlik bir hattın ancak yüzde 1,3’ü kullanılabiliyor. Pencere ölçeklemesi bir iyileştirme değil, zorunluluk.

Kayıp oranı hızı nasıl yazıyor?

Testere dişinin ortalama hızı da kestirilebiliyor ve sonuç şaşırtıcı derecede kısıtlayıcı. Formülü 1997’de Mathis ve arkadaşları yayımladı. Hız iki şeye bağlı, ikisi de ters yönde çalışıyor.

Gidiş-dönüş süresine ters orantılı. Uzak sunucu yalnızca geç cevap vermiyor, aynı zamanda daha yavaş: turu iki katına çıkarmak hızı yarıya indiriyor.

Kayıp oranına ise karekökle ters orantılı. Bu ikincisi acımasız: kaybı dört kat azaltmak hızı yalnızca iki katına çıkarıyor; hızı on katına çıkarmak istiyorsan kaybı yüz kat azaltman gerekiyor.

Sayılara dökülünce ne demek olduğu görünüyor. 1.460 baytlık segmentler ve 40 ms’lik bir turla:

Şimdi ters soruyu sor: aynı yolda 1 Gbit/s sürdürmek için kayıp ne kadar seyrek olmalı? Cevap sekiz milyon pakette bir. Bu, kayba dayalı denetimin uzun ve hızlı yollarda niçin zorlandığının tek cümlelik cevabı: talep edilen hata oranı, fiziğin verdiğinin sınırında.

Buna iki farklı cevap var. CUBIC’in dayandığı sezgi şu: kayıp anındaki pencere darboğaz kapasitesinin taze bir ölçümü ve darboğaz o ölçümden bu yana muhtemelen çok değişmedi. Pencereyi yarıladıktan sonra o değere hızla tırmanıyor, yaklaştıkça yavaşlıyor. Artış, dönüm noktasına olan uzaklığın küpüne bağlı ve o nokta ayarlanabilir. CUBIC 2006’dan beri Linux’un varsayılanı, 2023’te RFC 9438 ile standartlaştı ve internette en yaygın tıkanıklık denetimi algoritmalarından biri.

BBR başka bir noktayı hedefliyor: borunun tam dolduğu ama kuyruğun birikmediği yer. Google 2016’da yayımladı ve dört evrede çalışıyor. Hızlanma, throughput platoya oturana kadar gönderim hızını artırıyor. Boşaltma, hızlanırken kuyrukta biriken fazlayı eritiyor. Seyir, ağın gerçekten teslim ettiği hızda gönderiyor ve kanıtı geri dönen onaylar. Yavaşlama, hattaki veriyi kasten azaltıp yeni bir en küçük RTT ölçüyor.

İkisi de darboğazı doyuruyor. CUBIC bunu kuyruğu doldurarak yapıyor ve bedeli gecikme; BBR ise kuyruğu boş tutmaya çalışıyor.

Router de konuşabilir

Buraya kadar anlattığım her şey uçtan uca denetim; TCP’nin seçtiği yol bu. Ağ destekli denetimde ise router’lar flow’ların uçlarına doğrudan haber veriyor; ECN, ATM’nin ABR hizmeti ve DECbit bu aileden. Açık bildirimin ilk denemesi daha eskiydi: ICMP’nin Source Quench mesajı göndereni yavaşlatmak için doğrudan ona yollanıyordu. İşe yaramadı ve RFC 6633 onu 2012’de resmen emekliye ayırdı.

Router’ın elinde iki araç var: düşürmek ve işaretlemek. En basit düşürme biçimi kuyruk sonundan atmak; 40. bölümde gördüğün RED erken düşürüyor, ECN ise düşürmek yerine işaretliyor. Tampon boyutu bir doğa yasası değil, bir tasarım kararıydı. 100 Mbit/s’lik bir darboğazda 1.000 paketlik dolu bir kuyruk 12 Mbit taşıyor. Boşalması 120 ms sürüyor ve senin gidiş-dönüş süren tam o kadar uzuyor.

Fazla tampon gecikmeyi büyütüyor ve bu en çok ev router’larında görülüyor; 40. bölümdeki bufferbloat bu. Oradaki RFC 3439 kuralı tamponu tipik RTT’yle hat kapasitesinin çarpımı kadar tutuyordu ve 10 Gbit/s’lik bir hatta 2,5 Gbit tampon istiyordu. Daha yeni öneri, hattı paylaşan flow sayısı arttıkça tamponu küçültmek.

İşaretlemenin künyesi ayrı. IP başlığındaki hizmet türü baytının 6-7 bitlerini router işaretliyor, 0-5 bitleri 40. bölümdeki DSCP’nin ve işaretleme politikasını ağ işletmecisi seçiyor. İşaret hedefe kadar IP’de gidiyor, hedef onayda ECE bitini kaldırıyor, gönderen de CWR bayrağıyla pencereyi küçülttüğünü bildiriyor. Döngü iki katmanı birden kullanıyor. İki bayrak RFC 3168’de tanımlı ve TCP başlığının sekiz bitlik bayraklar alanının ikisini kaplıyor.

Adalet hedefi sade. Aynı darboğazı paylaşan oturumların her biri kapasitenin eşit payını alsın. Ama bu ancak idealleştirilmiş varsayımlar altında doğru: aynı RTT, hepsi tıkanıklıktan kaçınmada ve sayıları sabit. RTT’si kısa olan flow penceresini daha sık büyüttüğü için payın büyüğünü alıyor. Üstelik adalet flow başına tanımlı, uygulama başına değil; 40. bölümde paralel bağlantı açan uygulamanın payını nasıl büyüttüğünü görmüştün. Tıkanıklık denetimini kullanmaya zorlayan bir merci de yok; uyum gönüllü. Sabit hızda ses ve video gönderen uygulamaların bir kısmı bu yüzden UDP’ye geçip kayba katlanıyor.

Kayba dayalı denetimin varsayımı da tek: kayıp tıkanıklık demek. Kablosuzda bu varsayım zorlanıyor, çünkü kayıp gürültüden ve hareketlilikten de doğuyor. Wi-Fi ve hücresel ağ kayıpların çoğunu 30. bölümde gördüğün gibi kendi içinde yeniden göndererek gizliyor; gizleyemediği kaybı ise TCP tıkanıklık sayıp gereksiz yere yavaşlıyor. BBR’ın kaybı değil teslim hızını ölçmesinin cazibesi burada.

Özet

• Tıkanıklık: ağın kaldırabileceğinden fazla veri gönderiliyor ve uca yalnızca uzayan gecikme ile paket kaybı olarak iniyor.
• İki pencere: gönderilebilir miktar, ağın izin verdiği tıkanıklık penceresiyle alıcının başlıkta ilan ettiği kredinin küçüğü.
• Testere dişi: slow start pencereyi katlıyor, tıkanıklıktan kaçınma birer segment ekliyor, kayıp bir anda yarılıyor.
• BDP: hattı dolu tutmak için havada olması gereken veri bant genişliği ile RTT’nin çarpımı; pencere ondan küçükse hat hiç dolmuyor.
• Kayıp hızı yazıyor: kayba dayalı denetimde hız RTT’yle ve kayıp oranının kareköküyle ters orantılı; gigabit için sekiz milyon pakette birden seyrek kayıp gerekiyor.
• Çalışma noktası: kayba dayalı denetimde kuyruk hiç boşalmıyor; CUBIC kapasiteyi son ölçümden, BBR boruyu doyma noktasından kestiriyor.
• Pay: adalet flow başına tanımlı, bu yüzden paralel bağlantı açan bir uygulama darboğazdan daha büyük dilim alıyor.

Gönderen hızını ayarladı, kayıp toparlandı ve dosya indi. Ama bu anlatının tamamı çıkarım; kimse sana o pencereyi göstermedi. Olup biteni sonradan tek tek nasıl kanıtlarsın?