20180618 네트워크 정리 08 답변

window size

window size 네트워크 상황과 리시버 버퍼, 이 두 개의 값 중에서 최소값을 선택하여 window size 를 선택한다.

Congestion Control

Congestion control 이 발생하게 된다면 두가지 현상이 나타난다. 우선 패킷이 유실되고 패킷 딜레이로 인해 네트워크 데이터 전송 시간이 지연된다. 이 과정에서 우리는 네트워크가 혼잡한지 여부를 어떻게 알 것인가에 대한 문제에 봉착하게 된다. 

상황 가정 )

• 두 센더 존재

• 두 리시버 존재

• 하나의 라우터가 존재하며, 해당 라우터는 무한대의 버퍼(큐)를 소유하고 있다.

• 더 이상의 데이터 재전송은 없다.

• 대역폭(bandwidth) 는 R이다.

• 처리량(throughput) 을 확인하여야 한다. (처리량 : 단위시간당 얼마만큼의 데이터를 전송할 수 있는가)

• 아무리 빠른속도로 데이터를 보내고 무한대의 큐를 가지고 있다고 하더라도 처리량의 값에 수렴하게 된다면 더 이상의 값을 빠르게 보낼 수 없다.

Congestion Control 로 인해 발생되는 두가지 현상 & 악순환

• Packet Loss
  실제 Transport Layer 에 Packet Loss 가 발생한다. 이를 해결하기 위해서 패킷을 재전송(re-transmition)하는데, 결과적으로 기존의 데이터보다 더 많은 양의 데이터를 보내게 된다. 그리고 이로 인해 Congestion 이 발생하고 다시 Packet Loss, 처리량이 낮아지고 이러한 악순환이 반복된다. Network congestion 에서 packet loss 가 발생되지 않았음에도 불구하고 타임아웃이 되고 또 다시 패킷을 보내게 된다.

• Packet Delay

Source --> Destination ( Upstream )

Destination --> Source ( Downstream )

이렇게 말하며, Upstream 의 자원이 소모되면 이후에는 congestion 때문에 re-transmition 을 한다. 결국 이 re-transmition 은 의미있게 보낸 데이터가 감소했음을 은연중에 말해주고 있다. Upstream 의 자원은 낭비되고 계속 이 악순환이 반복된다.

네트워크 상황을 판단하기 위한 방법

실제 End to End 의 양쪽의 TCP 연결을 맺은 엔드포인트끼리 네트워크 상황을 유추해야 한다. 세그먼트를 전송하고 이후에 ACK가 왔다면 중간에 패킷이 유실되지 않고 제대로 전달되었음을 의미한다. 반대로 ACK가 안와서 타임아웃이 되었다면 네트워크 상황이 좋지 않음을 판단할 수 있다.

Additive Increase & Multiple Decrease

(1) window size 만큼 세그먼트를 전송한다.

(2) 세그먼트에 대한 ACK 가 정상적으로 왔다면 이후에 보내는 세그먼트의 전송량을 +1 씩 늘려나간다. (additive increase)

(3) 계속 전송량을 늘려나가다가 ACK가 오지 않았다면 세그먼트의 전송량을 절반으로 줄인다. (multiple decrease)

(4) (3) 처럼 수행하는 이유는 다른 엔드포인트들도 세그먼트를 전송하기 때문에 Congestion 에 대해 예방하기 위함이다.

(5) 네트워크의 상황이 개선되면 다시 additive increase 방식을 이용한다.

네트워크 상황에 따라서 전송하는 세그먼트의 양을 적절하게 보내며, 최적의 데이터 전송량을 찾아가는 방식이다.

Congestion window size (= window size )

윈도우 사이즈는 네트워크 상황에 따라 유동적으로 변함을 의미한다.

TCP Slow-Start

Congestion Control 알고리즘의 하나이다.  

• awnd : 전송 윈도우 크기 (송신측 세그먼트 수)

• rwnd : 수신 윈도우 크기 (수신측 버퍼 여유용량)

• cwnd : 혼잡 윈도우 크기 ( '연결초기' & '혼잡상황' 에서 사용되는 윈도우 )

