[Network] 왕복 시간(RTT) 예측과 타임아웃 주기 설정

왕복 시간(RTT) 예측

SamepleRTT : RTT 샘플 세그먼트
- RTT(Rount-trip time) : 세그먼트가 송신된 시간부터 긍정 확인응답될 때까지의 시간의 길이
TCP는 한 번에 하나의 SampleRTT만 측정
→ 모든 전송된 세그먼트에 대해 SampleRTT를 측정하지 않는다.
→ SampleRTT가 전송되었지만 현재 확인응답이 없는 세그먼트 중 하나에 대해서만 측정됨
- 이 측정시간은 왕복시간마다 SampleRTT의 새로운 값을 얻게 한다.
- TCP는 재전송한 세그먼트에 대한 SampleRTT는 계산하지 않고,
- 한 번 전송된 세그먼트에 대해서만 측정한다.

해당 값은 라우터에서의 혼잡과 종단 시스템에서의 부하 변화 때문에 세그먼트마다 다름
→ 이러한 변동성 때문에 주어진 SampleRTT 값은 불규칙적이다.
대체로 RTT를 추정하기 위해 SampleRTT 값의 평균값을 채택
→ EstimatedRTT
- TCP는 EstimatedRTT(Sample RTT 값의 평균)을 유지한다.

긍정 확인응답을 수신하고 새로운 SampleRTT를 획득하면, 공식에 따라 EstimatedRTT를 갱신
EstimatedRTT의 새로운 값은 이전 값과 SampleRTT에 대한 새로운 값의 가중된 조합임
EstimatedRTT는 SampleRTT 값의 가중 평균(weighted average) 임
- 가중 평균은 예전 샘플보다 최근 샘플에 높은 가중치를 줌
  → 최신 샘플들이 네트워크상의 현재 혼잡을 더 잘 반영
  - 이런 평균을 지수적 가중 이동 평균(EWMA)라고 부른다.
    - SampleRTT의 가중치가 갱신됨에 따라 빠르게 지수적으로 감소

DevRTT를 SampleRTT가 EstimatedRTT로부터 얼마나 많이 벗어나는지에 대한 예측
- DevRTT : RTT의 변화율을 의미
DevRTT는 SampleRTT와 EstimatedRTT 값 차이의 EWMA임
- SampleRTT 값이 어떠한 변화도 없다면 DevRTT 값은 작음
- SampleRTT 값이 변화가 크다면 DevRTT 값은 큼
ß의 권장값은 0.25

타임아웃 주기는 EstimatedRTT보다 크거나 같아야 한다.
- 작다면 불필요한 재전송이 보내질 것
그렇다고 타임아웃 주기가 EstimatedRTT보다 너무 크면 안 된다.
← 너무 크면 세그먼트를 잃었을 때, TCP는 세그먼트의 즉각적인 재전송을 하지 않게 됨
- 이 때문에 애플리케이션에서 확연한 데이터 전송 지연이 발생
바람직한 타임아웃 값 → EstimatedRTT에 약간의 여유값을 더한 값

이러한 모든 고려사항은 재전송 타임아웃 주기를 결정하는 TCP 방식에서 사용됨
초기 TimeoutInterval의 값은 1초로 권고함
타임아웃이 발생할 시
- TimeoutInterval 값을 2배로 함
  → 곧 확인응답할 후속 세그먼트에게 발생할 수 있는 조기 타임아웃을 피하도록
세그먼트가 수신되고 EstimatedRTT가 수정되는 경우(타임아웃 발생 X)
- TimeoutInterval은 다시 위의 공식에 따라 계산됨

기존에는 마지막 EstimatedRTT와 DevRTT로부터 타임아웃값을 가져왔음
타임아웃 주기를 이전 값의 두 배로 설정한다.
- 타임아웃이 발생
  → TCP는 아직 확인응답 안 된 가장 작은 순서 번호의 세그먼트를 재전송
- 그러나 다른 이벤트(ACK 수신과 상위 애플리케이션으로부터의 데이터 수신) 이후
  → 타이머가 시작될 때 TimeoutInterval은 EstimatedRTT와 DevRTT의 가장 최근값에서 가져옴
예시
1. 타이머가 먼저 만료
  → 가장 이전의 확인응답이 안 된 세그먼트와 연관된 TimeoutInterval 확인
  - 여기서는 0.75초라고 가정
2. TCP는 이 세그먼트를 재전송하고 새로운 종료 소요 시간을 1.5초로 함
  → 이 주기는 각 재전송 후에 지수적으로 증가한다.
이러한 수정은 제한된 형태의 혼잡 제어를 제공한다.
- 타이머 종료는 주로 네트워크에서의 혼잡에 의해 발생
  - 송수신 중 라우터 버퍼에 도착한 과도한 양의 패킷은 패킷의 손실이나 오랜 큐 대기의 원인
    → 혼잡할 때 출발지에서 지속적으로 패킷 재전송을 하면 더욱 혼잡해짐
- 이러한 수정은 TCP는 송신자가 더 긴 간격으로 재전송하도록 함