타임아웃(Timeout)
rdt 프로토콜처럼 TCP가 손실 세그먼트를 발견하기 위해서 타임아웃/재전송 매커니즘을 사용한다는 것을 알아봅시다.
이 매커니즘을 구현할 때 가장 중요한 점은 타임아웃 주기일 것입니다.
타임아웃 주기를 얼만큼 잡느냐에 따라 애플리케이션의 네트워크 성능은 크게 달라질 것입니다.
왕복시간 예측
타임 아웃을 계산하기 위해선 송신자와 수신자 사이의 왕복시간(round-trip time)을 어떻게 예측해야 하는지를 생각해야 합니다.
sampleRTT라고 표시되는 세그먼트에 대한 RTT 샘플은 세그먼트가 송신된 시간(IP에게 넘겨진 시간) 으로부터 그 세그먼트에 대한 긍정응답이 도착한 시간까지의 시간 길이입니다.
TCP는 모든 전송된 세그먼트에 대해서 sampleRTT를 측정하는 대신, 대부분의 TCP는 한 번에 하나의 SampleRTT 측정만을 시행합니다.
재전송한 세그먼트의 경우에는 sampleRTT를 측정하지 않습니다. 그 이유는 송신측 입장에서 재전송한 세그먼트는 ACK가 첫 전송에 의한 것인지, Retransmit에 의한 것인지 알 수 있는 방법이 없습니다.
즉, 어떤 시점에서 sampleRTT는 전송되었지만 현재까지 확인응답이 없는 세그먼트 중 하나에 대해서만 측정 되며, 이는 대략 왕복시간마다 sampleRTT의 새로운 값을 얻게 됩니다.
이 부분의 말이 헷갈릴 수 있는데, 본인이 판단하기로는 다음과 같습니다.
일단, 모든 세그먼트에는 각자의 타이머가 존재합니다. 여기서 만약 한 세그먼트가 도착을 해서 sampleRTT값을 가져왔다면 다음 세그먼트가 도착할 때까지 공백의 시간이 있을 것입니다. 그래서 timer를 다시 시작하고 나서 도착하는 세그먼트로 다시 측정한다는 의미같습니다. (이 부분에 연산 과정이 관련 있는지는 찾아봐도 발견을 하지 못해서 모르겠네요..)
왜 이런 차이가 발생하는 것일까요?
이것은 라우터에서의 혼잡과 종단 시스템에서의 부화 변화때문에 세그먼트마다 차이를 보이는 것입니다.
따라서, 대채로 RTT를 추정하기 위해서 sampleRTT 값의 평균값을 채택합니다.
긍정 확인응답을 수신하고 새로운 sampleRTT를 획득하자마자 TCP는 다음 공식에 따라 EstimatedRTT를 갱신합니다.
여기서 권장되는 α의 값은 α = 0.125[RFC 6298]입니다.
EstimatedRTT는 SampleRTT값의 가중평균(weighted average)을 유념하자.
이 가중 평균은 예전 샘플보다 최근 샘플에 높은 가중치를 줍니다. 더 최근 샘플들이 네트워크상의 현재 혼잡을 더 잘 반영하기 때문입니다. 통계에서 이런 평균은 지수적 가중 이동 평균(exponential weighted moving average, EWMA)이라고 부릅니다.
주어진 sampleRTT의 가중치가 갱신 절차가 진행됨에 따라 빠르게 지수적으로 감소하므로 EWMA에서 "지수적(exponentia)"이라는 용어가 쓰입니다.
SampleRTT값들과 EstimatedRTT를 이용해서 RTT의 변화율(variation) DevRTT도 구할 수 있습니다.
DevRTT는 SampleRTT와 EstimatedRTT값 차이의 EWMA임을 기억합시다.
참고로 β의 권장값은 0.25입니다.
재전송 타임아웃 주기의 설정 관리
이제 주기를 결정해야 하는데 분명한 것은 주기는 EstimatedRTT보다는 커야할 것입니다.
만약 그렇지 않다면, 불필요한 재전송이 보내질 것입니다.
그렇다고 너무 크게 잡는 것도 안될 것입니다.
그러므로 타임아웃 값은 EstimatedRTT에 약간의 여유값을 더한 값으로 설정해야 하는 것이 바람직할 것입니다.
SampleRTT값에 많은 변동이 있을 때에는 여유값이 커야 하며, 변동이 작을 때는 작아야 합니다.
따라서, 이 역할을 DevRTT가 수행하게 됩니다.
초기 TimeoutInterval의 값으로 1초를 권고합니다[RFC 6298].
또한 타임아웃이 발생했을 경우, TimeoutInterval의 값은 두 배로 하여 조만간 확인응답 할 후속세그먼트에게 발생할 수 있는 조기타임아웃을 피하도록 합니다.
Reference
