20180418 8 : TCP, Congestion control

window size 를 조절하는 것은, 사실상 속도를 조절하는 것이며 네트워크 상황과 리시버 버퍼의 값에 대해서 이 두개의 내용에 대해서 최소값을 window size 를 결정한다.

어떻게 network condition 에 따라서 어떠한 방식으로 조절하는가에 따른 Congestion control 을 알기.

• Congestion control

• 네트워크의 혼잡 여부를 어떻게 알 것인가?

• 불특정 다수이며 군집의 형태인데 어떻게 알 수 있는가?
  
  

• congestion control 의 원리

• 네트워크 컨제션이 발생하게 되면 두 가지 현상이 발생

• 1) 패킷 유실

• 2) 딜레이가 발생

• 비현실적인 상황 1
• 두 센더가 존재, 두 리시버가 존재
• 두 센더는 데이터를 전송
• 하나의 라우터가 존재하며 무한대의 버퍼, 즉 큐를 소유
• 재 전송은 없다
• 대역폭은 R 이다.
• throughput : 단위시간당 얼마만큼의 데이터가 전달되는가, 즉 처리량을 확인하자.
• 아무리 빠른 속도로 데이터를 보내고, 무한대의 큐를 가지고 있다고 하더라도 처리량의 값에 수렴하게 되면 더 이상의 값을 빠르게 보낼 수 없게 된다.
  
  
  
• 비현실적인 상황 2
• 하나의 라우터가 존재하며, 무한대의 큐를 가지고 있다.
• 센더는 유실된 패킷을 재전송한다.
• 특정 대역폭까지 올라간다면 이후의 네트워크 상황은 나아지지 않는다.
  
  
• 실제 트랜스포트 레이어에서는 패킷 유실이 발생하는데, 이를 해결하기 위해서 재전송을 실시한다. 결과적으로 기존 데이터보다 더 많은 양을 보낸다. 그리고 이로 인해 congestion 이 발생하고 이 결과 패킷 유실이 발생하고 처리량(throughput)은 낮아지는 것이다. 결국 congestion 으로 인해 악순환이 반복되고 본래의 데이터는 제대로 보내지 못한다.
  
  여기서 network congestion 에서 패킷이 유실되지 않았음에도 타임아웃이 되고 또 다시 패킷을 보내게 되므로 congesion 을 더욱 악화시킨다. 
  
  
• Source 에서 Destination 까지 물이 흐른다고 해서 업 스트림이라고 표현한다. 반대는 다운 스트림이라고 표현한다. 업 스트림에서 자원이 소모되면 이후에는 
• 여기서 Congestion 때문에 re-transmition 이 발생
• re-transmition 으로 인해 의미있게 보낸 데이터 량 감소
• 업스트림에서 사용된 자원의 낭비, 다시 Congestion 발생
• 악순환의 반복
  
  
• TCP 의 동작으로 인한 congestion
• 리시버 측으로 ACKs가 안 온 경우, 또 다시 패킷을 보낸다. (유실유무를 모르는 상태) - reliable 이지만 reliable 로 인해서 congestion 이 더욱 더 크게 발생되는 경우
• 지속적인 재전송으로 인해서 reliable 의 특성은 제공하지만 TCP의 동작은 congestion 의 상황은 알지 못한다.
• 예시) 차도의 도로가 정체되어 있음에도 불구하고 도로에 차들이 계속 유입되서 차량정체를 일으키는 것이라고 생각하면 된다.
• 따라서 네트워크 상황을 판단해서 패킷을 전송할지 말지를 결정해야 한다.
  
  
• 네트워크의 상황은 어떻게 판단할 것인가? (TCP congestion control)
• 현재 실질적으로 판단되는 상황 
• 1) end 2 end : 양쪽의 TCP 연결은 맺은 포인트끼리 네트워크 상황을 지레짐작하는 형태.
  
  세그먼트를 전송하면, ACKs가 왔다면 중간에 패킷이 유실되지 않고 제대로 전달되었음을 확인이 가능하다.
  
  세그먼트를 전송하고, ACKs가 오지 안왔다면, 타임아웃이 되었다면 네트워크 상황이 좋지 않았음을 확인이 가능하다.
  
  
• additive increase & multiple decrease
• 윈도우 사이즈만큼 세그먼트를 전송한다.
• 해당 세그먼트에 대한 ACKs가 정상정으로 왔다면, 이후에 보내는 세그먼트의 전송량을 +1 씩 늘려간다. : additive increase, 이후에 계속 전송량을 늘려나가다가 ACKs가 오지 않왔다면 세그먼트 전송량을 절반으로 줄인다. : multiple decrease. 왜냐하면 다른 엔드포인트들 또한 세그먼트를 전송하기 때문에 네트워크 상황이 매우 악화되었음을 암시한다. 그리고 다시 네트워크 상황이 나아지면 다시 늘려나간다. : additive increase 이 과정을 계속해서 반복한다.
  
  최대한 많은 양을 보내주기 위함. 네트워크 상황이 해당 세그먼트 전송량을 버틸 수 있을 만큼 적절한 양으로 보내준다. 최적의 양을 찾아가는 과정.
  
  
• Bottle-Neck 
• 네트워크가 막혀있다면 적절한 대역폭 (Bandwidth) 를 찾는 것이 중요하다.
• congestion window size (=window size)
• 해당 윈도우 사이즈는 네트워크의 상황에 따라서 다이내믹하게 변한다.
  
