요약

  • RFC 3148은 하나의 보편적인 네트워크 용량 수치를 정의하지 않았다. 이 문서는 대량 전송 용량(Bulk Transport Capacity)을 전송 동작이 명시되어야 하는 측정군으로 다루었다.
  • 손실 패턴, 재전송 타임아웃, TCP 확인 응답 클록 같은 부수 관찰은 서로 다른 속도를 설명하는 데 도움이 될 수 있지만, 하나의 테스트 플로우가 모든 사용자나 모든 애플리케이션에 대한 판정이 되게 하지는 못했다.

수치는 실험보다 단순해 보였다

두 개의 테스트 호스트가 같은 경로로 큰 파일을 전송한다고 상상해 보자. 각 테스트는 동일한 병목을 채우고 경과 시간 동안의 유용한 데이터를 계산한다. 둘 다 초당 비트 수를 보고한다. 그런데 한 테스트는 손실 묶음에서 빠르게 복구하는 혼잡 제어 알고리즘을 사용하고, 다른 테스트는 확인 응답 클록을 잃고 재전송 타임아웃을 기다린다. 경로는 변하지 않았다. 측정된 속도는 변했다.

이것은 산술의 버그가 아니다. RFC 3148이 이를 드러내고자 한 문제 그 자체다. 2001년 7월에 정보성(Informational) RFC로 발표된 "A Framework for Defining Empirical Bulk Transfer Capacity Metrics"는 대량 전송 용량(BTC)을 일반적으로 TCP인, 혼잡 인식 전송 연결 하나의 장기 평균 속도로 다루었다. 이 문서는 유일하게 전송된 데이터 비트 수를 경과 시간으로 나눈 단순한 필수 수치를 제시했지만, 겉보기 단순함 뒤에 구현 선택이 숨어 있다고 경고했다.

"용량"이라는 단어는 독자에게 링크의 고정된 속성을 상상하게 한다. RFC 3148은 더 신중했다. 그 직관적 기준점은 한 경로 위에서 이상적인 TCP 구현이 보일 것으로 기대되는 장기 속도였다. 그러나 IETF 규격은 여러 혼잡 제어 알고리즘과 그 안에서의 재량을 허용했다. 허용된 선택들이 실질적으로 다른 측정값을 낸다면 "이 경로의 BTC"는 스스로 설명되는 단일 값이 아니다. 방법이 함께 붙어야 했다.

준수하는 TCP는 하나의 고정된 계측기가 아니었다

전송 표준은 모든 구현 세부사항을 지시하지 않고 공유된 동작을 확립한다. 예컨대 RFC 5681은 측정 방식에 중요한 선택을 남겨 둔 채 TCP 혼잡 제어를 기술한다. 따라서 RFC 3148은 각 BTC 방법론이 혼잡 창이 어떻게 성장하는지, 슬로우 스타트 임계점에서 무슨 일이 일어나는지, 어떤 복구 알고리즘을 사용하는지, 세그먼트 크기를 어떻게 고르는지, 재전송 타이밍이 어떻게 작동하는지, 측정 클록을 어떻게 설정하고 읽는지 같은 결정을 명시하도록 요구했다.

이것들은 미관상의 설정이 아니다. 송신자의 속도는 경로에서 돌아오는 확인 응답에 의존한다. 손실은 빠른 재전송과 복구를 촉발할 수도, 송신자를 타이머를 기다리게 둘 수도 있다. SACK 기반 복구, NewReno 동작, 재전송 타임아웃, 송신 버퍼링, 수신 창, 최대 세그먼트 크기는 모두 한 플로우가 어떤 구간 동안 이동시키는 데이터 양을 형성할 수 있다. 관련 메커니즘은RFC 5681,RFC 6298,RFC 2018,RFC 6582,RFC 6675에 걸쳐 문서화되어 있다. 이것들의 존재가 모든 구현을 동등하게 만들지는 않는다. 대신 테스트가 선택한 동작이 결과의 의미의 일부가 되게 한다.

