Tıkanıklık Denetimi

Önceki dersin akış denetimi alıcının kapasitesini korur. Alıcı bir megabaytlık pencere bildiriyorsa, gönderen bu miktarı onaysız gönderme hakkını elde eder — yol boyunca ne olduğu hesaba katılmadan.

Yol, o kadar veriyi kaldıramayabilir. Yönlendiricilerin kuyrukları dolar, paketler atılır, atılan paketler yeniden gönderilir ve yeniden gönderimler kuyrukları daha da doldurur. Bu dersin sorusu, gönderenin göremediği bir kapasiteyi nasıl tahmin edebileceğidir.

Tıkanıklık

Tıkanıklık (congestion), bir bağlantıya gelen trafiğin o bağlantının kapasitesini aşmasıdır. Yönlendirici fazla paketleri kuyruğa alır; kuyruk dolduğunda atmaya başlar.

Denetimsiz bırakıldığında bir geri besleme döngüsü oluşur. Atılan paketler yeniden gönderilir, yeniden gönderimler yükü artırır, yük arttıkça daha çok paket atılır. Sonuçta bağlantı üzerinden geçen yararlı veri miktarı, yük artmasına karşın düşer. Bu duruma tıkanıklık çöküşü (congestion collapse) denir.

Sorunun zorluğu bilgi eksikliğidir. Gönderen ne yolun kapasitesini bilir ne de aynı yolu kimlerin paylaştığını. Elindeki tek bilgi kendi gönderdiği segmentlerin başına gelenlerdir. Bu nedenle tıkanıklık denetimi bir ölçüm ve uyum döngüsüdür: gönderen hızını artırır, ağın tepkisini gözler, tepkiye göre ayarlar.

Tıkanıklık Penceresi

Gönderen, alma penceresine ek olarak ikinci bir sınır tutar: tıkanıklık penceresi (congestion window, cwnd). Bu değer karşı taraftan gelmez; gönderenin kendi tahminidir.

Onaysız gönderilebilecek veri miktarı ikisinin küçüğüdür:

$$\text{etkin pencere} = \min(\text{cwnd},\ \text{rwnd})$$

Ayrım anlamlıdır. Alma penceresi alıcıyı, tıkanıklık penceresi ağı korur. Bir aktarım yavaşsa hangisinin sınırladığı sorulmalıdır: alıcı arabelleği küçükse alma penceresi, yol sıkışıksa tıkanıklık penceresi darboğazdır.

Yavaş Başlangıç

Bağlantı kurulduğunda yolun kapasitesi hakkında hiçbir bilgi yoktur. Başlangıç değeri küçük seçilir ve her onayla artırılır. Bir tur boyunca pencere kadar segment onaylandığından pencere her turda ikiye katlanır.

MSS = 1460

cwnd = 1
for tur in range(1, 12):
    print(f"tur {tur:2d}: cwnd={cwnd:5d} MSS = {cwnd * MSS / 1024:8.1f} KiB")
    cwnd *= 2

tur  1: cwnd=    1 MSS =      1.4 KiB
tur  2: cwnd=    2 MSS =      2.9 KiB
tur  3: cwnd=    4 MSS =      5.7 KiB
tur  4: cwnd=    8 MSS =     11.4 KiB
tur  5: cwnd=   16 MSS =     22.8 KiB
tur  6: cwnd=   32 MSS =     45.6 KiB
tur  7: cwnd=   64 MSS =     91.2 KiB
tur  8: cwnd=  128 MSS =    182.5 KiB
tur  9: cwnd=  256 MSS =    365.0 KiB
tur 10: cwnd=  512 MSS =    730.0 KiB
tur 11: cwnd= 1024 MSS =   1460.0 KiB

Evrenin adı yanıltıcıdır: büyüme üsteldir ve hızlıdır. “Yavaş” sözcüğü, kapasiteye doğrudan sıçramak yerine küçükten başlanmasını anlatır.

Üstel büyüme, bir eşiğe kadar sürer. Yavaş başlangıç eşiği (slow start threshold) aşıldığında veya bir kayıp sezildiğinde evre değişir.

Toplamalı Artış, Çarpımsal Azalış

Eşikten sonraki evre tıkanıklıktan kaçınmadır (congestion avoidance) ve büyüme doğrusaldır: her turda pencereye bir MSS eklenir.

Kayıp sezildiğinde pencere çarpımsal olarak düşürülür — yaygın davranış yarıya indirmektir. İki kuralın birlikte adı **toplamalı artış, çarpımsal azalış (additive increase, multiplicative decrease, AIMD)**tir.

