네트워크 정리 : Transport Layer _ Window Control (Flow Control & Congestion Control)

Window Control

TCP는 Reliable한 통신을 위해서 수신측과 네트워크의 상태를 파악해서 전송량을 조절하는 기법이 존재한다. 이를 조절하는 기법을 Window Control이라고 한다. 여기서 수신측의 혼잡도를 확인하고 조절하는 것이 Flow Control, 네트워크의 혼잡도를 유추해서 조절하는 것이 Congestion Control이다.

RTT

• Round Trip Time의 약자로 Data가 수신측에 전송되어 ACK를 수신측에서 받을 때 까지 걸린 총 시간을 지칭한다. 이 시간이 길 수록 데이터 전송량은 줄어드어 전송량과 반비례 관계를 갖는다.

Window

• ACK의 수신 없이도 보낼 수 있는 패킷의 최대 크기를 말한다.
• Window가 1000이라면 ACK를 수신받은 후 ACK의 수신 없이도 1000 byte 만큼의 패킷은 연속해서 보낼 수 있다는 것.
• Window가 크면 한번에 더 많은 데이터를 전송할 수 있는 장점이 존재하지만 수신측, 네트워크의 혼잡도에 따라 조절해줘야 패킷 유실을 막을 수 있다. 또한 너무 작다면 자원 낭비에 전송에도 오랜 시간이 걸리는 단점이 있으므로 적절한 크기를 잡는것이 중요하다.

전송량 R

• Transmission Rate로 RTT에 반비례, Window에 비례한다. R = W * P / RTT (Bit/S), P : 패킷의 크기, W : Window size

(Receiver) Flow Control

• 수신측의 overloading을 방지한다.
• 수신측에서 Window Size를 설정한다.
• Window Size는 수신측에서 받을 수 있는 여유 BUFFER SIZE이다. (총 버퍼 - 사용중 버퍼)
• rwnd : receiver window

(Network) Congestion Control

• 네트워크의 overloading을 방지한다.
• 송신측에서 네트워크의 혼잡도를 유추해서 Window Size를 설정한다.
  • Q. 송신측에서 어떻게 네트워크의 혼잡도를 계산해낼 수 있을까?
  • A. 미수신된 ACK가 발생하면 네트워크의 혼잡도가 올라갔다고 판단한다. ACK가 오지 않으면 window size를 줄이고 또 안오면 더 줄이고 반복.
• cwnd : congestin window

W는 rwnd와 cwnd의 값 중 최소값으로 설정함으로서 Flow Control, Congestion Control이 적용되도록 한다.

Congestion

• 송신측은 네트워크가 나타내는 혼잡도를 가지고 cwnd를 계산한다.
• 네트워크의 혼잡도를 파악하는 방법
  • 1) Packet Loss : 패킷 유실로부터 파악한다. ACK가 오지 않았다는 것을 Packet Loss로 판단한다. 현재 TCP에서 사용하는 방식.
  • 2) Delay : 딜레이가 발생하면 혼잡도가 있다고 판단.

Packet Loss로부터 Congestion을 판단하는 것의 문제점

• 데이터 유실이라는 최악의 상황이 발생해야 cwnd를 줄이는 조치를 취하므로 늦장대응의 문제가 있다.
• 무선랜의 경우 데이터 유실이 쉽게 발생할 수 있는데 Congestion 상황이라고 판단하게 된다.

Delay로 Congestion을 판단하는 것의 문제점

• 정확이 얼마만큼의 Delay가 발생해야 Congestion이라고 판정할 것인지 정하기 어렵다.
• 매 순간 Delay의 정도를 확인해야하는데 이를 위한 오버헤드가 더 크다.

Congestion이 발생해서 Congestion Control을 할 경우 cwnd의 크기는 얼마로 조정해야 할까?

1. TCP Original 방식 : 전송량을 절반으로 낮춘다. ex) window size n -> n/2
2. TCP Tahoe, Reno 방식 : 최소 패킷 전송량으로 낮춘다. ex) window size 1

 

Packet Switching & Statistical Multiplexing

Packet Switching

• 데이터를 패킷단위로 네트워크에 보내고 최종적으로 수신측에 전달하는 방식.
• 패킷 스위칭은 비용 효율적인 자원 공유를 위해 Statiscal Multiplexing에 의존한다.

Statistical Multiplexing (통계적 멀티플렉싱)

