요약

  • RFC 3517은 누적 확인 응답과 SACK 블록을 송신 측 스코어보드로 변환한 뒤,SetPipe()를 사용해 아직 전송 중으로 취급해야 하는 옥텟 수를 추산했습니다.
  • 송신 측은 어느 사본이 네트워크를 벗어났는지 알 수 없었기 때문에 이 추산은 재전송된 데이터를 보수적으로 두 벌로 셀 수 있었습니다.cwnd - pipe는 추가 전송을 허가했을 뿐, 경로상의 재고나 전달을 증명하지 않았습니다.

하나의 윈도 안에서 여러 손실이 발생한 뒤의 송신 측을 상상해 보십시오. 누적 확인 응답은 끊기지 않은 접두부가 어디서 끝나는지 알려 줍니다. SACK 블록은 그 간격 너머에서 수신된 구간들을 보고합니다. 그러나 그 어떤 메시지도 라우터 내부에 관찰자를 배치하지 않습니다. 그럼에도 송신 측은 재전송할지, 새 데이터를 보낼지, 아니면 기다릴지를 결정해야 합니다.

RFC 2018은 수신 측의 어휘를 제공했습니다. SACK-Permitted는 선택적 확인 응답 사용을 협상했고, SACK 블록은 불연속적으로 수신된 범위들을 기술했습니다. 이 근거는 다중 손실 이후 불필요한 재전송을 크게 줄였습니다. 그래도 이는 권고 사항이었습니다. 수신 측은 이전에 SACK으로 보고했던 데이터를 버릴 수 있었기 때문에, 송신 측은 누적 확인 응답이 전진하기 전까지는 재전송 버퍼를 해제할 수 없었습니다.

RFC 3517은 그 근거에 보수적으로 대응하는 방법을 제공했습니다. 송신 측은HighACK,HighData,HighRxt,RecoveryPoint와 스코어보드를 유지했습니다.Update()는 누적으로 ACK된 범위와 선택적으로 ACK된 범위를 표시했습니다.IsLost()는 더 높은 시퀀스 번호에 대한 SACK 근거가 임계치를 넘은 뒤에야 해당 시퀀스 번호를 손실로 판정했습니다. 이 판정은 유용했지만, 세그먼트를 드롭한 링크나 큐, 사건 자체를 밝혀 주지는 않았습니다.

그 다음SetPipe()는HighACK부터HighData까지 시퀀스 공간을 훑습니다. 아직 손실로 판정되지 않은 미확인 데이터는 네트워크에 남아 있다고 가정되므로pipe를 증가시켰습니다.HighRxt이하에서 재전송된 옥텟도 마찬가지로 이를 증가시켰습니다. 그 결과는 명시적으로 하나의 추산이었습니다.

가장 말해 주는 규칙은 이중 계산이었습니다. 데이터가 손실로 분류되기 전에 재전송되었다면, 원본과 재전송 사본이 모두pipe에 더해질 수 있었습니다. 송신 측은 두 전송 중 어느 하나만 네트워크를 벗어났는지, 아니면 둘 다 벗어났는지 알 수 없었습니다. 둘 다 세는 것은 과잉 트래픽을 추가로 주입할 위험을 줄였습니다. 이는 불확실성을 거짓 측정으로 세탁하는 대신 통제 변수 안에 새겨 넣은 것입니다.

중복 ACK 임계치가 복구를 열면RecoveryPoint가HighData로 설정되고, 당시의 혼잡 제어 규칙에 따라 혼잡 윈도가 축소되며, 첫 추정 손실이 재전송되고SetPipe()가 실행되었습니다. 이후 각 ACK는 스코어보드를 갱신하고 추산을 다시 계산하게 했습니다.cwnd - pipe가 최소 한 SMSS 분의 여유를 남긴다면NextSeg()가 다음에 보낼 수 있는 것을 골랐습니다.

그 뺄셈은 권한 확인이었지 센서가 아니었습니다. 전송 이후pipe를 증가시키는 것은 송신 측의 장부를 바꿨을 뿐입니다. 이는 패킷이 특정 큐에 들어갔는지, 경로에 남아 있는지, 수신 측에 도달했는지, 애플리케이션에 의해 소비되었는지를 증명하지 않았습니다.RecoveryPoint를 넘어선 누적 ACK는 다른 근거 계층에서 그 에피소드를 종결했습니다.

주변 RFC들이 이 경계를 더 선명하게 만듭니다. RFC 3042의 Limited Transmit은 빠른 재전송 이전에 첫 두 개의 중복 ACK로 새 데이터를 보낼 수 있었습니다. RFC 2883의 D-SACK는 중복 도착을 보고하여 불필요한 재전송이나 재정렬을 드러내는 데 도움을 줄 수 있었습니다. RFC 5681은 혼잡 제어 프레임워크를 기술했고, RFC 6582는 SACK을 요구하지 않으면서 NewReno에 부분 ACK 기반 복구 방식을 부여했습니다. 각 메커니즘은 송신 측이 추론하거나 할 수 있는 것을 바꿨지만, 어느 것도 경로에 패킷 계수기를 설치하지 않았습니다.

타임아웃은 최후의 수단으로 남았습니다. 재전송 타임아웃이 발생하면 수신 측이 약속을 파기(리니그)했을 수 있으므로 이전 SACK 정보를 더 이상 내구성 있는 것으로 다룰 수 없었습니다. 그래서 송신 측의 겉보기에 정밀한 스코어보드는 영구적인 수신 장부도, 애플리케이션 전달의 증명도 아니었습니다.

RFC 6675는 2012년에 RFC 3517을 대체(obsoleted)했습니다. 손실 임계치, 복구 진입, 구제 재전송 규칙을 정교화했지만, 추산이라는 언어와 SACK의 권고적 성격은 유지했습니다. 역사적 교정은pipe가 진실이 되었다는 것이 아니라, 더 잘 규정된 추산이 되었다는 것이었습니다.

RFC 6937은 이후 비례 속도 감소(Proportional Rate Reduction)를 도입하며 전달 기반 복구 페이싱을 RFC 6675의 pipe 알고리즘과 대조했습니다. 이 전환은 중요합니다. 복구 회계는 정책 표면입니다. 서로 다른 알고리즘은 같은 불완전한 근거 위에서 보수적으로 움직일 수 있으며, 그중 어느 것도 네트워크의 직접 측정이 되지 않습니다.

현재 RFC 9293이 TCP 기본 사양을 제공하며, IANA는 SACK-Permitted와 SACK 옵션 할당을 기록합니다. 레지스트리 행은 코드 포인트의 권위를 확립합니다. 이는 특정 연결에서의 협상, 올바른 스코어보드 동작, 특정 손실 사건 또는 전달된 바이트를 증명하지 않습니다.

오래 남는 교훈은 소박하면서도 강력합니다. 인터넷 프로토콜은 현실이 완전히 관찰되기 전에 운영 변수가 필요할 때가 많습니다. 건전한 표준은 그 변수의 근거, 범위, 불확실성을 명명합니다. RFC 3517은pipe로 그렇게 했습니다. 다음 전송을 선택할 만큼의 지식은 있었지만, 네트워크가 계수되었다고 주장할 만한 지식은 아니었습니다.

출처