Taşıma katmanı II: akış kontrolü, tıkanıklık kontrolü ve RTT tahmini

Geçen hafta TCP’nin segmentleri nasıl numaraladığını gördük. Bu hafta ne kadar hızlı gönderdiğini konuşuyoruz. İki ayrı fren var: alıcıyı boğmamak için akış kontrolü (flow control) ve ağı boğmamak için tıkanıklık kontrolü (congestion control). Sınavda neredeyse her zaman tur tur cwnd tablosu ve bir timeout hesabı çıkar. Altın kurallar:

1. Gönderen pencere = min(cwnd, rwnd). Biri alıcıdan, biri ağdan gelir.
2. Slow start ikiye katlar, congestion avoidance 1 ekler. Geçiş noktası ssthresh.
3. Kayıpta ssthresh = cwnd / 2. Her iki sürümde, her iki kayıp türünde.
4. Timeout’ta cwnd = 1. Tahoe üç tekrar ACK’de de 1’e iner; Reno ssthresh + 3’e iner.
5. Timeout = EstimatedRTT + 4 · DevRTT.

Akış kontrolü (flow control)

Alıcının bir tamponu (RcvBuffer) var. Ağdan gelen baytlar buraya yazılır, uygulama okudukça boşalır. Uygulama yavaş okursa tampon dolar ve yeni gelenler kaybolur. TCP bunu önlemek için her segmentin başlığında boş yer miktarını, receive window (rwnd) alanını gönderir:

$\text{rwnd} = \text{RcvBuffer} - (\text{LastByteRcvd} - \text{LastByteRead})$

Gönderen de yolda olan veriyi bu değerin altında tutar:

$\text{LastByteSent} - \text{LastByteAcked} \le \min(\text{cwnd}, \text{rwnd})$

Çözümlü örnek: RcvBuffer = 20000 bayt, LastByteRcvd = 15000, LastByteRead = 9000.

tamponda okunmamış veri = 15000 − 9000 = 6000 bayt
rwnd = 20000 − 6000 = 14000 bayt

TUZAK · rwnd = 0 kilitlenmesi. Alıcı rwnd = 0 dediyse ve gönderecek verisi yoksa yeni rwnd bildirmez. Gönderen sonsuza kadar bekleyebilir. Bu yüzden gönderen, pencere sıfırken 1 baytlık deneme (zero window probe) segmentleri yollar.

Pencere aynı zamanda hız sınırıdır: her RTT’de en fazla bir pencere dolusu veri gönderilir. Window scaling olmadan rwnd en fazla 65535 bayttır, RTT 50 ms ise hız en fazla $65535 \cdot 8 / 0.05 \approx 10.49$ Mbps.

Tıkanıklık kontrolü: cwnd ve ssthresh

Ağ ortasındaki yönlendiricilerin kuyrukları dolunca paket düşer. TCP ağdan açık bir sinyal almaz (klasik TCP, uçtan uca yaklaşım). Kaybı tıkanıklık işareti sayar ve gönderen taraftaki tıkanıklık penceresini (congestion window, cwnd) ayarlar. Hız yaklaşık $\text{cwnd} / RTT$ olur.

Üç evre var:

Kayıp tepkileri:

Üç tekrar ACK gelince gönderen timeout’u beklemeden eksik segmenti hemen yeniden gönderir. Buna hızlı yeniden gönderim (fast retransmit) denir. Neden üç? Bir ya da iki tekrar ACK, sadece sıra karışmasından da gelebilir.

Çözümlü örnek (fast retransmit): gönderen 1’den 6’ya kadar segment yolluyor, 2 numaralı segment kayboluyor. Segment 1 gelince alıcı segment 2’yi istediğini bildirir. Segment 3, 4 ve 5 geldikçe aynı ACK üç kez tekrarlanır:

gelen seg   ACK (beklenen)   gönderende tekrar sayısı
1           2                -
3           2                1. tekrar
4           2                2. tekrar
5           2                3. tekrar → seg 2 hemen yeniden gönderilir

Segment 6’nın gelmesini ya da zamanlayıcının dolmasını beklemeye gerek kalmaz. Kayıp yaklaşık bir RTT içinde onarılır.

AIMD (additive increase, multiplicative decrease): kayıp yokken doğrusal artış, kayıpta yarıya bölme. Aynı darboğazı paylaşan iki AIMD bağlantısı zamanla eşit paya yaklaşır. Bu, TCP’nin adalet (fairness) özelliğidir.

İPUCU · tablo kuralı. Bu sayfada izler tur (RTT) başına yazılır. Slow start’ta cwnd’yi ikiye katlarken ssthresh’i aşarsan ssthresh’te durdururuz: cwnd = min(2·cwnd, ssthresh). Bazı hocalar Reno’da +3’ü atıp cwnd = ssthresh yazar. Sınavda sorunun kuralını oku.

