컴퓨터 네트워크 16일차 : TCP congestion control

15일차는 소켓프로그래밍 과제 리뷰였기 때문에,

비공개 상태로 저만 볼 수 있게 올렸습니다 ^^

16일차 드디어 네트워크 레이어에 대해

공부 시작했습니다~!

 

---

1. congestion control

flow control은 리시버가 받을 수 있는 속도만큼만 보내자라는 원리였습니다. 네트워크 상태 상관없이 upper bound를 결정해주는 요소였습니다. congestion control은 네트워크가 감당할 수 있는 만큼 윈도우 사이즈를 결정하는 알고리즘 입니다.

 

 

1-1. congestion control이 왜 필요할까요?

네트워크가 congestion이 심하다는 것은 네트워크가 막힌다는 뜻 입니다. 막히게 되었을 때 전조증상으로 알 수 있는 것은 packet loss가 많이 발생할 것이고, delay가 크게 증가할 것 입니다. 네트워크는 막힘으로 인해 발생하는 현상으로 인해 "네트워크가 막혔다"라는 것을 알게 됩니다.

 

*네트워크 막힐 때 전조 증상 : packet loss & delay

 

패킷이 라우터에 들어오는 것은 arrival rate라고 합니다. 패킷이 도착하는 속도가 링크로 내보내는 속도보다 많으면, 패킷이 쌓이게 되는 데 이것을 queuing이라고 했습니다. 메모리는 유한하기 때문에 꽉 차버리면, 그 이후에 패킷들은 drop이 되게 됩니다. 이를 packet loss라고 합니다. 버퍼에 기록된 애들은 자신들의 차례가 올 때까지 계속 기다려야하는 데 이것을 queuing delay라고 합니다.

 

 

 

 

Link bandwidth R과 하나의 패킷의 사이즈랑 packet arrival rate를 뜻한게 일시적으로 라우터에 들어오는 bit rate라고 할 수 있습니다.

LXa는 링크로 유입된 양입니다.

이 링크로 내보내는 양은 R입니다.

이 두 개의 비율을 traffic intensity라고 합니다. (LXa/R) 즉, 나가는 비율로 들어오는 비율을 나눈 것 입니다.

 

이 traffic intensity가 1보다 크다면, 들어오는 게 더 많다는 겁니다. 이렇게 되면 queuing이 계속해서 증가할 수 밖에 없는 구조가 되는 것이죠. 큐가 누적되다보면 delay가 늘어날 것이고, 어느 순간에는 loss까지 발생할 수가 있는 겁니다.

 

가능한 traffic intensity는 1 이하로 유지되게 하는 것이 중요합니다. 그럼 안정적인 네트워크가 형성 될 것 입니다. 이는 congestion control에 목적이 되기도 합니다.

 

 

1-2. congestion control, 혼잡제어

flow control과는 목적이 전혀 다릅니다. 둘 모두 윈도우 사이즈를 결정하는 데 영향을 미치긴 합니다. 하지만 목적은 다릅니다.

 

flow control의 목적은 수신단까지 잘 왔는데 거기서 발생하는 로스를 막기 위해 수신자가 transport layer에서 application layer까지 올리는 속도보다는 좀 느리게 보낼 필요가 있습니다. 결국엔 리시버 단에서 오버플로우를 막기위함입니다.

 

congestion control은 네트워크 단에서 Loss를 줄이는 것이 목적입니다.

 

 

2. congestion control 시나리오

 

2-1. congestion control 시나리오1 : packet loss, retransmission 안일어난다.

라우터 버퍼가 무한대이기 때문에 packet loss는 일어나지 않는다는 것이 시나리오 1 입니다. 플러스로 retransmission도 발생하지 않는다고 가정해보겠습니다. output link capacity가 R일 때, 두 host는 R/2씩 자원을 link(자원)을 나눠서 사용합니다.

이 상황에서 host들이 데이터를 보내는데, 데이터 보내는 애플리케이션 레이어의 데이터 속도는 람다 in이라고 하겠습니다.

