[TCP 혼잡]Bufferbloat

이 글은 2011년 11월 29일 acmqueue에 등재된 bufferbloat에 관련된 내용을 짧게 정리해놓은 글입니다. 원본은 https://queue.acm.org/detail.cfm?id=2071893에서 확인하실 수 있습니다.

Bufferbloat

네트워크 분야에서 종단 간 지연(End to End Latency)은 통신 속도에 있어 매우 중요하다. 일반적으로 컴퓨터 간의 통신을 한다고 하면 누구나 한번쯤은 TCP/IP라는 단어를 들어보았을 것이다. TCP에서는 종단 간 지연을 줄이기 위해 여러 가지 congestion control(혼잡 제어) 기법들을 이용하는데 대표적으로 slow-start(슬로우 스타트)이다.

slow-start는 여러 네트워크들이 동시에 통신하면 네트워크 장치(network device)에서 발생할 수 있는 혼잡(Congestion)을 회피하기 위한 TCP 알고리즘 중 하나이다. slow-start는 혼잡을 피하기 위해 초기에는 데이터 송출량을 적게 설정하고 점점 증가시키면서 조사를 한다. 만일 패킷이 폐기된다면 전송 속도를 줄이게 되고 TCP 발신자는 적절한 윈도우 크기를 신속하게 찾는데 도움을 준다. slow-start 알고리즘은 연결 초기에는 느린 속도로 인해 다소 지연이 발생하지만 혼잡(Congestion)을 회피할 수 있기 때문에 많이 사용한다.

통신 기술이 발달하면서 데이터를 전송하는 속도는 매우 빨라졌다. 이에 따라 윈도우 사이즈도 증가하게 되었고 네트워크 장치 안에 있는 버퍼(Queue)의 크기 또한 증가하게 되었다. 하지만 이러한 과정에서 Jim Gettys에 의해 문제점이 제기되었는데, 바로 Bufferbloat 현상이다.

Bufferbloat는 말 그대로 풀어서 쓰면 Buffer(버퍼)가 bloat(=swell, 부풀어오르다)하는 현상이다. Bufferbloat는 버퍼의 사이즈가 커지면서 생기는 문제인데, 버퍼 안에 패킷이 들어가면 그만큼 체류 시간이 길어지면서 발생하는 문제이다.

<Throughput과 Delay, Buffer size간의 상관관계>

위 사진은 한 사용자가 링크를 독점했을 때를 기준으로 throughput(단위 시간당 보내는 데이터양)과 delay(지연)의 상관관계를 보여주는 그래프이다. delay가 일정하면 보낼 수 있는 데이터의 양은 증가하게 되지만, 버퍼의 크기가 증가하게 된다면, 그만큼 버퍼 안에 들어가서 대기하는 시간 또한 길어지기 때문에 데이터를 보낼 수 있는 양이 일정해지게 된다. 

문제는 링크를 공유하면서(공유하지 않더라도) 대량의 데이터가 유입될 때 발생한다. 네트워크 장치에 패킷이 도달하면 처리 중인 패킷 외에는 버퍼에서 대기를 하게 된다. 여러 곳에서 온 데이터들은 빠른 속도로 버퍼에 들어가게 되고 언젠가는 꽉 차게 된다.

문제는 버퍼의 크기가 커졌기 때문에 버퍼가 차는데 걸리는 시간이 늘어나게 되었고, 그동안 송신측 slow-start 알고리즘은 패킷의 drop이 감지되지 않았으므로 송신속도를 점점 높여간다. 그러다가 버퍼가 꽉 찼을 때 tail drop 알고리즘에 의해 버퍼 안에 있는 패킷을 제외한 전송된 패킷들은 모두 폐기(drop) 된다. 이를 인지한 slow-start 송신 속도를 줄이게 되고 transmission delay(전송 지연, 통신 링크를 통해 전송하는데 걸리는 시간, related to RTT : Round-Trip Time)가 늘어나게 된다. 또한 이미 버퍼에 들어간 패킷들은 미리 버퍼에 들어온 패킷들이 처리될 때까지 기다리면서 queueing delay(큐잉 딜레이, 큐 내부에서 처리되고 송신되기까지 기다리는 시간)가 늘어난다. 이 때문에 사용자 입장에서는, 인터넷의 속도가 빨라졌다가 어느 순간 급격히 느려지고를 반복하는 현상이 나타난다.

<RTT와 window size의 상관관계>

보통 RTT의 최대값은 100ms(지구 끝에서 반대편 끝까지 데이터를 보낼 때 걸리는 최대 시간)라고 정의되어 있지만 Bufferbloat가 발생하면 RTT는 100ms를 훌쩍 넘어가며, RTT에 따라 window 사이즈 또한 늘어나는 것을 확인할 수 있다.

이를 해결하기 위해서 확률론적으로 평균 버퍼 크기 및 폐기 패킷을 모니터링하는 RED(Random Early Detection)이 제기되었다. 그 후 bottleneck의 버퍼(queue)를 모니터링하면서 버퍼가 너무 커질 경우에 송신자의 TCP 속도를 slow down하여 관리하는 AQM(Active Queue Management)의 연구가 진행되고 있다.