CC BY
90
Анализ механизмов контроля перегрузок SIP-серверов в сетях NGN
Ключевые слова: БРсервер, механизмы контроля перегрузками, 1ВОС, КВОС, гистерезисное управление перегрузками.
Целью статьи является анализ существующих методов и механизмов контроля перегрузок SIP-серверов. Перегрузка SIP-сервера происходит, когда количество получаемых сообщений больше, чем сервер может обработать из-за ограниченности ресурсов, например, недостатка мощности ЦПУ, объема памяти, пропускной способности сети. Перегрузка может привести к существенному падению пропускной способности до небольшой части изначального значения пропускной способности. Стандарт протокола SIP определяет базовое реагирование на перегрузку — посылку перегруженным элементом ответа с кодом 503 Server Error. Несмотря на то, что в теории этот механизм кажется достаточно работоспособным, существует ряд до сих пор нерешенных проблем при его применении, которые рассмотрены в данной статье. Приведены различные причины возникновения перегрузок и методы их контроля, в том числе расширения алгоритмов LBOC и RBOC, контроль нагрузки посылкой событий Load Control Event Package, механизм контроля перегрузок при массовых рестартах Avalanche Restart Overload Control, а также адаптивный таймер повторной передачи. Для анализа механизмов контроля перегрузок применена математическая модель в виде системы массового обслуживания с пороговым управлением.
Павлоцкий О.Э.,
аспирант кафедры сетей и систем связи,
Московский технический университет связи и информатики,
Таланова М.О.,
аспирант кафедры систем телекоммуникаций, Российский университет дружбы народов, [email protected]
Введение
В сети SIP-серверов возможны ситуации, когда перегрузка приводит к существенному падению пропускной способности (congestion collapse). Возможны случаи, когда SIP-сер-вер вынужден отклонить входящие запросы из-за условий, не связанных с перегрузкой сервера. Для таких ситуаций контроль перегрузок не используется. В статье кратко рассмотрены причины перегрузок, приведены основные существующие методы борьбы с перегрузками и описана математическая модель гистерезисного управления перегрузками для схемы LBOC.
Причины перегрузок
Причины перегрузок могут быть различные, в том числе:
Плохое планирование емкости (Poor Capacity Planning): SIP-сеть должна быть оснащена достаточным количеством серверов, аппаратных устройств, дисков и так далее, чтобы удовлетворить потребности абонентов, которых эта сеть обслуживает.
Зависимость от отказов (Dependency Failures): SIP-эле-мент может быть перегружен, когда ресурс, от которого этот элемент зависит (например, DNS-сервер, База Данных или сетевые диски), вышел из строя или перегружен. В таких случаях даже минимальный трафик может вызвать перегрузку сервера.
Сбой работы компонентов (Component Failures): SIP-эле-мент может быть перегружен, когда он является одним из
серверов кластера, которые делят между собой трафик, и один (или более) из серверов кластера вышел из строя. В этом случае остальные сервера кластера принимают его (или их) нагрузку на себя. Однако при необычных условиях отказа из строя могут выйти сразу большое число серверов, например, при сбое ПО, когда неверный пакет или неверная запись в БД вызывают одну и ту же ошибку на наборе элементов кластера.
Массовые рестарты (Avalanche Restart): Такая ситуация может возникнуть, когда большое число клиентов одновременно пытаются зарегистрироваться на сервере, вызывая его перегрузку. Это происходит, например, при сбое питания или восстановлении участка города. Аналогичную ситуацию могут создать множественные запросы SUBSCRIBE и PUBLISH.
Мгновенный рост (Flash Crowds): Подобное событие происходит, когда очень большое число пользователей пытаются одновременно сделать звонок, например, при телевикторине, онлайн-телемагазине или при глобальном катаклизме (землетрясении, урагане), при котором люди пытаются дозвониться в зону бедствия (из зоны бедствия). Такой мгновенный поток вызовов способен вызвать перегрузку сервера.
Атаки типа Отказ в Обслуживании (Denial of Service (Do S) Attacks): злоумышленник создает большой трафик на сервер, желая нарушить его работу. Трафик может создаваться на центральном источнике или с помощью распределенной атаки типа отказ в обслуживании (Distributed Denial of Service, DDoS). В обоих случаях объем посылаемого трафика превышает мощность атакуемого сервера[1][2].
К сожалению, проблема перегрузки имеет тенденцию саморазрастаться. Переход сети в состояние перегрузки часто приводит к сбою элементов, пытающихся обрабатывать трафик. При перегрузке общая мощность функциональных элементов падает, так как большая часть ресурсов расходуется на отклонение запросов, которые они не могут обработать. Сообщения, которые теряются или задерживаются, передаются повторно, увеличивая тем самым трафик и ухудшая ситуацию.
Стандарт протокола SIP определяет базовое реагирование на перегрузку - посылку перегруженным элементом ответа с кодом 503. RFC 3261предусматривает следующее реагирование на перегрузку:
# Вели сервер временно перегружен, он может указать клиенту в заголовке Retry-After временной интервал, по истечении которого клиент может повторно отправить запрос на сервер. Шли клиент получил ответ без Retry-After, он должен действовать, как будто получил ответ 500 (Server Internal Firror);
F.c.i]и клиент (прокси-сервер или UAC) получил 503, он должен попытаться отправить запрос на альтернативный сервер;
^ Сервер вместо посылки 503 может отказать в соединении или сбросить запрос.
В [21 также содержится инструкция, согласно которой прокси-сервер не должен отправлять ответ 503 вышележащему узлу, так как тогда этот узел может решить, что недоступен сам прокси-сервер.
Несмотря на то, что в теории механизм с использованием ответа 503 кажется достаточно работоспособным, существует ряд до сих пор нерешенных проблем при его применении:
Усугубление перегрузки (Load Amplification)', когда прокси-сервер посылает запрос на перегруженный сервер, этому серверу вследствие перегрузки может понадобиться время для того, чтобы отправить ответ 503. Во время этого интервала времени прокси-сервер может повторно посылать запросы, еще больше усиливая нагрузку на сервер.
# Неполное использование (Underutilization)'• если ряд серверов образуют кластер, и при обращении по URI DNS-сервер возвращает адрес одного из них. Тогда когда один из этих серверов перегружен, и прокси-сервер получает от него 503 в ответ на запрос, этот прокси-сервер решает, что весь кластер перегружен, и перестает посылать запросы, хотя в кластере есть неперегруженные сервера.
# Проблема использование Retry-After (The Off/On Retry-After Problem): данный механизм предусматривает всего два состояния - первое, когда вышележащий узел передает всю нагрузку без ограничений, и второе, когда вышележащий узел не посылает сообщения нижележащему перетруженному серверу в течение указанного промежутка времени (т.е. "все или ничего")1*1.
Неоднозначное использование 503 (Ambiguous Usages): в стандарте четко не указаны случаи, когда можно генерировать сообщение 503.
Этти проблемы имеют серьезные последствия, подробно описанные в [I] и [8J.
Методы контроля перегрузок
Методы контроля перегрузок делятся на явные и неявные в зависимости от способа, которым нижележащий сервер сообщает вышележащим узлам о перегрузке. При явном (explicit) механизме контроля перегрузок нижележащий сервер отправляет вышележащим узлам сигнал о перегрузке, в ответ па который вышележащие узлы корректируют скорости передачи трафика на перегруженный сервер. При неявном (implicit) механизме признаком перегрузки являются отсутствие ответов, т.е. потеря сообщений. Сервер, заметив это, уменьшает нагрузку на нижележащий узел. При отсутствии сигнала механизма явного контроля перегрузок
неявные механизмы контроля работают стабильно, так как они не зависят от действий перегруженного сервера.
Используя методы явного контроля перегрузок с обратным сигналом, получатель может указать какой объем трафика он может принять. Разделение методов контроля перегрузок производится на основе типа информации, передаваемой обратным сигналом, и находится ли функция управления на отправителе и/или получателе.
► Rate-based Overload Control (Контроль перегрузок на основе скорости);
Loss-based Overload Control (Контроль перегрузок на основе потерь);
► Window-based Overload Control (Контроль перегрузок на основе размера окна);
*■ Overload Signal-based Overload Control (Контроль перегрузок на основе сигнала о перегрузке);
* On/Off Overload Control (Контроль перегрузок на основе временного запрета передачи).
Подробнее о них в [1 ] и [8].
Методы неявного контроля перегрузок обеспечивают самоограничение сервером объема графика. Признаком пере-]рузки могут служить существенные задержки ответов или их полное отсутствие. Цель методов неявного контроля перегрузок - реакция отправителя на задержку, когда не приходит обратный сигнал явных методов. Это полезно в случае, когда сервер перегружен настолько, что не способен генерировать сообщения методов явного контроля перегрузок. Механизмы явного и неявного контроля дополняют друг друга.
Алгоритмы LBOC и RBOC
В [3] определен протокол обмена информацией о перегрузке между серверами и клиентами для того, чтобы клиенты могли сократить объем трафика на перегруженный сервер для предотвращения сбоя и для увеличения полезной нагрузки (good throughput). Для этого определены четыре новых параметра via-заголовка для контроля перегрузок. Эти параметры обеспечивают механизм для передачи информации контроля перегрузок между соседними узлами.
Параметр "ос" используется сервером для требования снижения количества запросов, поступающих на сервер. Параметр "oe-algo" содержит маркер или список маркеров, сообщающих класс алгоритмов контроля перегрузок, поддерживаемых клиентом. Сервер выбирает один алгоритм из этого списка. Параметр "ос-validity" устанавливает временной интервал, в течении которого выполняется контроль перегрузок. Параметр "oc-seq" помогает упорядочить ответы клиента. Рассмотрим эти параметры более подробно.
# Параметр "ос" вставляется клиентом и обновляется сервером. Клиент должен вставлять данный параметр в начало via-заголовка каждого запроса. Таким образом, нижележащие узлы информируются, что клиент поддерживает контроль перегрузки. При этом значение параметра не устанавливается клиентом, это делается сервером. Нижележащий сервер должен добавить значение параметра "ос" в ответе на запрос клиента, содержавшего данный параметр. Присвоение значения сообщает клиенту о том, что нижележащий сервер поддерживает контроль перегрузки. В случае, когда контроль перегрузки является активным, значение
параметра указывает тот уровень контроля, который должен быть применен. Когда клиент получает ответ е заполненным значением параметра "ос", он должен снизить число запросов серверу, от которого получен данный ответ, в соответствии со значениями параметров "ос" и "oc-algo",
# Параметр "oc-algo" вставляется клиентом и обновляется сервером. Клиент должен вставлять данный параметр в начало via-заголовка каждого запроса со значением по умолчанию "loss". Данный параметр содержит одно или более имен классов алгоритмов контроля нере!рузок. Клиент должен поддерживать метод LBOC и устанавливать маркер "loss" как одно из значений параметра "oc-algo". Клиент может через запятую указать другие маркеры в параметре "oc-algo", если данный клиент поддерживает другие методы контроля перегрузок.
+ Параметр "ос-validity" может быть вставлен в ответ исключительно сервером. Данный параметр содержит значение, указывающее временной интервал в миллисекундах, в течение которого должен быть активен уровень контроля, указанный в значении параметра "ос". По умолчанию данный параметр равен 500. Если клиент получает ответ с установленными значениями параметров "ос" и "oc-algo", но не содержащего "oe-validity", клиент должен считать, что получил параметр "oc~validity=500". Значение "ос-validity—0" используется в случае, когда сервер хочет прекратить контроль перегрузки или сообщает, что поддерживает контроль перегрузок, но в данный момент не запрашивает снижение нагрузки. Ненулевое значение параметра "oe-validity" принимается клиентом только вместе с установленным значением параметра "ос", а противном случае сбрасывается. По истечению временного интервала, указанного в параметре "ос-val idity", клиент не выполняет контроль перегрузок до получения обновленных значений параметров.
Параметр "oc-seq" должен быть вставлен в ответ исключительно сервером. Данный параметр содержит значение последовательности, связанное ео значением "ое", и используется для дифференциации двух различных значений "ос", сгенерированных в разные моменты времени. Значение параметра "oe-seq" для каждого следующего значения "ос" должно быть больше предыдущего, что позволяет клиенту упорядочивать ответы, пришедшие не по порядку. В качестве значений "oc-seq" могут использоваться временные метки. Если значение данного параметра выходит за предел в течение периода понижения нагрузки, то этот параметр должен быть сброшен до значения текущей временной метки или соответствующего базового значения.
Алгоритм LBOC является алгоритмом контроля перегрузок по умолчанию. Общий принцип его работы следующий. Клиент поддерживает две категории запросов: запросы первой категории при перегрузке отбрасываются в первую очередь, запросы второй категории отбрасываются только в том случае, если все запросы первой категории отклонены, но необходимо дальнейшее сокращение числа сообщений. Разделение сообщений по этим двум категориям выполняется, как правило, на основе местной политики. При перегрузке клиент преобразует значение "ос" в значение, которое затем применяется к запросам первой категории. Для сокращения клиент присваивает каждому запросу первой категории случайное число из диапазона от 0 до 100. Если это число меньше или равно преобразованному
значению "ос", то запрос не отравляется. Запросы второй категории передаются без каких-либо сокращений.
Суть алгоритма RBOC заключается в следующем: перегруженный сервер сообщает вышележащим серверам, сколько запросов в секунду он готов принять от каждого из них. Данный механизм гарантирует, что нижележащий сервер не получит объем трафика, больше чем он сможет обработать, В [4] описано расширение RBOC для гарантии верхней ]раницы скорости, постоянные обновления клиентских запросов, посылаемых па перегруженный сервер. Когда клиент впервые соединяется с сервером, он может вставить в парамerp"oc-algo" кроме обязательного "loss" значение "rate", таким образом, указав поддержку и RBOC. Если сервер выбрал RBOC, он должен в ответе как значение параметра "oc-algo" указать "rate". Затем сервер периодически, используя внутренние изменения (например, загрузка процессора, задержка очереди), оценивает состояние перегрузки и рассчитывает желаемую скорость — планируемое число запросов в секунду (в отличие от процента потерь при LBOC). При перегрузке сервер использует "ос"-пара метры ответов для информирования клиентов о состоянии перегрузки и планируемом числе запросов. После получения "ос"-парамстров с указанием желаемого числа запросов клиент душит новые запросы к перегруженному серверу.
Контроль нагрузки посылкой событий
В [51 определен механизм посылки событий для контроля нагрузки (Load Control Event Package) протокола SIP. Это позволяет SIP-объектам распространять политику фильтрации нагрузки другим SIP-объектам. Политика фильтрации нагрузки содержит правила регулирования звонков в зависимости от домена источника или получателя, префикса телефонного номера или конкретного пользователя. Данный механизм позволяет предотвратить передачу си¡нала контроля перегрузки и дополнений, использующих обратный вызов. Также в [5] определен дополнительный метод управления нагрузкой, называемый фильтрацией нагрузки (load filtering). Сетевые операторы создают политики фильтрации нагрузки, которые определяют, что вызовы на определенные направления или от определенных источников должны быть ограничены по скорости или частично отброшены. Затем эти политики распространяются серверам и, возможно, агентам пользователя, которые Moiyr генерировать вызовы в зону бедствия (или из зоны бедствия). Фильтрация нагрузки работает тем более эффективно, чем ближе к исходному агенту пользователя она фильтрует. Данный метод фильтрации наиболее приемлем для ситуаций, когда всплеск трафика и его источник/место назначения могут быть предсказаны заранее.
Механизм предотвращения массового рестарта
В [ó J описан механизм предотвращения лавинных перегрузок. Такая ситуация может возникнуть, когда большое число клиентов регистрируется па сервере, вызывая его перегрузку. Это происходит, например, при сбое питания или восстановлении участка города. Аналогичную ситуацию могут создать множественные запросы SUBSCRIBE и PUBLISH. В рамках механизма предотвращения подобных ситуаций перегрузки сервер оценивает интервал отсрочки для лавинного перезапуска
(avalanche restart) во время нормальной работы и передает этот интервал своим клиентам с помощью нового заголовка Restart-Timer в ответе на клиентский запрос о регистрации. Во время лавинного перезапуска клиенты на основе ранее полученного значения интервала выполняют отсрочку перед попыткой отправки первого запроса. Клиент случайным образом выбирает значение этой отсрочки на промежут ке от О до полученного от сервера интервала отсрочки (в заголовке Restart-Timer). Таким образом, данный механизм разбрасывает все клиентские запросы во времени, предотвращая перегрузку сервера.
Строгая регулировка таймера повторной
передачи сообщения Invite
Когда можно использовать определенные серверы для установления сеанса, то увеличение количества этих серверов, распределение нагрузки между ними или повышение возможности обработки серверами могут помочь сократить время инициации сеанса. Разумеется, эти изменения являются дорогостоящими и в некоторых случаях трудновыполнимымн. Другой способ - использование режима Stateless вместо Stateful на серверах. Но при этом полная история общения не будет доступна. Иной способ Сокращения времени установления сеанса связи заключается в удалении подтверждений аутентификации пользователей, который имеет самый высокий положительный эффект, ею из-за природы Интернета и в некоторых случаях необходимости использования подтверждений подлинности, использование этого метода имеет значительные проблемы.
В [7] вводится адаптивный таймер (Adaptive Timer) повторной передачи Invite-сообщений для уменьшения времени установления сеанса. В отличие от обычного фиксированного таймера, адаптивный таймер реагирует на состояние сети в соответствии со следующими замечаниями:
# Если задержка а сети невелика, таймер может быть уменьшен для предотвращения напрасного ожидания сообщения Invite от UAC или промежуточного ответа от UAS;
Вели задержка в сети выше, чем значение по умолчанию (т.е. 500 мс), например, для спутниковой среды передачи, таймер должен быть увеличен .тля предотвращения повторных передач INVITE из-за большой задержки;
Ф Если задержка получения ответа от UAS связана с высокой нагрузкой CPU этого узла, то за счет увеличения таймера можно уменьшить рабочую нагрузку на UAS;
# В случае существенных потерь в канале передачи сообщений Invite или промежуточных ответов, лучше снизить скорость повторной передачи сообщений путем увеличения таймера, что может уменьшить нагрузку;
# Если сообщение передается поврежденным, то лучше быстро ретранслировать сообщение за счет сокращения значения таймера.
Значение таймера высчитывается на основе данных о RTT и потерянных и поврежденных пакетах.
Математическая модель схемы LBOC
Одним из способов управления перегрузками в сетях SIP -серверов является механизм просеивания нагрузки, предложенный, например, в |1]. Процесс обработки сообщений прокси-сервером можно описать с помощью системы массового обслуживания м,|м,|1|(1,я)|в (рис. 1) с
конечной очередью размера В и гистерезисным управлением нагрузкой с порогами L, IsL<B, и Н, 1 йН<В.
о-
Рис. (.Система М,|Мг|1|{/.,//)|й с гистерезисным управлением нагрузкой
На систему поступает пуассоновский поток заявок с интенсивностью Л , время обслуживания заявки на приборе имеет экспоненциальное распределение с параметром //. При поступлении на обслуживание заявка сохраняет место в очереди, дисциплина выбора заявок из очереди на обслуживание РСТ8. Система может функционировать в одном из трех режимов: режиме нормальной нагрузки (,5=0), режиме перегрузки (5=1) и режиме сброса нагрузки (л=2). В режиме нормальной нагрузки при достижении длиной очереди значения н система переходит в режим перегрузки (.?=!), в котором новые заявки принимаются с интенсивностью Л'. Для предот вращения осцилляции интенсивность поступающего потока не восстанавливается до нормального значения I, пока длина очереди не уменьшится до порога I снижения нагрузки. В режиме перегрузки при достижении длиной очереди значения В система переходит в режим сброса нагрузки (л=2), в котором новые заявки не принимаются. Для предотвращения осцилляции интенсивность поступающего потока не восстанавливается до значения Л', пока длина очереди не уменьшится до порога н обнаружения перегрузки.
Состояние системы имеет вид (.*,«), где .*е{о, 1,2} -
статус нагрузки, а п - количество заявок в очереди, п=0,В. Функционирование системы описывает марковский процесс Х(1), 1>о, с пространством состояний х=хйих,их,, где
Хо = {(.*,и):.? = 0,0<п< И-1} - множество состояний
нормальной нагрузки, Х1 = {(^,п):л = 1,-множество
состояний снижения нагрузки, а X. ={(*,п)и-2, н + \<п< в\ -
множество состояний сброса нагрузки.
График интенсивности входящего потока, зависящей от состояния системы, представлен на рис. 2. При нахождении системы в множестве Х(3 интенсивность входящего потока заявок равна я > о, в множестве X, — уменьшается таким образом, что Л' = рЛ, гдер- доля заявок, которые принимаются на обслуживание в множестве X,. Если система находится в множестве X., то Л = о .
Для понимания функционирования системы важно провести анализ случайного времени т12 пребывания в множестве состояний перегрузки, которое в физической модели соответствует времени, когда управление входящим потоком на 81 ['-сервере включено, то есть времени пребывания 81Р-сервера в состоянии перегрузки. Для этого введем марковский процесс А'(г) с пространством состояний
>( = Х1их:и{(о,1-1)} и обозначим п)(0=^¡А'С)-е
В Н I L
4M) „I
......► "I
Ms'n) „ I
У
р(0=(%.„)('>)<,я)бХ ~ вектор ряда вероятностей состояний МП Щ в момент времени /го, а Р(0=(>(3.„),,.„)(0}(^).(г,(„)ех " матрица вероятностей переходов на интервале [о,/).
№ лг= * \ « .
!\ $-2 "v 1
о ¿-I I, н-\ и /ж в-1 Й п
Рис.2. Функция интенсивности А (я, я) потопа заявок
Диаграмма интенсивностей переходов состояний процесса показана на рис. 3.
1=0
¿=2
О I
¿-I £ £+)
н-1 н н+\ н+г
Рис. 3. Диаграмма интенсивностей переходов состояний процесса Л'(|)
Известно, что матрица Р(/) вероятностей переходов систем 1.1 может быть записана следующим образом:
: »
11=0 "1
где д - матрица интенсивностей переходов усеченного процесса х(>). Тогда вектор р(г) удовлетворяет следующим уравнениям:
РГ(0 = РГ(0)Р(0, (1)
—рг(0=рг(0)ЛеЛ', 12 0. Начальный вектор р(0) вероятностей: б =
Утверждение 1, Функция распределения случайной величины тп равна:
Доказательство. Функция распределения случайной величины т12 - это вероятность перехода системы из состояния (1 ,Н) в состояние (0.1-1), то есть • Решим уравнение (I):
-п<0
♦Л.я(0) ; (°.....1»-0)м
(I)
'И.НХ1.1.)
>/Ь.в(')) = (^11.//И(и-|>(').....I. Я ХШ)—'>(')) •
Из решения видно, что = Аод-цО •
Значение 95% квантиль величины г(, функции распределения - это значение г,,95, которое случайная величина тп не превып1ает с вероятностью 0,95. Так как распределение непрерывно, то:
Утверждение 2. Среднее время пребывания системы в множестве состояний перегрузки вычисляется по формуле (2).
('))<* (2)
Доказательство. Математическое ожидание случайной величины г,2 вычисляется следующим образом:
мт12=]ЫР!12 (0=14Ам-1)(')Л. и а
Посчитаем — :
п(0
Ж
Л
р7(/) = (0.....
(«.¿-1)10.
Ч1.ЯИШ
(О
'(1.ЯК1.
Ж«
Значит, Тогда:
00 4 00 . д .
Для численного анализа возьмем исходные данные: В = 100; I =44; Н =52, р = 1,2; /< =200 с"1; 9 =0,3.
Для значений (3) среднее время пребывания системы в множестве состояний перегрузки равно Мтп - 0,280547 с.
Одной из основных задач при управлении перегрузками 81Р-сервера является минимизация времени пребывания сервера в состоянии перегрузки |9, 10]. Однако, при этом следует учитывать, что вероятность потери сообщений не должна превышать определяемый международными стандартами уровень у1 , а цикл управления не должен быть
слишком коротким (меньше, чем уг} во избежание частого переключения управления. Таким образом, сформулированы две задачи оптимизации: минимизировать среднее время возврата из множества состояний перегрузки в множество
состояний нормальной нагрузки и значение 95% квантили величины rt относительно выбора порогов L и И так, чтобы выполнялись требования /?] —R3:
Mrn(L,H)-> min; min;
Я!: Я(Х, n: КЗ: Л/г>ft,
где У\. Yi» Уъ ~ заданные значения.
Задачи оптимизации решены для ^ =0,2; уг =0,0001, уъ = 0,45 с и для данных (3). Получены следующие результаты:
1) Мт[2 (44,52) = 0,280547 с, то есть минимальное время 0,280547 секунды пребывания системы в множестве состояний перегрузки достигается при значениях порогов L =44, И =52.
2) Г|зЧ5(44,52} = 0,9, то есть минимальное время, через которое с вероятностью 0,95 система выйдет из состояния перегрузки, составляет 0,9 секунды и достигается при тех же значениях порогов L = 44, И - 52.
Функция распределения F (/), необходимая для
решения задачи оптимизации значения 95% квантили величины г,2, для данных (3) построена на рис. 4.
Рис. 4, Функция распределения Ff|_(0
Из графика на рис. 4 видно, что с вероятностью 0,95 время пребывания системы М|М|1|{44,52)||00 в множестве
состояний перегрузки не превышает 0.9 с, но через 2 секунды после начала пребывания в таком множестве состояний с вероятностью 1 система вернется в множество состояний нормальной нагрузки.
Заключение
Рассмотрены основные стандарты и драфты, касающиеся борьбы с перегрузкой и разработанные научной группой IETF SIP Overload AConlroI (SOC). Кратко рассмотрены предложения по борьбе с перегрузкой, не отраженные на данный момент в документах IETF, в частности, адаптивный таймер повторной передачи. Все описанные методы позволяют повысить эффективность работы SIP в условиях перегрузки и отражают тенденцию дальнейшего развития методов контроля перегрузок. При помощи математической модели гистерезисного контроля перегрузок рассчитаны временные характеристики для схемы LBOC.
1. Абаев П.О., Гайдамака Ю.В., Самуилов К.Е, Гистерезисное управление нагрузкой в сетях сигнализации II Вестник РУДН. Серия «Математика. Информатика. Физика» - М.: Изд-во РУДН. -2011.-№4.-С. 55-73.
2. J. Rosenberg Requirements for Management of Overload in the Session Initiation Protocol, RFC 5390, http://tools.ietf.org/html/rfc5390,2008.
3. Gurbani, Ed.V. Hilt. Session initiation Protocol (SIP) Overload Control, http://datatracker.ietf.org/doc/draft-ietf-soc-overload-control/
4. E, Noel. P. M. Williams. Session Initiation Protocol (SIP) Rate Cont ro I, h tt p ://dat atrac ker. i et f.org/doc/d ra ft- iet f-soc-o ve rl oad- rate-co lit го I/, 2013.
5. C. Shen. //. Schulzrinne. A. Koike. A Session Initiation Protocol (SIP) Load Control Event Package, littp://datatracker.ietf.org/ doc/dra ft-iett-soc-load-control-event-package/, 2013.
6. С Shen, H. Schulzrinne, A. Koike. A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart Overload Control, http://datatracker.ietf.org/doc/drafl-shen-soc-avalanche-iestart4iverload/, 2013.
7. A. Montazerolghaem, M. H. Yaghmaee. The Overload Reduction in SJP Servers through Exact Regulation of the Retransmission Timer of the Invite Message. Journal of Computer and Communications, http ://too Is. iet f.onVhiml/dra ft-wang-appsawg-end2 end-overload control-00, 2013.
8. V. Hilt. £ Noel, C. Shen. A. Abdelal. RFC 6357: Design Considerations for Session Initiation Protocol (SIP) Overload Control. - 2013.
9. Pavel Abaev. Yuliya Gaidamaka, and Konstantin Samouylov Queuing Model for Loss-Based Overload Control in a SIP Server Using a Hysteretic Technique// Proceedings 12th International Conference, NEW2AN 2012, and 5th Conference. ruSMART 2012, St. Petersburg, Russia, August 27-29, 2012. - Lecture Notes in Computer Science. -Germany, Heidelberg, Springcr-Vcrlag. -2012. - Vol. 7469. - Pp. 371 -378.
10. Pavel O. Abaev, Yuliya V. Gaidamaka, Alexander V. Pcchinkin, Rostislav V. Razumchlk, Sergey Ya. Shorgin Simulation of overload control in SIP server networks II Proc. of the 26th European Conference on Modelling and Simulation ECMS 2012, Koblenz, Germany, May 29 - June 1, 2012. - Pp.533-539.
Analysis of overload control mechanisms on sip servers for NGN
Pavlotsky O.E., Moscow Technical University of Communication and Informatics, [email protected] Talanova M.O., Peoples' Friendship University of Russia, [email protected]
Abstract. The purpose of article is the analysis of methods and mechanisms of control of overloads of SIP servers. The overload of the SIP server occurs when the number of received messages is more than the server can process because of limitation of resources, lor example, a lack of power of a CPP, memory size, and network capacity. The overload can lead to essential falling of capacity lo small part of initial value of capacity. The standard of the SIP protocol determines basic response lo an overload - a parcel by the overloaded element of the answer with a code 503 Server Error. In spite of the fact that in the theory this mechanism seems rather efficient, there is a row still unresolved problems at its application which are considered in this article. Various reasons of emergence of overloads and methods of their control including expansion of algorithms of LBOC and RBOC, loading control by a parcel of events of Load Control Event Package, the mechanism of control of overloads at mass restarts of Avalanche Restart Overload Control and also the adaptive timer of repeated transfer are also given in article. The mathematical model is applied to the analysis of mechanisms of control of overloads in the form of system of mass service with threshold control.
Keywords: SIP server, overload control, LBOC, RBOC, hysteretic load control.
Литература
