컴퓨터 네트워크 7주차

---

Congestion Control(혼잡제어의 원리)

• 네트워크 혼잡이란 너무 많은 sender들이 너무 많은 데이터를 너무 빨리 보내서 네트워크 전체가 감당할 수 없는 상태.

• flow control과 다름. flow control(receiver가 overflow가 안 되도록 control)은 특정 receiver가 데이터를 처리를 못 할 때 사용하는 기법임.

 

시나리오 1

• 두 개의 sender와 두 개의 receiver

• 거치는 라우터는 하나이고, 라우터에 있는 버퍼는 무한 버퍼 → 버퍼에 한계가 없기 때문에 데이터가 얼마든지 대기할 수 있음

• 재전송은 없다고 가정

• 링크 수용량은 R이라고 하자.

• 애플리케이션 레이어에서 데이터의 양을 람단 in, output 데이터를 람다 out 이라고 하자.

• 두 개의 sender와 receiver가 라우터를 동등하게 사용한다고 하면 사용량은 각각 R/2, R/2일 것이다(두 개의 sender, receiver가 있기 때문에). 만약에 througput이 R/2보다 커지더라도 라우터는 총 R밖에 처리를 못하기 때문에 라우터의 버퍼에서 큐 형태로 기다릴 것이다.

 

시나리오 2-1

• 템플릿 1과 달리 템플릿 2에서는 라우터 버퍼가 무제한이 아닌 한정되어 있고, timeout이 된 패킷에 대해서는 재전송을 한다고 가정하자.

• 따라서 오리지널 데이터인 람다 in이 내려오지만 재전송할 데이터도 고려해야 하므로 람다' in(오지지널 데이터 + 재전송 데이터)가 더 커진다.

 

시나리오 2-2

Finite Buffer(한정된 버퍼)를 사용하기 때문에 sender가 router buffer가 사용가능할 때만 보내면 매우 이상적이지만 실제로는 sender가 router의 버퍼 상태를 알 방법이 없다. sender가 버퍼 상태를 알고 전송하기 때문에 람다 in과 람다` in은 같을 것이다.

 

 

시나리오 2-3

이번 가정에서는 sender가 패킷이 손실된 것에 한해서만(timeout은 고려X) 재전송을 한다. 그렇다고 하더라도 이 상황에서는 람다 in은 람다 out이랑 같지만 람다` in은 람다 in보다 커질 것이다. 즉, 람다` in이 람다 out보다 크므로 기울기는 1보다 작아진다. 람다 out에 오기 전에 데이터가 버려지더라도 재전송을 통해 언젠가는 람다 out으로 가기 때문에 R/2에 수렴

 

시나리오 2-4(지금까지는 가정이었고 이제는 현실 세계)

1. 라우터의 버퍼가 가득 차면 패킷이 버려진다

2. 패킷이 도착하기 전에 타임 아웃이 작동하면 receiver는 duplicate 패킷을 받을 수 있다. → receiver는 중복패킷이 도착하면 하나는 버린다.

실제 필요한 재전송 뿐만 아니라 duplicate 패킷도 전달되기 때문에 그래프는 좀 더 하위에서 수렴한다(good put이 낮아짐)

• congestion의 비용
  • good throughput(실제로 데이터가 전송되는 비율 - 수렴하는 선)에 도달하기 위해서 재전송을 많이 해야함
  • 불필요한 재전송이 발생하기 때문에 good put이 낮은 위치에서 수렴한다.

 

 

시나리오 3

• 4개의 sender인 동시에 receiver

• 라우터 2개를 거쳐서 receiver에 도달함(multihop)

• 타임아웃과 재전송이 있다고 모두 가정

• lambda in(오리지널 데이터), lambda` in(오리지널 데이터 + 재전송 데이터)

Host A(red)의 lambda in이 증가할 때 Host B(blue) lambda out도 과연 증가할까? → 증가한다(영향을 받는다) → 왜? → Host A가 Host B에게 패킷을 전송하는 건 아니지만 동일한 라우터를 사용하고 있기 때문에 Host A가 전송하는 데이터 양이 많아지면 버퍼도 더 차지하기 때문에 Host B에 도착하는 패킷은 버려질 가능성이 있다. 그렇게 되면 blue의 throughput은 처리가 제대로 안 되기 때문에 0으로 수렴한다. 즉, lambda out은 Host B에 도착하지 못한다.

