3-6 TCP detecting loss & Fairness & ECN

TCP detecting, reacting to loss

<TCP Tahoe> - 오래된 버전

loss 감지되면 무조건 SS 단계 ( 무조건 바닥까지 떨어짐, 파란색 선처럼)

 

 

<TCP RENO> - 보편화된 방법

loss를 timeout으로 감지 -> SS 단계로

• 아예 꽉 막혀있다고 생각하고 cwnd를 1 MSS로 초기화 후 다시 급격하게 증가시킴
• 그러다가 cwnd가 ssthresh에 도달하면 CA단계로

 

loss를 3 dup ACK으로 감지 -> CA 단계로

• ssthresh = cwnd/2로 설정
• cwnd <- cwnd/2, 즉 cwnd를 반으로 줄임
• 그러면 ssthresh와 cwnd가 일치하기에 선형적으로 증가하는 CA 단계

 

<정리>

TCP의 더 오래된 버전인 TCP Taho에서는 
packet loss가 감지될 때마다 무조건 CWND를 1로 감소시키고 
slow start를 시작했던 것에 반해  

현재 보편적으로 사용되고 있는 TCP Reno에서는 
packet loss를 감지한 case를 
time out에 의한 것과 triple dup. ack.에 의한 것으로 구분해 
time out이라면 CWND를 1로 감소시키고 slow start를 시작하지만 
triple dup. ack.에 의한 것이면 CWND를 반으로 감소시키고 congestion avoidance를 시작한다.

 

P14. Consider the following plot of TCP window size as a function of time.

Assuming TCP Reno is the protocol experiencing the behavior shown above, answer the following questions.

In all cases, you should provide a short discussion justifying your answer.

a.     Identify the intervals of time when TCP slow start is operating.

slow start는 1~6, 23~26에서 일어남 (급격히 증가하는 부분 -2배씩)

b.    Identify the intervals of time when TCP congestion avoidance is operating.

TCP congestion avoidance는 6-16, 23-26에서 일어남 (서서히 증가하는 부분 - 1 MSS만큼)

c.     After the 16th transmission round, is segment loss detected by a triple duplicate ACK or by a timeout?

반으로 줄었으니까  triple duplicate ACK에 의해 packet loss 감지

d.    After the 22nd transmission round, is segment loss detected by a triple duplicate ACK or by a timeout?

반이 아닌 1로 줄었으니깐 timeout에 의해 loss 감지

e.     What is the initial value of ssthresh at the first transmission round?

32. 거기까지 진행한 뒤 CA로 전환됐기 때문

f.      What is the value of ssthresh at the 18th transmission round?

packet loss가 감지될 때마다 ssthesh는 cwnd의 절반으로 설정됨. 고로 42/2 = 21임

g.    What is the value of ssthresh at the 24th transmission round?

26/2=13

h.     Assuming a packet loss is detected after the 26th round by the receipt of a triple duplicate ACK, what will be the values of the congestion window size and of ssthresh?

loss 발생 시 cwnd는 현재 값 8에서 절반으로 감소

따라서 cwnd와 ssthresh는 4로 설정됨

i.      During what transmission round is the 70th segment sent?

Packets 2-3 are sent in the 2nd transmission round.
Packets 4-7 are sent in the 3rd transmission round.
Packets 8-15 are sent in the 4th transmission round.
Packets 16-31 are sent in the 5th transmission round.
Packets 32-63 are sent in the 6th transmission round.
Packets 64-96 are sent in the 7th transmission round. 
Thus packet 70 is sent in the 7th transmission round.

---

 

TCP throughput

TCP throughput에 영향을 미치는 것은 window size

 

throughput은 단위 시간 당 받는 양을 의미하는데

window size에 의해서 각 RTT마다 내보낼 양이 정해지기 때문

 

sending buffer에 데이터가 없다면

보낼 게 없으니 이 경우는 고려하지 않아도 됨

또한 slow start도 일어나지 않고

항상 데이터를 보낸다고 가정해보자

 