RFC 3148은 더 좁은 "혼잡 회피 용량(Congestion Avoidance Capacity)"을 더 완전한 BTC 측정과 구분했다. 더 좁은 속도는 재전송 타임아웃과 슬로우 스타트 복구가 개입되는 구간을 제외한다. 이것은 정상 상태의 혼잡 회피를 기술할 수 있지만, 실제 대량 전송에 중요한 동작을 생략할 수 있다. 이 RFC의 요점은 어느 쪽 지표가 항상 더 낫다는 것이 아니었다. 이름과 속도가 포함되거나 제외된 전송 동작을 감추어서는 안 된다는 것이었다.

차이를 설명하는 추적 기록을 남겨라

헤드라인 속도는 운영자에게 두 방식이 왜 갈렸는지 말해 줄 수 없다. RFC 3148은 방법론이 부수 측정을 수집하거나, 세그먼트 추적처럼 나중에 그것들을 도출할 수 있을 만큼 충분한 정보를 남기도록 권고했다. 후보에는 손실 묶음, 패킷 재정렬, 재전송 타임아웃, 혼잡 창의 변화, 셀프 클록 유지, 호스트 측 패킷 드롭과 큐잉, 세그먼트 크기, 역방향 경로 부하가 포함된다.

확인 응답 클록은 유용한 예다. TCP는 흔히 이미 전달된 데이터에 대한 확인 응답에 응답해 새 데이터를 보낸다. 이 셀프 클로킹 과정이 깨지면, 타임아웃과 슬로우 스타트 복구가 정상 상태 용량 수치가 놓칠 시간을 소모할 수 있다. 두 방식이 같은 손실 패턴에 복구 동작을 다르게 반응하기 때문에 서로 다른 속도를 보고할 수 있다. 부수 추적은 이 불일치를 조사 가능하게 만들 뿐, 어떤 라우터, 큐 또는 통신사가 원인인지 자동으로 증명하지는 않는다.

이 접근은RFC 2330에 담긴 더 넓은 측정 원칙과 부합한다. RFC 2330은 신중하게 정의된 지표와 그것을 측정하는 방법론을 구분하고, 불확실성과 오류가 이해되기를 요구한다. 혼잡 제어 평가에 관한RFC 5166과 TCP 처리량 테스트에 관한RFC 6349등 이후 작업은 인접한 측정 맥락을 제공한다. 그 문서들이 RFC 3148을 하나의 보편적인 테스트로 바꾸거나 특정 운영자가 하나를 배치했다는 사실을 확립하지는 않는다.

RFC 3148에는 미묘하지만 결과가 큰 경제적 경고가 담겨 있다. 혼잡 제어는 비선형일 수 있기 때문에, 어떤 조건에서는 경로의 링크 속도를 높이는 것이 TCP/BTC 방법이 내는 처리량을 오히려 낮출 수 있다는 것이다. 이 문서는 이것을 가능한 동작과 연구 과제로 제시하며, 현장 보고, 업그레이드에 관한 일반 법칙, 또는 더 많은 대역폭이 보통 사용자에게 해롭다는 증명으로 제시하지 않는다. 이는 수치가 바뀌었을 때 상업적 결론을 내리기 전에 방법 세부사항과 경로 증거를 보존해야 하는 이유다.

용량 테스트는 네트워크도 점유한다

BTC는 몇 개의 수동 관찰이 아니라 상당한 전송으로 측정된다. BTC 테스트는 자연스럽게 병목을 채우려 한다. RFC 3148은 일부 방법이 일반적인 TCP 패킷을 사용하지 않을 수 있고, 네트워크 운영자에게는 서비스 거부 공격처럼 보일 수 있다고 언급했다. 이 RFC는 테스트 당사자들이 측정의 시점, 크기, 빈도를 조정하도록 권고했다. 또한 테스트가 인식되어 의도적으로 다르게 처리될 수 있고, 테스트 트래픽처럼 보이는 패킷이 주입되어 결과가 왜곡될 수 있다고 경고했다.

