А В Бабич, М Али - Модели обратной связи для протокола rtcp - страница 1

Страницы:
1 

УДК 004.732

А. В. БАБИЧ, МУРАД АЛИ А.

МОДЕЛИ ОБРАТНОЙ СВЯЗИ ДЛЯ ПРОТОКОЛА RTCP

Рассматриваются модели обратной связи для протокола RTCP, использование кото­рых позволяет решить проблему снижения нагрузки на сеть и сбалансированности широ­ковещательного трафика RTP и RTCP. Исследуются их особенности, преимущества и недостатки. Предлагается расширение одной из моделей обратной связи (резюмирующая модель), позволяющее включить в отчеты получателя информацию о факторах, оказываю­щих наибольшее влияние на сеанс RTP и, таким образом, дающее возможность оперативно выявлять и устранять узкие места данного сеанса. Формулируются задачи, результатом решения которых будет реализация предложенного ранее расширения применительно к протоколу RTCP.

Введение

Благодаря многоадресной природе протоколов RTP/RTCP, все участники сеанса пере­дачи мультимедийных данных получают отчеты обратной связи остальных участников и, таким образом, каждый из них может оценить общее и индивидуальное качество приема и передачи во время сеанса связи, а именно: скорость данных, уровень утерянных пакетов и уровень неравномерности передачи. Хотя трафик RTCP передается таким образом, что его доля в RTP-сеансе не превышает 5%, тем не менее, это чревато двумя проблемами. Во-первых, согласно стандарту [1], возрастание плотности мультимедийного трафика при­водит к уменьшению RTCP-трафика и, как результат, снижает вероятность своевременной реакции участников сеанса на изменившиеся условия передачи. Во-вторых, 5% широкове­щательного трафика является достаточно большим значением. Доля широковещательного трафика в 8% от общей доли трафика уже рассматривается как широковещательный шторм, который может привести к значительному уменьшению пропускной способности сети. Таким образом, снижение уровня многоадресного RTCP-трафика, которое позволит избежать перегрузок в сети и сохранить исходную функциональность RTCP, является достаточно актуальной задачей.

Модели обратной связи RTCP

В качестве решения упомянутой выше задачи в [1] предлагается простая модель обратной связи. Такая модель (рис.1) - базовый механизм "отражения" RTCP-трафика, где каждый участник сеанса передачи мультимедийных данных отсылает нешироковещатель­ным образом специальный пакет обратной связи, так называемый отчет получателя (Receiver Report, RR), к целевому узлу обратной связи (Feedback Target), который пересылает данные отчеты в исходном виде к источнику рассылки (Distribution Source). Далее источ­ник рассылки "отражает" отчеты получателя широковещательным образом всем участни­кам сеанса передачи мультимедийных данных. Преимущество данного метода заключа­ется в том, что для его использования существующая реализация модуля получателя требует лишь незначительной модификации. Вместо рассылки отчетов по групповому адресу получатель использует одноадресную передачу, в то же время получая "отражен­ный" RTCP-трафик широковещательным способом.

Таким образом, механизм "отражения" является неплохой альтернативой коммуникаци­онному каналу "многие ко многим", но в то же время использование однонаправленного канала приводит к другой проблеме - ограничению по числу соединений и значительному сокращению масштабируемости для больших мультимедийных сеансов (например, IPTV). Более того, пересылка всех отчетов получателя от каждого участника сеанса мультиме­дийной передачи данных по однонаправленному каналу неэффективна. Например, в случае вычисления временных меток RTT, которые могут быть полезны только источнику муль­тимедийных данных, нет никакой необходимости пересылать их в группу участников мультимедиа-сеанса.

Receiver 1

Receiver 2

DS - Distribution Source FT - Feedback Target

i.o ил a - &    Receiver N

MS - Media Sender

RR - Receiver Report

-- Multicast traffic

-«- - Unicast traffic

Рис.1. Простая модель обратной связи

Помимо простой модели обратной связи, в области оптимизации трафика обратной связи протокола RTP имеются и другие разработки. Так, в [1-3] представлены следующие модели и методы обратной связи:

- метод резюмирования,

- фильтрование обратной связи,

- алгоритм смещения,

- иерархическое агрегирование обратной связи.

Резюмирующая модель обратной связи источника рассылки - схема сводной отчетнос­ти, обеспечивающая экономичное использование пропускной способности путем слияния отчетов получателя на источнике рассылки, необязательно, но возможно при помощи целевого узла обратной связи, в сводные (резюмирующие) пакеты, которые затем рассы­лаются всем получателям (рис. 2).

Рис. 2. Структура пакета RTCP-RSI (Report Summary Information) [1] Преимущество применения последней схемы лучше всего проявляется в сеансах пере­дачи мультимедийного трафика для больших групп, при использовании в которых механиз­ма "отражения" RTCP-трафика, описанного ранее, имеет место генерация значительного числа пересылаемых пакетов во время репликации всей информации на всех получателей. Ясно, что метод резюмирования требует, чтобы все участники сеанса понимали новый формат сводного пакета (рис.3). Вдобавок, резюмирующая схема предоставляет опцио­нальный механизм рассылки информации о данных обратной связи, сообщенных всей группой, в виде значений распределения или гистограммы.