Bakışımsızlık bilinçlidir. Artış yavaş olduğu için kapasite aşımı sınırlı kalır; azalış hızlı olduğu için tıkanıklık çabuk hafifler. Aynı yolu paylaşan akışlar bu kural altında paylarını dengeler: fazla alan akış kayıptan daha çok etkilenir ve payı düşer.

Bakışımsızlığın bedeli, yüksek kapasiteli ve yüksek gecikmeli yollarda görülür.

import math

MSS = 1460
bdp = 1000e6 * 0.100 / 8
hedef = bdp / MSS
print(f"bant genişliği-gecikme çarpımı: {bdp/1e6:.1f} MB = {hedef:.0f} MSS")
tur_ustel = math.ceil(math.log2(hedef))
print(f"üstel artışla: {tur_ustel} tur = {tur_ustel * 100} ms")
tur_dogrusal = round(hedef / 2)
print(f"doğrusal artışla (yarıdan): {tur_dogrusal} tur = {tur_dogrusal * 100 / 1000:.1f} s")

bant genişliği-gecikme çarpımı: 12.5 MB = 8562 MSS
üstel artışla: 14 tur = 1400 ms
doğrusal artışla (yarıdan): 4281 tur = 428.1 s

1 Gb/s kapasiteli, 100 ms gecikmeli bir yolda pencerenin kapasiteye ulaşması üstel evrede 1,4 saniye alır. Tek bir kayıp pencereyi yarıya indirirse, doğrusal artışla geri tırmanmak yedi dakikadan uzun sürer. Bu ölçekteki yollarda klasik AIMD davranışı kapasiteyi kullanamaz; sonraki bölümde ele alınan yaklaşımların gerekçesi budur.

Kaybın Sinyal Olarak Okunması

Klasik tıkanıklık denetimi, paket kaybını tıkanıklık göstergesi sayar. Varsayım şudur: kablolu bir yolda bit hatası seyrektir, dolayısıyla kaybın nedeni büyük olasılıkla dolu bir kuyruktur.

Varsayımın geçerli olmadığı durumlar vardır. Kablosuz bağlantılarda paket kaybı girişim veya sinyal zayıflığından kaynaklanabilir; bu durumda pencereyi yarıya indirmek sorunu çözmez, yalnızca verimi düşürür. Aynı biçimde, geçici bir yol değişikliğinden kaynaklanan sıra bozulması yinelenen onaylar üretir ve gereksiz bir azaltmayı tetikleyebilir.

Kaybın oluşmasını beklemeden tıkanıklığı bildirmenin bir yolu vardır: açık tıkanıklık bildirimi (explicit congestion notification). Kuyruğu dolmaya başlayan yönlendirici paketi atmak yerine IP başlığındaki iki biti işaretler; alıcı bunu onayında geri bildirir ve gönderen paket kaybetmeden hızını azaltır. Yöntemin çalışması için yol üzerindeki düğümlerin ve her iki ucun desteklemesi gerekir.

Üçüncü bir yaklaşım, kaybı hiç beklemeden gecikmedeki artışı sinyal olarak okumaktır: kuyruklar dolmaya başladığında gidiş–dönüş süresi yükselir. Gecikme tabanlı yöntemler kuyrukları boş tutar ve gecikmeyi düşük tutar; ancak kayıp tabanlı akışlarla aynı yolu paylaştıklarında pay kaybederler, çünkü diğerleri kuyruk dolana kadar geri çekilmez.

Hızlı Yeniden İletim ve Hızlı Kurtarma

Kayıp iki yolla sezilir ve tepki farklıdır.

Sezme yolu	Anlamı	Tepki
Zaman aşımı	Ağdan hiç haber yok	Pencere en küçük değere iner, yavaş başlangıca dönülür
Üç yinelenen onay	Sonraki segmentler ulaşıyor	Pencere yarıya iner, tıkanıklıktan kaçınma sürer

Ayrımın gerekçesi bilgi miktarıdır. Yinelenen onay geliyorsa, yol tümüyle kopmamış demektir: sonraki segmentler alıcıya ulaşmaktadır. Bu durumda sıfırdan başlamak gereksizdir; pencere yarıya indirilip akış sürdürülür. Buna hızlı kurtarma (fast recovery) denir.

Zaman aşımında ise hiçbir onay gelmemiştir; yolun durumu bilinmez ve baştan ölçmek gerekir.

Kayıp Oranı ve Verim

Kayıp tabanlı bir akışın uzun dönemli verimi, kayıp oranına ve gidiş–dönüş süresine bağlıdır. Testere dişi biçimli pencere davranışının ortalaması alınarak şu yaklaşım elde edilir:

$$\text{verim} \approx \frac{\text{MSS}}{\text{RTT}} \cdot \sqrt{\frac{3}{2p}}$$

