요약

  • RFC 3095는 모든 ROHC 컨텍스트가 단방향 모드에서 시작하도록 요구했으며, 이 모드에서는 주기적 갱신과 관찰된 헤더 동작이 반환 채널을 대신했습니다.
  • 복호화기는 이후 낙관적 또는 신뢰 기반 양방향 동작을 요청할 수 있었습니다. 이들 모드는 피드백을 서로 다르게 소모했기 때문에, 하나의 확인 응답은 한 압축 컨텍스트의 건강 상태를 기술하는 것이지 종단 간 전달을 의미하지 않았습니다.

첫 패킷은 응답을 가정할 수 없었다

강건 헤더 압축(ROHC)은 까다로운 자원 계산 문제를 풀기 위해 만들어졌습니다. RTP 음성 패킷은 IP, UDP, RTP 헤더 뒤에 작은 페이로드를 담는데, 이 헤더들의 필드는 반복되거나 예측 가능하게 이동합니다. 희소한 무선 링크 위에서 반복되는 모든 비트를 보내는 것은 용량 낭비입니다. 그러나 그 비트를 생략하면 수신 측이 송신 측과 공유하는 상태로부터 이를 재구성해야 합니다. 갱신 하나를 잃어버리면 링크가 완벽하게 전달한 패킷들이 손상될 수 있습니다.

RFC 3095는 이 위험에 단일한 보편 운용 규칙으로 답하지 않았습니다.상태(state)와모드(mode)를 분리한 것입니다. 압축기 상태—초기화·갱신(Initialization and Refresh), 1차·2차(First Order and Second Order)—는 헤더 동작이 얼마나 예측 가능해졌는지를 기술했습니다. 복호화기 상태—컨텍스트 없음(No Context), 정적 컨텍스트(Static Context), 전체 컨텍스트(Full Context)—는 무엇을 안전하게 재구성할 수 있는지를 기술했습니다. 모드는 또 다른 질문에 답했습니다. 이 상태들을 조율하는 데 실제로 사용 가능한 반환 경로 권한은 무엇인가?

답은 보수적으로 시작했습니다. RFC는 압축이반드시단방향(Unidirectional) 모드에서 시작해야 한다고 명시합니다. U-mode는 복호화기에서 압축기로 돌아가는 경로가 없거나 바람직하지 않을 때 동작합니다. 압축기는 낙관적 규칙으로 진행합니다. 충분한 정보를 보낸 후에는 수신자가 더 작은 형태를 해독할 수 있을 것이라고 어느 정도 확신할 수 있습니다. 주기적 타임아웃, 갱신, 불규칙한 변화는 확신을 새로 확보해야 할 때 더 풍부한 패킷으로 되돌리게 합니다.

“어느 정도 확신”은 “확인 응답받음”과 같지 않습니다. 이는 없는 기능에 대한 공학적 대응입니다. 압축기는 컨텍스트를 충분히 반복해 침묵이 입히는 피해를 한계 내로 묶을 수 있지만, 침묵을 상대 끝이 갱신을 수신했다는 증거로 바꿀 수는 없습니다.

양방향 모드의 문은 복호화기가 열었다

RFC 3095는 압축기가 반환 경로를 선언으로 존재하게 만들지 못하게 했습니다. 패킷이 복호화기에 도달한 후에야, 복호화기가 원하는 모드를 담은 피드백을 보낼 수 있었습니다. 그때에야 컨텍스트가 U-mode에서 양방향 모드 중 하나로 이동할 수 있었습니다.

이 권한 배분이 중요합니다. 재구성이 성공하는지 관찰할 수 있는 끝점은 복호화기입니다. 압축기는 자신이 보낸 것을 보지만 상대가 무엇을 재건했는지는 보지 못합니다. 따라서 모드 요청은 컨텍스트 실패를 즉시 겪는 행위자로부터 다음 압축 형태를 선택하는 행위자로 향합니다.

RFC 4815의 후속 명확화는 이 조율 경계를 더 선명하게 만들었습니다. 이 문서는 모드 변경을 압축기와 복호화기를 일관되게 이동시키기 위한 3단계 핸드셰이크로 기술했습니다. 확인 응답 경계 주변의 패킷은 올바른 이전 규칙 또는 새 규칙에 따라 해독되어야 했습니다. “신뢰 기반”이라는 라벨이 명시적 전환 절차를 대신할 수는 없었습니다.

낙관적 피드백은 의도적으로 희소했다

양방향 낙관적(Optimistic) 모드는 모든 패킷을 영수증으로 만들지 않으면서 피드백 채널을 추가했습니다. 복호화기는 복구 요청을 보내고, 중대한 컨텍스트 갱신을 선택적으로 확인 응답할 수 있었지만, 순수한 시퀀스 번호 갱신에는 같은 대우를 받지 않았습니다. 주기적 갱신은 사라졌습니다. 설계의 목표는 압축 효율을 유지하고 피드백을 희소하게 유지하는 것이었습니다.

이 선택은 위험을 폐지한 것이 아니라 옮긴 것이었습니다. O-mode는 감지된 컨텍스트 문제를 U-mode의 지속적 갱신 비용 없이 복구할 수 있었습니다. 그러나 RFC 3095는 컨텍스트 무효화가 신뢰 기반(Reliable) 모드보다 더 자주 발생할 수 있다고 경고했으며, 특히 긴 손실·오류 연쇄 구간에서 그렇다고 했습니다.

중요한 단어는컨텍스트입니다. 부정 확인 응답은 복호화기의 재구성 상태가 주의를 필요로 한다고 말합니다. 그것은 음성 프레임이 지각 가능했는지, 애플리케이션이 페이로드를 소비했는지, 사용자가 한 문장을 들었는지는 말하지 않습니다. ROHC의 피드백 루프는 압축 채널에 국한되었습니다.