• 통계적 멀티플렉싱은 FIFO 방식으로 동작하며 BUFFER 공간이 존재한다.
• 어떤 Host 든 요청이 오면 버퍼에 담고 온 순서대로 처리를 하게 된다. 이때 평균적인 입력 속도가 출력속도 이하라면 문제 없이 작동한다.
  만약 패킷이 몰리면 버퍼 공간에 담게 되고 이 공간이 다 차버리면 Congestion이 발생하게 된다.
• 평균적인 입력을 계산하므로 통계적이라는 단어가 붙어있다.

Time Division Multiplexing (유선 전화 방식)

• 말 그대로 시간을 배분해서 사용하는 방식으로 한시간 중 20분은 A Host, 다음은 B Host, 다음은 C Host 등 호스트가 일정 시간동안 스위치를 점유하여 사용하는 방식이다.
• 정해진 개수만큼의 클라이언트와만 통신이 가능하다는 단점이 있다.

Congestion 별 해결방법

• Short-term Congestion : 일시적인 혼잡의 경우 Buffer 공간을 조금 더 가지므로서 해결할 수 있다.
• Long-term Congestion : 장시간 혼잡의 경우 송신 패킷의 양을 조절해주는 방법밖에 없다. cwnd를 줄여야 한다.

 

TCP Congestion Control

1) Original 방식 : Addictive Increase & Multiplicative Decrease

접근방식

• 송신측은 적절한 크기의 초기 window size를 기준으로 RTT가 성공할 때마다 1씩 늘린다.
• addictive increase : LOSS가 관측될 때까지 1씩 cwnd 크기를 늘린다. 마치 독에 1틱씩 중독되는 것처럼 찔끔찔끔 올림.
• multicative decrease : LOSS가 관측되면 절반으로 줄인다. 곱셈적 감소로 1/2를 곱한다.

2) TCP Tahoe 방식 : Slow Start & Exponential Growth

접근방식

• 송신측은 1 만큼의 cwnd 크기를 기준으로 RTT가 성공할 때마다 2배씩 늘린다.
• Slow Start : LOSS가 관측되면 cwnd의 크기를 1로 줄여버린다. Origin 방식과 다르게 시작점이 1로 낮으므로 슬로우 스타트이다.
• Exponential Growth : LOSS가 관측 될 때까지 RTT가 성공할 때까지 cwnd를 2배씩 늘린다. 1, 2, 4, 8, 16 ...
• LOSS가 관측되면 1로 줄이는데 이때 2/window 크기를 threshold로 설정한다. 그러면 cwnd가 1로 줄어들고 다시 2배씩 증가하다가 threshold에 도달하면 linear하게 1씩 증가하게 된다. 이후 또 Congestion이 발생하면 1로 줄이고 threashold를 해당 cwnd의 절반으로 설정하게 된다.

Tahoe 방식 Congestion Control

3) TCP Reno 방식 : 현재 TCP에 사용하는 방식 (slow start & exponential growth + origin)

접근방식

• Tahoe방식과 동일하게 LOSS 검출 전까지는 2배씩 증가하고 검출 시 1로 줄인다. threshold를 발생 시 cwnd의 절반으로 설정한다.
• 단, Congestion이 발생했다고 판단하는 부분에서 좀 더 온건적인 입장을 갖는다.
• Packet Loss가 발생한 원인에 따라 다른 조치를 취한다.
• Time Out으로 인한 Packet Loss 발생 시 -> 기존과 동일하게 cwnd를 1로 줄이고 threshold를 절반으로 설정한다.
• 3-dup ACK로 인한 Packet Loss 발생 시 -> 좀 더 유하게 적용하여 cwnd를 절반으로 줄이고 linear하게 증가하도록 한다.
  • 3-dup ACK는 다른건 다 갔는데 하나가 가지 않아서 3개의 ACK가 중복적으로 특정 패킷의 유실을 알리는 것이고 Time-out은 모든 패킷이 유실되어 3-dup이 아닌 Timer 만료가 발생한 것이다.
    따라서 3-dup은 Timeout 보다는 네트워크 상황이 낫다고 판단할 수 있으므로 덜 보수적으로 접근하여 절반으로만 줄이도록 하는 것이다.
  • 만약 위 그림에서 발생한 congestion이 3-dup ack였다면 1이아니라 8로 줄어들고 1씩 늘어나게 될 것이다.

초록색 선 : Reno 방식 Congestion Control