• TCP의 sending rate 는 어떻게 되는가?
• TCP는 가진 윈도우 사이즈 만큼 데이터를 전송할 수 있다.
• rate = CongWin / RTT 
  
  
• Slow-Start
• 겸손하게 시작한다.
• 하나의 세그먼트만 전송한다.
• ACKs가 잘 도착하면 이후에 하나씩 증가시키면서 ACKs의 도착유무를 확인한다.
• 하나씩 증가한다는 것은 expotential 하게 증가한다는 말.
• 하지만 기하급수적으로 늘릴 수 없기 때문에 임계치(threshold)를 설정해놓는다.
• 임계치만큼 전송 데이터가 올라가면 이후에는 데이터 전송량을 하나씩 증가시킨다.
• X축은 시간이고, Y축은 시간에 따른 윈도우 사이즈를 나타낸다.
• 제일 처음 시작할 때에는 겸손하게 하나를 보내고 이후에 기하급수적으로 증가시킨다. 그리고 임계치를 만나면 하나씩 증가시킨다.
• 위의 그림에서 윈도우 사이즈가 12가 되는 시점에서 문제가 터지고, 패킷 유실이라고 판단된다. 왜냐하면 ACKs가 오지 않아 타임아웃이 되었다거나 3-duplicate packet 이 발생된 경우
• timeout 으로 인한 패킷 유실
  전송한 세그먼트가 네트워크 상황에서 다 유실되고 제대로 전달되지 못한 경우
  예시) 군부대로 따지면 진도개 하나 (매우 위험한 상태)
• 3-duplicate 으로 인한 패킷 유실
  네트워크는 동작하지만, 일부 세그먼트만 전송되지 않은 경우
  예시) 군부대로 따지면 진도개 둘 (조금 위험한 상태)
  
  
• 3-duplicate ACKs 인 경우
• TCP의 초기버전은 TCP Tahoe 그림처럼 일어났다.
• TCP의 이후버전은 TCP Reno 그림처럼 Threshold 을 현재 congestion window size의 절반으로 줄이고 해당 윈도우 사이즈부터 linear 하게 증가시킨다.
• timeout 으로 인한 패킷 유실인 경우
• TCP의 초기버전 TCP Tahoe 그림처럼 일어난다.

- 어느 경우나 slow start threshold 는 congestion 이 일어나는 그 상황에서 절반으로 줄인다. 그렇기 때문에 threshold 이후 값부터는 어떤 문제가 발생될지 모르기 때문에 리니어하게 조심스럽게 데이터를 전송한다.

• TCP Tahoe & TCP Reno 차이알기.

• TCP throughput
  리시버가 단일시간동안 받는 양 혹은 센더가 보낸 데이터의 전송량
  
  
• TCP Fairness
  A라는 유저가 TCP 를 사용, 파일을 보낸다.
  B라는 유저가 TCP 를 사용, 파일을 보낸다.
  
  TCP 에 대한 동작은 독립적으로 수행한다. 이런 상황에서 같은 라우터를 이용한다면, 같은 경로를 사용한다면 해당 bottle neck 의 capacity 가 R이라고 한다면 공평하게 R/2씩 자원을 사용하는가?
  
  capacity R을 각각 얼마만큼 공평하게 나눠가질 것인가.
  
  TCP 는 결과적으로 2/R씩 수렴하도록 만든다. 왜 나누어 가지는가 ?
  
  
• X 축과 Y 축은 합해서 최대 R의 capacity 를 가질 수 밖에 없다.
  
• 패킷 유실이 발생되면 이전 congestion 에 따라서 패킷 전송량을 1/2로 줄이고 이후에 데이터를 전송하고 다시 패킷 유실이 발생되고 1/2로 줄여지며 이 과정을 반복하며 결과적으로 2/R 로 각각의 capacity 를 갖도록 수렴하게 된다.
  
  TCP 는 Connection Level 에서 매우 공평함을 이야기할 수 있다.
  
  
• UDP 는 보장 없이 데이터를 전송한다.

[ 참고동영상 ]

[ 컴퓨터 네트워크 ]

정리 )

• window size 의 역할
• Congestion Control 이란
• Congestion Control 로 인해 발생되는 현상 두 가지
• 패킷 유실
• 패킷 딜레이
• Congestion Control 은 선순환인가 악순환이가
• 네트워크 상황을 판단하기 위한 방법
• end-to-end 방식
  양쪽의 TCP 연결을 맺은 엔드포인트끼리 네트워크 상황을 지레짐작하는 형태이다. 세그먼트를 전송하고 이후에 ACKs가 왔다면 중간에 패킷이 유실되지 않고 제대로 전달되었음을 의미한다. 세그먼트를 전송하고 ACKs 가 오지 않으면 타임아웃이 발동되고 네트워크 상황이 좋지않음을 판단할 수 있다. 
  
  
• additive increae & multiple decrease 란 무엇인가
• congestion window size (= window size) : 네트워크 상황에 따라서 다이내믹하게 변화
• TCP sending rate 란
• Slow-Start 란 무엇인가
• TCP Tahoe & TCP Reno 의 개념 및 차이점
• 3-Duplicate ACKs 란 무엇인가
• TCP Fairness 란 무엇인가