수신단에서 받는 애플리케이션 레이어의 데이터 속도는 람다 out이라고 하겠습니다.

 

host A,B에서 발생하는 람다 in을 R/2보다 적게 발생을 시킨다면 어떻게 될까요?

내가 람다 in만큼 보내면, 람다 out도 람다 in 만큼 일할 겁니다. 그래서 R/2까지는 리니어하게 증가하는 그래프를 볼 수 있습니다. (기울기 1) 근데, 람다 In이 R/2를 넘어가는 순간 네트워크의 지연만 증가시킬 뿐 수신단이 받는 데이터 rate는 R/2에 수렴되서 더이상 못올라가게 됩니다. 가용한 네트워크 자원 이상으로 자원을 발생시키면 얻는건 없고 실만 늘어납니다.

오른쪽 그래프를 보면, 람다 in이 R/2이 늘어나면서 delay가 늘어나는 것을 볼 수 있습니다. 이게 실이겠죠.

 

GO-BACK-N도 이와 같습니다. 파이프라인(N)을 키우면 키울수록 utilization이 올라간다라는 것을 배웠습니다. 하지만 N을 키우는데도 조건이 있었으니 가용한 것 이상으로 키우게 되면 다음과 같이 throughput을 올릴 수 없고 네트워크 지연만 발생시키는 지점이 존재합니다.

 

아주 쉽게 생각하면, '네트워크 자원만큼만 보내면 되겠네요'라고 생각할 수 있습니다. 하지만 이는 간단한 문제가 아닙니다. 네트워크에 가용한 자원이 몇 인지를 알 수 없기 때문입니다. 그에 맞게 N을 결정하는 것은 더욱 어려운 일이겠죠.

 

 

2-2. congestion control 시나리오2-1 : packet loss, retransmission 일어난다. + 트랜스포트 레이어 사이즈가 커진다?!

라우터 버퍼가 이제는 유한하다고 가정해보겠습니다. 즉, packet loss가 발생한다는 의미입니다. loss가 발생하면, sender에선 이에 대해 재전송을 발생시킬 겁니다. 이는 또한 람다 in과 람다 out이 같게된다는 의미입니다.

 

하지만 transport layer input(람다')은 실제 애플리케이션 레이어의 rate보다 항상 크거나 같습니다. 재전송을 해서 중복 데이터가 발생하기 때문입니다. 어플리케이션 레이어가 100이라고 한다면 트랜스포트 레이어는 120~130이 될 수 있다는 것입니다.

이 경우에 sender는 라우터 버퍼가 가용할 때만 전송한다고 가정하겠습니다. 즉 라우터 버퍼가 여유가 있다는 것을 알고 보낸다는 것 입니다. 그러면 packet loss는 발생 안할 겁니다. 또한 재전송도 안생기게 됩니다. 이때는 람다in=람다in'=람다out이 됩니다.

위 그림에서 람다in'가 데이터를 카피하는 이유는 재전송을 대비하기 위함입니다. 트랜스포트 레이어에서는 ack을 받기 전엔 항상 복사를 해둡니다. ack을 못받으면 loss되는데, 그때 재전송을 위해 다시 어플리케이션에서 읽어들이는 게 아니라 트랜스포트 레이어에서 재전송 합니다.

 

 

2-3. congestion control 시나리오2-2 : packet loss, retransmission 일어난다. + 트랜스포트 레이어 사이즈가 커진다?!

실제로는 버퍼가 없을 때도 보내게 됩니다. packet loss가 나면 sender는 loss가 났다고 판단하고 재전송을 해줍니다. 이때는 애플리케이션 레이어의 람다 in보다 트랜스포트 레이어의 람다' in가 더 커지게 됩니다. (람다 in<람다'in)

 

트랜스포트 레이어에서 보낸 양이랑 람다 out은 같아지기 때문에, 람다'in과 람다 out은 같아집니다. (람다'in=람다out)

