요약

  • 중복 통지는 한 번의 재전송이 불필요했다는 사실은 보여줄 수 있지만, 같은 윈도우의 모든 세그먼트가 안전하게 도착했다는 사실은 보여주지 못한다.
  • RFC 3708은 이전 윈도우에서 재전송된 모든 단위가 확인 응답을 받고 중복으로 표시된 경우에만, 그리고 중단 조건이 발동하지 않은 경우에만 혼잡 상태 되돌림 결론을 허용한다.

시사적인 사례는 거의 함정에 가깝다. 송신자가 세그먼트 N과 N+1을 재전송했다고 하자. 실제로 잃어버린 것은 N뿐이고, N+1은 단지 지연되었을 뿐이다. 수신자가 N+1을 중복으로 보고하면, 송신자는 유용한 사실 하나를 알게 된다. N+1의 재전송은 불필요했다는 것. 그러나 네트워크가 아무것도 잃지 않았다는 사실을 알게 된 것은 아니다. 세그먼트 N은 여전히 실제 손실 신호이므로, 윈도우 전체에 대해 혼잡 상태를 복원하면 여전히 중요한 증거를 지워버리게 된다.

바로 이 구분이 RFC 3708의 핵심이다. 2004년 2월에 실험(Experimental) 메모로 발표된 이 문서는 TCP의 중복 선택 확인 응답(DSACK)과 SCTP의 중복 전송 시퀀스 번호(TSN) 보고에서 나오는 중복 통지를 보수적으로 활용하는 방법을 다룬다. 문서는 두 가지 서로 다른 용도를 제시한다. 스택은 회계나 모니터링을 위해 단순히 중복 통지를 집계할 수 있다. 반면 혼잡 제어 변경을 되돌릴지 판단하는 송신자에게는 훨씬 까다로운 판별 알고리즘이 필요하다.

알고리즘은 먼저 보고된 시퀀스 범위나 TSN이 재전송되었는지를 묻는다. 윈도우 내에서 한 번보다 많이 재전송되었다면 처리는 거기서 멈춘다. 송신자는 이전 혼잡 상태를 복원하지 않는다. 송신자가 한 번도 재전송하지 않은 데이터라면, 그 중복은 대신 네트워크가 패킷을 복제했다는 신호일 수 있다. 이 경우 RFC 3708은 해당 연결의 나머지 기간 동안 이 알고리즘의 사용을 중단한다. 이후의 중복 보고는 송신자 자신의 불필요한 재전송에 대한 증거로 해석하기 더 어려워지기 때문이다.

한 번의 재전송과 일치하는 보고조차 충분하지 않다. 송신자는 이전 데이터 윈도우에서 재전송된 모든 세그먼트나 청크를 확인한다. 그 모든 것이 확인 응답을 받고 중복으로 표시되었을 때에만, RFC 3708은 해당 재전송들이 모두 불필요했고 윈도우에 손실이 없었다고 결론짓는다. 하나의 재전송이라도 표시되지 않고 남아 있다면, 알고리즘은 그 통지로부터 어떤 결론도 끌어내지 않는다. 추가로, 비어 있는 TCP SACK 스코어보드와SND.UNA에서 시작하는 DSACK이라는 패턴을 다루는 보호 장치가 있다. 이는 ACK 윈도우 전체가 유실되었을 가능성과 부합하는 패턴이며, 이 경우 계속해서 속도를 낮추는 것이 보수적인 선택이다.

따라서 이 알고리즘에는 메모리가 필요하다. 일반적인 SACK 복구 상태 외에도, 구현은 어떤 시퀀스 번호나 TSN이 이미 중복으로 확인 응답을 받았는지를 추적해야 한다. 이 비용은 수신자의 정직함이나 경로상의 모든 사건에 대한 확신이 아니라, 신중하게 한정된 추론을 얻기 위한 것이다. RFC 3708의 보안 섹션은 실제 손실 상황에서 수신자가 순서가 어긋난 데이터를 중복으로 잘못 표시해 안전하지 않은 혼잡 상태 변경을 유발할 수 있다고 경고한다.

RFC 2883은 TCP 수신자가 D-SACK 블록으로 중복 데이터를 표현하는 방법을 정의할 뿐, 송신자가 어떻게 대응해야 하는지는 말하지 않는다. RFC 3522의 Eifel 알고리즘은 다른 증거 경로를 따른다. TCP 타임스탬프를 사용하면 불필요한 재전송을 더 빨리 탐지할 수 있지만, 모든 패킷에 타임스탬프 옵션을 실어야 하는 비용이 든다. RFC 3708은 더 느리지만, 그 교훈은 단일 패킷보다 넓다. 불필요한 재전송을 식별한 다음, 그 증거가 윈도우 전체를 말끔히 해소하는지 별도로 묻는 것이다. 이 문서는 탐지 이후에 어떤 조치를 취할지는 규정하지 않는다.

출처:RFC 3708,RFC 3708 상태,RFC 2883,RFC 3517,RFC 3522,RFC 2960,RFC 4960.