Для однозначного распознавания каждого из рассмотренных методов рассылки отчетов вводится новый идентификатор SDP. При этом метод рассылки отчетов должен быть выбран перед началом сеанса передачи мультимедийных данных и должен оставаться неизменным в течение всего сеанса.

=4-=4-=4-=-t-=4= -t-=4-

Lentjtb

I     MF I

і—і і—і <іі і і <іі—і і і—іі—і t і—ііі і і—і—і—і і ііt І Міпілшт Distribution Value |

H--1---H + —I---1---1---H    + -H---1---h-1---H    H---1---H-1---I-H--h-h-1---I-H-H--h-1---I---I---1---1--+

І Мазсілші Distribution Value |

-H=-H=H-=+=+=+=-H=H-=H-=+=+=-H=-H=H-=+=+=+=-H=+=H-=+=+=-H=+=+=+=-H=+=+=+=+=+=+

I Distribution Buckets |

I ... I

I ■-■ I

4- = -t- = -t- = -t- =-t- = 4-= 4- = -t- = -t- =4- = 4-= 4- = -t- = -t- =4- = 4-= 4- = 4- = -t- = -t-=+-= 4- = 4- = -t- =-t- =-t- = -t- = 4- = -t- = -t- = 4-= 4- = 4-

Рис. 3. Общая форма блока отчета [1]

К недостатку резюмирования можно отнести то, что некоторая информация обратной связи, ориентированная на получателя, такая как отображение значений обратной связи в сетевые адреса, больше получателям не доступна. Но для больших групп (каковые предпо­лагаются для IPTV-сервиса, например) резюмирующие отчеты как индикаторы групповых явлений более полезны, чем индивидуальные отчеты получателя. Таким образом, резюмиро­вание еще и обеспечивает возможность реализации функций мониторинга и отладки мульти-сервисной сети, которые в свою очередь могут быть дополнены персонализированными отчетами, если таковые требуются в заданных условиях функционирования сети.

Модель обратной связи с фильтрованием (рис. 4) базируется на концепции, согласно которой в организации обратной связи медиа-сервера с получателями будут задействова­ны только некоторые, так называемые выделенные, участники сеанса передачи мультиме­дийных данных. Здесь основной задачей, требующей решения, является корректный с точки зрения значимости для качества сеанса связи и полноты покрытия выбор выделен­ных участников мультимедиа-сеанса.

Метод смещения (рис.5) довольно похож на реализацию обратной связи с фильтровани­ем и также базируется на выборе ряда участников сеанса передачи мультимедийных данных в качестве выделенных. Однако, в отличие от модели обратной связи со смещени­ем, здесь отчеты получателей отсылаются источнику RTP-трафика от всех участников сеанса, но трафик обратной связи от выделенных участников является более приоритет­ным и интенсивность его передачи не зависит от ширины полосы пропускания, занимаемой трафиком данных мультимедиа. Таким образом, результаты данного метода более объек­тивны. Более того, подгруппа выделенных участников может быть реорганизована в соответствии со значимостью поведения остальной части группы участников сеанса.

Однако, указанный алгоритм чувствителен к вариабельности размеров смещенных групп вследствие мобильности участников сеанса передачи мультимедийных данных (прихода новых и ухода старых членов группы), а также к высокой динамичности значений обратной связи членов смещенной группы. Оба явления влияют не только на точность алгоритма смещения, но и на стандартный RTCP.

Рис. 4. Модель обратной связи с фильтрованием Рис. 5. Модель обратной связи со смещением

Для масштабных сеансов передачи мультимедийных данных предпочтителен метод иерархического агрегирования (рис.6). Он базируется на концепции, в которой данные обратной связи не отсылаются напрямую источнику мультимедиа данных от каждого участника сеанса, а выполняется разбиение всех участников сеанса на подгруппы, пред­почтительно равные, в каждой подгруппе выбирается один участник, так называемый агрегатор (см. рис.6), который и является ответственным за сбор отчетов от каждого члена подотчетной ему подгруппы и передачу данных обратной связи источнику трафика RTP.

Реализация иерархического агрегирования также может быть представлена в много­уровневом виде и расширяться практически до любых размеров. Единственная задача, которую необходимо решить, заключается в выборе подходящих агрегаторов.

Главный недостаток иерархического агрегирования состоит в дополнительных времен­ных затратах на передачу данных обратной связи. Другой недостаток заключается в том, что данный механизм зависим от эффективного размещения агрегаторов и гарантии отсут­ствия недостатков топологии, закладываемой еще на этапе проектирования компьютерной сети. Например, к серьезным последствиям может привести зацикливание пути прохожде­ния через коммутаторы.

MS - Media Sender

RR - Receiver Report