근데, 람다in<람다'in이므로, 람다 out은 실제 오리지널 어플리케이션 데이터 레이트보다 작아지는 겁니다. 왜냐하면 네트워크 레이어에서 발생한 양만큼만 수신단에 갈 수가 있는데, 이 네트워크에 발생한 데이터가 어플리케이션 레이어 데이터보다 재전송을 파악하고 있으므로 결국에는 실제 어플리케이션 데이터가 다 못갑니다. 

때문에 시나리오 1에서는 리니어하게 갔지만, 시나리오 2에서는 재전송이 포함되기 때문에 람다 out이 R/2을 달성하는 게 아니라 R/2보다 더 적은 양은 달성하게 됩니다. 재전송데이터는 사실상 중복 데이터이기 때문입니다. (내 의견 : 재전송이 있기 때문에 R/2에 가기 전에 네트워크 지연이 발생하게 되는 것 입니다.)

 

람다' in는 트랜스포트 레이어이기 때문에 트랜스미션 레이어에서 실제로 R/2만큼 보낸다고하면, 수신단의 어플리케이션 레이어는 그것보다 더 작은 레이트가 발생된다고 보면 됩니다. 더 안좋아지는 것이죠.

 

실제론 이것보다 더 안좋은 것이 있습니다. packet은 항상 버퍼가 꽉 찼을 때만 loss가 되지 않습니다. 라우터에서 drop은 발생하지 않았지만 queuing delay가 클 수 있습니다. 송신자는 라우터에서 drop이 생겼는지, 큐잉인지 알 방법은 없기 때문에 타임아웃 터지면, loss라고 판단합니다. 결국엔 실제 라우터에서 drop이 나지 않았더라고 큐잉 딜레이가 커지면 송신자는 loss라고 간주할 수 있습니다.

이거 역시도 중복데이터 입니다. 중복데이터는 어플리케이션의 throughput을 감소시킵니다. 이는 congestion에 대한 비용이 될 겁니다.

 

2-4. goodput

어플리케이션에서 발생하는 rate를 어려운 말로 goodput이라고도 합니다.

sender가 receiver한테 a(bps)로 데이터를 보내고, 재전송으로 b(bps)를 보냈다하면, throughput은 a+b라고 합니다. 즉, 물리적으로 데이터를 얼마만큼 받았냐를 뜻합니다.

 

하지만, 재전송한 b는 의미있는 데이터는 아닙니다. 실제 의미있는 데이터는 a인 것이죠. 따라서 goodput은 a입니다. 즉, 의미있는 데이터 레이트를 측정합니다.

 

즉, congestion이 가중되면 어플리케이션에서 수신되는 data rate, goodput이 나빠진다는 겁니다.

 

 

2-5. congestion control 시나리오3 : multi-hop

지금까지는 하나의 라우터를 기준으로 했지만, 실제 우리는 멀티hop 즉, 여러개의 라우터로 이루어진 인터넷을 사용하죠.

 

그리고 이 멀티 홉 중 하나라도 congestion이 발생하면, goodput 감소가 있을 수 있습니다.

위 그래프는 우리가 사용하고 있는 실제 네트워크 상황입니다. R/2에 도달하기 훨씬 전부터 goodput이 나빠지고 있죠.

 

 

여담으로 congstion control은 tcp 프로토콜 만들어진 이후에 만들어져 발전되고 있다고 합니다.

 

 

3. TCP congestion control

3-1. 역사

TCP/IP 프로토콜 스택은 1980년대 만들어졌습니다. 그래서 이 프로토콜이 인터넷에 적용되면서 congestion 문제로부터 진통을 겪기 시작했습니다.

 

첫 번째로는 "host가 데이터를 보낼 때 리시브 윈도우가 허용한 범위 내에서 보내야한다"라는 문제가 발생했습니다. flow control로 쉽게 해결이 되었습니다.

 