1. 연결 초기에 cwnd = 1 세팅
2. 최대값이 될 때까지 cwnd 를 1씩 증가
3. 윈도우 크기가 1씩 증가하나 각각 확인응답되는 세그먼트마다 윈도우 크기가 1씩 증가하기 때문에 실제 전송되는 세그먼트 수는 expotential 하게 증가한다.
4. 하지만 3의 경우에 기하급수적으로 윈도우 크기를 증가시키면서 늘릴 수 없다. 따라서 임계치 (threshold) 를 설정해놓는다.
5. 임계치만큼 전송하는 윈도우 크기가 올라가면 이후에는 데이터 전송량을 하나씩 증가시킨다.

TCP Tahoe & TCP Reno

아래의 그래프를 살펴보자. 왼쪽은 TCP Tahoe, 오른쪽은 TCP Reno 이다. 

• X축 시간

• Y축 시간에 따른 윈도우 사이즈

제일 처음 시작할 때에는 slow start 로 시작한다. 하나의 세그먼트만 보내면서 이후에 expotential 하게 세그먼트를 전송한다. 하지만 앞서 말했다시피 slow start 를 수행하면서 임계치에 도달하면 다시 세그먼트를 하나씩 증가시킨다. 양쪽의 그림을 살펴보면 윈도우 사이즈가 20이 되는 시점에서 Packet loss 가 발생한다. 

Packet loss 에 대한 근거는 두가지가 있다. 

1. ACK 가 오지 않아서 타임아웃(Time Out) 
   전송한 세그먼트가 네트워크 상황이 불안정하여 다 유실되고 제대로 전달되지 않았다. 
2. 3-Duplicate Packet 
   네트워크 상황은 어느정도 동작하고있지만 일부의 세그먼트는 전송되지 않아서 동일한 ACK 를 반환받는 경우

1과 2의 상황에서 1의 상황이 상대적으로 더 위험한 상태이다. 왜냐하면 네트워크 상태가 매우 불안정하기 때문이다.

TCP의 초기버전은 TCP Tahoe 처럼 문제가 발생하면 윈도우 사이즈를 확 내린다. 하지만 TCP의 이후버전, TCP Reno 는 문제가 발생하면 Threshold 을 congestion window size 의 절반으로 줄이고 (그림에서 보면 윈도우 사이즈가 20이고 임계치는 10으로 바뀐것을 확인할 수 있다) 해당 윈도우 사이즈 시점부터, 해당 임계치부터 linear 하게 증가시킨다. 

어느 경우에서나 slow start threshold 는 congestion 이 일어나는 그 윈도우 사이즈에서 절반으로 줄어든다. 그리고 그 이후부터는 어떤 문제가 다시 발생될지 모르기 때문에 linear 하게 조심스럽게 데이터를 전송한다.

따라서 TCP Tahoe & TCP Reno 의 차이는 문제가 발생되고 나서 이후에 데이터를 리니어하게 보내게되는데 그 시점을 어디에 맞출 것인가가 중점이 되어있다. 추가로 TCP Throughput 이라는 것이 있는데 이는 리시버가 단일시간동안 받는 양(센더가 보내는 데이터 전송량) 인데 알아두자.

TCP Fairness

• A라는 유저가 TCP 프로토콜을 사용하고, 파일을 전송한다.

• B라는 유저가 TCP 프로토콜을 사용하고, 파일을 전송한다.

TCP 에 대한 동작은 독립적으로 수행되는데, 이런 상황에서 같은 라우터를 이용한다면 (같은 경로를 사용한다면) 해당 bottle neck 의 capacity 가 R이라고 했을때, 공평하게 R/2 씩 자원을 사용하는가? 결과적으로 TCP 는 R/2 씩 자원을 사용하도록 수렴한다. 패킷 유실이 발생되면 이전 Congestion 에 대해 전송량을 1/2 로 줄이고 이후 데이터를 전송하면서 다시 패킷 유실이 발생할 것이다. 이후 1/2 로 다시 줄어든다. 이 과정을 반복하게 된다면 결과적으로 각각의 capacity 는 2/R 갖게 된다. TCP 는 Connection Level 에서 매우 공평하다. 

https://www.youtube.com/results?search_query=TCP+fairness

[ 참고링크 ]

https://tools.ietf.org/html/rfc5681