TCP Congestion control

TCP는 에러컨트롤 플로우컨트롤 컨제스천 컨트롤 3가지의 컨트롤이있음

CONGESTION CONTROL이란 CWND값을 결정하는 과정임 

첫번째는 네트워크 컨제스천을 감지해야함

두번째는 그걸바탕으로CWND계산해야함

버퍼가 꽉차면 전송된 시그널이 없어지는데 이걸 패킷로스라고함. <-이게 문제야! 목적지까지 너무 오래걸리고 심지어 없어짐.

근데 이걸 어캐 감지함???

크게 3가지 솔루션

1. 컨제스천이 발생하면 딜레이가 됨

2. 더 나아가서는 패킷로스가 일어남 

3. 중간에 있는중계기가 능동적으로 컨제스천이 발생한걸 알려줌(Explict Marks) <- 데이터 패킷에 컨제스천 발생했음이라고 쓰는 방법있음!

근데 이 3번 방법은 tcp에서 사용어려움 why? 앤드 투 앤드 프로토콜이기때문 중계기에 tcp가 안올라감

그래서 1 2 번 두개가 가능성이 있는 솔루션임.

그래서 1번으로 만약 패킷로스가 발생하면 컨제스천이다 라고 여기고, cwnd사이즈를 줄여주는 방식으로 할것임.

이게 결론적으로 tcp가 하는 일임! 패킷로스를 감지하면 cwnd를 줄인다.

근데 이 패킷로스를 어캐감지행?? 

쉽게말하면 1001번 패킷을 보냈는데 거기에대한 애크가 안오는 경우 1001번 패킷이 로스됐다고 생각함.

여기서 다시 집어보자면 윈도우는 한번에 보낼수있는 데이터이고 한번에 보낸다는 의미는 리시버에서 애크가 안와도 보낼수있는 최대 데이터의 양!

만약 cwnd의 크기가 1000이라고 치자! 여기서 패킷로스가 발생하면 이때 cwnd값은 뭘로하면 좋을까? TCP는 반으로 쫙줄임 500으로 함.

statistical multiplexing이란? 평균적인 인풋속도가 아웃풋 속도를 넘지 않는다는 평균 개념이 들어간 통계적인 멀티플렉싱이라고 함!

여러개의 인풋이 하나의 아웃풋으로 뭉치는 부분이 있는데 이런 인터넷의 구조상 호스트가 여러군데에서 오는 데이터가 하나로 몰리는 경우가 발생하고 이런 링크가 혼잡을 유발함!(컨제스천) 일시적으로 많아지면 버퍼가 쌓이고 이게 컨제스천이고 심하면 패킷로스가 발생하게됨

일시적인 컨제스천은 버퍼 스페이스를 늘리는 것으로 해결이된다.

그치만! 컨제스천이 길어진다면 소스에서 전송률을 낮춰야하는 상황이 발생한다.

 

이렇게 인풋이 계속 올라가면 아웃풋도 일정한만큼 올라가다가 한계치에 다다르게되면 더이상 올라가지않음 

 

 

여기 보면 컨제스천이 발생하지 않는 상황에서는 인풋rate가 올라가는 만큼 아웃풋도 올라간다 근데 점점 인풋이 더 증가할수록 아웃풋이 증가하는 비율은 점차 줄어들고 결국엔 급격하게 떨어져서 throughput이 0으로간다(0에수렴함 = 네트워크가 망가짐 그래서 저 동그라미 친부분을 왔다갔다하도록 해줘여함) 이때 throughput은 시간당 전송 성공률을 뜻한다

근데 어떻게해야 저수준에서만 왔다갔다함?

첫번째 방법은 end - end congestion control

로스나 딜레이를 관찰한 앤드시스템이 컨제스천을 유추하고 이를바탕으로 인풋속도를 조절하게 함

 

2번째 방법은 네트워크가 적극적으로 개입하는거

중계기가 자기가 컨제스천이 발생하면 그걸 엔드호스트에 적극적으로 알림! 그러면 그얘기를듣고 엔드호스트는 인풋 rate를 낮춰주는데 이방법은 tcp에서 채택하기 어려움 이유는 아까 말했져?

 

TCP에서는 Additive increase라고 하는걸 하는데 이게 뭐냐면 만약에 내가 최초의 cwnd가 500으로 시작했다 근데 내가 데이터를 보내고 애크를받았어 그럼 501로 늘리고 또 데이터를 보냈는데 애크를 받았어 그럼 502로 늘리고 이렇게 애크를 받을때마다 1씩 cwnd를 늘리는게 저거임! 

이렇게 처음에 1로 cwnd를  하면 애크받으면 1씩 늘리면서 해주는게 저거임

근데 만약에 이렇게 올리다가 컨제스천이 발생해서 패킷로스가 일어났다? 그럼 반으로 줄이는 거임 예를들어서 계속 애크받고 그러다보니까 cwnd가 510까지 갔다 근데 패킷로스가 발생했어 그러면 반을 줄여서 cwnd가 255가 되는거임 또 쭉 증가시키다가 로스 발생하면 또 반으로 줄이고 이런식으로 진행함.

이렇게 톱니마냥 진행함

이런식으로 진행하는게 1번 TCP

근데 이방식이 좋을까? 저렇게 CWND값을 올려서 저꼴난건데 반으로 줄이는게 좋은건가?

그래서 2번 TCP를 Tahoe라고 부르는데 얘는 cwnd를 로스가 발생하면 1로 줄임 근데 이러면 컨제스천은 해소가되는데

또 cwnd올리는데에 시간이  오래걸려 1부터 다시 증가해야하니까 그래서 1로 줄이는 대신 문제가없으면 이걸 cwnd사이즈를 빨리 키우자 함그래서 슬로우하게 스타트하지만 이걸 적당히 슬로우하게 해서 1다음에 2 다음에 4다음에 8이런식으로 증가하게함 긍까 애크가 하나오면 1+1해서 2보내고 그럼 애크2개오자나 그러면 2+2해서 다음 4보내고 또 4+4해서 8보내고 이런식으로 증가하게함(exponential growth)

 이 TCP 2번째 버전인 Tahoe는 현재 cwnd값의 2분의1을 threshold라고 저장해두고 그다음에 cwnd는 1로세팅하고 1부터는 저 threshold값 까지 exponential growth방식으로 증가하게 한다.

여기서 3dupACK가 와도 패킷로스라고 보고 또 1로 줄임!

 

TCP 3번인 Reno는 만약에 패킷 로스가 발생하면 현재의 cwnd의 2분의1을 threshold라고 일단 정하고 이 로스가 타임아웃에관한 것이라면 tcp2번 tahoe처럼 처리하고  3dup ACK에 의한 것이라면 1번 TCP처럼 함.

TCP 3번은 이런식으로 동작함! 두개를 상황에따라 다르게 합친것임 ㅎㅎ

 

TCP vegas도 있는데 이건 구현하기 어려워서 아직 구현 안됨 ㅋㅋ