두 번째로는 "congestion이 발생하지 않게 데이터를 보낼 수 있는 방법을 어떻게 연구할 것이냐"라는 문제가 발생했습니다. 이로 인해 생긴 것이 congestion control이라는 겁니다. 해당 기술은 Van Jacobson이라는 사람에 의해서 소개가 되었습니다.

 

이 때부터 초석이 만들어진 congestion 알고리즘은 현재까지 발전되어오며 리눅스에서는 TCP 큐빅이라는 알고리즘으로 쓰이고 있습니다. TCP 큐빅은 꽤 최근에 만들어진 프로토콜로 한국사람이 만들었습니다.

 

 

3-2. 네트워크 capacity 파악하는 방법 : ACK

TCP congestion 알고리즘은 end to end congestion 알고리즘이고, sender가 네트워크 capacity를 파악할 필요가 있습니다. 그래야 그것에 맞게 윈도우 사이즈를 조정할 수 있기 때문입니다. '네트워크 capacity를 어떻게 파악을 할까'는 TCP congestion 알고리즘의 핵심적인 부분입니다. 만약 네트워크 capacity가 어느정도 가늠이 된다하면 그것에 맞게 sending 속도를 조절해야합니다.

 

congestion이 별로 없다면 속도를 늘리고, congestion이 있다면 속도를 낮추면 되겠죠. 이게 아주 기본적인 아이디어 입니다.

 

그렇다면 네트워크 capacity는 어떻게 알 수 있을까요?

직접적으로 알 수 있는 것은 아니지만 간접적으로 알 수 있는 정보가 있습니다.

바로 ACK입니다. 유일하게 ACK정보만 가지고 네트워크 capacity를 가늠합니다.

 

ACK이 잘온다는 소리는 loss가 발생하진 않는다는 말입니다. 이 때는 전송속도를 좀 높여도 되겠죠.

근데, ACK이 잘 못오고, 타임아웃이 터진다면 congestion이 발생하기 시작했다는 뜻입니다. 이 때는 전송속도를 낮출 필요가 있습니다. 낮추지 않으면 더 큰 피해를 입을 수 있기 때문입니다.

 

 

3-2. TCP congestion control Question

 

Q1. sender가 어떻게 전송속도를 limit할 수 있을까요?

A1. 전송속도를 높이고 낮추는 변수는 윈도우 사이즈 입니다. 윈도우 사이즈를 키우면 전송속도가 빨라지고, 줄이면 전송속도는 느려질 겁니다.

cwnd는 congestion window를 말합니다. 이는 GO-BACK-N에서 N이라고 생각하면 됩니다. 즉, cwnd는 ack을 안받은 상태에서 보낼 수 있는 데이터 양을 말합니다. 노란색은 이미 보낸 것이고, ack은 아직 못받은 것 입니다. 이 상태에서 추가적으로 보낼 수 있는 데이터는 파란색 영역입니다.

 

ack 하나 받고 보내고 하는 방식은 시간이 너무 오래 걸립니다. 그래서 ack과 데이터를 줄줄이 보내고 받는 형식을 택했죠. cwnd를 굉장히 크게하면 속도를 빠르게 할 수 있고, 굉장히 작게하면 느리게 보낼 수 있는 효과가 오는 겁니다.

 

last byte sent : 가장 마지막에 보낸 것

last byte ACKed : 액 받은 것 중에 가장 오래된 것

이 두 개의 차이는 항상 cwnd보다 같거나 작아야 합니다. (last byte sent-last byte ACKed <= cwnd)

즉, cwnd는 네트워크 congestion에 대한 dynamic function입니다.

 

우리는 이 cwnd가지고, 대략적인 전송 속도를 계산할 수 있습니다. 만약 cwnd byte만큼 데이터를 흘려보낸다면, 그 후에 ack이 올 때까지 데이터를 못보냅니다. 보낸 다음에 ack을 받을 때 까지 시간은 RTT입니다.

