[TCP] BIC-TCP

제 공부 정리를 목적으로 작성된 글입니다. 혹시, 잘못된 부분이 있다면 피드백 부탁드립니다 :-)

---

진로에 대해 고민하고 있는 와중, 교수님께서 논문 한 번 읽어보라고 추천해주셨다.

• Binary increase congestion control (BIC) for fast long-distance networks
• CUBIC: a new TCP-friendly high-speed TCP variant

최근 네트워크 전공시간에 배웠던 TCP를 다시 공부해보는 시간을 가지기도 했고, 기존 Tahoe, Reno 같은 고전적인 방식이 아닌 최신 congestion control 방식은 어떠한 것이 있는가를 공부해보고 싶기도 했다.

 

사실 근데 BIC-TCP, CUBIC 또한 최신 방식은 아니다. BIC-TCP의 경우 2004년, CUBIC의 경우는 2008년에 나왔다. 하지만 이 둘을 공부한 이유는 Linux kernel에서 default로 사용되었을 정도로 안정적이고 성능이 보장되었기 때문이다.

 

두 논문 중 나는 CUBIC 논문만을 정독했다. CUBIC 논문에서 BIC-TCP를 설명해준다. 하지만 다시 돌아보면 BIC-TCP를 제대로 읽는 것이 좋다고 생각한다.

 

TCP Congestion control에 익숙한 사람이면 모르지만 잘 알지못한다면 Throughput, Utilization, RTT-fairness, TCP-friendliness 등 개념등이 익숙하지 않을 수 있으므로... BIC-TCP를 간단하게라도 읽고 CUBIC을 읽으면 도움이 될 것 같다.

 

이 글에서는 논문을 전체적으로 설명하지 않고 짧고, 중요한 부분만 설명하고자 한다.

나중에 다시 봤을 때, 간단히 보고 갈 수 있도록. 그리고 내가 제대로 설명하지 못하는 부분도 있을 것이라 생각하고, 잘못 이해한 부분도 있을 것이라 생각한다. 고로, 애매하다고 생각되면 그냥 논문을 읽는 것을 추천한다.

 

+) CUBIC 논문의 작성자를 보면서 나도 언젠가 리눅스 커널의 한 부분을 개발하고 싶다는 생각이 들었다. 노력하자.

---

 

Introduction

네트워크는 계속해서 진화하고 있다. 즉, 기술의 발전에 따라 갈수록 더 빨라지고, 넓어지고 있다.

 

 

하지만 기존의 TCP congestion control은 개발 당시의 네트워크 상황에 맞게 설계되었기에 현재 네트워크를 제대로 사용하지 못하며, 성능 또한 만족스럽지 못하다.

 

 

구체적으로, Standard TCP (TCP Reno, TCP NewReno, TCP-SACK 등)은 한 RTT 당 Window를 하나씩 증가시켰다. 이는 Window를 너무 느리게 증가시켜 제대로 된 효율을 내지 못할 수 있다.

 

진짜 간단하게 예를 들어 100개의 TCP 패킷이 왔다갔다 할 수 있는 경로가 있다하자. 그리고 현재 100개의 TCP 패킷을 이 경로에 보내야 한다. 아무도 이 경로를 사용하지 않는다는 전제 하에 당연히 100개를 보내는 것이 좋겠지만, 이 경로가 아무도 사용하고 있지 않다는 것을 알지 못하기에 TCP들은 천천히 증가시키는 방법을 채택하고 있다. 더욱이, Standard TCP의 경우 Window를 1씩 증가시키기 때문에 경로의 Full size까지 크지 못하고 종료될 것이다.

 

애매한 예제이긴 결론적으로 네트워크에 비해 너무 느리게 Window를 증가시키기 때문에 네트워크를 제대로 사용하지 못하고 있다는 것이다.

 

 

Under-utilize problem을 해결하기 위해 몇 년간 많은 High-speed TCP variants들이 제안되었다.

• FAST, HSTCP, BIC TCP, CUBIC, ...
• 최근에는 ML/DL/RL을 활용한 방법들이 제안되어지고 있다.
  • 예시로 읽었던 논문인 Dynamic TCP Initial Windows and Congestion Control Schemes Through Reinforcement Learning가 있다.

---

BIC TCP

BIC TCP

BIC TCP: Binary Increase Congestion control for Fast, Long Distnace Network (LFN)

• Packet Loss가 발생했던 Window size ( Wmax )와 Packet Loss로 인한 감소 후의 Window size( cwnd )
• 그 둘의 중간 지점( mid point )으로 윈도우를 증가시키는 Binary search algorithm을 사용한다.
• 이분탐색을 직접 시스템에 사용한 사례라고 생각할 수 있다.

 

Pseudo code

Pseudo code를 보면 이해가 더 쉽다. (논문보다 보기 쉬운 Wikipedia)

 

Smax: the maximum increment
Smin: the minimum increment
wmax: the maximum window size
β: multiplicative window decrease factor
cwnd: congestion window size
bic_inc: window increment per RTT (round trip time)

 

간단히 두 부분으로 나눌 수 있다.

 

