Bölüm 60: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 yönlendirici 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.

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. 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 sekizli 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 tek bir maksimum segment boyu. TCP ağ hakkında hiçbir şey bilmediği için en küçük değerden başlıyor.

Sonra yavaş başlangıç 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. Durum makinesi açılışta bu eşiği 64 KB’ye, yinelenen onay sayacını da sıfıra kuruyor. 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 ve bunun sağlam bir gerekçesi var. 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 gidiş-dönüş süresi 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 gidiş-dönüş süresinin çarpımı. Burada 50.000 bayt eder, yani yaklaşık 34 segment. Pencere birden ikiye katlanarak bu boruyu altı gidiş-dönüşte, yani 240 ms’de dolduruyor.

Ş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 gidiş-dönüş süresine 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ı.

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 198.51.100.7:51844 203.0.113.10:443
      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ı.

Otoyol benzetmesinde yolun en dar kesiti darboğaz hattıydı, giriş rampasındaki bekleme de kuyruk gecikmesi. Benzetme yine aynı yerde bitiyor: taşan rampada araç beklemiyor, düşüyor.

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 × gidiş-dönüş süresi

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 hat asla dolmuyor — kablonun hızı ne olursa olsun.

Buradan sınır kendiliğinden çıkıyor. Pencere alanı 16 bit ve ölçeklemesiz en büyük ilan 65.535 bayt. 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 yüzde biri bile kullanılamıyor. 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ı. İki ş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 bir tarafta 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 Linux’un varsayılanı; kaynağın kaydına göre yaklaşık 2024’e kadar yaygın web sunucularında en çok kullanılan TCP sürümüydü.

BBR başka bir noktayı hedefliyor: borunun tam dolduğu ama kuyruğun birikmediği yer. Üç evrede çalışıyor. Hızlanma, throughput platoya oturana kadar gönderim hızını artırıyor. 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 gidiş-dönüş süresi ölçüyor.

İkisi de darboğazı doyuruyor. Biri gecikme bedelini ödüyor.

Yönlendirici de konuşabilir

Buraya kadar anlattığım her şey uçtan uca denetim; TCP’nin seçtiği yol bu. Ağ destekli denetimde ise yönlendiriciler akışların uçlarına doğrudan haber veriyor; ECN, ATM 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.

Yönlendiricinin elinde iki araç var: düşürmek ve işaretlemek. En basit düşürme biçimi kuyruk sonundan atmak; işaretlemenin iki bilinen adı ise RED ve ECN. 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 yönlendiricilerinde görülüyor. RFC 3439’un pratik kuralı ortalama tamponu tipik gidiş-dönüş süresiyle hat kapasitesinin çarpımı kadar tutuyor ve tipik değer olarak 250 ms anıyor. 10 Gbit/s’lik bir hatta bu 2,5 Gbit tampon demek. Daha yeni öneri, hattı paylaşan akış 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 yönlendirici işaretliyor, 0-5 bitleri diffserv’in 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ı gidiş-dönüş süresi, hepsi tıkanıklıktan kaçınmada ve sayıları sabit. Üstelik adalet akış başına tanımlı, uygulama başına değil. 60 Mbit/s’lik bir darboğazda beş akış varken gelen ve tek bağlantı açan uygulama 10 Mbit/s alıyor, beş bağlantı açan 30 Mbit/s alıyor. Bu da kapasitenin %50’si. 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.

Zaman aşımı kestirimi ölçülen gidiş-dönüş süresine değil onun tahminine dayanıyordu. Kablosuzda o tahminin altındaki varsayım büsbütün çöküyor: kayıp gürültüden ve hareketlilikten doğuyor ama TCP onu tıkanıklık sayıp gereksiz yere yavaşlıyor. Kaybı sinyal saymanın bedeli en açık burada görülüyor.

Özet

Peki, ne öğrendik?

• 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. Yavaş başlangıç pencereyi katlıyor, tıkanıklıktan kaçınma birer segment ekliyor, kayıp bir anda yarılıyor.
• Çalışma noktası. Kayba dayalı denetimde kuyruk hiç boşalmıyor; CUBIC kapasiteyi son ölçümden, BBR boruyu doyma noktasından kestiriyor.
• Pay. Adalet akış 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?