대략적인 전송 속도는 RTT동안에 cwnd만큼 데이터를 보낸 것입니다. 즉, cwnd/RTT가 대략적으로 달성되는 throughput입니다.

 

실제 대략적인 전송송도는 MIN(flow control window, congestion window)에 따라 결정되고 있습니다.

만약 네트워크 상황이 너무 좋아 congestion control이 1000이라면 리시버가 성능이 나빠서 트랜스포트 레이어에서 애플리케이션 레이어로 올리는 속도가 느려서 남은 버퍼 양이 100이라고 합시다. 이러면 최종 데이터는 100으로 보내야 할 겁니다.

반대로 수신자의 디바이스는 10000정도 여유있을 정도로 문제가 없고, 네트워크가 10정도로 굉장히 느리다면 10으로 보내야 합니다.

 

 

Q2. 어떻게 sender는 sender와 목적지 사이에 congestion이 있다는 것을 알까요?

A2. 타임아웃이 터지면 loss가 나기 때문에 100%는 아니지만, congestion이 생겼다고 최선으로 예측하게 되는 것입니다. 단, 어디서 congestion이 났는지는 데이터를 전송할 때 알 수 없습니다. 네트워크 레이어에서는 congestion 발생에 대한 메세지를 주지 않기 때문에 실제로 어디 라우터에서 congestion이 발생했는지 알 수 없습니다.

 

지금 유일하게 사용하는 피드백은 ACK입니다.

 

congestion이 심해지면 어디 라우터에서인지는 모르지만 overflow가 발생할 겁니다. 이로 인해 패킷이 drop되게 됩니다. 패킷로스를 우리에게 알려주는 단서는 2가지가 있습니다.

 

*네트워크에 loss가 있다고 알려주는 간접정보 2가지

-time out : loss라 간주합니다.

-duplicate ack : time out이 터지기 전에 duplicate ack이 3번 발생하면 loss라 간주하게 됩니다.

 

TCP는 이 두 가지 정보를 가지고 congestion window를 조절하게 됩니다.

 

 

Q3. 어떤 알고리즘이 sender가 send rate를 바꾸는데 쓰일까요?

A3. 만약에 TCP가 너무 빠르게 보내서 congestion이 발생하면, goodput이 아주 나빠집니다.

이 때 만약 TCP가 신중하게 아주 느리게 보낸다고 가정해봅시다. 그럼 congestion이 발생할 일은 없습니다. 하지만 여전히 goodput이 나쁩니다. 왜냐하면 너무 느리게 보냈기 때문입니다.

 

결국엔 그래프의 가장 높은 지점을 달성하면 좋은 성능을 달성할 수 있을 것 입니다. 여기를 달성하기 위해 윈도우 사이즈를 잘 조절해보자라는 겁니다. 

 

 

3-3. TCP congestion control 원리

 

계속 반복되지만, TCP의 대원칙은 lost segment는 결국 congestion을 암시하고, TCP는 sending rate를 줄여줘야 합니다. 그리고 ack이 잘 오고 있다는 것은 네트워크가 견딜만 하다는 것을 의미하고, 그 때는 공격적으로 데이터를 늘려도 됩니다.

 

TCP는 톱날같은 움직임으로 전송제어를 한다고 합니다. 네트워크 상황이 굉장히 다이나믹하기 때문에 continuous하게 제어하지 않고, 동적으로 제어를 해서 마치 움직이는 모습이 톱니바퀴와 같다해서 브루트포스 방식이라고 합니다.

 

*TCP 알고리즘의 핵심

TCP sender가 ack을 잘 받으면 계속 윈도우 사이즈를 증가시킵니다. 그리고 언제까지 증가시키냐면 loss가 발생할 때 까지 증가시킵니다. 문제가 터지기 전에는 네트워크가 얼마나 여유있는지 알 턱이 없기 때문입니다. loss 발생할 때까지 윈도우 사이즈를 증가시키다가 loss가 발생하면, 빠르게 수습합니다. 이것이 바로 TCP 알고리즘의 핵심입니다. (위의 그래프가 브루트포스 방식으로 나타나는 이유겠네요)

 

 