따라서 운영 표면은 두 종단점보다 넓다. 테스터는 알고리즘, 기간, 버퍼, 계측 장비를 통제한다. 경로는 지연, 손실, 재정렬, 큐 동작을 내놓는다. 운영자는 희소한 용량을 소모하는 공격적인 플로우를 목격할 수 있다. 책임 있는 결과는 이러한 조건을 반복하고 해석할 수 있을 만큼 충분히 기록하며, 테스트 자체가 사용된 경로와 시간창에 대해 승인되어 있어야 한다.

하나의 결과가 말할 수 있는 것과 말할 수 없는 것

RFC 3148은 가까운RFC 3133이야기와 구별된다. RFC 3133은 방향성 프레임 릴레이 전달 비율을 정의하고, 작은 손실 확인 응답이 훨씬 큰 재전송 작업을 촉발할 때 좋은 링크 수준 비율이 열악한 애플리케이션 성능과 공존할 수 있다고 경고한다. 그것은 특정한 전송 회계 메커니즘이다. RFC 3148은 다른 질문을 던진다. 전송 방식들이 다르게 동작하도록 허용되어 있다면, 무엇이 두 개의 단일 플로우 대량 속도 측정을 비교 가능하게 만드는가?

그 답은 방법론적 규율이다. 전송 동작을 명시하라. 부수 증거를 남겨라. 테스트 호스트 자체가 병목이 아닌지 확인하라. 가능하면 정방향 경로 효과를 역방향 경로 부하와 구분하라. 기술된 조건 아래에서 실험을 반복하라. 그러면 결과는 경계를 지닌 진술을 지지한다. 이 명시된 방법이 이 관측된 경로에서 이 구간 동안 이만큼의 유일 데이터를 이동시켰다는 진술이다.

그것은 그 자체로 물리적 링크 속도, 경쟁 플로우가 사용할 수 있는 집계 용량, 모든 TCP 구현의 처리량, 서비스 수준 위반, 애플리케이션의 완료 시간, 또는 사용자가 경험한 것을 확립하지 않는다. 더 높거나 낮은 결과 역시, 그 설명을 검증할 추적 기록과 독립적 증거 없이는 원인을 찾아 주지 않는다.

역사적 기여는 검소하지만 오래 간다. RFC 3148은 단일 라벨이 측정 계측기 내부의 선택을 지워 버리는 일을 거부했다. 헤드라인 수치를 유지하면서 그 방법이 수치와 함께 이동해야 한다고 주장했다.

해석적 틀로서, 나는 Lu Heng의 최소 초기 명세와 지역적 선택에 관한 노트 64, 그리고 형식적 기술을 관측 가능한 현실과 구별하는 노트 20을 참고한다. 이것들은 편집적 틀이며, RFC 3148의 저자들이 주장한 것이 아니다.

출처

  1. RFC 3148 — A Framework for Defining Empirical Bulk Transfer Capacity Metrics
  2. RFC Editor record for RFC 3148
  3. RFC 2330 — Framework for IP Performance Metrics
  4. RFC 3133 — Terminology for Frame Relay Benchmarking
  5. RFC 5166 — Metrics for the Evaluation of Congestion Control Algorithms
  6. RFC 6349 — Framework for TCP Throughput Testing
  7. RFC 5681 — TCP Congestion Control
  8. RFC 6298 — Computing TCP's Retransmission Timer
  9. RFC 2018 — TCP Selective Acknowledgment Options
  10. RFC 6582 — The NewReno Modification to TCP's Fast Recovery Algorithm
  11. RFC 6675 — A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment
  12. Lu Heng, Note 64 — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  13. Lu Heng, Note 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile