Построение модели
UDP-потока
Новые мультимедийные услуги реального
времени появились на рынке коммерческих услуг сети Интернет сравнительно недавно
и нельзя сказать, что эти услуги были в достаточной мере поддержаны в сети
адекватными средствами, например, такими как новые протоколы, ориентированные на
эти услуги и алгоритмы управления мультимедийным трафиком. Именно поэтому
качество, с которым предоставляются мультимедийные услуги, в основном напрямую
зависит от количества свободных ресурсов на сети.
Очевидно, что обеспечение качества
обслуживания требует внедрения новых механизмов и протоколов как на сети, так и в оборудовании пользователя.
Транзитные узлы (маршрутизаторы) являются собственностью провайдеров и являются
достаточно инертными с точки зрения внедрения новых механизмов и протоколов.
Именно поэтому проще и дешевле моделирование процессов передачи такого трафика
при проектировании новой сети или внесении кардинальных изменений в уже существующую.
Протоколы транспортного уровня UDP и
TCP позволяют разработчику приложений свободу выбора транспортной услуги с точки
зрения доставки информации: UDP является простым протоколом и не предоставляет
никаких гарантий по качеству обслуживания, а протокол TCP, в свою очередь,
обеспечивает гарантированную
доставку данных, но зачастую с высокой задержкой.
Для большинства мультимедийных услуг,
реализованных «из-конца-в конец» на прикладном уровне и, как правило,
использующих на транспортном уровне протокол UDP, достаточно важными параметрами
являются задержка пакета «из-конца-в-конец» и дисперсия этой задержки (джиттер),
и то время как случайная потеря пакета, зачастую, не является помехой. И первую очередь, это объясняется тем,
что услуги «потокового» (streaming) типа ориентированы на пере
дачу незамедлительно аудио и/или видеовоспроизведения переданной информации, в
результате чего оконечный пользователь и является той системой, которая
оценивает качество предоставляемой услуги.
Протокол передачи данных UDP (User
Datagram Protocol) был определен IETF в 1980 году в документе [RFC768], он
обладает рядом достоинств, делающих его очень привлекательным, в первую очередь
для приложений, не имеющих жестких требований по таким параметрам качества
обслуживания, как вероятность потери пакета задержка и джиттер задержки. Среди
очевидных достоинств UDP необходимо выделить следующие: отсутствие фазы
установления соединения, отсутствие состояния соединения, малые накладные
расходы.
В табл. 1 представлены различные
приложения и протоколы прикладного уровня использующие
обычно протокол UDP. Как видно, протокол UDP
используется в основном служебными протоколами прикладного уровня (SNMP, RIP,
DNS и пр.) и мультимедийными услугами (Интернет-телефон, видео/телеконференция и
пр.). Применение UDP для потокового мультимедийного трафика предпочтительнее,
чем TCP, в первую очередь, в связи с тем, что реакция этих приложений на работу
функции «управления перегрузками» может быть неадекватна и грозит существенным
ухудшением качества предоставления услуги.
Таблица 1.
Приложения и протоколы использующие UDP
Приложение |
Протокол прикладного
уровня |
Протокол транспортного
уровня |
Удаленный файловый
сервер |
NSF |
Обычно
UDP |
Потоковые мультим.
услуги |
Корпоративный |
Обычно
UDP |
Интернет-телефония |
Корпоративный |
Обычно
UDP |
Управление
сетью |
SNMP |
Обычно
UDP |
Протокол
маршрутизации |
RIP |
Обычно
UDP |
Служба трансляции
имен |
DNS |
Обычно
UDP |
На основании вышеизложенного было принято решение о создании адекватной
модели UDP-потока, позволяющей выполнять задачи возникающие у проектировщика сетей (администратора,
разработчика сетей и протоколов).
Первым этапом
моделирования является построение концептуальной модели, и первая задача в нем –
классификация системы по типу поведения. Система является динамической с
непрерывным множеством состояний, так как основные показатели (заполнение
очередей) зависят от времени и являются непрерывными функциями времени. С точки
зрения течения времени объект можно считать системой с непрерывным временем, так
как для обмена между маршрутизаторами используются асинхронные протоколы, и
квант времени (время передачи одного бита) пренебрежимо мал по сравнению с
длительностью основных процессов (время передачи информационного кадра). По
условиям перехода из одного состояния в другое сеть сама по себе является
детерминированной, но, поскольку информационные потоки в сети случайны, то и вся
система также является стохастической. На рисунке 1 представлена схема
проектируемой модели.
Рабочей
нагрузкой системы является информационный поток, который она должна передавать
от отправителя к получателю с заданными показателями качества. Поскольку
информационные запросы в системе возникают случайным образом, то для описания их
будет использоваться метод генерации случайных величин – такие потоки будут с
требуемой точностью моделировать реальный обмен, характеристики которого были
получены с помощью средств анализа сетей.
Проектируемая
модель должна отвечать требованиям реального объекта. Модель должна иметь
возможность терять пакеты (например по time-out) и задерживать их на неодинаковое
время. Это достигается манипуляциями над очередями в коммутационных устройствах
(маршрутизаторах). Буфер маршрутизаторов может быть разным, а
маршруты следования информационных потоков случайными.
При
построении модели за основу берется представление о сети, как совокупности
каналов с известной пропускной способностью, которые соединяют между собой
единицы коммуникационного оборудования (маршрутизаторы). Каждый маршрутизатор
рассматривается, как очередь на передачу. Кроме того, сеть представляемая
количеством N
маршрутизаторов должна позволять добавление N+1, N+2,… маршрутизаторов и иметь случайные
элементы расположения этих маршрутизаторов.
Реализация
модели может быть осуществлена в программной среде MatLab.