Кратко

  • RFC 3095 требовала запускать ROHC в однонаправленном режиме, где периодическое обновление заменяло отсутствующий обратный канал.
  • Декомпрессор мог запросить оптимистичный или надёжный двунаправленный режим; подтверждение относилось к контексту сжатия, а не к доставке от конца до конца.

Первый пакет не мог предполагать ответ

На радиолинии заголовки IP, UDP и RTP могли быть больше небольшой голосовой нагрузки. Отказ от постоянных и предсказуемых полей экономил канал, но заставлял получателя восстанавливать их из общего состояния. Потерянное обновление могло испортить последующие пакеты, даже если линия доставила их без ошибки.

RFC 3095 разделяла состояние и режим. IR, FO и SO описывали зрелость модели компрессора; отсутствие, статический и полный контекст — возможности декомпрессора. Режим отвечал на другой вопрос: какая координирующая власть реально существует в обратном направлении?

Начальная норма была осторожной: сжатие должно стартовать в U-mode. Без обратного пути компрессор повышал степень сжатия оптимистично, когда считал, что повторил достаточно сведений. Таймеры, периодические обновления и нерегулярные изменения возвращали более полные форматы. Обоснованная уверенность ограничивала цену молчания, но не превращала молчание в доказательство приёма.

Двунаправленные режимы открывал декомпрессор

Компрессор не мог объявлением создать обратный канал. Получив пакет, декомпрессор мог послать отзыв с желаемым режимом и инициировать переход в O-mode или R-mode.

Направление решения было практичным. Компрессор видел отправленное, а декомпрессор — успех восстановления. Сторона, наблюдавшая непосредственный сбой контекста, просила изменить дисциплину сторону, выбирающую следующий формат.

RFC 4815 позднее уточнила трёхшаговое рукопожатие, которое согласованно переводило обе стороны. Пакеты вокруг границы подтверждения следовало декодировать по старому или новому правилу в точный момент. Название «надёжный» не заменяло процедуру.

Оптимистичный режим экономил отзывы

O-mode использовал обратный путь для запросов восстановления и необязательных подтверждений значимых обновлений. Чистые изменения номера последовательности не получали того же обращения, а периодические обновления исчезали. Целью были эффективность и редкое использование обратного канала.

Риск менял место, а не исчезал. На обнаруженный ущерб можно было ответить, однако длинные всплески потерь или ошибок могли чаще обесценивать контекст, чем в R-mode. NACK описывал местное восстановление, но не понятность речи, приём нагрузки приложением или результат для пользователя.

Надёжный режим защищал ссылки

R-mode интенсивнее использовал обратный канал и более строгую логику. Все обновления контекста, включая номер последовательности, подтверждались, хотя не каждый пакет менял контекст. Принцип безопасной ссылки разрешал обновлять контекст и стать опорой для будущего восстановления только пакету с семи- или восьмибитным CRC.

Надёжность имела точный предел: уменьшить распространение потерь и повреждений при ошибках заголовков или отзывов. Остаточные ошибки оставались возможны. R-mode не удостоверял нагрузку, приложение или весь путь.

Обратный путь входил в смету

RFC 3096 описывала линии с высокой частотой ошибок и большой круговой задержкой, включая WCDMA, EDGE и CDMA-2000. Восстановленный заголовок должен был быть семантически равен исходному, иначе пакет отбрасывался; распространение ошибок требовалось минимизировать.

В накладные расходы включались вспомогательные каналы и отзывы. Малый прямой заголовок не был всей ценой, если ему требовались обратные подтверждения и восстановление. RFC 3409 уточнила нижний контракт: U-mode обходился без отзывов, O-mode и R-mode требовали их своевременной перевозки нижним уровнем.

Развитие текста не доказывало эксплуатацию

RFC 4815 собрала исправления. RFC 4995 отделила каркас от профилей и отметила, что исполнители считали части RFC 3095 сложными или неясными, сохранив совместимость. RFC 5225 задала упрощённые профили ROHCv2 для потерь и переупорядочивания. RFC 3241 стандартизировала согласование поверх PPP.

Это доказательства работы над спецификацией, но не применения названным оператором, измеренной экономии спектра, успешного handover или совместимости конкретных продуктов.

Историческая граница полезнее: 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