요약

  • 비례 전송률 감소(Proportional Rate Reduction, PRR)는 각 ACK가 보고하는 전달 진행 상황을 사용해 상한이 있는 전송 허용량을 계산하며, 실제 전송 중인 데이터를 별도의 모듈이 선택한 목표값 쪽으로 이동시킨다. 복구를 하나의 갑작스러운 창 축소로 취급하지 않는다.
  • 그 ACK는 범위가 좁은 운영 영수증일 뿐, 경로가 회복되었다는 증명이 아니다. 신뢰할 수 있는 배포는 누가 목표를 선택했는지, 어떤 PRR 분기가 실행되었는지, 실제 무엇이 전송되었는지, 그리고 페이싱과 결과가 주장과 일치했는지를 보존해야 한다.

종단은 그 과정을 감추었다

손실로 인해 혼잡 제어 알고리즘이 복구 목표를 10으로 선택해야 하는 상황에서 전송 중 세그먼트가 20개인 TCP 송신자를 생각해 보자. 구식 복구 방식은 창을 즉시 줄이고, 추정 전송량이 빠져나갈 때까지 기다린 뒤, 여러 세그먼트를 한꺼번에 내보낼 수 있다. RFC 9937의 계산 예제는 이 정지를 “반 창의 침묵(half window of silence)”이라고 부른다. 반대로 또 다른 추정기 불연속성은 정반대의 문제, 즉 갑작스러운 허용량과 버스트를 만들어 낼 수 있다.

이번에는 두 번째 송신자를 생각해 보자. 이 송신자도 같은 목표값 10에 도달하지만, 확인 응답(ACK)이 돌아오는 대로 전송 중 데이터를 점진적으로 줄인다. 각 ACK는 절제된 하나의 대응만을 허용한다. 최종 산술 결과는 동일하게 보일 수 있지만, 네트워크에 제시되는 트래픽은 그렇지 않다.

비례 전송률 감소(Proportional Rate Reduction), 즉 PRR의 출발점이 바로 이 문제였다. 낀디타 듀키파티(Nandita Dukkipati), 맷 매시스(Matt Mathis), 유충 청(Yuchung Cheng), 모니아 고바디(Monia Ghobadi)의 2011년 논문은 짧은 플로우, 응용 정지, 버스트 손실, ACK 손실과 재정렬, 그리고 스트레치 ACK를 검토했다. 이 연구는 기존 메커니즘이 창을 과잉 축소하거나 큰 버스트를 보낼 수 있음을 보고했다. 그 연구에서 PRR과 함께 진행된 조기 재전송(early retransmit) 작업은 손실을 경험한 TCP 연결의 지연 시간을 응답 크기에 따라 3–10% 줄였다. 이것은 측정된 역사적 결과이며, 모든 경로에 대한 약속은 아니다.

이어 2013년에 실험적 RFC 6937이 매시스, 듀키파티, 청의 저자로 발표되었다. 2025년 12월, 매시스, 닐 카드웰(Neal Cardwell), 청, 듀키파티의 저자로 표준 트랙(Standards Track) RFC 9937이 이를 대체했다. 여기서는 이 연구 계보를 전체로서 다룬다. 듀키파티에게 단독 발명이 돌려지는 것도, 모든 구현에 대한 책임이 지워지는 것도 아니다. 그녀의 기록된 역할은 최초의 측정 문제를 실험으로 이어가고, 다시 개정된 표준으로 이어가는 연결이다.

하나로 뭉개면 안 되는 세 가지 결정

PRR은 세 가지 결정을 분리해 두면 훨씬 이해하기 쉽다.

첫째, 혼잡 제어 알고리즘이ssthresh를 선택한다. 이번 복구 에피소드가 끝날 때 전송 중에 유지하기 원하는 데이터 양이다. Reno, CUBIC 또는 다른 호환 컨트롤러가 그 선택을 할 수 있다. PRR은 혼잡이 얼마나 심한지를 판단하지 않고, 목표를 정하는 주체도 아니다.

둘째, 복구 메커니즘은 확인 응답을 관찰하고 진행 상황을 추정한다. RFC 9937은DeliveredData를, 현재 ACK가 이전 ACK 이후 수신자에게 도달했다고 말하는 바이트 수에 대한 송신자의 최선 추정으로 정의한다. “최선 추정”이라는 표현이 중요하다. ACK는 특정 관찰 지점에서 온 증거를 실어 오는 것이며, 경로에 대한 완전한 진단이 아니다.

셋째, PRR은 그 ACK에 응답하여 송신자가 전송할 수 있는 바이트 수인SndCnt를 계산한다. 그 바이트가 재전송인지 새 데이터인지는 별도의 선택 함수가 결정한다. PRR은 양과 시점을 규제할 뿐, 전송 내용을 고르지 않는다.

실무에서 이 분리는 최소 사양이다. 공통 계산은 정밀하며, 미래의 선택과 로컬 선택은 관련 상태를 실제로 갖고 있는 모듈에 남는다. 어떤 ACK도 보편적 지시로 격상되지 않는다. 어떤 표준 문서도 실행 중인 종단이 되지 않는다.

전달된 진행 상황이 전송 클록이 된다

복구 시작 시 송신자는 이 에피소드 동안 전달될 것으로 믿는 전송량 크기를 기록하는데, 이를RecoverFS라고 부른다. 동시에 두 개의 카운터를 시작한다. 누적 전달 진행 상황인prr_delivered와 복구 중 전송된 데이터인prr_out이다.

