Fast Retransmit (Duplicate Acknowledgement)

 

TCP의 혼잡 윈도우의 크기는 패킷 손실이 발생하지 않는 한 계속 증가한다. 반대로 말하면, 언젠가는 혼잡으

로 인한 패킷 손실이 발생하게 된다. TCP 혼잡 제어 메커니즘에는 손실된 패킷을 복구하고 혼잡 윈도우의 크

기를 재조정 하기 위한 기능이 포함되어 있는데, 이를 흔히 TCP 손실 복구 메커니즘이라고 한다. TCP 손실

복구 메커니즘은 패킷 손실을 감지했을 때 우선 이를 재전송에 의해서 복구하기 위한 시도를 하게 된다. 만약,

재전송에 의한 복구가 불가능한 경우 재전송 타임 아웃 이후에 패킷 전송이 다시 시작된다. 따라서, 손실된

패킷을 어느 정도 복구할 수 있는지의 여부는 전반적인 TCP의 성능에 큰 영향을 미친다. TCP의 손실 복구 메

커니즘은 두 개의 기본적인 알고리듬인 Fast Retransmit과 Fast Recovery를 통해 동작하는데, 특히 Fast

Recovery는 손실 복구 메커니즘의 성능 향상을 위해서 수 차례에 걸쳐서 수정되어 왔고, 이에 따라 흔히 TCP

Tahoe, TCP Reno, TCP NewReno로 구분된다. 이 글에서는 이 세 가지 종류의 TCP 손실 복구 메커니즘의 동

작을 비교하고, 추가적으로 Selective Acknowledgement option을 사용하는 TCP의 손실 복구 메커니즘의 동

작에 대해서도 알아본다.

 

 

2. Fast Retransmit [1]

Fast Retransmit은 1988년 Van Jacobson에 의해서 제안되고 이를 구현한 TCP를 흔히 TCP Tahoe라고 한다.

모든 TCP의 손실 복구 과정은 Fast Retransmit으로 시작된다. Fast Retransmit의 동작을 설명하기에 앞서,

중복 승인 (Duplicate Acknowledgement)을 이해하는 것이 필요하다. 이를 위해 다음 그림 1에 나타난 윈도우

의 크기가 4인 상태에서 패킷 1~4까지의 패킷을 전송하고 이들 중 패킷 2가 손실된 경우를 생각해보자.

 

TCP는 패킷을 수신할 때마다 지금까지 정상적으로 수신된 가장 나중의 패킷을 송신원에게 알려주는데 이를

흔히 누적 승인 방식 (Cumulative Acknowledgement)이라 한다. 패킷 1을 수신한 수신원은 송신원측에 패킷

2를 받을 차례라는 것, 즉 패킷 1까지는 정상적으로 수신되었다는 것을 알려주는 승인 패킷을 전송한다. 패킷

2는 전송 도중 손실되었으므로 수신원은 패킷 2를 수신하지 못한 상태에서 패킷 3을 수신한다. 따라서, 패킷

3을 수신한 수신원은 정상적으로 수신된 마지막 패킷은 패킷 1이고 패킷 2를 받을 차례라는 똑 같은 승인 패

킷을 다시 전달하게 되는데 이를 흔히 중복 승인 (Duplicate Acknowledgement)라고 한다.

송신원이 세 개의 중복 승인을 받게 되면 해당 패킷은 손실되었다고 단정하고 이를 즉시 재전송하는데 이것이

Fast Retransmit 알고리듬의 기본 동작이다. Fast Retransmit 을 사용하지 않는 경우에는 패킷 손실이 발생

하면 항상 재전송 타임 아웃이 만료된 후에 전송을 다시 시작하기 때문에, Fast Retransmit은 TCP의 성능을

크게 향상 시킨다. Fast Retransmit을 동작시키기 위해서 필요한 중복 승인 패킷의 수를 세 개로 정한 것에는

특별한 이론적인 배경은 없다. 다만, IP 패킷들은 서로 다른 경로로 전달되는 경우가 흔히 발생하기 때문에

TCP 패킷들 역시 순서가 바뀐 채로 전달될 수 있다. 이런 경우에 중복 승인을 한 개 받았을 때 무조건 그 패

킷이 손실되었다고 가정하고 Fast Retransmit을 통해 재전송하게 되면 너무 많은 불필요한 재전송을 수행하게

되기 때문에 오히려 성능 저하의 요인이 될 수 있다. 반대로, 패킷 손실이 발생했는데도 이에 대한 세 개의

중복 승인을 수신할 수 없는 경우도 발생할 수 있는데 이 역시 TCP의 성능을 저하시키는 요인이 될 수 있다.

어쨌든 이에 대해서는 많은 연구가 진행되어 왔고 최근 제안된 Limited Transmit 알고리듬을 통해서 거의

100% 해결이 가능하다. (관심 있는 분들은 RFC 3042를 참조하시기 바랍니다.)