3-4. TCP congestion control 알고리즘

TCP congestion control 알고리즘은 2가지 파라미터에 의해서 운영됩니다.

 

1) congestion window (cwnd)

2) Slow-start threshold Value (ssthresh)

 

먼저 slow-start 구간에 대해서 알아보도록 하겠습니다.

운전을 할 때 엑셀을 밟으면, 차의 속도가 확 올라가는데요. 어느 정도 속도가 올라가면 엑셀에 힘을 덜 줘야겠죠. 어느 정도 임계치가 있을 겁니다. 그게 바로 slow-start 구간입니다.

 

우리는 네트워크 상황을 모르기 때문에 처음부터 크게 윈도우 사이즈를 주면 안됩니다. 때문에 작은 윈도우 사이즈로 시작합니다. 하지만 작게 시작하면 문제는 속도가 너무 느리다는 겁니다. 그래서 작게 시작하지만, 굉장히 급격하게 크기를 늘립니다. (exponential하게~)

slow-start threshold 값이 될 때까지 크기를 올릴 겁니다. 

 

이 slow-start threshold 값의 의미는 이제부터 조금 조심하는 게 좋겠다 라는 의미입니다. congestion이 발생할지도 모르는 위험구간이라는 뜻입니다. 하지만, slow-start threshold 값에 와도 congestion이 발생하지 않아서 늘리긴 늘립니다. 이때부턴 굉장히 천천히 늘린다는 것이 포인트에요.

 

slow-start threshold를 넘어가는 구간을 우리는 congestion avoidance 구간(혼잡회피구간)이라고 합니다. 즉, 이 구간에서는 혼잡을 늦추기 위해 천천히 윈도우 사이즈를 늘려보는 구간이라고 할 수 있겠네요.

 

slow-start 구간은 매 RTT마다 2배 증가시킵니다. 처음에 congestion window를 1MSS라고 한다면, 1번 메세지 즉 세그먼트 1개를 보내면 ack 받고, 그 다음 윈도우 사이즈를 2배로 늘립니다. 그럼 2개의 segment를 보낼 수 있고, ack을 2개 받을 수 있는 겁니다. 그 다음엔 2배 더 늘려 4개의 segment를 보내고, 4개의 ack을 받을 수 있게 됩니다. 그 다음에는 8개, 16개로 늘려나가게 됩니다.

 

cwnd는 ack을 받을 때 마다 1개씩 증가시키면 됩니다. 수도코드를 보면 이 부분이 제일 이해하기 어렵다고 해요.

segment 1개일 때 ack을 받고, 1개 증가시키면 n은 2개가 됩니다. 또 segment 2개를 보내고 ack 1개씩 들어올 때마다 n을 늘리면 4개가 되겠죠. 한 번 더! segment 4개를 보내고 ack을 받을 때마다 1씩 늘려주면 n은 8개가 되는 겁니다 ㅎㅎ

 

n = 1

1 -> 1+1

총2개

 

n=2

1->1+1

1->1+1

총 4개

 

n=4

1->1+1

1->1+1

1->1+1

1->1+1

총 8개

 

이런 식인 것이죠.

 

 

<congestion avoidance 구간>

이 구간에서 증감율을 어떻게 낮추냐면, ack을 받을 때마다, 1/cwnd씩 증가시키는 겁니다. 이렇게 증가시키다보면,  결국엔 1이 되는 순간이 옵니다.

 

예를 들어 n=4일 때는 다음과 같아요.

ack / 증가율

1 -> 1/4

1 -> 1/4

1 -> 1/4

1 -> 1/4

 

1/4x4 = 1

이처럼 결국엔 1 증가가 되는 것이죠.

 

즉, slow-start 구간에서는 2배씩 증가시키는 것이 목적이고, congestion avoidance 구간에서는 1개씩 증가시키는 게 목적입니다.

 