추정 전송 중 데이터가ssthresh보다 큰 동안, 핵심 비례 계산은 원래 전송량 중 지금까지 전달 보고된 비율과 축소된 목표를 근거로 지금까지 얼마를 내보냈어야 했는지를 묻는다. 송신자는 그 허용량을 올림하고 PRR이 이미 보낸 양을 빼서 다음SndCnt를 얻는다.

그 결과는 네트워크가 다시 건강하다고 알려주는 타이머가 아니다. 영수증이 발동시키는 예산이다. 전달 진행이 작은 단위로 도착하면 전송도 작은 단위로 따라간다. ACK가 유실되더라도 나중 ACK가 더 많은 누적 전달을 보고할 수 있으며, 계산은 따라잡되 추정기 불연속성에 무제한 버스트를 넘겨주지는 않는다.

이것이 더 깊은 성취다. PRR은 매 전송 전에 혼잡에 관한 형이상학적 진실을 알 필요가 없다. 좁은 동작을 위해 좁고, 로컬에서 검증 가능한 신호를 사용한다. 목표는 혼잡 컨트롤러가 둔 그 자리에 그대로 있다.

목표값 아래에서의 주의

손실은 추정 전송 중 데이터를ssthresh아래로 내려놓을 수 있다. 그 지점에서 지나치게 보수적인 송신자는 복구가 너무 느려질 수 있지만, 무단 가속은 또 다른 손실 에피소드를 만들어 낼 수 있다. RFC 9937은 두 개의 감소 상한으로 이를 다룬다.

기본인 보수적 감소 상한(Conservative Reduction Bound)은 추가 전송량을 전달된 데이터에 밀접하게 묶는다. 느린 시작 감소 상한(Slow Start Reduction Bound)은SafeACK를 충족하는 ACK에 대해 한 번의 최대 세그먼트만큼 더 공격적일 수 있다. 이 플래그는 누적 확인 진행과, 그 ACK가 새 손실을 표시하지 않았다는 사실을 요구한다.

2025년 개정판은 이 선택을 적응적으로 만들었다. 토큰 버킷 트래픽 폴리서에 관한 연구는 이전 설계가 잘 다루지 못한 사례를 드러냈다. 토큰이 고갈되면 폴리서는 자신의 보충률을 송신자에게 먼저 드러내지 않은 채 높은 비율로 폐기를 시작할 수 있다. 따라서 이전 성능에서 추론된 목표는 지나치게 낙관적일 수 있다. 보수성이 기본이며, 추가 세그먼트는 명시된 진행 증거로 획득하는 것이다.

여기서조차 이름이 증거를 앞서서는 안 된다.SafeACK는 경로가 안전하다는 뜻이 아니다. 이 복구 계산의 이 분기에 대해, 제한된 추가 허용량에 필요한 두 가지 사실을 그 ACK가 담고 있다는 뜻이다.

완료는 면죄가 아니다

PRR은 매 전송마다prr_out을 갱신한다. 복구 에피소드가 완료되면 알고리즘은 혼잡 창을ssthresh로 설정한다. 이는 종단을 명시적으로 만들지만, RFC 9937은 불편한 경계 하나도 기록한다. 완료 단계는 일부 시나리오에서 연속 버스트를 허용할 수 있다는 것이다. 표준은 버스트성을 줄이기 위해 페이싱을 권장한다.

따라서 이 사양은 모든 타이밍 위험에 대한 승리를 선언하지 않는다. 때로 PRR과 함께 언급되는 부드러운 페이싱 효과가 모두 정량화되었다고도 주장하지 않는다. 알고리즘, 인터페이스, 그리고 알려진 한계를 제시할 뿐이다.

RFC 9937은 PRR이 2011년 최초의 광범위 배포 구현 이후 리눅스 TCP의 기본 및 지원 혼잡 제어 모듈을 위한 빠른 복구 알고리즘으로 기능해 왔다고 기록한다. 이는 중요한 구현 역사다. 그래도 어제 특정 커널이 어떤 분기를 실행했는지, 페이싱이 활성화되었는지, 특정 서비스가 논문의 지연 효과를 보았는지는 증명하지 않는다.

운영자가 보관해야 할 영수증

방어 가능한 PRR 주장은 제품 라벨이 아니라 에피소드 기록에서 시작된다. 기록은 전송 계층 빌드와 혼잡 제어 모듈, 손실 감지 트리거, 시작 시점의cwnd,inflight,RecoverFS, 그리고ssthresh를 선택한 구성 요소와 구성을 식별해야 한다.

관련된 각 ACK에 대해 기록은 누적 진행, 새로 보고된 손실,DeliveredData,SafeACK결과와 사유, 선택된 비례/CRB/SSRB 분기, 계산된SndCnt, 실제 전송된 바이트, 그 결과의prr_out을 보관해야 한다. 재전송과 새 데이터 사이의 별도 선택도 식별해야 한다.

완료 시점에는 운영자가 최종 창과 전송량 추정, 페이싱 상태, 버스트·타임아웃·반복 손실 여부, 그리고 비교 가능한 통제 코호트에 대한 지연과 유효 처리량(goodput) 분포를 확보해야 한다. 테스트에는 재정렬, 응용 정지, 지원되는 경우 SACK 및 비-SACK 사례, 그리고 토큰 버킷 폴리싱이 포함되어야 한다. 부정적 증거도 기록에 들어간다. 경로나 응용의 결과가 나쁜 채로도 ACK 진행은 계속될 수 있기 때문이다.

이 장부는 주장의 위계를 보존한다. ACK는 전달을 관찰했다. 혼잡 컨트롤러가 목표를 골랐다. PRR은 전송량을 계산했다. 또 다른 함수가 바이트를 골랐다. 실행 중인 코드가 그것을 보냈다. 결과를 확립하는 것은 RFC 제목이 아니라 측정이다.

출처