요약

  • RFC 7141은 두 가지 결정을 분리한다. 네트워크 장비는 개별 패킷의 마킹 또는 드롭 확률을 패킷 크기에 따라 조정해서는 안 되며, 트랜스포트는 손실되거나 마킹된 패킷을 그 옥텟 수에 비례해 해석해야 한다.
  • 이 분리는 작은 패킷에 네트워크가 만들어 준 할인을 주는 일을 피하면서, 트랜스포트의 반응 방식을 강제하거나 동일 비트 전송률을 약속하거나 이 관행이 얼마나 널리 배치되었는지 증명하는 일을 하지 않는다.

같은 전송률, 25배 많은 패킷

패킷은 라우터에게는 작업 단위이자 링크에게는 바이트의 담겨 있음이다. 이 차이는 네트워크가 큐가 단순히 차기 전에 혼잡을 신호하려 할 때, 즉 능동 큐 관리(AQM)에서 결정적으로 중요해졌다. 1990년대 후반 Random Early Detection(RED)이 이 논쟁의 틀을 잡는 데 기여했다. RFC 2309는 패킷 손실이 대역폭을 더 정확히 반영하도록 하는 방법으로 바이트 모드 드롭을 논의했다. 그러나 작은 패킷이 더 낮은 드롭 확률을 받으면, 패킷 크기 자체가 이점이 된다.

2014년에 Best Current Practice로 발표된 RFC 7141은 이 질문을 다시 살폈다. 문서의 예시는 48 Mbps의 두 흐름을 비교한다. 하나는 60바이트 패킷을, 다른 하나는 1,500바이트 패킷을 보낸다. 작은 패킷은 수가 25배 많다. 모든 패킷에 대해 0.1%의 패킷 모드 드롭 확률을 적용하면, 작은 패킷 흐름은 더 많은 패킷을 잃지만 이 예시에서는 두 흐름이 잃는 비트 수가 같다. 바이트 모드 드롭은 작은 패킷의 확률을 25분의 1로 낮춘다. 그 결과 패킷 손실은 동등해지지만, 작은 패킷 흐름이 잃는 비트는 훨씬 적다. 이것은 예시의 산수가 만들어 낸 결과이며, 실제 네트워크에서 측정한 값이 아니다.

RFC의 답은 의도적으로 분리되어 있다. 네트워크에서는 특정 패킷을 드롭하거나 ECN 마킹할 확률이 그 패킷의 크기에 의존해서는 안 된다. RED의 바이트 모드드롭변형은 사용하지 말아야 한다. 작은 패킷이 마킹될 가능성을 낮추는 것은 단편화에 보상을 주고 잘게 쪼개진 패킷의 홍수를 부를 수 있다. 그러나 이 문서는 바이트 모드큐 측정까지 거부하지는 않는다. 비트로 한계가 정해진 링크는 큐를 바이트 단위로 측정해야 하고, 패킷 처리 작업으로 한계가 정해진 자원은 패킷 수를 셀 필요가 있을 수 있다. 측정 단위와 마킹 선택 편향은 서로 다른 결정이다.

트랜스포트 쪽에서 RFC 7141은 손실되거나 마킹된 패킷의 혼잡 표시를 그 옥텟 수에 비례해, 즉 마치 표시가 각 바이트에 적용되는 것처럼 읽으라고 권한다. 이렇게 하면 엔드포인트가 공유 네트워크 장비에게 어떤 트랜스포트의 공정 개념을 강제할지 추론하도록 요구하지 않고도 신호의 강도를 계산에 반영할 수 있다. RFC는 이를 해석 목표라고 부른다. 모든 트랜스포트에 알고리즘을 바꾸라고 명령하지는 않으며, TCP 흐름이 동일한 비트 전송률에 도달해야 한다고 명시적으로 말하지도 않는다. 동일한 전송률을 원한다면 그 해결책은 네트워크가 아니라 TCP를 바꾸는 것이다.

이 구분은 ECN 마킹된 패킷이 분할되거나 병합될 때도 중요하다. 권장되는 계산 방식은 구식 프로토콜과의 호환성 조건 하에 변환 과정에서 마킹된 옥텟을 보존한다. 이후 RFC 7567이 RFC 2309의 일반 AQM 권고를 대체하며 RFC 7141의 분리를 인용했다. RFC 7141 자체의 RED 구현 조사는 한계가 명시되어 있었고, 바이트 모드 드롭의 설치 기반은 거의 또는 전혀 발견하지 못했다. 이 문서들이 확립한 것은 공학적 권고와 역사적 논쟁이지, 보편적 채택이나 관측된 공격, 현재의 설정이 아니다.

출처:RFC 7141·RFC Editor 기록·RFC 2309·RFC 2914·RFC 3168·RFC 7567·RFC 5681·RFC 6679·RFC 3550·RFC 2474