RRagg - Aggregator Receiver Report

-^- - Multicast traffic

-> - Unicast traffic

Рис.6. Модель обратной связи с иерархическим агрегированием

Постановка задачи и дальнейшие исследования

Согласно [3], метод резюмирования позволяет экономично использовать пропускную способность транспортной платформы и, как следствие, делает возможным увеличение объема и классов данных, включаемых в резюмирующие пакеты, таких как тип (например, загрузка процессора) или степень детализации и прочее, оставаясь, вместе с тем, в рамках стандартных ограничений полосы пропускания для RTCP. Таким образом, представляется возможным включение в резюмирующий отчет (Report Summary Information, RSI), в поле блоков подотчетов, информации о факторах, оказывающих наибольшее влияние на каче­ство сеанса RTP. Это позволит своевременно выявить узкие места и избежать перегрузок в сети с трафиком реального времени.

Проблема предлагаемого подхода заключается в вычислении и оценивании уровня влияния наблюдаемых факторов. Для ее решения может быть использована теория плани­рования экспериментов (ТПЭ). ТПЭ является наиболее эффективным способом отбора различных репрезентативных наборов экспериментов, когда процесс или система включа­ют в себя две или более переменных. Здесь ТПЭ формирует такой набор экспериментов, в котором все факторы независимы друг от друга и вместе с тем должны варьироваться одновременно. Результатом будет прогнозирующая модель, показывающая степень зна­чимости всех факторов и их взаимодействий для выходного параметра. Уровень влияния наблюдаемых факторов и их взаимодействий вычисляется с использованием множествен­ной регрессионной модели (1), (2):

Y = b0 +bixi, (1)

где b0 - свободный коэффициент; bi - коэффициенты регрессии; xi - факторы, включенные в эксперимент.

Для полнофакторного эксперимента 2n коэффициенты регрессии bi для факторов xi вычисляются по следующей формуле:

N

S XiuYu

b = -u=1_, (2)

i N

здесь N - число экспериментов, включенных в план; Yu - значение параметра Y в каждом эксперименте.

Для реализации данной идеи необходимо решить следующие задачи:

- разработать факторную модель сеанса передачи данных RTP/RTCP,

- разработать план эксперимента для заданной факторной модели,

- выполнить практическую реализацию метода выявления факторов, оказывающих наибольшее влияние на качество сеанса RTP и механизма его внедрения в резюмирующую модель обратной связи RTCP.

Выводы

Рассмотрены модели обратной связи для протокола RTCP, использование которых позволяет решить проблему снижения нагрузки на сети и сбалансированности широкове­щательного трафика RTP и RTCP. Исследованы их особенности, преимущества и недо­статки. Предложено расширение одной из моделей обратной связи (резюмирующая мо­дель), позволяющее включить в отчеты получателя информацию о факторах, оказываю­щих наибольшее влияние на сеанс RTP и, таким образом, дающее возможность оперативно выявлять и устранять узкие места данного сеанса. Сформулированы задачи, результатом решения которых будет реализация предложенного ранее решения применительно к прото­колу RTCP.

Список литературы: 1. Schulzrinne H., Casner S., FrederickR., Jacobson V. RTP: A Transport Protocol for RealTime Applications. RFC 3550. Internet Engeneering Task Force, July 2003. 2. Ott J., Chesterfield J., Schooler E. RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback. IETF draft, AVT-RTCP-SSM, March 2007. 3. Chesterfield J., SchoolerE. An Extensible RTCP Control Framework for Large Multimedia Distributions. Proceedings of the Second IEEE International Symposium on Network Computing and Applications, IEEE Computer Society, 2003. 4. Komosny D., Novotny V. Tree Structure for Source-Specific Multicast with Feedback Aggregation. The Sixth International Conference on Networking. Martinique, 2007, ISBN 0-7695-2805-8. 5. KomosnyD., Novotny V. Large-Scale RTCP Feedback Optimization. Journal of Networks, Vol. 3, No. 3, March 2008. 6. Burget R., Komosny D., Novotny V. Transmitting Hierarchical Aggregation Information Using RTCP Protocol. International Journal of Computer Science and Network Security, Vol. 7, No. 11, November 2007. 7. Burget R., Komosny D., Smilek M. One Source Multicast Model Using RTP in NS2. International Journal of Computer Science and Network Security, Vol. 7, No. 11, November 2005.

Поступила в редколлегию 14.07.2009

Бабич Анна Витальевна, канд. техн. наук, доцент кафедры АПВТ ХНУРЭ. Научные интересы: сетевые технологии, технологии дистанционного образования. Увлечения: ак­тивный отдых, путешествия, иностранные языки. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел. 70-21-326. E-mail: babich@kture.kharkov.ua

Мурад Али А., аспирант кафедры АПВТ ХНУРЭ. Научные интересы: компьютерные сети следующего поколения . Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел. 70-21-326.

Страницы:
1 


Похожие статьи

А В Бабич, М Али - Модели обратной связи для протокола rtcp