신뢰 기반 모드는 결과가 아니라 참조를 확보했다

양방향 신뢰 기반(Reliable) 모드는 반환 채널을 더 많이 소모했습니다. 더 엄격한 논리를 사용하고 시퀀스 번호 필드 갱신을 포함한 모든 컨텍스트 갱신을 확인 응답했으며, 다만 모든 R-mode 패킷이 컨텍스트를 바꾸지는 않았습니다. 이 모드의 보안 참조(secure-reference) 원칙은 7비트 또는 8비트 CRC를 담은 패킷만이 복호화 컨텍스트를 갱신하고 이후 패킷의 참조가 될 수 있도록 했습니다.

이것은 정밀한 형태의 신뢰성이었습니다. 압축 패킷이 이전 참조에 의존한다면, 그 참조는 그 역할을 감당할 만큼 충분한 검사와 확인 응답 규율을 갖추어야 했습니다. RFC 3095는 헤더나 피드백이 유실되거나 손상될 때 손실과 손상의 전파를 줄이는 것을 목표로 했습니다.

그러나 실패의 불가능성을 약속하지는 않았습니다. RFC는 잔존 비트 오류, CRC 커버리지, 그리고 손상된 헤더가 상위 계층에 여전히 도달할 수 있는 사례들을 논의합니다. “신뢰 기반(Reliable)”이라는 이름은 U-mode 및 O-mode에 대한 이 모드의 컨텍스트 동기화 전략을 나타낼 뿐, 페이로드·애플리케이션·종단 간 경로에 대한 보증서가 아닙니다.

반환 채널은 비용 대장에 들어 있었다

RFC 3096은 이 설계가 왜 중요했는지 설명합니다. ROHC 작업은 높은 오류율과 긴 왕복 지연을 가진 링크를 겨냥했고, WCDMA, EDGE, CDMA-2000 같은 셀룰러 기술을 명시했습니다. 이 작업은 의미적 투명성을 요구했습니다. 압축 해제는 원래 헤더를 재현하거나, 그렇지 않으면 오류 패킷을 폐기해야 합니다. 또한 오류 전파를, 이전 헤더의 유실이나 손상 때문에 이후 헤더들이 사용 불가능해지는 현상으로 정의했습니다.

이 요구 사항들은 편리한 회계 기교를 거부했습니다. 어떤 보조 제어·피드백 채널이든 상대 오버헤드 계산에 포함되어야 했습니다. 작은 정방향 헤더가 역방향 트래픽, 확인 응답, 복구 메시지에 의존한다면, 그것만으로 전체 비용이 아닙니다.

RFC 3409는 같은 경계를 링크 통합으로까지 가져갔습니다. U-mode는 피드백 없이 동작할 수 있었습니다. O-mode와 R-mode는 하위 계층이 피드백을 전송해야 했으며, 가급적 신속하게 그래야 했습니다. 프로토콜은 반환 경로를 활용할 수 있었지만, 모든 링크가 필요한 지연으로 하나를 제공한다고 가정할 수는 없었습니다.

이후 문서들은 문서와 운용의 구분을 유지했다

기록은 계속 변했습니다. RFC 4815는 정정과 명확화를 모았습니다. RFC 4995는 이후 프레임워크를 개별 프로파일과 분리하면서, 구현자들이 RFC 3095의 일부를 복잡하거나 난해하다고 느꼈다고 적으면서도 두 프레임워크 정의가 호환 가능하다고 기술했습니다. RFC 5225는 손실과 재정렬에 대한 간소화 및 추가 강건성 도구를 갖춘 개정된 ROHCv2 프로파일을 정의했습니다.

이 문서들은 명세 작업이 계속되었음을 증명합니다. 그러나 실제 배치된 사업자를 식별하거나, 스펙트럼 절감을 측정하거나, 핸드오버를 증명하거나, 특정 두 제품이 상호 운용했음을 보여주지는 않습니다. RFC 3241도 마찬가지로 PPP가 ROHC를 협상하고 운반하는 표준화된 방법을 얻었음을 증명할 뿐, 이름이 밝혀진 링크가 이를 사용했다는 증거가 아닙니다.

지속되는 역사적 교훈은 더 좁고 더 유용합니다. RFC 3095는 피드백을 방향과 비용과 소유자를 가진 하나의 기능으로 만들었습니다. 이 프로토콜은 그 기능이 부재한 지점에서 시작하여, 관찰 끝점이 더 강한 조율을 요청하게 하고, 세 종류의 증거—압축기가 예측한 것, 복호화기가 공유 컨텍스트에 대해 확인한 것, 그리고 종단 간 관찰만이 확립할 수 있는 것—를 분리하여 유지했습니다.

출처

  1. https://www.rfc-editor.org/rfc/rfc3095.html
  2. https://www.rfc-editor.org/info/rfc3095
  3. https://datatracker.ietf.org/doc/rfc3095/
  4. https://www.rfc-editor.org/rfc/rfc3096.html
  5. https://www.rfc-editor.org/info/rfc3096
  6. https://datatracker.ietf.org/doc/rfc3096/
  7. https://www.rfc-editor.org/rfc/rfc1144.html
  8. https://www.rfc-editor.org/rfc/rfc2508.html
  9. https://www.rfc-editor.org/rfc/rfc3241.html
  10. https://www.rfc-editor.org/rfc/rfc3409.html
  11. https://www.rfc-editor.org/rfc/rfc4815.html
  12. https://www.rfc-editor.org/info/rfc4815
  13. https://www.rfc-editor.org/rfc/rfc4995.html
  14. https://www.rfc-editor.org/rfc/rfc5225.html