요약

  • RFC 791은 Type of Service 옥텟을 우선순위(precedence)와 별도의 지연, 처리량, 신뢰성 지표로 나누었고, RFC 1349는 이후 서비스 유형을 4비트 단일 선택으로 정하고 화폐 비용 항목을 추가했습니다.
  • RFC 2474는 이 구조를 홉별 동작(per-hop behavior)을 선택하는 6비트 DSCP로 대체했으며, RFC 3168은 나머지 2비트를 명시적 혼잡 통지(ECN)에 배정했습니다.

RFC 791만으로 작성된 IPv4 구현과 20년 뒤 작성된 구현은 같은 옥텟을 보고 서로 다른 구조를 읽어낼 수 있습니다. 필드는 헤더의 같은 자리에 있었습니다. 해석은 중요성과 원하는 품질을 압축적으로 표현하는 방식에서, 서로 다른 주인을 가진 두 메커니즘, 즉 차등화된 포워딩 처리와 혼잡 신호 방식으로 이동했습니다.

이것은 단순한 이름 바꾸기가 아니었습니다. 후속 사양들은 비호환성을 공개적으로 인정하고, 유용한 곳에는 호환 코드포인트를 예약하며, 정책을 행정 경계 쪽으로 옮겼습니다. 이 옥텟은 배포된 와이어 포맷이 물리적으로 커지지 않으면서 어떻게 진화할 수 있는지를 보여주는 사례가 되었습니다.

품질이 스위치 집합이던 시절

RFC 791은 이 필드를 Type of Service라고 불렀습니다. 처음 3비트는 Routine부터 네트워크 제어 트래픽에 이르는 여러 상위 등급을 포함한 Precedence를 담았습니다. 다음 3비트는 낮은 지연, 높은 처리량, 높은 신뢰성을 각각 독립적으로 요청했습니다. 마지막 2비트는 미래 사용을 위해 예약되었습니다.

사양은 가운데 선택지를 절충 관계로 규정했습니다. 한 차원에서의 성능 향상은 다른 차원을 악화시키거나 어떤 의미에서 서비스 비용을 높일 수 있었습니다. 특수한 경우를 제외하고는 세 가지 지표 중 두 개 이상을 설정하지 말 것을 권고했습니다. 패킷은 보편적인 처리를 명령하는 것이 아니라, 특정 네트워크가 실제 제공하는 서비스에 매핑될 수 있는 추상적 품질을 서술하고 있었습니다.

이 구분이 중요한 이유는 네트워크들이 하나의 큐잉 시스템이나 하나의 경제 모델을 공유하지 않았기 때문입니다. 낮은 지연 요청은 그런 선택이 존재하는 곳에서 경로나 서비스 선택에 영향을 줄 수 있었지만, 비트 자체가 용량을 만들어 낼 수는 없었습니다. Precedence 역시 중요성을 서술할 뿐, 모든 행정 도메인이 같은 특권을 존중하게 만들지는 못했습니다.

비트 조합에서 하나의 요청 유형으로

RFC 1349는 수년간 상충하는 정의들 끝에 1992년 이 옥텟을 다시 다루었습니다. 서비스 부분을 4비트로 고정하고, RFC 791과 달리 독립적인 스위치가 아니라 단일 열거형 값으로 취급했습니다. 인식되는 선택지는 최소 지연, 최대 처리량, 최대 신뢰성, 최소 화폐 비용, 또는 일반 서비스를 요청하는 것이었습니다.

이 변경은 임의의 조합이 우연한 의미를 갖는 것을 막았습니다. 송신자는 하나의 절충안을 요청했고, 논리 OR로 여러 값을 결합하는 방식은 더 이상 여러 품질을 요청하는 유효한 방법이 아니었습니다. 비용 값은 또한 RFC 791이 더 나은 서비스의 가능한 결과로만 언급했던 차원을 명시적으로 드러냈습니다.

RFC 1349는 여전히 요청 수위를 절제했습니다. 새로운 서비스 유형을 배포할 수 있도록 고정 크기 필드를 추구했고, 호스트와 라우터는 그 의미를 이해할 필요 없이 낯선 유형을 올바르게 처리해야 한다고 말했습니다. 신호는 선호를 서술한 것입니다. 경로가 요청된 속성을 실제로 전달할 것을 보장하지 않았습니다.

필드가 동작 선택자가 되다