Çözümlü örnek: Tahoe ve Reno izi

Başlangıç: cwnd = 1 MSS, ssthresh = 8 MSS. 12. turun sonunda üç tekrar ACK görülüyor.

tur   :   1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20
Tahoe :   1  2  4  8  9 10 11 12 13 14 15 16  1  2  4  8  9 10 11 12
Reno  :   1  2  4  8  9 10 11 12 13 14 15 16 11 12 13 14 15 16 17 18
ssth  :   8  8  8  8  8  8  8  8  8  8  8  8  8  8  8  8  8  8  8  8

Adım adım:

• Tur 1-4: slow start, 1 → 8. Tur 4’te cwnd = ssthresh = 8, artık congestion avoidance.
• Tur 5-12: her tur +1, 9 → 16.
• Tur 12 sonu üç tekrar ACK: ssthresh = 16 / 2 = 8 (aynı kaldı).
• Tahoe: cwnd = 1, yeniden slow start: 1, 2, 4, 8 (tur 13-16), sonra 9, 10, 11, 12.
• Reno: cwnd = 8 + 3 = 11 (tur 13), sonra doğrusal: 12, 13, … 18.

Sekiz tur sonra Reno 18’de, Tahoe 12’de. Fast recovery’nin kazancı bu.

Soruların sorduğu tipik şeyler: “Hangi turlarda slow start?” (cwnd < ssthresh olan turlar), “Kayıp tespiti üç tekrar ACK mi timeout mu?” (cwnd 1’e düşüyorsa ve Reno ise timeout; yarıya iniyorsa üç tekrar ACK), “n. turda ssthresh kaç?” (son kayıptaki cwnd’nin yarısı).

Ortalama TCP hızı

Congestion avoidance’ta pencere kayıp anındaki W değerine kadar çıkar, yarıya iner, tekrar çıkar. Testere dişinin ortalaması $\frac{3}{4}W$:

$\text{ortalama hız} \approx \frac{0.75 \cdot W}{RTT}$

Çözümlü örnek: W = 40 segment, MSS = 1500 bayt, RTT = 100 ms.

W = 40 × 1500 × 8 = 480000 bit
0.75 × 480000 / 0.1 s = 3600000 bit/s = 3.6 Mbps

RTT tahmini ve timeout

Timeout çok kısa olursa gereksiz yeniden gönderim, çok uzun olursa kayba geç tepki olur. TCP ölçülen gidiş dönüş sürelerini (SampleRTT) üstel ağırlıklı hareketli ortalama (EWMA) ile yumuşatır:

$\text{EstimatedRTT} = (1-\alpha)\,\text{EstimatedRTT} + \alpha\,\text{SampleRTT}, \quad \alpha = 0.125$

$\text{DevRTT} = (1-\beta)\,\text{DevRTT} + \beta\,\lvert \text{SampleRTT} - \text{EstimatedRTT} \rvert, \quad \beta = 0.25$

$\text{TimeoutInterval} = \text{EstimatedRTT} + 4\cdot\text{DevRTT}$

Çözümlü örnek: EstimatedRTT = 100 ms, DevRTT = 10 ms, yeni SampleRTT = 140 ms.

Est     = 0.875 × 100 + 0.125 × 140 = 87.5 + 17.5 = 105 ms
Dev     = 0.75 × 10 + 0.25 × |140 − 105| = 7.5 + 8.75 = 16.25 ms
Timeout = 105 + 4 × 16.25 = 170 ms

TUZAK · güncelleme sırası. Ders kitabındaki sıra: önce EstimatedRTT, sonra DevRTT yeni Est ile. RFC 6298 ise DevRTT’yi eski Est ile önce günceller: Dev = 0.75·10 + 0.25·|140 − 100| = 17.5, Timeout = 175 ms. Soru sırayı belirtmiyorsa kitaptaki sırayı kullan ve yazdığın sırayı belirt.

Birden fazla örnek gelirse aynı adımı zincirle. Est = 80, Dev = 8 ile başlayıp 120, 60, 96 ms örnekleri:

örnek   EstimatedRTT   DevRTT       Timeout
120     85             14.75        144
60      81.875         16.53125     148
96      83.640625      15.48828125  145.59375

Tek büyük örnek (120) Est’i sadece 5 ms oynatır ama Dev’i hemen büyütür. Timeout’u asıl koruyan Dev terimidir.

Ek iki kural:

• Karn algoritması: yeniden gönderilmiş bir segmentin ACK’inden SampleRTT alınmaz, çünkü ACK’in hangi kopyaya ait olduğu belli değildir.
• Exponential backoff: timeout olunca bir sonraki timeout ikiye katlanır (1.25 s → 2.5 s → 5 s). Yeni ACK gelince formüle dönülür.

Sık yapılan hatalar