실제로 congestion avoidance 구간에선 1씩 리니어하게 증가하기 때문에 일직선 그래프가 나오고, slow-start 구간에선 2배씩 증가하기 때문에 exponential한 그래프가 나오는 것을 볼 수 있네요.

 

receiver 윈도우로 초기 셋팅을 하고 loss가 발생할 때까지 늘리다가 loss가 발생하면, 발생하기 직전의 값의 1/2 값으로 slow-start threshold 값으로 설정합니다.

 

+ 처음엔 TCP 알고리즘 이름을 TCP Tahoe라고 지었다고 하네요. 타호가 지명이름이라고 하네요.

 

눈 여겨 보셔야 할 것은 loss가 났을 때 congestion window가 1로 떨어지는 점 입니다. slow-start threshold가 업데이트 되어서 1부터 다시 시작하기 때문인데요. 업데이트는 loss가 난 congestion window의 절반으로 slow-start threshold가 업데이트 됩니다.

 

그래서 처음 시도에는 threshold가 8이었지만, loss가 난 지점이 12였기 때문에 loss 이후에는 이에 절반인 6으로 threshold가 잡히는 것을 확인하실 수 있습니다. 또한 congestion avoidance 기간이 늘어난 것을 볼 수 있네요 : )

 

 

4. TCP congestion control 알고리즘의 개선

 

트랜스포트에서 쓰고 있는 위의 알고리즘은 성능이 별로 좋지가 않아 개선하고자 여러 알고리즘이 나오게 됩니다.

 

 

4-1. TCP Reno : duplicate ack에 의한 Loss의 경우 slow-start 구간 말고, congestion avoidance 구간에서 시작하자!

생각보다 꽤 오랫동안 사용되어 온 알고리즘입니다. 우리는 위에서 timeout이 터지면 congestion window를 1로 보내버리는 것을 확인했습니다. 1로 보내는 것은 너무 utilization이 나쁘다고 평가가 되었습니다. 때문에 1로 보내지 않고 조금 더 위에서 시작할 방법을 찾기 시작하며 나온 알고리즘 입니다.

 

TCP Reno는 만약 time out에 의한 loss가 아니고, duplicate ack에 의한 loss가 발생한다면 1로 시작하지말고, cwnd의 반이 되는 구간을 congestion avoidance 구간으로 시작하자는 겁니다.

 

다시 리마인드하자면 loss가 발생하는 경우는 2가지로 time out(혼잡 심각하다), duplicate ack(비교적 혼잡도가 낮다)에 의해 날 수 있습니다. 때문에 duplicate ack은 심각한 상황이 아니기 때문에 보수적으로 1로 확 낮추지 말고, 절반으로 낮춰서 slow-start 없이 congestion avoidance 구간에서 시작하자는 겁니다. (아래 TCP Reno 부분 참고해주세요)

 

 

FR (Fast Retransmit / Recovery) 

Fast Recovery는 1로 가지 않고, loss 절반으로 바로 이동하는 모습입니다. 1부터하면 느리니 빠르게 복원시키자는 의미에서 해당 TCP Reno 방식을 Fast Recovery 알고리즘으로 이름짓게 되었습니다.

 

 

4-2. TCP Reno : Additive Increase Multiplicative Decrease (AIMD)

TCP가 congestion control을 동작하는 모습을 Additive Increase Multiplicative Decrease (AIMD) 라고 부르기도 합니다.

윈도우 사이즈를 증가시킬 때 산을 오르듯 점진적으로 증가(Additive Increase)시켰습니다. 하지만 낮출 때는 한 방에 확 낮췄습니다.(Multiplicative Decrease)

---

오랜만에 끝맺음 말을 쓰는 것 같네요 ㅎㅋㅋㅋ

드디어 챕터 3가 끝났습니다 (광광)

비록 중간고사는 망쳤지만, 매일 배우는 게 있는 것 같아 뿌듯하네요.

앞으로 있을 팀플도 넘나 두렵습니다!