Network Working Group M. Handley
Request for Comments: 2736 ACIRI
BCP: 36 C. Perkins
Category: Best Current Practice UCL
December 1999
Руководство для авторов спецификаций форматов полезной нагрузки RTP
Статус этого меморандума
Этот документ определяет Лучшую современную практику Интернета для
Интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение этого меморандума не ограничено.
Уведомление об авторских правах
Авторское право (C) The Internet Society (1999). Все права защищены.
Аннотация
Этот документ содержит общие рекомендации, призванные помочь авторам
спецификаций форматов полезной нагрузки RTP выбирать хорошие форматы.
Эти рекомендации пытаются обобщить часть опыта, полученного с RTP по
мере его развития.
1. Введение
Этот документ содержит общие рекомендации, призванные помочь авторам
спецификаций форматов полезной нагрузки RTP [9] выбирать хорошие
форматы. Эти рекомендации пытаются обобщить часть опыта, полученного
с RTP по мере его развития.
Изложенные в этом документе принципы применимы почти ко всем типам
данных, но для ясности сформулированы на примерах аудио- и
видеокодеков.
2. Предыстория
RTP был разработан вокруг концепции фреймирования на уровне приложения
(Application Level Framing, ALF), впервые описанной Clark и
Tennenhouse [2]. Ключевой довод, лежащий в основе ALF, состоит в том,
что приложение может по-разному обрабатывать пакеты, пришедшие в
неправильном порядке или потерянные. Эти способы варьируются от
игнорирования потери до повторной отправки недостающих данных (либо из
буфера, либо путём их повторного формирования) и отправки новых данных,
заменяющих недостающие данные. Приложение имеет такой выбор, только
если транспортный протокол работает с данными в «единицах данных
приложения» (Application Data Units, ADU). ADU содержит данные,
которые могут быть обработаны вне порядка относительно других ADU.
Таким образом, ADU является минимальной единицей восстановления после
ошибки.
Ключевое свойство транспортного протокола для ADU состоит в том, что
каждая ADU содержит достаточно информации для немедленной обработки
получателем. Примером служит видеопоток, в котором сжатые видеоданные
в ADU должны допускать распаковку независимо от того, были ли получены
предыдущие ADU. Кроме того, ADU должна содержать информацию «заголовка»,
указывающую её положение в видеоизображении и кадр, из которого она
получена.
Хотя ADU не обязана быть пакетом, для многих приложений пакет является
естественной ADU. Такие приложения ALF обладают большим преимуществом:
все полученные пакеты могут быть немедленно обработаны приложением.
RTP был разработан в соответствии с философией ALF. В контексте потока
данных RTP заголовок пакета RTP предоставляет достаточно информации,
чтобы идентифицировать и декодировать пакет независимо от того,
получен ли он по порядку или были ли потеряны предшествующие пакеты.
Однако эти доводы справедливы только в том случае, если форматы
полезной нагрузки RTP также разработаны в соответствии с философией
ALF.
Обратите внимание, что это также подразумевает интеллектуальные,
осведомлённые о сети конечные точки. Приложению, использующему RTP,
следует учитывать ограничения нижележащей сети и следует адаптировать
передачу к этим ограничениям. Наш опыт показывает, что интеллектуальная
реализация конечной точки способна достигать в реальных сетях на базе IP
значительно более высокой производительности, чем наивная реализация.
3. Характеристики канала
Мы выделяем следующие характеристики канала, влияющие на транспортировку
RTP поверх UDP/IP в Интернете в режиме негарантированной доставки:
o Пакеты могут быть потеряны
o Пакеты могут дублироваться
o Пакеты могут быть переупорядочены при передаче
o Пакеты будут фрагментированы, если они превышают MTU нижележащей
сети
Характеристики потерь линии связи могут сильно изменяться за короткие
интервалы времени.
Хотя фрагментация не является катастрофическим явлением, если она
происходит редко, полагаться на фрагментацию IP — плохая стратегия
проектирования, поскольку она значительно увеличивает эффективный
уровень потерь в сети и уменьшает полезную пропускную способность.
Это происходит потому, что при потере одного фрагмента получателю затем
потребуется отбросить остальные фрагменты (которые уже использовали
пропускную способность узкого места). Это также создаёт дополнительную
нагрузку на маршрутизаторы, выполняющие фрагментацию, и на конечные
системы, повторно собирающие фрагменты.
Кроме того, следует отметить, что время прохождения между двумя узлами
в Интернете не будет постоянным. Это обусловлено двумя факторами —
джиттером, вызванным постановкой в очередь за перекрёстным трафиком, и
изменениями маршрутизации. Первый фактор можно охарактеризовать и
скомпенсировать с помощью буфера воспроизведения, но второй невозможно
предсказать и трудно корректно учесть.
4. Рекомендации
Мы выделяем следующие требования к спецификациям форматов полезной
нагрузки RTP:
+ Формат полезной нагрузки следует разрабатывать так, чтобы
транспортируемый поток оставался полезным даже при наличии
умеренного количества потерь пакетов.
+ В идеале должна быть возможность декодировать и воспроизводить всё
содержимое каждого пакета независимо от того, были ли потеряны
предшествующие пакеты или пришли с опозданием.
Первое из этих требований основано на природе Интернета. Хотя может
быть возможно спроектировать части Интернета для обеспечения низких
уровней потерь за счёт тщательного выделения ресурсов или использования
услуг, отличных от негарантированной доставки, как правило, форматы
полезной нагрузки не следует разрабатывать для таких
специализированных сред. Форматы полезной нагрузки следует
разрабатывать для использования в общедоступном Интернете с услугой
негарантированной доставки, поэтому в них следует ожидать умеренных
уровней потерь. Например, уровень потерь 5% не является необычным. Мы
отмечаем, что модели установившегося состояния TCP [3][4][6] показывают,
что уровень потерь 5% при размере пакета 1KByte и времени кругового
прохождения 200ms приведёт к тому, что TCP достигнет пропускной
способности около 180Kbit/s. Чтобы ограничить TCP более низкими
скоростями передачи данных, требуются более высокие уровни потерь,
меньшие размеры пакетов или большее RTT. По большей части именно такой
трафик TCP создаёт фоновые потери, с которыми должны сосуществовать
многие потоки RTP. Без явного уведомления о перегрузке (ECN) [8] потеря
должна рассматриваться как внутреннее свойство частей Интернета,
работающих в режиме негарантированной доставки.
Когда форматы полезной нагрузки не предполагают возникновения потерь
пакетов, им следует явно заявлять об этом с самого начала, и они будут
считаться специализированными форматами полезной нагрузки, непригодными
для использования в общедоступном Интернете без специальной поддержки
со стороны сетевой инфраструктуры.
Второе из этих требований более явно определяет, как RTP следует
обрабатывать потери. Если формат полезной нагрузки RTP правильно
разработан, каждый действительно полученный пакет следует считать
полезным. Обычно это подразумевает соблюдение следующих рекомендаций:
+ Следует, чтобы границы пакетов совпадали с границами кадров кодека.
Таким образом, пакет обычно следует составлять из одного или
нескольких полных кадров кодека.
+ Минимальную единицу данных кодека никогда не следует пакетировать
так, чтобы она пересекала границу пакета, если только её размер не
превышает MTU.
+ Если размер кадра кодека превышает MTU, формат полезной нагрузки
НЕ ДОЛЖЕН (MUST NOT) полагаться на фрагментацию IP. Вместо этого он
ДОЛЖЕН (MUST) определять собственный механизм фрагментации. Такие
механизмы могут включать специфичную для кодека информацию,
позволяющую декодировать фрагменты. В качестве альтернативы они
могут допускать применение пакетной прямой коррекции ошибок [5], не
зависящей от кодека, которая не может использоваться при фрагментации
на уровне IP.
В абстрактном виде кадр кодека (то есть ADU или единица минимального
размера, обладающая семантическим смыслом при передаче кодеку) может
иметь произвольный размер. Для PCM-аудио это один байт. Для GSM-аудио
кадр соответствует 20ms аудио. Для видео H.261 это Group of Blocks
(GOB) либо одна двенадцатая видеокадра CIF.
Для PCM не имеет значения, как пакетируется аудио, поскольку размер ADU
составляет один байт. Для GSM-аудио произвольная пакетизация разделила
бы 20ms кадр между двумя пакетами, что означало бы: при потере одного
пакета частичные кадры в пакетах до и после потери не имеют смысла. Это
означает, что были потеряны не только биты отсутствующего пакета, но и
дополнительные биты в соседних пакетах, использовавшие пропускную
способность узкого места, фактически также были потеряны, поскольку
получатель должен их отбросить. Вместо этого мы пакетировали бы GSM,
включая в пакет несколько полных кадров GSM; в текущих реализациях
обычно включают четыре кадра GSM. Таким образом, каждый полученный пакет
можно декодировать, поскольку даже при наличии потерь не принимаются
неполные кадры.
Спецификация H.261 допускает GOB длиной до 3KBytes, хотя большую часть
времени они меньше. Можно было бы считать, что следует помещать группу
блоков в пакет, когда она помещается, и произвольно разделять GOB между
двумя или более пакетами, когда
GOB велика. В первой версии формата полезной нагрузки H.261 именно так
и поступали. Однако это всё равно означает, что существуют
обстоятельства, при которых пакеты H.261 поступают получателю и должны
быть отброшены из-за потери других пакетов — эффект мультипликатора
потерь, которого мы хотим избежать. В действительности в битовом потоке
H.261 есть единицы меньше GOB, называемые макроблоками, но их невозможно
идентифицировать без разбора начиная с начала GOB. Однако, если мы
предоставим немного дополнительной информации в начале каждого пакета,
мы сможем восстановить информацию, которая обычно обнаруживается при
разборе с начала GOB, и сможем пакетировать H.261, разделяя поток данных
на границах макроблоков. Это менее очевидная пакетизация для H.261, чем
пакетизация по GOB, но она означает, что несколько более интеллектуальный
депакетизатор у получателя может восстановить корректный битовый поток
H.261 из потока пакетов RTP, в котором произошли потери, и ему не
требуется отбрасывать какие-либо из поступивших данных.
Дополнительная рекомендация относится к кодекам, требующим, чтобы
конечный автомат состояния декодера сохранял синхронность с конечным
автоматом состояния кодера. Многие аудиокодеки, такие как LPC или GSM,
имеют такую форму. Обычно они устойчивы к потерям в том смысле, что
после потери коэффициенты предиктора затухают, так что спустя некоторое
время ошибка предиктора, вызванная потерей, исчезает. Большинство
кодеков, разработанных для услуг телефонии, имеют такую форму, поскольку
они проектировались для обработки битовых ошибок без постоянного
сохранения неверного состояния предиктора декодера. Простая пакетизация
этих форматов так, чтобы пакеты состояли из целого числа кадров кодека,
может быть не оптимальной, поскольку, хотя пакет, полученный сразу после
потери пакета, можно декодировать, начало сформированного аудиопотока
будет неверным (и, следовательно, исказит сигнал), потому что предиктор
декодера теперь не синхронизирован с кодером. В принципе всё внутреннее
состояние декодера можно было бы добавить с помощью заголовка,
присоединённого к началу каждого пакета, но для кодирований с более
низкой скоростью передачи данных это состояние настолько значительно,
что скорость передачи перестаёт быть низкой. Однако обычно можно найти
компромисс, при котором в каждом пакете передаётся сильно сокращённая
форма состояния декодера, не воспроизводящая предиктор кодера точно,
но уменьшающая величину и длительность искажения, возникающего при
потере предыдущего пакета. Такое сжатое состояние по определению сильно
зависит от рассматриваемого кодека. Поэтому мы рекомендуем:
+ Форматам полезной нагрузки для кодирований, в которых декодер
содержит внутреннее состояние, управляемое данными и пытающееся
отслеживать состояние кодера, обычно следует рассмотреть включение
небольшого дополнительного заголовка, передающего наиболее критичные
элементы этого состояния для уменьшения искажения после потери
пакета.
Схожий вопрос возникает в отношении параметров кодека и того, следует
ли включать их в формат полезной нагрузки. Примером служит кодек, у
которого для сжатия имеется выбор таблиц Хаффмана. Кодек может
использовать для кодирования либо таблицу Хаффмана 1, либо таблицу
Хаффмана 2, и получателю необходимо знать эту информацию для правильного
декодирования. Существует несколько способов передачи такого рода
информации:
o Сигнализация вне полосы, до передачи медиа.
o Сигнализация вне полосы, но параметр может быть изменён в середине
сеанса. Это требует синхронизации изменения в медиапотоке.
o Изменение сигнализируется посредством изменения поля RTP payload type.
Это требует сопоставления пространства параметров с конкретными
значениями payload type и сигнализации этого сопоставления вне полосы
до передачи медиа.
o Включение параметра в формат полезной нагрузки. Это позволяет надёжно адаптировать параметр, но делает формат полезной нагрузки менее эффективным.
Выбор механизма зависит от полезности изменения параметра в середине сеанса для поддержки адаптации на уровне приложения. Однако использовать внеполосную сигнализацию для изменения параметра в середине сеанса, как правило, не следует из-за проблемы синхронизации изменения параметра с медиапотоком.
4.1. Расширения заголовка RTP
Для многих форматов полезной нагрузки RTP требуется передавать некоторую дополнительную информацию заголовка помимо той, которая включена в фиксированный заголовок пакета RTP. Рекомендуемый способ передачи этой информации — в секции полезной нагрузки пакета. Расширение заголовка RTP не следует использовать для передачи информации, специфичной для полезной нагрузки ([9], раздел 5.3), поскольку это неэффективно с точки зрения использования полосы пропускания; требует определения нового профиля RTP или расширения профиля; и затрудняет применение схем FEC, таких как, например, [7]. Использование расширения заголовка RTP уместно только в случаях, когда рассматриваемое расширение применяется к широкому диапазону типов полезной нагрузки.
4.2. Сжатие заголовка
Разработчикам форматов полезной нагрузки также следует учитывать потребности сжатия заголовка RTP [1]. В частности, алгоритм сжатия работает лучше всего, когда метка времени RTP увеличивается на постоянное значение между последовательными пакетами. Форматы полезной нагрузки, которые полагаются на отправку пакетов не по порядку, так что приращение метки времени не является постоянным,
вероятно, будут сжиматься хуже, чем те, которые отправляют пакеты по порядку. Чаще всего это было проблемой при проектировании форматов полезной нагрузки для информации FEC, хотя некоторые видеокодеки также полагаются на передачу пакетов не по порядку ценой снижения степени сжатия. Хотя в некоторых случаях такая передача не по порядку может быть наилучшим решением, разработчикам форматов полезной нагрузки рекомендуется искать альтернативные решения, где это возможно.
5. Резюме
Проектирование форматов пакетов для RTP — нетривиальная задача. Как правило, требуется подробное знание соответствующего кодека, чтобы разработать формат, устойчивый к потерям, не вносящий эффектов усиления потерь из-за неподходящей пакетизации и не вносящий ненужных искажений после потери пакета. Мы считаем, что следует приложить значительные усилия к проектированию форматов пакетов, хорошо приспособленных к рассматриваемому кодеку. Как правило, это требует очень небольшого объёма обработки у отправителя и получателя, но результатом может быть значительно улучшенное качество при работе в типичных средах Интернета.
Разработчикам новых кодеков для использования с RTP следует рассмотреть возможность сделать вывод кодека «естественно пакетизируемым». Это подразумевает, что кодек следует проектировать так, чтобы он формировал поток пакетов, а не битовый поток; и чтобы этот поток пакетов содержал минимальный объём избыточности, необходимый для обеспечения независимой декодируемости каждого пакета при минимальной потере отслеживания предиктора декодера. Признаётся, что пожертвовать некоторым небольшим объёмом полосы пропускания для обеспечения большей устойчивости к потере пакетов часто является оправданным компромиссом.
Ожидается, что в долгосрочной перспективе будут создаваться новые кодеки, которые можно пакетизировать непосредственно, без трудностей проектирования формата полезной нагрузки, специфичного для кодека.
Возможно проектировать универсальные форматы пакетизации, не учитывающие вопросы, описанные в этом документе, однако такие форматы подходят только для сетей специального назначения, в которых потери пакетов можно избежать за счёт тщательного проектирования на сетевом уровне, и не подходят для современных сетей с обслуживанием по мере возможности.
6. Вопросы безопасности
Рекомендации в этом документе приводят к форматам полезной нагрузки RTP, устойчивым в условиях реальных сетевых условий. Проектирование форматов полезной нагрузки для сетей специального назначения, предполагающих пренебрежимо малые уровни потерь, обычно приведёт к несколько лучшему сжатию, но создаст более хрупкие форматы, тем самым делая их более лёгкими целями для атак типа «отказ в обслуживании».
Разработчикам форматов полезной нагрузки следует уделять пристальное внимание возможным проблемам безопасности, которые могут возникнуть вследствие плохих реализаций их форматов, и следует тщательно определять правильное поведение при возникновении аномальных условий. Примеры включают обработку недопустимых значений полей и условия, когда существуют несоответствия между полями длины и фактическими данными. Хотя правильным действием обычно будет отбросить пакет, следует обратить внимание реализатора на возможные такие условия, чтобы обеспечить их надлежащую обработку.
Спецификация RTP охватывает шифрование полезной нагрузки. Обычно этот вопрос не следует рассматривать в самих форматах полезной нагрузки. Однако некоторые форматы полезной нагрузки распределяют информацию об определённой единице данных приложения по нескольким пакетам либо полагаются на пакеты, относящиеся к нескольким единицам данных приложения. При изменении шифрования таких потоков необходимо соблюдать осторожность, поскольку такие форматы полезной нагрузки могут ограничивать места в потоке, где возможно изменить ключ шифрования без раскрытия чувствительных данных.
Разработчикам форматов полезной нагрузки, включающих FEC, следует учитывать, что автоматическое добавление FEC в ответ на потерю пакетов может увеличить перегрузку сети, приводя к усугублению проблемы, для решения которой предназначалось использование FEC. Поскольку в худшем случае это может представлять собой атаку типа «отказ в обслуживании», разработчикам таких форматов полезной нагрузки следует позаботиться о наличии надлежащих мер защиты для предотвращения злоупотреблений.
Адреса авторов
Mark Handley
AT&T Center for Internet Research at ICSI,
International Computer Science Institute,
1947 Center Street, Suite 600,
Berkeley, CA 94704, USA
EMail: mjh@aciri.org
Colin Perkins
Dept of Computer Science,
University College London,
Gower Street,
London WC1E 6BT, UK.
EMail: C.Perkins@cs.ucl.ac.uk
Благодарности
Этот документ основан на опыте, накопленном за несколько лет многими людьми, в том числе Van Jacobson, Steve McCanne, Steve Casner, Henning Schulzrinne, Thierry Turletti, Jonathan Rosenberg и Christian Huitema, среди прочих.
Ссылки
[1] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links", RFC 2508, February 1999.
[2] D. Clark and D. Tennenhouse, "Architectural Considerations for
a New Generation of Network Protocols" Proc ACM Sigcomm 90.
[3] J. Mahdavi and S. Floyd. "TCP-friendly unicast rate-based flow
control". Note sent to end2end-interest mailing list, Jan 1997.
[4] M. Mathis, J. Semske, J. Mahdavi, and T. Ott. "The macro-scopic
behavior of the TCP congestion avoidance algorithm". Computer
Communication Review, 27(3), July 1997.
[5] J. Nonnenmacher, E. Biersack, Don Towsley, "Parity-Based Loss
Recovery for Reliable Multicast Transmission", Proc ACM Sigcomm
[6] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, "Modeling TCP
Throughput: A Simple Model and its Empirical Validation", Proc.
ACM Sigcomm 1998.
[7] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
Bolot, J.C., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload
for Redundant Audio Data", RFC 2198, September 1997.
[8] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"Real-Time Transport Protocol", RFC 1889, January 1996.
Полное заявление об авторских правах
Copyright (C) The Internet Society (1999). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иным образом поясняющие его либо содействующие его реализации, могут подготавливаться, копироваться, публиковаться и распространяться полностью или частично без каких-либо ограничений при условии, что приведённое выше уведомление об авторских правах и настоящий абзац включаются во все такие копии и производные работы. Однако сам этот документ не может быть каким-либо образом изменён, например путём удаления уведомления об авторских правах или ссылок на Internet Society либо другие интернет-организации, кроме случаев, когда это необходимо для разработки интернет-стандартов, в которых случае должны соблюдаться процедуры в отношении авторских прав, определённые в процессе разработки интернет-стандартов, либо когда это требуется для перевода его на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не будут отозваны Internet Society, её правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях «КАК ЕСТЬ», И INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Благодарность
Финансирование функции RFC Editor в настоящее время обеспечивается Internet Society.