Guidelines for Writers of RTP Payload Format Specifications
Документ устанавливает Best Current Practice для подготовки спецификаций форматов полезной нагрузки RTP и просит обсуждений и предложений по улучшению. Он рекомендует проектировать форматы с расчётом на умеренные потери, дублирование и переупорядочение пакетов в best-effort сетях общего пользования. Границы пакетов следует по возможности совмещать с границами кадров кодека, а кадры, превышающие MTU, фрагментировать средствами самого формата, не полагаясь на IP-фрагментацию. Рассматриваются передача параметров кодека, расширения заголовка RTP, сжатие заголовков, а также устойчивость и меры предосторожности в отношении ошибок реализации, шифрования и FEC.
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 является минимальной единицей восстановления после
ошибки.
Handley & Perkins Best Current Practice [Page 1]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
Ключевое свойство транспортного протокола для 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 нижележащей
сети
Характеристики потерь линии связи могут сильно изменяться за короткие
интервалы времени.
Handley & Perkins Best Current Practice [Page 2]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
Хотя фрагментация не является катастрофическим явлением, если она
происходит редко, полагаться на фрагментацию IP — плохая стратегия
проектирования, поскольку она значительно увеличивает эффективный
уровень потерь в сети и уменьшает полезную пропускную способность.
Это происходит потому, что при потере одного фрагмента получателю затем
потребуется отбросить остальные фрагменты (которые уже использовали
пропускную способность узкого места). Это также создаёт дополнительную
нагрузку на маршрутизаторы, выполняющие фрагментацию, и на конечные
системы, повторно собирающие фрагменты.
Кроме того, следует отметить, что время прохождения между двумя узлами
в Интернете не будет постоянным. Это обусловлено двумя факторами —
джиттером, вызванным постановкой в очередь за перекрёстным трафиком, и
изменениями маршрутизации. Первый фактор можно охарактеризовать и
скомпенсировать с помощью буфера воспроизведения, но второй невозможно
предсказать и трудно корректно учесть.
4. Рекомендации
Мы выделяем следующие требования к спецификациям форматов полезной
нагрузки RTP:
+ Формат полезной нагрузки следует разрабатывать так, чтобы
транспортируемый поток оставался полезным даже при наличии
умеренного количества потерь пакетов.
+ В идеале должна быть возможность декодировать и воспроизводить всё
содержимое каждого пакета независимо от того, были ли потеряны
предшествующие пакеты или пришли с опозданием.
Первое из этих требований основано на природе Интернета. Хотя может
быть возможно спроектировать части Интернета для обеспечения низких
уровней потерь за счёт тщательного выделения ресурсов или использования
услуг, отличных от негарантированной доставки, как правило, форматы
полезной нагрузки не следует разрабатывать для таких
специализированных сред. Форматы полезной нагрузки следует
разрабатывать для использования в общедоступном Интернете с услугой
негарантированной доставки, поэтому в них следует ожидать умеренных
уровней потерь. Например, уровень потерь 5% не является необычным. Мы
отмечаем, что модели установившегося состояния TCP [3][4][6] показывают,
что уровень потерь 5% при размере пакета 1KByte и времени кругового
прохождения 200ms приведёт к тому, что TCP достигнет пропускной
способности около 180Kbit/s. Чтобы ограничить TCP более низкими
скоростями передачи данных, требуются более высокие уровни потерь,
меньшие размеры пакетов или большее RTT. По большей части именно такой
трафик TCP создаёт фоновые потери, с которыми должны сосуществовать
многие потоки RTP. Без явного уведомления о перегрузке (ECN) [8] потеря
должна рассматриваться как внутреннее свойство частей Интернета,
работающих в режиме негарантированной доставки.
Handley & Perkins Best Current Practice [Page 3]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
Когда форматы полезной нагрузки не предполагают возникновения потерь
пакетов, им следует явно заявлять об этом с самого начала, и они будут
считаться специализированными форматами полезной нагрузки, непригодными
для использования в общедоступном Интернете без специальной поддержки
со стороны сетевой инфраструктуры.
Второе из этих требований более явно определяет, как 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 между
двумя или более пакетами, когда
Handley & Perkins Best Current Practice [Page 4]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
GOB велика. В первой версии формата полезной нагрузки H.261 именно так
и поступали. Однако это всё равно означает, что существуют
обстоятельства, при которых пакеты H.261 поступают получателю и должны
быть отброшены из-за потери других пакетов — эффект мультипликатора
потерь, которого мы хотим избежать. В действительности в битовом потоке
H.261 есть единицы меньше GOB, называемые макроблоками, но их невозможно
идентифицировать без разбора начиная с начала GOB. Однако, если мы
предоставим немного дополнительной информации в начале каждого пакета,
мы сможем восстановить информацию, которая обычно обнаруживается при
разборе с начала GOB, и сможем пакетировать H.261, разделяя поток данных
на границах макроблоков. Это менее очевидная пакетизация для H.261, чем
пакетизация по GOB, но она означает, что несколько более интеллектуальный
депакетизатор у получателя может восстановить корректный битовый поток
H.261 из потока пакетов RTP, в котором произошли потери, и ему не
требуется отбрасывать какие-либо из поступивших данных.
Дополнительная рекомендация относится к кодекам, требующим, чтобы
конечный автомат состояния декодера сохранял синхронность с конечным
автоматом состояния кодера. Многие аудиокодеки, такие как LPC или GSM,
имеют такую форму. Обычно они устойчивы к потерям в том смысле, что
после потери коэффициенты предиктора затухают, так что спустя некоторое
время ошибка предиктора, вызванная потерей, исчезает. Большинство
кодеков, разработанных для услуг телефонии, имеют такую форму, поскольку
они проектировались для обработки битовых ошибок без постоянного
сохранения неверного состояния предиктора декодера. Простая пакетизация
этих форматов так, чтобы пакеты состояли из целого числа кадров кодека,
может быть не оптимальной, поскольку, хотя пакет, полученный сразу после
потери пакета, можно декодировать, начало сформированного аудиопотока
будет неверным (и, следовательно, исказит сигнал), потому что предиктор
декодера теперь не синхронизирован с кодером. В принципе всё внутреннее
состояние декодера можно было бы добавить с помощью заголовка,
присоединённого к началу каждого пакета, но для кодирований с более
низкой скоростью передачи данных это состояние настолько значительно,
что скорость передачи перестаёт быть низкой. Однако обычно можно найти
компромисс, при котором в каждом пакете передаётся сильно сокращённая
форма состояния декодера, не воспроизводящая предиктор кодера точно,
но уменьшающая величину и длительность искажения, возникающего при
потере предыдущего пакета. Такое сжатое состояние по определению сильно
зависит от рассматриваемого кодека. Поэтому мы рекомендуем:
Handley & Perkins Best Current Practice [Page 5]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
+ Форматам полезной нагрузки для кодирований, в которых декодер
содержит внутреннее состояние, управляемое данными и пытающееся
отслеживать состояние кодера, обычно следует рассмотреть включение
небольшого дополнительного заголовка, передающего наиболее критичные
элементы этого состояния для уменьшения искажения после потери
пакета.
Схожий вопрос возникает в отношении параметров кодека и того, следует
ли включать их в формат полезной нагрузки. Примером служит кодек, у
которого для сжатия имеется выбор таблиц Хаффмана. Кодек может
использовать для кодирования либо таблицу Хаффмана 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 увеличивается на постоянное значение между последовательными пакетами. Форматы полезной нагрузки, которые полагаются на отправку пакетов не по порядку, так что приращение метки времени не является постоянным,
Handley & Perkins Best Current Practice [Страница 6]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
вероятно, будут сжиматься хуже, чем те, которые отправляют пакеты по порядку. Чаще всего это было проблемой при проектировании форматов полезной нагрузки для информации FEC, хотя некоторые видеокодеки также полагаются на передачу пакетов не по порядку ценой снижения степени сжатия. Хотя в некоторых случаях такая передача не по порядку может быть наилучшим решением, разработчикам форматов полезной нагрузки рекомендуется искать альтернативные решения, где это возможно.
5. Резюме
Проектирование форматов пакетов для RTP — нетривиальная задача. Как правило, требуется подробное знание соответствующего кодека, чтобы разработать формат, устойчивый к потерям, не вносящий эффектов усиления потерь из-за неподходящей пакетизации и не вносящий ненужных искажений после потери пакета. Мы считаем, что следует приложить значительные усилия к проектированию форматов пакетов, хорошо приспособленных к рассматриваемому кодеку. Как правило, это требует очень небольшого объёма обработки у отправителя и получателя, но результатом может быть значительно улучшенное качество при работе в типичных средах Интернета.
Разработчикам новых кодеков для использования с RTP следует рассмотреть возможность сделать вывод кодека «естественно пакетизируемым». Это подразумевает, что кодек следует проектировать так, чтобы он формировал поток пакетов, а не битовый поток; и чтобы этот поток пакетов содержал минимальный объём избыточности, необходимый для обеспечения независимой декодируемости каждого пакета при минимальной потере отслеживания предиктора декодера. Признаётся, что пожертвовать некоторым небольшим объёмом полосы пропускания для обеспечения большей устойчивости к потере пакетов часто является оправданным компромиссом.
Ожидается, что в долгосрочной перспективе будут создаваться новые кодеки, которые можно пакетизировать непосредственно, без трудностей проектирования формата полезной нагрузки, специфичного для кодека.
Возможно проектировать универсальные форматы пакетизации, не учитывающие вопросы, описанные в этом документе, однако такие форматы подходят только для сетей специального назначения, в которых потери пакетов можно избежать за счёт тщательного проектирования на сетевом уровне, и не подходят для современных сетей с обслуживанием по мере возможности.
6. Вопросы безопасности
Рекомендации в этом документе приводят к форматам полезной нагрузки RTP, устойчивым в условиях реальных сетевых условий. Проектирование форматов полезной нагрузки для сетей специального назначения, предполагающих пренебрежимо малые уровни потерь, обычно приведёт к несколько лучшему сжатию, но создаст более хрупкие форматы, тем самым делая их более лёгкими целями для атак типа «отказ в обслуживании».
Handley & Perkins Best Current Practice [Страница 7]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
Разработчикам форматов полезной нагрузки следует уделять пристальное внимание возможным проблемам безопасности, которые могут возникнуть вследствие плохих реализаций их форматов, и следует тщательно определять правильное поведение при возникновении аномальных условий. Примеры включают обработку недопустимых значений полей и условия, когда существуют несоответствия между полями длины и фактическими данными. Хотя правильным действием обычно будет отбросить пакет, следует обратить внимание реализатора на возможные такие условия, чтобы обеспечить их надлежащую обработку.
Спецификация 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
Handley & Perkins Best Current Practice [Страница 8]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
Благодарности
Этот документ основан на опыте, накопленном за несколько лет многими людьми, в том числе 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.
Handley & Perkins Best Current Practice [Страница 9]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
Полное заявление об авторских правах
Copyright (C) The Internet Society (1999). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иным образом поясняющие его либо содействующие его реализации, могут подготавливаться, копироваться, публиковаться и распространяться полностью или частично без каких-либо ограничений при условии, что приведённое выше уведомление об авторских правах и настоящий абзац включаются во все такие копии и производные работы. Однако сам этот документ не может быть каким-либо образом изменён, например путём удаления уведомления об авторских правах или ссылок на Internet Society либо другие интернет-организации, кроме случаев, когда это необходимо для разработки интернет-стандартов, в которых случае должны соблюдаться процедуры в отношении авторских прав, определённые в процессе разработки интернет-стандартов, либо когда это требуется для перевода его на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не будут отозваны Internet Society, её правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях «КАК ЕСТЬ», И INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Благодарность
Финансирование функции RFC Editor в настоящее время обеспечивается Internet Society.
Network Working Group M. Handley
Request for Comments: 2736 ACIRI
BCP: 36 C. Perkins
Category: Best Current Practice UCL
December 1999
Guidelines for Writers of RTP Payload Format Specifications
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document provides general guidelines aimed at assisting the
authors of RTP Payload Format specifications in deciding on good
formats. These guidelines attempt to capture some of the experience
gained with RTP as it evolved during its development.
1. Introduction
This document provides general guidelines aimed at assisting the
authors of RTP [9] Payload Format specifications in deciding on good
formats. These guidelines attempt to capture some of the experience
gained with RTP as it evolved during its development.
The principles outlined in this document are applicable to almost all
data types, but are framed in examples of audio and video codecs for
clarity.
2. Background
RTP was designed around the concept of Application Level Framing
(ALF), first described by Clark and Tennenhouse [2]. The key argument
underlying ALF is that there are many different ways an application
might be able to cope with misordered or lost packets. These range
from ignoring the loss, to re-sending the missing data (either from a
buffer or by regenerating it), and to sending new data which
supersedes the missing data. The application only has this choice if
the transport protocol is dealing with data in "Application Data
Units" (ADUs). An ADU contains data that can be processed out-of-
Handley & Perkins Best Current Practice [Page 1]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
order with respect to other ADUs. Thus the ADU is the minimum unit
of error recovery.
The key property of a transport protocol for ADUs is that each ADU
contains sufficient information to be processed by the receiver
immediately. An example is a video stream, wherein the compressed
video data in an ADU must be capable of being decompressed regardless
of whether previous ADUs have been received. Additionally the ADU
must contain "header" information detailing its position in the video
image and the frame from which it came.
Although an ADU need not be a packet, there are many applications for
which a packet is a natural ADU. Such ALF applications have the
great advantage that all packets that are received can be processed
by the application immediately.
RTP was designed around an ALF philosophy. In the context of a
stream of RTP data, an RTP packet header provides sufficient
information to be able to identify and decode the packet irrespective
of whether it was received in order, or whether preceding packets
have been lost. However, these arguments only hold good if the RTP
payload formats are also designed using an ALF philosophy.
Note that this also implies smart, network aware, end-points. An
application using RTP should be aware of the limitations of the
underlying network, and should adapt its transmission to match those
limitations. Our experience is that a smart end-point implementation
can achieve significantly better performance on real IP-based
networks than a naive implementation.
3. Channel Characteristics
We identify the following channel characteristics that influence the
best-effort transport of RTP over UDP/IP in the Internet:
o Packets may be lost
o Packets may be duplicated
o Packets may be reordered in transit
o Packets will be fragmented if they exceed the MTU of the
underlying network
The loss characteristics of a link may vary widely over short time
intervals.
Handley & Perkins Best Current Practice [Page 2]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
Although fragmentation is not a disastrous phenomenon if it is a rare
occurrence, relying on IP fragmentation is a bad design strategy as
it significantly increases the effective loss rate of a network and
decreases goodput. This is because if one fragment is lost, the
remaining fragments (which have used up bottleneck bandwidth) will
then need to be discarded by the receiver. It also puts additional
load on the routers performing fragmentation and on the end-systems
re-assembling the fragments.
In addition, it is noted that the transit time between two hosts on
the Internet will not be constant. This is due to two effects -
jitter caused by being queued behind cross-traffic, and routing
changes. The former is possible to characterise and compensate for
by using a playout buffer, but the latter is impossible to predict
and difficult to accommodate gracefully.
4. Guidelines
We identify the following requirements of RTP payload format
specifications:
+ A payload format should be devised so that the stream being
transported is still useful even in the presence of a moderate
amount of packet loss.
+ Ideally all the contents of every packet should be possible to be
decoded and played out irrespective of whether preceding packets
have been lost or arrive late.
The first of these requirements is based on the nature of the
Internet. Although it may be possible to engineer parts of the
Internet to produce low loss rates through careful provisioning or
the use of non-best-effort services, as a rule payload formats should
not be designed for these special purpose environments. Payload
formats should be designed to be used in the public Internet with
best effort service, and thus should expect to see moderate loss
rates. For example, a 5% loss rate is not uncommon. We note that
TCP steady state models [3][4][6] indicate that a 5% loss rate with a
1KByte packet size and 200ms round-trip time will result in TCP
achieving a throughput of around 180Kbit/s. Higher loss rates,
smaller packet sizes, or a larger RTT are required to constrain TCP
to lower data rates. For the most part, it is such TCP traffic that
is producing the background loss that many RTP flows must co-exist
with. Without explicit congestion notification (ECN) [8], loss must
be considered an intrinsic property of best-effort parts of the
Internet.
Handley & Perkins Best Current Practice [Page 3]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
When payload formats do not assume packet loss will occur, they
should state this explicitly up front, and they will be considered
special purpose payload formats, unsuitable for use on the public
Internet without special support from the network infrastructure.
The second of these requirements is more explicit about how RTP
should cope with loss. If an RTP payload format is properly
designed, every packet that is actually received should be useful.
Typically this implies the following guidelines are adhered to:
+ Packet boundaries should coincide with codec frame boundaries.
Thus a packet should normally consist of one or more complete
codec frames.
+ A codec's minimum unit of data should never be packetised so that
it crosses a packet boundary unless it is larger than the MTU.
+ If a codec's frame size is larger than the MTU, the payload format
must not rely on IP fragmentation. Instead it must define its own
fragmentation mechanism. Such mechanisms may involve codec-
specific information that allows decoding of fragments.
Alternatively they might allow codec-independent packet-level
forward error correction [5] to be applied that cannot be used
with IP-level fragmentation.
In the abstract, a codec frame (i.e., the ADU or the minimum size
unit that has semantic meaning when handed to the codec) can be of
arbitrary size. For PCM audio, it is one byte. For GSM audio, a
frame corresponds to 20ms of audio. For H.261 video, it is a Group
of Blocks (GOB), or one twelfth of a CIF video frame.
For PCM, it does not matter how audio is packetised, as the ADU size
is one byte. For GSM audio, arbitrary packetisation would split a
20ms frame over two packets, which would mean that if one packet were
lost, partial frames in packets before and after the loss are
meaningless. This means that not only were the bits in the missing
packet lost, but also that additional bits in neighboring packets
that used bottleneck bandwidth were effectively also lost because the
receiver must throw them away. Instead, we would packetise GSM by
including several complete GSM frames in a packet; typically four GSM
frames are included in current implementations. Thus every packet
received can be decoded because even in the presence of loss, no
incomplete frames are received.
The H.261 specification allows GOBs to be up to 3KBytes long,
although most of the time they are smaller than this. It might be
thought that we should insert a group of blocks into a packet when it
fits, and arbitrarily split the GOB over two or more packets when a
Handley & Perkins Best Current Practice [Page 4]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
GOB is large. In the first version of the H.261 payload format, this
is what was done. However, this still means that there are
circumstances where H.261 packets arrive at the receiver and must be
discarded because other packets were lost - a loss multiplier effect
that we wish to avoid. In fact there are smaller units than GOBs in
the H.261 bit-stream called macroblocks, but they are not
identifiable without parsing from the start of the GOB. However, if
we provide a little additional information at the start of each
packet, we can reinstate information that would normally be found by
parsing from the start of the GOB, and we can packetise H.261 by
splitting the data stream on macroblock boundaries. This is a less
obvious packetisation for H.261 than the GOB packetisation, but it
does mean that a slightly smarter depacketiser at the receiver can
reconstruct a valid H.261 bitstream from a stream of RTP packets that
has experienced loss, and not have to discard any of the data that
arrived.
An additional guideline concerns codecs that require the decoder
state machine to keep step with the encoder state machine. Many
audio codecs such as LPC or GSM are of this form. Typically they are
loss tolerant, in that after a loss, the predictor coefficients
decay, so that after a certain amount of time, the predictor error
induced by the loss will disappear. Most codecs designed for
telephony services are of this form because they were designed to
cope with bit errors without the decoder predictor state permanently
remaining incorrect. Just packetising these formats so that packets
consist of integer multiples of codec frames may not be optimal, as
although the packet received immediately after a packet loss can be
decoded, the start of the audio stream produced will be incorrect
(and hence distort the signal) because the decoder predictor is now
out of step with the encoder. In principle, all of the decoder's
internal state could be added using a header attached to the start of
every packet, but for lower bit-rate encodings, this state is so
substantial that the bit rate is no longer low. However, a
compromise can usually be found, where a greatly reduced form of
decoder state is sent in every packet, which does not recreate the
encoders predictor precisely, but does reduce the magnitude and
duration of the distortion produced when the previous packet is lost.
Such compressed state is, by definition, very dependent on the codec
in question. Thus we recommend:
+ Payload formats for encodings where the decoder contains internal
data-driven state that attempts to track encoder state should
normally consider including a small additional header that conveys
the most critical elements of this state to reduce distortion
after packet loss.
Handley & Perkins Best Current Practice [Page 5]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
A similar issue arises with codec parameters, and whether or not they
should be included in the payload format. An example is with a codec
that has a choice of huffman tables for compression. The codec may
use either huffman table 1 or table 2 for encoding and the receiver
needs to know this information for correct decoding. There are a
number of ways in which this kind of information can be conveyed:
o Out of band signalling, prior to media transmission.
o Out of band signalling, but the parameter can be changed mid-
session. This requires synchronization of the change in the media
stream.
o The change is signaled through a change in the RTP payload type
field. This requires mapping the parameter space into particular
payload type values and signalling this mapping out-of-band prior
to media transmission.
o Including the parameter in the payload format. This allows for
adapting the parameter in a robust manner, but makes the payload
format less efficient.
Which mechanism to use depends on the utility of changing the
parameter in mid-session to support application layer adaptation.
However, using out-of-band signalling to change a parameter in mid-
session is generally to be discouraged due to the problem of
synchronizing the parameter change with the media stream.
4.1. RTP Header Extensions
Many RTP payload formats require some additional header information
to be carried in addition to that included in the fixed RTP packet
header. The recommended way of conveying this information is in the
payload section of the packet. The RTP header extension should not be
used to convey payload specific information ([9], section 5.3) since
this is inefficient in its use of bandwidth; requires the definition
of a new RTP profile or profile extension; and makes it difficult to
employ FEC schemes such as, for example, [7]. Use of an RTP header
extension is only appropriate for cases where the extension in
question applies across a wide range of payload types.
4.2. Header Compression
Designers of payload formats should also be aware of the needs of RTP
header compression [1]. In particular, the compression algorithm
functions best when the RTP timestamp increments by a constant value
between consecutive packets. Payload formats which rely on sending
packets out of order, such that the timestamp increment is not
Handley & Perkins Best Current Practice [Page 6]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
constant, are likely to compress less well than those which send
packets in order. This has most often been an issue when designing
payload formats for FEC information, although some video codecs also
rely on out-of-order transmission of packets at the expense of
reduced compression. Although in some cases such out-of-order
transmission may be the best solution, payload format designers are
encourage to look for alternative solutions where possible.
5. Summary
Designing packet formats for RTP is not a trivial task. Typically a
detailed knowledge of the codec involved is required to be able to
design a format that is resilient to loss, does not introduce loss
magnification effects due to inappropriate packetisation, and does
not introduce unnecessary distortion after a packet loss. We believe
that considerable effort should be put into designing packet formats
that are well tailored to the codec in question. Typically this
requires a very small amount of processing at the sender and
receiver, but the result can be greatly improved quality when
operating in typical Internet environments.
Designers of new codecs for use with RTP should consider making the
output of the codec "naturally packetizable". This implies that the
codec should be designed to produce a packet stream, rather than a
bit-stream; and that that packet stream contains the minimal amount
of redundancy necessary to ensure that each packet is independently
decodable with minimal loss of decoder predictor tracking. It is
recognised that sacrificing some small amount of bandwidth to ensure
greater robustness to packet loss is often a worthwhile tradeoff.
It is hoped that, in the long run, new codecs should be produced
which can be directly packetised, without the trouble of designing a
codec-specific payload format.
It is possible to design generic packetisation formats that do not
pay attention to the issues described in this document, but such
formats are only suitable for special purpose networks where packet
loss can be avoided by careful engineering at the network layer, and
are not suited to current best-effort networks.
6. Security Considerations
The guidelines in this document result in RTP payload formats that
are robust in the presence of real world network conditions.
Designing payload formats for special purpose networks that assume
negligable loss rates will normally result in slightly better
compression, but produce formats that are more fragile, thus
rendering them easier targets for denial-of-service attacks.
Handley & Perkins Best Current Practice [Page 7]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
Designers of payload formats should pay close attention to possible
security issues that might arise from poor implementations of their
formats, and should be careful to specify the correct behaviour when
anomalous conditions arise. Examples include how to process illegal
field values, and conditions when there are mismatches between length
fields and actual data. Whilst the correct action will normally be
to discard the packet, possible such conditions should be brought to
the attention of the implementor to ensure that they are trapped
properly.
The RTP specification covers encryption of the payload. This issue
should not normally be dealt with by payload formats themselves.
However, certain payload formats spread information about a
particular application data unit over a number of packets, or rely on
packets which relate to a number of application data units. Care must
be taken when changing the encryption of such streams, since such
payload formats may constrain the places in a stream where it is
possible to change the encryption key without exposing sensitive
data.
Designers of payload formats which include FEC should be aware that
the automatic addition of FEC in response to packet loss may increase
network congestion, leading to a worsening of the problem which the
use of FEC was intended to solve. Since this may, at its worst,
constitute a denial of service attack, designers of such payload
formats should take care that appropriate safeguards are in place to
prevent abuse.
Authors' Addresses
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
Handley & Perkins Best Current Practice [Page 8]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
Acknowledgments
This document is based on experience gained over several years by
many people, including Van Jacobson, Steve McCanne, Steve Casner,
Henning Schulzrinne, Thierry Turletti, Jonathan Rosenberg and
Christian Huitema amongst others.
References
[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.
Handley & Perkins Best Current Practice [Page 9]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Handley & Perkins Best Current Practice [Page 10]