1998년 무렵 RFC 2474는 TOS 정의를 Differentiated Services 필드로 대체했습니다. 6비트는 구조화되지 않은 Differentiated Services Codepoint, 즉 DSCP가 되었습니다. 규격을 따르는 노드는 6비트 값 전체를 매칭하고 이를 사용해 그 노드에 구현된 홉별 동작을 선택합니다. 매핑은 설정 가능해야 합니다.

이 변경은 이름 붙은 소수의 종단 간 열망 어휘를, 포워딩 처리를 위한 더 큰 선택자로 바꾸었습니다. 코드포인트는 동작을 식별할 수 있었지만, 연산자는 여전히 로컬 매핑과 트래픽 조건화를 통제했습니다. 노드는 행정 경계에서 DS 필드를 재작성할 수 있었습니다. 도메인 간 서비스 수준 관계가 기본 필드만으로 표현할 수 없는 변환을 규율했습니다.

RFC 2474는 새 레이아웃이 RFC 791과 동일하다고 가장하지 않았습니다. 구조가 비호환된다고 명시했습니다. 제한된 하위 호환성은 Class Selector 코드포인트를 통해 이루어졌는데, 이들의 선행 비트 패턴은 역사적 IP Precedence 값에 대응하고 그 홉별 동작에는 최소 정렬 요구가 있었습니다. 이는 유용하게 배포된 기대를 보존하면서도, 옛 의미 모델 전체를 새 모델에 강요하지 않았습니다.

결과는 제약된 재해석을 통한 호환성이었습니다. 와이어상의 위치는 남았고, 선별된 역사적 패턴에는 다리가 놓였으며, 나머지에 대한 임의의 가정은 남지 않았습니다.

쓰이지 않던 2비트는 다른 주인을 찾다

RFC 2474는 마지막 2비트를 차등 서비스 처리에 대해 현재 미사용(Currently Unused)으로 명명하고 홉별 동작을 선택할 때 무시할 것을 요구했습니다. RFC 3168은 이후 그 자리를 별도의 2비트 명시적 혼잡 통지 필드로 사용했습니다.

네 가지 코드포인트는 Not-ECT, ECT(0), ECT(1), 그리고 Congestion Experienced(CE)입니다. 송신자는 전송 계층 양단이 참여할 수 있을 때만 ECT(0)나 ECT(1)를 사용합니다. 혼잡이 시작되는 경우, 활성 큐 관리 메커니즘은 ECN을 지원하는 패킷을 드롭하는 대신 CE를 설정할 수 있습니다. 수신자와 전송 송신자는 그 대응을 혼잡 제어로 되돌려 보냅니다.

따라서 ECN은 남은 2비트를 추가 우선순위로 바꾸지 않았습니다. DSCP와 다른 의미를 가지고 다른 참여자를 가진 피드백 채널을 만들었습니다. 상위 6비트는 노드가 처리를 선택하도록 돕고, 하위 2비트는 ECN을 지원하는 전송 계층을 위해 혼잡을 기록할 수 있습니다. 라우터는 가득 찬 큐에서 여전히 드롭할 수 있으며, ECN을 지원하지 않는 트래픽이 손실 대신 마킹을 약속받는 것은 아닙니다.

안정된 위치, 불안정한 가정들

이 역사가 가치 있는 이유는 옥텟이 보이는 자리에 머무른 채 의미가 바뀌었기 때문입니다. 모든 옛 비트가 1981년 의미를 유지한다고 가정한 구현은 나중 패킷을 오독할 수 있습니다. 모든 DSCP를 보편적 전역 서열로 취급한 도메인은 설정 가능한 선택자를 권리로 오해할 수 있습니다. CE를 지우는 장치는 패킷을 포워딩하면서도 종단 간 혼잡 신호를 깨뜨릴 수 있습니다.

인용된 RFC들은 마킹이 실제 경로, 터널, 재마킹 정책, 미들박스를 거치며 얼마나 일관되게 생존하는지를 측정하지 않습니다. 특정 코드포인트가 고정된 지연, 처리량, 신뢰성 또는 화폐 대가를 사들이는 것으로 증명하지도 않습니다. 그런 결과는 구현된 동작, 합의, 현재 경로 상태에 달려 있습니다.

출처들이 보여주는 것은 아키텍처적 방법입니다. IETF는 희소한 고정 위치를 재사용하면서, 비호환 변경을 문서화하고, 배포된 실무를 위한 다리를 예약하며, 해석을 행정 도메인에 할당하고, 혼잡 필드를 동작 선택자와 분리했습니다. 이 옥텟이 견딜 수 있었던 이유는 물리적 안정성을 의미적 불변성과 혼동하지 않았기 때문입니다.

출처