CC BY
36
ИМИТАЦИОННАЯ МОДЕЛЬ МЕХАНИЗМА СНИЖЕНИЯ СКОРОСТИ ПЕРЕДАЧИ ПРИ УПРАВЛЕНИИ ПЕРЕГРУЗКАМИ СЕРВЕРА ПРОТОКОЛА УСТАНОВЛЕНИЯ СЕССИЙ
Самуйлов Константин Евгеньевич,
д.т.н., Российский Университет Дружбы Народов (РУДН), Заведующий кафедрой прикладной информатики и теории вероятностей, Москва, Россия, ksam@sci.pfu.edu.ru
Павлоцкий Олег Эваристович,
Московский Технический Университет Связи и Информатики (МТУСИ), аспирант кафедры сетей связи и систем коммуникации, Москва, Россия, oleg.pavlotsky@yandex.ru
Ключевые слова: SIP-сервер, механизм контроля перегрузок, загруженность процессора SIP-сервера, гистерезисное управление перегрузками, Rate-based overload control.
Предоставление пользователям мультимедийных услуг предполагает безукоризненное качество передачи и современное технологическое оборудование, что влечет за собой необходимость разработки новых методов анализа и прогнозирования функционирования сети связи. Исследуется проблема перегрузок, возникающих на серверах протокола установления сессий SIP (Session Initiation Protocol), для решения которой предлагается использовать механизм с ограничением скорости потока сигнальных сообщений (RBOC, Rate-based overload control). Для контроля за поступающей на серверы нагрузкой вводится гистерезисное управление, реализуемое с помощью двух порогов. При возникновении перегрузки сервера вышележащим элементам сети сообщается о необходимости снижения скорости передачи запросов на данный сервер. Механизм гарантирует, что нижележащий сервер не получит объём трафика больше, чем он сможет обработать. Для ограничения количества поступающих заявок применяется алгоритм маркерного ведра. Система может функционировать в одном из трех режимов: режиме нормальной нагрузки, режиме снижения нагрузки и режиме сброса нагрузки. Предлагается имитационная модель механизма снижения скорости передачи, где с помощью ограниченного числа маркеров определяется скорость передачи запросов на сервер. Источник заявок реализует собой модель MMPP-2 (Markov-Modulated Poisson Process), когда источник может находиться в одном из двух состояний: состоянии генерации потока заявок с начальной или нулевой интенсивностью источника. Исследуются следующие вероятностно-временные характеристики: коэффициент загруженности SIP-сервера, процент обслуженных заявок, зависимость среднего времени ожидания начала обслуживания от структурных параметров и от числа маркеров.
Для цитирования:
Самуйлов К.Е., Павлоцкий О.Э. Имитационная модель механизма снижения скорости передачи при управлении перегрузками сервера протокола установления сессий // Т-Сотт: Телекоммуникации и транспорт. - 2016. - Том 10. - №3. - С. 44-48.
For citation:
Samouylov K.E, Pavlotsky O.B. Rate-based overload control mechanism simulator for SIP server overload control. T-Comm. 2016. Vol. 10. No.3, pp. 44-48. (in Russian)
T-Comm ^м 10. #3-2016
Введение и анализ механизма RBOC
Перегрузка происходит в сети SiP-серверов при отсутствии достаточного ресурса производительности для обработки получаемых сигнальных сообщений. Одним из способов управления перегрузками в сетях SIP-серверов является механизм просеивания нагрузки. Представлена имитационная модель контроля перегрузок, основанная на гистерезисном управлении нагрузкой и механизме контроля перегрузок RBOC (Rate-based Overload Control). Механизм работает таким образом, что и случае наступления перегрузки сервер сообщает вышележащим серверам, сколько запросов в единицу времени (например, в секунду) он готов принять от каждого из них. Данный механизм гарантирует, что нижележащий сервер не получит объём трафика больший, чем он сможет обработать.
Для обмена информацией о перегрузке между серверами и клиентами в рекомендациях IETF определены четыре параметра - "ос", "oc-algo","ос-validity" и "oc-seq", описание которых приведено также в [3]. Параметр "ос" вставляется клиентом и обновляется сервером. Клиент должен вставлять данный параметр в начало via-заголовка каждого запроса. Таким образом, нижележащие узлы информируются, что клиент поддерживает контроль перегрузки. При этом значение параметра не устанавливается клиентом, это делается сервером. Нижележащий сервер должен добавить значение параметра "ос" в ответе па запрос клиента, содержавшего данный параметр. Присвоение значения сообщает клиенту о том, что нижележащий сервер поддерживает контроль перегрузки. В случае, когда контроль перегрузки является активным, значение параметра указывает тот уровень контроля, который должен быть применён. Когда клиент получает ответ с заполненным значением параметра "ос", он должен понизить число запросов серверу, от которого получен данный ответ, в соответствии со значениями параметров "ос" и "oc-algo".
Параметр "oc-algo" вставляется клиентом и обновляется сервером. Клиент должен вставлять данный параметр в начало via-заголовка каждого запроса со значением по умолчанию "loss". Данный параметр содержит одно или более имён классов алгоритмов контроля перегрузок. Клиент должен поддерживать метод LBOC (Local-based Overload Control) и устанавливать маркер "loss" как одно из значений параметра "oc-algo". Клиент может через запятую указать другие маркеры в параметре "oc-algo", если данный клиент поддерживает другие методы управления перегрузок.
Параметр "oc-validity" может быть вставлен в ответ исключительно сервером. Данный параметр содержит значение, указывающее временной интервал в миллисекундах, в течение которого должен быть активен уровень контроля, указанный в значении параметра "ос". По умолчанию данный параметр равен 500 мс. Если клиент получает ответ с установленными значениями параметров "ос" и "oc-algo", но не содержащего "oc-validity", клиент должен считать, что получил параметр "oc-validity=500". Значение "oe-validity=0" используется в случае, когда сервер хочет прекратить контроль перегрузки или сообщает, что поддерживает контроль перегрузок, но в данный момент не запрашивает снижение нагрузки. Ненулевое значение параметра "oc-validity" принимается клиентом только вместе с установленным значением параметра "ос", в противном случае
отбрасывается. По истечению временного интервала, указанного в параметре "oc-validity", клиент не выполняет контроль перегрузок до получения обновлённых значений параметров.
Параметр "oc-seq" должен быть вставлен в ответ исключительно сервером. Данный параметр содержит значение последовательности, связанное со значением "ос", и используется для дифференциации двух различных значений "ос", сгенерированных в разные моменты времени. Значение параметра "oc-seq" для каждого следующего значения "ос" должно быть больше предыдущего, что позволяет клиенту упорядочивать ответы, пришедшие не по порядку.
В качестве значений "oc-seq" могут использоваться временные метки. Если значение данного параметра выходит за предел в течение периода понижения нагрузки, то этот параметр должен быть сброшен до значения текущей временной метки или соответствующего базового значения.
Когда клиент впервые соединяется с сервером, он может вставить в параметр "oc-algo" кроме обязательного "loss" значение "rate", таким образом, указав поддержку и RBOC. Если сервер выбрал RBOC, он должен в ответе как значение параметра "oc-algo" указать "rate".
Затем сервер периодически, используя внутренние изменения (например, загрузка процессора, задержка очереди), оценивает состояние перегрузки и рассчитывает желаемую скорость - планируемое число запросов в секунду {в отличие от процента потерь при LBOC). При перегрузке сервер использует "ос"-параметры ответов для информирования клиентов о состоянии перегрузки и планируемом числе запросов. После получения "ос"-параметров с указанием желаемого числа запросов клиент сокращает число новых запросов к перегруженному серверу.
Описанный выше алгоритм применен при разработке имитационной модели, описание которой приведено в следующем разделе статьи.
Описание имитационной модели
Обработка сообщений сервером описывается с помощью системы массового обслуживания с конечной очередью размера R и гистерезисным управлением нагрузкой с порогами L, 1 <L < R, н Н, 1 <H<R (см. рис. 1).
4M
5=0
« ► < ►
J=! <-»-
—*-*-1
V i V
s=2
О lr 1 L
НА И Н+1 5-1 5 п
Рис, 0, Функция интенсивности ¿¡(s,«) ¡-потока для системы ЩЩ1\{Ь, H)\R
Для ограничения количества поступающих заявок применяется алгоритм маркерного ведра. Система может функционировать в одном из трех режимов: режиме нормальной нагрузки (5=0), режиме снижения нагрузки (5=1) и сброса нагрузки (5=2), В режиме нормальной нагрузки при достижении длиной очереди значения Н, система переходит в режим пониженной нагрузки (5=1). В режиме пониженной нагрузки при достижении размера очереди значения /? система переходит в режим перегрузки (5=2).
В системе имеется ограниченное, заранее определённое, число маркеров. Эти маркеры накапливаются на стороне приёма и в определённые моменты времени (при достижении размера очереди значений 0,) передаются отправляющей стороне. При этом, в зависимости от состояния системы, могут быть отправлены как все накопившиеся маркеры (при ¿■=0), так и лишь их часть (при 5=1). Заявка из исходящей очереди может быть отправлена только и только в том случае, если для неё есть маркер, который закрепляется за заявкой. Если маркеров па стороне приёма лет, генерируемые заявки накапливаются в очереди отправления. По прибытию маркеров на сторону приёма заявки, которым хватило маркеров, отправляются, остальные заявки сбрасываются (сброс нагрузки). Общая схема взаимодействия компонентов имитационной модели представлена на рис. 2.
RTT
Функция управления
Монитор
RTT-
S IP-Клнент R' (источник заявок)
R II L
SlP-Сервер (процессор)
Рис. 2. Схема имитационной модели механизма RBOC
Ниже перечислены основные функции компонентов имитационной модели.
- Источник заявок — генерирует заявки на основе заданных параметров.
- 81Р-процессор - обрабатывает поступающие заявки и является компонентой, которую необходимо защищать от перегрузки.
- Монитор - измеряет текущую загрузку ироцессора. Он реализует механизмы определения использования ресурсов (в первую очередь, состояние буфера), необходимых для Й1Р-процессора и Функции контроля.
- Функция контроля - содержит алгоритм контроля перегрузки, по полученным значениям параметров использования ресурсов обнаруживает перегрузку и посылает соответствующее сообщение Актуатору для коррекции интенсивности потока на 31Р-процессор.
— Актуатор - реализует алгоритмы, гарантирующие объём формируемого Источником трафика согласно его критериям,
— Модуль управления — осуществляет общее управление работой модели.
Для имитационной модели исходными данными являются заданные значения следующих параметров: L, Н, R, q (ос), А (ос-validity), RTT, jli (интенсивность обслуживания). Собирается следующая статистика по загруженности процессора SIP-сервера: коэффициент загруженности процессора сервера: U - 1 - р00, где рпо -вероятность простоя процессора (вероятность того, что в системе находится 0 заявок), а также число периодов простоя процессора, число сгенерированных заявок, число обслуженных заявок, число перенаправленных заявок, среднее время ожидания заявкой начала обслуживания [5].
В следующем разделе представлен симулятор, как программное приложение, реализующее описанную выше модель механизма RBOC.
Симулятор
Симулятор представляет собой событийно-управляемое приложение [1,4], реализованное на языке С++ с использованием средств Microsoft Visual Studio 2012. Каждый компонент системы (SIP-процессор с буфером, Монитор, Функция Контроля, Источник и Актуатор) является независимым объектом.
Событиями в данной модели являются моменты поступления заявки от Источника в буфер Процессора и изменения состояния системы.
В симуляторс применяется два типа источника заявок. Первый — генерирует заявки с постоянной интенсивностью Л, второй представляет собой реализацию модели ММРР-2 (Markov-Modulated Poisson Process). Источник ММРР-2 может находиться в одном из двух состояний - состоянии генерации потока заявок с постоянной интенсивностью или состоянии с нулевой интенсивностью.
Ниже представлены исходные данные и график изменения длины очереди, числа маркеров и состояния системы (s) в зависимости от времени моделирования для случая потока ММПП-2 (следует отметить, что на выбранном интервале времени моделирования система не переходила в состояние s=2):
Д = 100;£ = 40;#=60;ц = 200 ]/с; RTT = 0,1 с/
Входные параметры для источника ММРР-2:
1 1 а = 100-, ß = 500 -;
с с
На рис. 4 представлен график зависимости коэффициента загруженности 81Р-процессор а и среднего времени ожидания обслуживания заявки от доли времени пребывания ММРР-2 источника (коэффициент у) в состоянии нулевой интенсивности.
T-Comm "Гом 10. #3-2016
RATE-BASED OVERLOAD CONTROL MECHANISM SIMULATOR FOR SIP SERVER OVERLOAD CONTROL
Samouylov Konstantin,
Peoples' Friendship University of Russia, Department of applied probability and informatics, professor,
ksam@sci.pfu.edu.ru
Pavlotsky Oleg,
Moscow Technical University of Communication and Informatics, Department of communication networks and commutation systems, PhD student, oleg.pavlotsky@yandex.ru
Abstract
Providing multimedia services to users assumes perfect quality of transfer and modern processing equipment that involves need of development of new methods of the analysis and forecasting of functioning of a communication network. In work the problem of the overload arising on servers of the protocol SIP (Session Initiation Protocol) for which decision it is offered to use the mechanism RBOC (Rate-based overload control) with restriction of speed of a flow of signal messages is investigated. For control of the loading arriving on servers the hysteresis control realized by means of two thresholds is entered. At emergence of an overload of the server to overlying elements of a network it is reported about need of reduction in the rate of transfer of requests for this server. The mechanism guarantees that the underlying server won't receive traffic volume more, than it will be able to process. The algorithm of a marker bucket is applied to restriction of number of the arriving demands. The system can function in one of three modes: mode of normal loading, mode of decrease in loading and mode of dumping of loading. The imitating model of the mechanism of reduction in the rate of transfer where by means of limited number of markers the speed of transfer of requests for the server is defined is offered. The source realizes itself the MMPP-2 model (Markov-Modulated Poisson Process) when the source can be in one of two states: a condition of generation of a flow of demands with initial or zero intensity of a source. The following probabilistic and time characteristics are investigated: coefficient of load of the SIP server, percent of the served demands, dependence of average time of expectation of the beginning of service on structural parameters and on number of markers.
Keywords: SIP server, mechanism of overload control, SIP processor utilization, hysteresis overload control, rate-based overload control. References
1. Gaidamaka, Y, Samouylov, K & Sopin, E. 2012, 'Model of one queuing system of M/G/1 type with hysteresis input flow control'. T-Comm. No. 7, pp. 60-62. (in Russian)
2. Noel, E & Williams, P. 2015, 'Session Initiation Protocol (SIP) Rate Control', viewed 01 February 2015, http://datatracker.ietf.org/doc/rfc74l5.
3. Pavlotsky, O & Talanova M. 2014, 'Analysis of overload control mechanisms on SIP servers for NGN'. T-Comm. No. 8. pp. 73-78.
(in Russian)
4. Samouylov, K, Abaev, P, Gaidamaka, Y, Pechinkin, A, Razumchik, R, Sopin, E & Shorgin S 2014, 'Analytical and simulation models to assessment of indexes of functioning of SIP server under overloads'. T-Comm. No. 8, pp. 83-87. (in Russian)
5. Samouylov, K & Zaripova E 2012, 'Model of SIP server overload control mechanism on processor utilization'. T-Comm. No 7, pp. 185-187. (in Russian)
T-Comm Tом 10. #3-2016