congestion의 무서운 점은 한 사거리에서 막히면 또 다른 사거리에서도 막힌다. 만약에 중간의 라우터에서 패킷이 버려지면 그때가지 사용됐던 네트워크 리소스가 결과적으로 낭비된 셈이 된다. 즉, congestion 상황을 그대로 놔두게 되면 전체 네트워크가 붕괴될 수가 있다.

---

TCP Congestion Control

 

• additive increase: TCP에서는 sender가 패킷(비트?) 손실이 발생할 때까지 윈도우 영역을(congestion window) maximum segment size만큼 증가시킨다. 손실이 발생했는지 사실상 알 수는 없지만 timeout & three duplicate로 추정한다.

• multiplcative decrease: loss가 발생하면 congestion 상황이 의심이 되므로 현재 window의 1/2로 decrease한다.

TCP에서 congestion window와 receive window가 있는데, receive window는 receiver가 sender에게 '한 번에 이만큼 보내도 돼!' 라고 receiver가 요청하도라도 congestion windows보다 많이 보낼 수 있다. 즉, congestion window는 receive window 내에서 증가한다.(두 개의 window size를 충족하는 한에서 한 번에 보낼 수 있는 데이터 사이즈가 결정된다)

 

 

TCP는 Congestion 상황을 발생시키지 않기 위해 slow start를 한다.