import math

MSS = 1460
for p in (1e-2, 1e-3, 1e-4, 1e-5, 1e-6):
    v = MSS * math.sqrt(1.5) / (0.100 * math.sqrt(p))
    print(f"p={p:.0e} -> {v * 8 / 1e6:8.2f} Mb/s")

p=1e-02 ->     1.43 Mb/s
p=1e-03 ->     4.52 Mb/s
p=1e-04 ->    14.31 Mb/s
p=1e-05 ->    45.24 Mb/s
p=1e-06 ->   143.05 Mb/s

İki sonuç okunur. Birincisi, verim kayıp oranının kareköküyle ters orantılıdır: kaybı yüz kat azaltmak verimi yalnızca on kat artırır. İkincisi, verim gidiş–dönüş süresiyle ters orantılıdır — uzak bir sunucudan aynı kayıp oranında daha düşük verim alınır.

Bu ilişki, aynı yolu paylaşan iki akıştan gecikmesi düşük olanın daha çok pay almasını da açıklar. Kısa gidiş–dönüş süresi, penceresini daha sık artırma fırsatı verir.

Formül bir yaklaşımdır ve sınırları vardır: yalnızca kayıp tabanlı davranış için, uzun süreli ve kararlı akışlarda geçerlidir. Kısa aktarımlar çoğunlukla yavaş başlangıç evresini bile bitiremez.

Arabellek Şişkinliği

Yönlendirici arabelleklerinin büyük tutulması, paket kaybını azaltır ama kuyruk gecikmesini artırır. Denetim algoritması kaybı bekliyorsa, arabellek dolana kadar hızını artırmaya devam eder; sonuçta kayıp azalmış, gecikme artmıştır. Bu duruma arabellek şişkinliği (bufferbloat) denir.

Belirtisi tanıdıktır: büyük bir aktarım sürerken aynı bağlantı üzerindeki etkileşimli kullanımın yanıt süresi belirgin biçimde uzar. Nedeni kapasite yetersizliği değil, sıradaki paketlerin dolu bir kuyruğun arkasında beklemesidir.

Karşı önlem arabellek küçültmek değil, kuyruğu etkin biçimde yönetmektir: kuyruk beklemesi bir eşiği aştığında paketleri erkenden atmak veya işaretlemek. Böylece gönderene sinyal, kuyruk tamamen dolmadan verilir.

Adalet

Aynı darboğazı paylaşan akışların kapasiteyi nasıl bölüştüğü ayrı bir ölçüttür. AIMD, eşit gidiş–dönüş süreli akışlar arasında dengeye yakınsar. Süreler farklıysa denge bozulur; kısa süreli akış daha çok pay alır.

Bir uygulamanın çok sayıda eşzamanlı bağlantı açması da payını artırır: her bağlantı ayrı bir AIMD döngüsü çalıştırır. Bu, tıkanıklık denetiminin bir uygulama tarafından aşılmasının en yalın yoludur ve tek bir bağlantı üzerinde çoğullama yapan uygulama protokollerinin tasarım gerekçelerinden biridir.

Özet

• Tıkanıklık, bir bağlantıya gelen trafiğin kapasitesini aşmasıdır; denetimsiz bırakıldığında yeniden iletimler yükü artırarak çöküşe yol açar.
• Gönderen iki pencere tutar; onaysız gönderilebilecek miktar tıkanıklık ve alma pencerelerinin küçüğüdür.
• Yavaş başlangıçta pencere her turda ikiye katlanır; eşikten sonra turda bir MSS artar ve kayıpta çarpımsal olarak azalır.
• 1 Gb/s ve 100 ms’lik bir yolda kapasiteye üstel evrede 1,4 saniyede ulaşılır, doğrusal evrede yarıdan tırmanmak 428 saniye sürer.
• Kayıp tabanlı verim $\text{MSS}/\text{RTT} \cdot \sqrt{3/2p}$ ile yaklaşık verilir; verim kayıp oranının kareköküyle ve gidiş–dönüş süresiyle ters orantılıdır.
• Zaman aşımı yavaş başlangıca döndürür, üç yinelenen onay yalnızca pencereyi yarıya indirir; büyük arabellekler kaybı azaltıp gecikmeyi artırır.

Sonraki Adım

TCP’nin sunduğu güvenceler ücretsiz değildir: el sıkışma bir tur, kayıp durumunda yeniden iletim ek turlar, sıralı teslim ise bekleme getirir. Her uygulama bu bedeli ödemek zorunda değildir. Sonraki ders, hiçbir güvence vermeyen taşıma protokolünü ve bu yalınlığın hangi uygulamalarda doğru seçim olduğunu ele alacak.