CC BY
31
ПРИМЕНЕНИЕ АВТОРЕГРЕССИОННОГО ИНТЕГРИРОВАННОГО СКОЛЬЗЯЩЕГО СРЕДНЕГО В АЛГОРИТМАХ УПРАВЛЕНИЯ ПЕРЕГРУЗКАМИ ПРОТОКОЛОВ ПЕРЕДАЧИ ПОТОКОВЫХ
ДАННЫХ М.Ю. Будько, М.Б. Будько, А.В. Гирик Научный руководитель - к. т.н., доцент Г.П. Жигулин
Настоящая статья посвящена вопросам применения краткосрочного прогнозирования в алгоритмах управления перегрузками протоколов передачи потоковых данных (таких, как RTP). Рассмотрены основные причины необходимости управления перегрузками в сетях без обеспечения качества обслуживания и подходы к реализации алгоритмов управления перегрузками в транспортных протоколах. Предложен подход к прогнозированию транспортных метрик с помощью ARIMA-процессов.
Введение
Рост объемов передаваемых по сетям данных в настоящее время таков, что проблема нехватки ресурсов встает остро даже для «быстрых» локальных сетей [1]. Если нагрузка превышает (возможно, временно) ресурсы сети, то в сети появляются перегрузки. Есть два выхода из этого положения: увеличить ресурсы и сократить нагрузку. Поскольку увеличить ресурсы чаще всего невозможно, остается только сокращение нагрузки, что в случае передачи мультимедийных данных означает ухудшение качества данных, передаваемых всем или некоторым пользователям.
Передача аудио- и видеоинформации в IP-сетях сопряжена с рядом трудностей. IP-сеть не может гарантировать надежную доставку или производительность, так как сетевой протокол IP осуществляет передачу дейтаграмм по принципу best effort. Пакеты в ходе доставки могут быть задержаны, переупорядочены, отброшены (потеряны) или повреждены. Протоколы более высоких уровней, работающие на конечных узлах, могут обеспечивать определенные гарантии доставки. Кроме этого, управление перегрузками и регулирование интенсивности трафика также возлагается на конечные узлы. Приложения, генерирующие мультимедийный трафик, должны учитывать текущее состояние сети и регулировать интенсивность трафика таким образом, чтобы избежать перегрузок [2].
Способы минимизации задержки потерь применяются в IP-сетях
Какие же способы гарантии минимизации задержки, вариации задержки и потерь применяются в изначально ненадежных IP-сетях? Все они сводятся к резервированию ресурсов сетевого оборудования для отдельных потоков данных. В случае использования системы интегрированного обслуживания (Integrated Services, IntServ) гарантии качества (Quality of Service, QoS) предоставляются для сетевых соединений на протяжении всего маршрута от источника данных к получателю, а в системе дифференцированного обслуживания (Differentiated Services, DiffServ) гарантии качества в виде приоритетного обслуживания предоставляются для классов трафика. Достоинством первой системы является прямая поддержка идеологии сквозной доставки (end-to-end) [3], характерной для многих потоковых приложений, недостатком - повышенная нагрузка на маршрутизаторы операторов, вынужденных поддерживать сведения о большом количестве пользовательских потоков, которые должны быть обслужены с затребованным уровнем QoS, что же касается второй системы, то ее применение существенно снижает нагрузку на магистральные маршрутизаторы, но не обеспечивает сквозной гарантии QoS для потоков данных, так как приоритетное обслуживание классов трафика (и способы задания этих классов) в различном сетевом оборудовании могут существенно отличаться. В результате ни та, ни другая система широко не применяется, и, как прави-
ло, обеспечить сквозное качество обслуживания в IP-сети не удается. Необходимо защититься хотя бы от критических перебоев в работе сервисов. Таким образом, организация потокового вещания в сетях, изначально не приспособленных для этого (а таких сетей большинство), представляет собой непростую и актуальную задачу. Эта задача может быть решена путем внедрения системы управления передачей потоковых данных как компонентов операционной системы или компонентов приложений, осуществляющих трансляцию потоковых данных. Понятно, что система управления передачей потоковых данных не является панацеей и обеспечить выполнение гарантий QoS с ее помощью нельзя, однако можно добиться своевременной реакции на критические ситуации, прогнозирования нагрузки и возможных коллапсов, адаптации сервиса к изменившимся условиям в сети [4].
Каким образом приложение может судить о текущем состоянии сети? При наблюдении за системой оно может использовать такие метрики, как средняя длина очередей или количество отброшенных пакетов. Если речь идет о транспортных или прикладных протоколах, то чаще используются такие метрики, как время прохождения пакетов по сети, вариация этого времени и число повторно переданных пакетов.
Основная задача алгоритма управления перегрузками - вовремя обнаружить, что ресурсов системы становится недостаточно, и отреагировать на это, например, снижением интенсивности передачи данных, что, в свою очередь, может быть достигнуто, например, увеличением задержки между пакетами при отправке их в сеть. Алгоритмы с явной обратной связью основаны на том, что получатель информирует отправителя о перегрузке, например, с помощью посылки специального пакета. Алгоритмы с неявной обратной связью основаны на том, что источник сам определяет факт перегрузки на основе своих локальных наблюдений за трафиком, например, по величине задержки уведомления о доставке пакета. Необходимо отметить, что в большинстве реализаций не делается попыток «заглянуть» в будущее и определить время и характер перегрузки, чаще всего предусматривается непосредственная реакция на изменение той или иной метрики.
Типичным примером протокола, в котором используется управление перегрузками, является TCP - протокол надежной доставки, работающий поверх ненадежного IP. Средства управления перегрузками появились в TCP не сразу - различные механизмы добавлялись в разное время [5]. Для оценки времени двойного оборота (и установки для отправленного пакета таймера повторной передачи) используется разновидность скользящего среднего - экспоненциальное сглаживание
rtte = а ■ rtte + (1 - a)rttm,
rto = в ■ rtte,
где rtte - расчетное время двойного оборота (оценка), rttm - последнее измерение rtt, rto - расчетное значение периода времени для таймера повторной передачи.
относительный размер окна
время, с
Рис. 1. Управление перегрузками AIMD (Additive Increase Multiplicative Decrease)
Так называемый «медленный старт» выполняется в начале передачи, когда скорость передачи растет экспоненциально. В тот момент, когда происходит потеря пакетов, соединение переводится в фазу предупреждения перегрузок: линейный рост скорости передачи (который обеспечивается увеличением на единицу размеров окна на каждый подтвержденный пакет) сочетается с уменьшением размера окна передачи в два раза при обнаружении потери. TCP-соединение «зондирует» доступную пропускную способность сети, каждый раз подходя к границе и отступая от нее. Результат такого поведения - характерный «пилообразный» трафик - представлен на рис. 1.
Есть несколько следствий подобного поведения. В случае, когда речь идет об эластичном трафике, удается значительно сэкономить ресурсы, сведя количество повторных передач к минимуму. Однако существуют и побочные эффекты: во-первых, при определенных условиях может наблюдаться явление, напоминающее «резонанс» множества TCP-источников, что отрицательно сказывается на функционировании сети [6]. Во-вторых, описанное поведение TCP-источников отрицательно сказывается на приложениях, передающих мультимедийный трафик и чувствительных к задержкам [4]. Протокол IP сам по себе не гарантирует своевременную доставку, наличие же в сети TCP трафика приводит к еще большей вариации задержки. При этом требование своевременной доставки для приложений реального времени (видео, аудио) является более важным, чем требование надежной доставки, так как с частичной потерей данных приложения реального времени, как правило, могут справиться.
В какой-то степени проблемы с временем доставки можно решить буферизацией данных в приемнике и использованием адаптивного кодирования (адаптивного к доступной пропускной способности соединения). Однако задержки, связанные с буферизаций, неприемлемы для многих интерактивных сервисов, например, видеотелефонии или видеоконференций, а кодеки, которые бы реализовывали принципы адаптивного кодирования и которые предусматривали бы возможность управления и изменения параметров кодирования «на лету», пока что находятся в экспериментальной стадии. С другой стороны, использование таких кодеков (по одному процессу транскодирования на каждое клиентское соединение) потребовало бы огромного количества ресурсов.
Ясно, что для передачи потоковых данных TCP и его модификации не подходят. В большинстве случаев приложения используют UDP и его разновидности [7] (в том числе собственные протоколы, работающие поверх UDP). В настоящее время все чаще используется протокол RTP (Real Time Protocol) [4, 8]. Трудность использования RTP - в том, что приложения должны реализовывать алгоритм управления перегрузками самостоятельно. В некоторых случаях это неудобно - реализация управления перегрузками на транспортном уровне позволила бы значительно упростить логику передачи потоковых данных во многих приложениях. Протокол DCCP (Datagram Congestion Control Protocol) непосредственно не предназначен для передачи мультимедийных данных, скорее это замена UDP [9]. Разработчики DCCP предполагали, что протокол будет реализован в ядре ОС и это позволит использовать его в качестве основы для протоколов прикладного уровня. В DCCP возможен выбор алгоритма управления перегрузками на этапе установления соединения. Также предусмотрена возможность задания собственного алгоритма [10].
Алгоритм TFRC
Были предложены различные алгоритмы, наиболее зрелым из которых сообществом Internet был признан TFRC (TCP Friendly Rate Control). Благодаря использованию этого алгоритма удается сгладить всплески скорости передачи, характерные для TCP, при сохранении той же средней пропускной способности соединения [11]. TFRC опи-
рается на то, что для устойчивого состояния TCP отправителя максимальная скорость передачи данных обратно пропорциональна корню квадратному из вероятности потерь:
Алгоритм управления перегрузками накладывает ограничения на максимальную скорость передачи и устанавливает, в какие моменты времени скорость может изменяться как в большую, так и в меньшую сторону.
TFRC сохраняет требование выполнять медленный старт, что неудобно для приложений реального времени. Кодеки, которые продуцируют взрывной поток данных, также плохо «уживаются» с TFRC [11]. С другой стороны, несомненна польза от управления перегрузками: интеллектуальное приложение может изменить параметры кодирования видео- или аудиопотока таким образом, что качество ухудшится, но не так, как в случае, если данные будут отброшены сетью. Способ, которым достигается изменение качества транслируемого потока, может отличаться от приложения к приложению, но можно смело утверждать, что в схемах, в которых реализуется переключение между уровнями качества, о моментах изменения желательно знать заранее.
Кратковременное прогнозирование перегрузок для отдельного соединения
В ходе разработки приложения для передачи потокового видео с использованием специального профиля протокола RTP и оригинальной схемы изменения качества транслируемых потоков перед авторами встала задача реализации механизма кратковременного прогнозирования перегрузок для отдельного соединения. Ни один из известных алгоритмов управления перегрузками не выполняет экстраполяцию данных с целью прогнозирования возможных действий для высокоуровневых прикладных механизмов. Задача решается экстраполяцией транспортных и прикладных метрик на основе модели авторегрессионных скользящих средних. Анализу подвергаются данные, которые отправитель получает по протоколу RTCP, и SNMP статистика, собранная с сетевых устройств.
Традиционно такие модели прогнозирования, как ARMA и ARIMA, и основанные на них используются при анализе временных рядов в эконометрике. Они также хорошо зарекомендовали себя в области долгосрочного и среднесрочного прогнозирования трафика в магистральных сетях, в сетях предприятий [12] и т.д.
Любое наблюдение процесса авторегресии и скользящего среднего состоит из линейной функции от предыдущего наблюдения плюс независимый случайный шум минус некоторая доля предыдущего случайного шума. Прогнозирование следующего наблюдения выполняется путем комбинирования прогнозируемого значения из оценки уравнения авторегрессии с оценкой текущего случайного шума: Yt =5 + çYt-i + st -0st-i.
Как правило, рассматриваемые процессы проявляют нестабильность [13]. Чистый интегрированный процесс (также называемый случайным блужданием) имеет тенденцию все дальше уходить от точки, в которой он находился. Нельзя рассчитывать на то, что с течением времени значение метрики будет оставаться достаточно близким к какому-либо долгосрочному среднему значению. Стационарным ARMA-процессом может быть процесс изменения или разности ряда. В этом случае сам ряд соответствует процессу авторегрессионного интегрированного скользящего среднего.
T
1
T
Основные трудности прогнозирования на основе ARIMA-процессов заключаются в подборе полинома и быстром расхождении доверительного интервала в области экстраполяции.
Заключение
Управление передачей потоковых данных в современных сетях без поддержки качества обслуживания является актуальной задачей, а выбор алгоритма управления перегрузками в большинстве случаев зависит от характеристик приложения. Прогнозирование перегрузок - это следующий шаг после реализации простой реакции на перегрузки. Перспективным подходом является кратковременное прогнозирование на основе ARIMA процессов.
Литература
1. Шувалов В.П., Ярославцев А.Ф. Телекоммуникационные системы и сети. Т.3, М., 2003.
2. C.S. Perkins, L. Gharai, T. Lehman and A. Mankin. Experiments with delivery of HDTV over IP networks. / Proceedings of the 12th International Packet Video Workshop, (Pittsburgh, PA, USA), April 2002.
3. J.H. Saltzer, D.P. Reed and D.D. Clark. End-to-end arguments in system design. // ACM Transactions on Computer Systems. 2, November 1984.
4. C.S. Perkins. RTP: Audio and Video for the Internet. Addison Wesley, June 2003.
5. V. Jacobson, Congestion Avoidance and Control, SIGCOMM, 1988.
6. Платов В.В., Петров В.В. Исследование самоподобной структуры трафика беспроводной сети, http://www.teletrafic.ru
7. L-A. Larzon, M. Degermark, S. Pink, The Lightweight User Datagram Protocol (UDP-Lite). // Internet Engineering Task Force, July 2004. RFC 3828.
8. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: A transport protocol for real-time applications. // Internet Engineering Task Force, July 2003. RFC 3550.
9. E. Kohler, M. Handley and S. Floyd. Datagram congestion control protocol (DCCP). // Internet Engineering Task Force, November 2004.
10. E. Kohler, M. Handley and S. Floyd, Designing DCCP: Congestion control without reliability. / International Computer Science Institute, Berkeley, CA, USA, May 2003.
11. S. Floyd, M. Handley, J. Padhey, J. Widmer. Equation-Based Congestion Control for Uni-cast Applications. SIGCOMM, 2000.
12. M. Papadopouli, H. Shen, E. Raftopoulos, M. Ploumidis, F. Hernandes-Campos. Short-term traffic forecasting in a campus-wide wireless network, SIGCOMM, 2004.
13. M. Papadopouli, H. Shen, E. Raftopoulos. Evaluation of short-term traffic forecasting in wireless network, SIGCOMM, 2005.