• 초기 congestion window 값을 1 maximus segment size로 설정. 즉, 사실상 세그먼트 1개밖에 못 보냄. → 모든 RTT마다 congestion window 값이 두 배가 된다.(매번 ACK를 받을 때마다 Congestion window 값을 증가 → 그런데 이게 왜 두 배가 될까? 처음에 세그먼트 1개를 보내고 ack를 받으면 congestion window 를 1개 증가시키면 2mss가 된다 → 이제 2개의 segment를 두 개를 보내면 → ack가 두 개 도착할 것이다 → ack 하나당 congestion window를 1개 증가시키므로 ack가 2개 도착했으므로 congestion window + 2를 하므로 congestion window 4개가 된다. → 즉 결과적으로 매 RTT마다 congestion window 값이 두 배가 된다(처음 시작은 slow, but 매 RTT마다 지수함수(2^n)로 증가) (loss가 일어나지 않는 한)

 

 

TCP에서는 loss를 어떻게 발견(추정)할까?

• timeout과 3 duplicate ack가 발생하면 loss(로 추정
  • 타임 아웃이 발생하면 congestion window를 1 mss로 변경한다.
  • congestion window를 slow start를 하면서 지수함수로 증가가 되는데, 무한정 증가가 되는 게 아니라 한계값까지 증가가 되고, 한계값 이후에는 선형적으로 증가한다.

• TCP RENO 방식(3 duplicate): duplicate ack가 발생하면 여전히 세그먼트들을 네트워크가 감당할 능력이 있다고 가정(즉, 아주 심한 상황은 아님) → RENO 방식은 congestion window를 절반으로 줄인 후, 이후 지수함수로 congestion window를 증가시키지 않고 선형으로 증가시킴

• TCP Tahoe: timeout이든 3 duplicate든 상관않고 congestion window를 1 mss로 줄인다.

 

위 그래프를 보면 ssthresh(한계값) 8로 시작한다. congestion window가 각 RTT마다 지수함수적으로 증가되다가 ssthresh 값이 되면 그 이후에는 선형적으로 증가하는 것을 볼 수 있다.

특정 지점에서 loss가 발생하면 Tahoe 방식(timeout & 3 duplicate 상관 X)에서는 cwnd를 무조건 1로 세팅한 후에 지수함수만큼 증가시킨다. 또한 위 그래프를 보면 loss가 발생했던 cwnd 지점이 12인 것을 알 수 있는데 loss가 발생하면 ssthresh 값은 loss가 일어났던 지점의 cwnd 값의 절반으로 줄어든다.

TCP RENO 방식은 congestion이 일어났던 지점의 ssthresh 값의 절반만큼 congestion window 값을 줄이고 그 이후에는 선형 증가로 변경한다.

 

 

 

한 세그먼트의 사이즈가 1500 바이트, RTT가 100ms 걸리다고 가정하다. thorughput은 10 Gbps가 걸리기른 바란다.

W = 83,333 세그먼트 → ACK 받지 않고 연속으로 보낸 세그먼트가 8만 333개라는 의미이다. 이게 무슨 의미냐면 한 번 TCP 커넥션을 맺고 이렇게 많은 세그먼트를 보낼 일은 거의 없다 → 불가능하다 → 하이 스피드를 위해서는 새로운 TCP가 필요하다.

 

 

과연 TCP는 Fair한가? → K개의 TCP 세션이 똑같은 링크(수용할 수 있는 데이터 양: R)를 공유하고 있다고 하면, 각각의 세션의 평균 속도가 R/K이 나오면 fair하다고 표현

 

1번 영역(x>y)에서 그래프가 시작했다는 의미는 x의 R/K가 y의 R/K보다 크다는 의미이다. 그렇게 가다가 파란색 선(버퍼)을 넘으면 로스가 발생한다는 의미이므로 윈도우를 절반으로 줄인다 → throughput도 절반으로 준다. 이런 식으로 y=x 선에 수렴할수록 fair한 TCP가 된다. 그래서 TCP는 fair하다고 말한다. 2번 영역에서 시작해도 마찬가지이다.

 

멀티미디어 애플리케이션은 TCP를 사용하면 congestion control 때문에 전송률이 줄어들 수 있으므로 종종 패킷 로스를 감소하더라도 UDP를 사용한다.

위에서 TCP가 fair하다고 얘기했는데, 이것도 현대에 와서는 무색해진다. TCP connection을 같은 목적지에다가 병렬적으로 구성하는 애플리케이션이 등장한다. 즉, 두 호스트 사이에 병렬적으로 연결을 구성한다. 웹 브라우저 같은 경우 이런 방식으로 반응속도를 높인다. (e.g. 수용량이 R인 링크에서 9개의 connection들이 있었을 때, 새로운 애플리케이션에 1개의 커넥션을 요청하면 10개의 커넥션이 될 것이고 이 때는 각각의 커넥션들이 R/10 만큼 링크를 사용할 것이다. 그런데 만약에 새로운 애플리케이션이 한꺼번에 11개 커넥션을 맺으면 이 애플리케이션은 기존의 9개의 커넥션에다가 11개가 추가된 11R/20 링크 자원을 사용하게 되므로 사실상 링크 자원 절반을 점유하게 된다 → 이건 공평하다고 말하기는 어렵다)

 

지금까지 TCP가 congestion을 control한 방식은 대부분 implicit(암시적, 추측)한 방법이었다면 명시적인 방법도 있다.

IP 헤더에 Type_of_Serview라는 필드가 있다. 이 ToS 필드를 네트워크 라우터가 마킹을 한다. 언제 마킹을 하냐면 congestion이 발생했을 때, congestion이 발생했다는 것을 알 수 있도록 ToS 필드를 마킹한다. 그런데 네트워크 라우터에서 ToS 필드를 마킹하려면 이미 sender에서 출발한 이후이기 때문에 ToS를 알 수 있는 건 receiver 뿐이다. congestion 사실을 받은 receiver는 sender에게 보내는 ACK 세그먼트에 ECE bit(sender가 congestion 사실을 알려줄 수 있는 비트)를 만들어서, ACK 세그먼트를 sender에게 보낸다. 이 ACK 세그먼트를 sender가 수신하면 sender는 전송량을 조절한다. 하지만 이런 Explicit 기능은 congestion을 control을 하기 위해서 하위 계층으로부터 정보(network layer → transport layer)를 얻어야 하므로 레이어 간의 분리가 확실히 되지 않으므로 Explicit한 congestion control을 동의하지 않는 분위기도 업계에 있다.