• 증가
  • Wmax보다 cwnd가 작으면, mid point - cwnd를 증가량으로 선택한다.
  • Wmax보다 cwnd가 크면, cwnd - Wmax를 증가량으로 선택한다.

 

• 감소
  • Decrease factor β를 사용하여 cwnd를 감소시킨다.

 

여기서 Smax, Smin 개념이 등장하는데, 난 이게 재밌다고 생각한다. 간단하면서도... 철학이 들어간듯한....?

 

Smax

만약 Packet Loss가 발생했다고 하자. cwnd을 줄여 패킷을 보내고 ACK을 받았을 때, bic_inc를 구해 cwnd 증가를 시킨다. 배운대로 mid point으로 이동하는 만큼 증가한다고 해보자. Packet Loss가 발생하자마자 다음번 부터 mid point로 계속 증가시킨다는 것은 매우 크게 증가하는 것일 수 있다.

 

Packet Loss가 발생했다는 것은 현재 Network 상황에 어느정도 Flow들이 포화가 되었다는 것이다. 곧 바로 cwnd의 많은 양을 증가시켜 진행하면 congestion이 일어날 수도 있으며, Network 상황을 더 악화시킬 수 있고, 마지막으로 다른 Flow들을 생각하지 않고 자신만의 신호를 위한 이기적인 접근일 수 있다.

 

** 이러한 문제를 해결하기 위해 Smax를 정해두고 있다.** 일정 Constant보다 큰 증가량이 구해지면, 그냥 Smax만큼만 증가할 수 있도록 만든다. 이 과정은 위 BIC TCP window graph에서 'Additive Increase' 단계로 표현되고 있다.

 

Smin

Additive Increase 과정을 수행하고, Binary search 단계로 들어서서 배운대로 mid point 까지의 증가량으로 Window를 증가시키고 있다고 하자. 이 과정이 뭔가 이상하지 않은가? Wmax와 cwnd의 중간 값으로 이동한다고 하면 Wmax는 절대 넘지 못한다는 것 아닌가?

 

Network에 갑자기 많은 Flow들이 들어왔다고 하자.많이 들어왔을 때, congestion이 일어나 Wmax가 정해졌다. BIC TCP로 cwnd를 증가시켜가고 있는 와중에 들어왔던 Flow들이 끝이나서 다시 Network가 상황이 좋아졌다. Wmax를 넘어선 Window 크기만큼 수용이 가능한데도 불구하고, 이전 Wmax를 못넘어서기 때문에 Network를 다 사용하지 못하는 문제가 발생한다.

 

** 이러한 문제를 해결하기 위해 Smin을 정해두고 있다.** 일정 Constant보다 작은 증가량이 구해지면, 그냥 Smin만큼은 증가할 수 있도록 만든다. 이 과정을 통해 Wmax를 넘어서서 증가할 수 있게 된다.

 

효과

BIC TCP는 앞의 과정들을 통해 많은 효과를 가져왔다.

 

• Wmax가 멀리 있는 경우, Window size를 빠르게 증가시킬 수 있다.
• Wmax가 가까이 있는 경우, Window size를 천천히 증가시킬 수 있다.
• Wmax를 넘어갔을 때, 처음엔 느리게/나중엔 빠르게 Window를 증가시킨다 (Max probing)

 

BIC TCP achieves good scalability in high speed networks, fairness among competing flows of its own and stability with low window oscillations.

 

하지만 이러한 특징과 기존 TCP와 비교해 얻을 수 있는 장점에도 불구하고 여러 문제점이 존재한다.

 

BIC TCP 단점

CUBIC 논문에서는 BIC TCP에 대해 대표적으로 2가지 단점을 이야기했다.

 

• BIC TCP의 Window growth fuction는 Low speed network, short flows 측면에서 너무 공격적으로 증가했다. 즉, Standard TCP와 fair하지 않을 수 있다.
  • 더 쉽게 이야기하자면, 기존 standard TCP들이 있는 네트워크 공간에서는 BIC-TCP를 사용하면 더 많은 대역폭을 차지한다는 것이다. 당연히 단순히 BIC-TCP 사용자 입장에서보면 네트워크적으로 좋은 성능을 가져올 수 있으니 좋을 수 있다.
  • 하지만 이건 TCP의 중요한 원칙인 fairness에 어긋나므로 좋지 않은 네트워크 상황을 가져올 수 있다.

 

• Window control different phase (Binary search increase, Max probing, Smax/Smin)들로 인해 implementation of protocol과 complexivity를 야기했다.
  • 최근 컴퓨터 아니 인터넷이 연결되었다고 하는 과거의 컴퓨터들까지 제일 기본적인 것은 네트워크 통신이다. 짧은 시간안에 엄청난 많은 네트워크 통신이 일어난다.
  • 하지만 그 부분에서 복잡성이 증가하여 overhead가 발생한다는 것은 엄청난 문제가 된다.

 

그래서 BIC TCP의 강점인 Stability, Fairness, Scalability를 유지하면서, Window control을 단순화시키고 TCP friendliness를 향상시키는 새로운 Window growth function인 CUBIC을 제안한 것이다.