W: loss가 발생한 window의 size

average window size = ¾ W

average throughput = RTT 당 ¾ W  = ¾ *( W/RTT)(bytes/sec)

---

TCP future : TCP over “long fat pipe”

최근 TCP 연구결과는 더 빠름

 

ex)

1500 byte segments, 100ms RTT에서

10Gbps throughput 의 pipe의 최대 효율을 보이고 싶을 때

 

이 때는 W=83,333개여야  in-flight segment를 감당

(in-flight 상태란 ack을 받지 않는 상태에서 back to back으로 내보낸 것)

 

만약 83,333개 중 drop이 발생하여 하나가 loss 되면 

TCP sending rate가 반으로 급격히 줄어듦

그러면 long fat pipe를 효율적으로 쓰지 못함

그래서 L: segment loss probability를 낮게 유지할 수 있어야 함

 

그래서 위의 식을 바탕으로 계산해보면

loss rate L이 2*10^(-10)이면 10Gbps throughput을 성취할 수 있음

 

---

TCP Fairness

tcp fairness의 목표

각 end entity의 average rate가 R/K를 가지도록 하는 것

R: bottleneck router capacity R

k: end entity 수

 

Why is TCP fair?

경쟁하는 두 개의 session이 같이 증가(additive increase)한다면 ... ㅠ

 

throughput에 영향을 크게 미치는 것이 window size라고 했으니

throughput을 window size라고 해보자

 

실선의 아래쪽은 under utilization

실선의 위쪽은 over utilization(over buffer)

 

실선의 아랫면에 위치할 때는

equal bandwidth share의 선과 같은 기울기로 증가함

 

어느 시점에 실선을 벗어나면 

multiplicative decrease를 하여 throughput도 decrease

그래서 window size를 반으로 줄임

 

또다시 실선 아래로 오게 되는 additive increase함

이를 반복

 

 

그렇기에 TCP는 근본적으로 fair하다곤 하지만

사실은 이를 방해하는 요소가 있음

 

UDP는 data rate를 유지하기 위해

전혀 network 상황을 고려하지 않고

막무가내로 나가버리니

TCP의 fairness가 ㅠㅠ 지켜질 수 없다 ㅠㅠ

 

 

+)

두 host 간 multiple parallel TCP의 경우에

Rate가 R인 링크에 9개가 달려있는데

또 다른 애가 나와서

1개의 TCP connection을 사용하는 경우

R/10 rate를 갖게 됨

 

그런데 걔가

11개의 TCP connection을 동시에 열면 

11/20  이니 거의 R/2가 되버림

 

 

---

 

ECN: Explicit Congestion Notification

network-assisted congestion control

 

라우터가 자신에게 제한적인 상황이 일어남을 감지하여  

(자신의 buffer가 꽉 찬다든지)

congestion 상황임을,

자신을 거쳐가는 대상들에게 헤더 속에

그 정보를 넣어 알림

(이를 IP datagram의 header에 ToS field에 2bit로 표현) 

(ToS : type of service)

 

그러면 받은 receiver가

sender에게 보낼 ACK에

ECN bit를 담아서 알림

 

IP datagram 속 ECN이 혼잡이 발생한 router를 거칠 때 11로 바꿈

source도 혼잡 여부를 알려면 receiver가 이 사실을

TCP ACK segment 안에 ECE=1로 설정하여 알려줘야 함

 

 

 

일반적으로 TCP/IP 네트워크는 패킷을 삭제하여 정체 신호를 보냅니다.( random early detection )

 ECN이 성공적으로 협상되면

ECN 인식 라우터는 임박한 정체를 알리기 위해 패킷을 삭제하는 대신

IP 헤더에 표시를 설정할 수 있습니다. 

패킷의 수신자는 혼잡 표시를 발신자에게 반향시켜 마치 누락된 패킷을 감지한 것처럼 전송 속도를 줄입니다.

https://en.wikipedia.org/wiki/Explicit_Congestion_Notification