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

1.3 Восприятие мультимедийной информации человеком и мультимедийной информации относится скорее к области психологии и физиологии, но оно, тем не менее, необходимо, так как на основе выработанных человеком оценок делаются выводы о качестве компьютерной сети. В процессе анализа производится сопоставление между субъективными оценками, которые делают пользователи сети во время эксперимента, и объективными, которые выводятся по результатам измерений в сети.

субъективного восприятия часто возникают не из-за плохого качества обслуживания, предоставляемого сетью, а из-за поведения людей во время конференции (говорят слишком громко или слишком тихо), а также из-за проблем с оборудованием. В работе были опрошены субъекта, которым предъявлялись на прослушивание записи разговора двух мужчин, как без искажений, так и с искажениями, типичными для аудиоконференций через Интернет. В числе таких искажений была и потеря пакетов при доле потерь 5% и 20%, при предыдущего. Субъективно потеря пакетов воспринималась следующим образом: при доле потерь 5%, большая часть опрошенных воспринимала речь как “нечеткую”. При доле потерь 20%, оттенком” и “цифровой голос”.

Кроме того, отмечалось, что в реальных условиях проведения аудиоконференций в академических кругах Великобритании доля потерь пакетов редко превышала 5%, а доля потерь в 20% наблюдалась только на очень коротких отрезках времени. На основе этих данных, представляется резонным считать допустимым уровнем потерь 5% потерянных пакетов.

Искажения в восприятие вносит и задержка пакетов в сети, являющаяся неизбежным следствием механизма коммутации пакетов.

При использовании мультимедийных приложений задержка, которую испытывает пакет от момента отправки в сеть до момента, когда он будет раскодирован и представлен пользователю, состоит из следующих частей [26]:

1. Задержка накопления речевого кодека. Она появляется из-за того, что кодек может начать кодирование, только если накопилось несколько речевых отсчетов. Значение этой задержки зависит от типа кодека и составляет 0,125..30 мс.

2. Задержка формирования пакетов наблюдается в связи с тем, что в один пакет коммуникационного протокола (например, UDP) включается несколько речевых кадров. Пакет не может быть отправлен, пока не накопится требуемое количество кадров. Например, 3 кадра по 10 мс каждый дадут совокупную 3. Наконец, сетевая задержка вносится при передаче пакета по IP-сети с пакетной коммутацией. Ее значение является случайной величиной и может составлять существенную часть общей задержки.

В результате действия всех этих факторов пакеты поступают на хост назначения не равномерно, а через случайные интервалы (это явление называется “дрожание”, или “jitter”). Поэтому мультимедийное приложение-клиент вынуждено создавать для поступающих пакетов буфер, откуда они поступают на вход декодера.

Если один или несколько пакетов будут значительно задержаны сетью, то до момента их поступления будут декодироваться пакеты из буфера.

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

Типичный размер такого буфера может быть рассчитан на размещение 5..10 секунд потока данных.

В интерактивных приложениях невозможно делать буфер таким большим. Если в буфере находится 5 секунд потока данных, то данные поступят к пользователю только через 5 секунд. Ответная реакция пользователя (например, фраза) отправится обратно к собеседнику. Если в приложении на его стороне установлен буфер такого же размера, он услышит ответ на сказанную им фразу только через 10 секунд. Это совершенно неприемлемо для общения. Поэтому размер буфера стараются делать достаточно небольшим. Вместе с тем, на нижню границу размера тоже существует ограничение: нужно, чтобы в буфере находилось достаточное количество информации для плавного воспроизведения на случай непредвиденной задержки сетью очередной порции пакетов. Кроме того, пакеты протокола UDP, который часто используется для передачи мультимедийных потоков, могут прибывать не в том порядке, в котором были отправлены, поэтому важно, чтобы слишком запоздавшие по сравнению со своими соседями пакеты успели вовремя прибыть в буфер и занять свое место в общей последовательности, прежде чем декодер обнаружит, что они не поступили к моменту воспроизведения, так как были потеряны.

Таким образом, при регулировании размера буфера требуется соблюсти баланс: слишком большой буфер – резкое ухудшение обратной связи с другими пользователями, слишком малый – искажения в воспроизведении из-за опустошения буфера и “пропажи” пакетов, которые просто были задержаны сетью дольше, чем другие, и не успели поступить к моменту воспроизведения.

Некоторые адаптивные алгоритмы для управления размером буфера рассмотрены, например, в [29].

Чтобы улучшить качество воспроизведения, необходимо строить такие компьютерные сети, в которых не будет наблюдаться перегрузок, долговременных заторов, потерь пакетов и т.д. Кроме того, следует минимизировать задержку, вносимую сетью. Как уже отмечалось выше, сетевая задержка более 100..150 мс резко ухудшает качество воспроизведения речи [26].

Хотя основной стандартной методикой субъективного определения качества переданного потока является методика [5], рекомендованная ITU, но она подвергается критике за счет своей простоты. Эксперты считают, что качество субъективно определяется по нескольким параметрам одновременно, тогда как предлагаемая стандартная методика является одномерной [1].

1.4 Понятие качества обслуживания и его роль в обеспечении функционирования мультимедийных Описанные выше характеристики мультимедийного трафика свидетельствуют о его высоких требованиях к качеству компьютерной сети. Предъявляются жесткие требования к пропускной способности канала связи, к сетевым задержкам и к уровню потерь пакетов. Если формализовать эти требования, можно заключить с провайдером услуг доступа к сети договор, в котором будут указаны значения приведенных выше параметров, измеренные с некоторым усреднением, и в соответствии с этим договором провайдер обязуется предоставить услугу подключения, при которой эти параметры будут соблюдаться. При этом усреднение измерений параметров, указанных в договоре, может происходить на периоде от нескольких секунд до одного месяца, в зависимости от того, насколько сеть провайдера позволяет управлять этими параметрами [27]. Такой договор носит название “соглашение о качестве обслуживания” (Service Level Agreement, SLA), или “трафик-контракт”.

Определенные обязательства берет на себя и пользователь: например, пользователь обязается передавать по каналу связи данные с битовой скоростью не больше B, а провайдер обязуется обеспечить сетевую задержку не выше D. В случае, если пользователь нарушает трафикконтракт, провайдер может либо вообще не обслуживать пакетынарушители, либо обслуживать их по методу “с максимальными усилиями” (best effort), то есть они будут передаваться принявшим их узлом в пункт назначения только в том случае, если у этого узла есть в данный момент свободные ресурсы.

В случае, если в сети задействованы механизмы, позволяющие управлять параметрами сети и регулировать потоки трафика, можно говорить о службе регулирования качества обслуживания (Quality of Service, QoS). Такая служба носит распределенный характер и имеет следующую архитектуру [27]:

1. Средства QoS хостов сети 2. Протоколы QoS-сигнализации для координации работы сетевых элементов по поддержке качества обслуживания “из 3. Механизмы централизованного управления и учета параметров Основную роль в обеспечении работы службы QoS играют средства QoS в узлах сети. Как правило, они включают элементы двух типов: механизмы обслуживания очередей и механизмы “кондиционирования” трафика. Последние требуются, чтобы предотвратить заторы в сетях, приводящие к увеличению задержек.

Делается это путем сравения интенсивности поступающего в узел трафика и потенциально возможной скорости продвижения пакета узлом сети, после чего все пакеты, превышающие допустимую интенсивность поступления трафика, отбрасываются. Такое поведение требуется для создания своевременной обратной связи с приложениями, отсылающими данные. Например, протокол TCP, обнаружив потерю пакетов, делает вывод, что в сети образовался затор, и не повышает интенсивность передачи данных. Подробно об адаптивном поведении алгоритма TCP в крупных сетях можно прочитать в [24].

Алгоритмы обработки очередей в маршрутизаторах обычно таковы: стандартный алгоритм FIFO (First In – First Out), приоритетное обслуживание (Priority Queuing), взвешенные очереди (Weighted Queuing). Подробное описание алгоритмов их работы читатель может найти в [27]. На практике обычно алгоритм обработки очереди каждого конкретного маршрутизатора и вообще информация о поддержке QoS сетью известна провайдеру услуг, но неизвестна пользователю, что усложняет имитационное моделирование сегмента сети.

Так называемая “поддержка из конца в конец” (end-to-end) требуется потому, что средств QoS отправляющего и принимающего хостов недостаточно: находясь в пути следования, мультимедийный трафик делит ограниченные сетевые ресурсы с другими потоками, обладающими разными динамическими параметрами, поэтому необходима поддержка QoS на всем протяжении маршрута для сохранения параметров трафика, предусмотренных SLA. Обеспечить поддержку из конца в конец можно двумя основными способами. Вопервых, можно воспользоваться протоколом сигнализации, роль которого в IP-сетях выполняет протокол RSVP [14]. Применение такого протокола позволит зарезервировать на всех маршрутизаторах вдоль пути следования пакетов среднее значение полосы пропускания. Если часть узлов вдоль маршрута не поддерживает протокол RSVP, то качество обслуживания будет соблюдаться на остальных участках. Этот метод относится к так называемым “интегрированным сервисам”: интегрированное взаимодействие всех узлов вдоль маршрута с резервированием пропускной способности дает гарантированное качество обслуживания. Второй основной метод – это “дифференцированные сервисы”: приложение сигнализирует о своих потребностях к параметрам сети установкой особого поля IP-пакета, IP precedence [16], и маршрутизаторы вдоль пути следования пакета распознают значение этого поля и оказывают такому пакету приоритетное обслуживание. Оба вида сервисов, и дифференцированные, и интегрированные, разрабатываются комитетом IETF [4].

1.5 Сложность имитационного моделирования крупных сегментов реальных компьютерных сетей Все многообразие существующих в сети потоков для целей математического моделирования сводится к нескольким моделям, формального объекта, представляющего топологию сети, – графа, ребрам которого приписаны значения пропускной способности каналов связи, а в узлах которого расположены системы массового обслуживания (маршрутизаторы) – этот этап сталкивается со значительными сложностями.

Первая сложность – построение собственно графа. Существуют лишь приближенные методы определения топологии сети – с помощью утилит, подобных traceroute – о них мы расскажем ниже. Вторая сложность заключается в приписывании ребрам графа значений пропускной способности каналов связи вдоль всего маршрута. Значения этих параметров, как правило, невозможно выяснить самостоятельно, и требуется совместная работа со специалистами Интернет-провайдеров, осблуживающих сегмент сети.

Некоторые научные исследования показывают, что иногда для достаточной точности описания требуется знать лишь пропускную способность самого узкого места сети, а ее можно оценить путем измерений [24]. Далее мы покажем, как производятся подобные измерения. Однако очевидно, что представление всей сети с несколькими маршрутизаторами в виде одной системы массового обслуживания неизбежно уменьшает точность модели. Наконец, еще представлением маршрутизаторов. Чтобы задать параметры системы представлением маршрутизатора, требуется знать как минимум последовательными требованиями, распределение времени их обслуживания и объем буферного накопителя. При этом, даже если удастся описать потоки в сети некоторыми моделями, что даст нам возможность выяснить распределение промежутков времени между количеством его буферной памяти, остаются для нас неизвестными.

Дисциплину обслуживания очереди и объем буферной пямяти для конкретного маршрутизатора вдоль маршрута можно было бы выяснить у сотрудников Интернет-провайдера, но обычно эта информация является закрытой по экономическим соображениям.

Согласно общепринятой практике, основная услуга, предоставляемая провайдером – это так называемое “подключение к сети провайдера”, при этом предполагается, что особенности построения опорной сети не должны интересовать клиента. Кроме того, указанные два параметра требуется определить у каждого маршрутизатора вдоль маршрута в одну сторону. Если в обратную сторону маршрут содержит новые маршрутизаторы, то требуется выяснить и их исследуемой сети, двое и более, трудности увеличиваются вдвое и более.

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

Пример подобного приближения находим в работе [29]. Однако построенная таким образом модель может передавать точно лишь определенные аспекты динамики трафика в сети. Например, в [29] модель адекватно передавала такой параметр, как условное распределение задержек пакетов. Дополнительные обсуждения сложностей имитационного моделирования крупных сетей, включая Internet, можно найти в [25].

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

2 ИССЛЕДОВАНИЕ КОМПЬЮТЕРНОЙ СЕТИ НА

ПРИГОДНОСТЬ К ПЕРЕДАЧЕ МУЛЬТИМЕДИЙНОЙ

ИНФОРМАЦИИ

Руководящим документом является [15]. В нем дается следующее описание термина “метрика”: “Метрика – аккуратно специфицированный количественный параметр, относящийся к производительности и надежности сети Internet”. Метрики задержек и потерь пакетов описаны в [17, 18, 19]. При проведении измерений задержек и потерь пакетов производят отсылку тестирующего потока от одного хоста сети к другому, после чего оценивают измеренные параметры. Указывается, что интервалы времени между измерениями следует брать распределенными по экспоненциальному закону. Если же промежутки времени между измерениями будут равными, и то явление в сети, которое мы хотим наблюдать, тоже будет проявляться через равные промежутки времени, то измерения зафиксируют явление только в случае совпадения их периодов. Экспоненциальное распределение свободно от этого недостатка: если при измерениях явление наблюдалось в M случаях из N, то и в действительности это явление будет наблюдаться в доле случаев M/N при N [11].

Данная техника получила название “Poisson sampling”, так как поток измерений является пуассоновским потоком.

Еще одно важное требование к измерениям заключается в том, что размеры IP-пакетов в тестирующем потоке должны быть меньше минимального значения MTU (Maximum Transfer Unit) всех интерфейсов каждого устройства сетевого уровня вдоль маршрута, чтобы избежать фрагментирования IP-пакетов и связанного с этим искажения результатов измерений. Узнать MTU вдоль маршрута можно с помощью утилиты tracepath, входящей в пакет iputils в GNU/Linux.

2.2 Методика исследования компьютерной сети на пригодность к передаче мультимедийного трафика Как было показано ранее, для передачи мультимедийного трафика наиболее важными параметрами сети являются задержка, вносимая сетью, и уровень потерь пакетов, так как они в первую очередь влияют на восприятие потока пользователем. Поэтому было решено при создании методики исследования компьютерной сети измерять именно эти параметры.

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

ОС GNU/Linux и программы, входящие в ее состав. Один из хостов, участвующих в измерении, находился в сети СПбГПУ, а второй – в сети Петродворцового телекоммуникационного центра СПбГУ.

Ядром программного комплекса является программа MGEN [8] – генератор и приемник тестового трафика, которая была создана специалистами военного ведомства США специально для анализа компьютерных сетей. Программа MGEN, установленная на одном компьютере сети, генерирует тестовый трафик, а такая же програма на другом компьютере принимает его и записывает в файл журнала информацию о принятых пакетах, которая включает в себя: время отправки пакета по локальным часам отправителя, порядковый номер отправленного пакета (два этих значения пересылаются в каждом пакете), а также время его приема по локальным часам приемника.

Работа MGEN управляется файлом сценария. Схема эксперимента изображена на рис. 1.

Рис. 1. Структурная схема эксперимента.

На хосте “Master” в среде ОС GNU/Linux на основе команды at (1) была создана инфраструктура, которая через интервалы времени, имеющие экспоненциальное распределение, запускала скрипт test_mgen_two_way. Этот скрипт выполнял следующие задачи:

1. Читал из файла конфигурацию измерительной системы 2. Запускал на хосте “Slave” скрипт listen_mgen 3. Проверял, был ли он запущен на хосте “Master” или на хосте “Slave”. Если был запущен на “Master”, то запускал свою копию test_mgen_two_way на хосте “Slave” 4. Запускал MGEN со сценарием send.mgn для отправки тестового трафика удаленному хосту 5. После окончания отсылки тестового трафика назначал время распределению Скрипт listen_mgen выполнял следующие задачи:

1. Читал из файла конфигурацию измерительной системы 2. Запускал MGEN со сценарием receive.mgn для приема тестового трафика от удаленного хоста 3. После окончания приема тестового трафика отсылал файл с запустившего его пользователя, после чего записывал файл в каталог для хранения Автоматический запуск программ на удаленном компьютере происходил с использованием протокола SSH и его открытой реализации OpenSSH [10]. В результате совместной работы описанной системы хост “Master” передавал тестовый трафик хосту “Slave” и наоборот. Таким образом, оба хоста совершенно равноправны при отправке трафика, и один из компьютеров назван “Master” потому, что он инициирует измерение. После окончания измерения на каждом из хостов оказывался файл журнала, который отсылался по электронной почте (совокупность двух файлов журнала, по одному с каждого хоста, в дальнейшем будет называться “след эксперимента”). Далее результаты измерений анализировались и делались выводы о качестве того сегмента компьютерной сети, который соединял два хоста.

Во время измерения трафик передавался в обе стороны одновременно, что имитирует типичное состояние в случае проведения нескольких мультимедийных конференций в сети между хостами: поток от каждого хоста к его соседу аналогичен мультиплексированному потоку нескольких одновременных конференций. Если предполагается, что сеть будет использоваться преимущественно для неинтерактивных приложений, таких, как RealAudio, когда почти весь трафик передается только в сторону клиента, можно изменить конфигурацию системы тестирования. При этом каждый хост становится ведущим и независимо от соседа выбирает интервал между измерениями исходя из экспоненциального распределения.

В состав MGEN входит программа trpr, которая позволяет извлекать из файлов журнала каждого хоста информацию о задержке передачи каждого пакета из конца в конец, об интервале времени между поступлениями соседних пакетов и о доле потерянных пакетов во время измерения. Тем не менее, часы двух хостов не были синхронизированы друг с другом, поэтому результаты измерения односторонней задержки были непригодны для прямого применения.

В табл. 2 рассмотрена терминология для описания параметров часов.

Подразумевается, что существуют “точные” часы, с показаниями которых мы будем сравнивать показания испытуемых часов.

Часы двух хостов, использовавшихся в результате эксперимента, обладают недостатками: во-первых, они не синхронизированны (то есть обладают малой точностью: модуль сдвига не близок к нулю), вовторых, они идут с разной скоростью: частотный сдвиг не равен нулю.

необязательно синхронизировать часы обоих хостов с некоторыми “точными” часами. Вместо этого можно синхронизировать часы одного хоста с часами другого. Это дало бы возможность определять задержку передачи пакета в одну сторону. Однако в случае наших измерений было недоступно даже это. Синхронизация часов по протоколу NTP [13] не годится, так как он предназначен для синхронизации времени с точностью нескольких десятков миллисекунд на протяжении интервалов времени в несколько дней. В нашем же случае требовалась синхронизация с точностью около 1 мс на небольшом отрезке времени, определяемом продолжительностью измерения. Кроме того, использование протокола NTP хотя бы на одном из хостов может привести к неожиданным эффектам во время измерений, так как таймер хоста, использующего NTP, сдвигается в ходе измерения вперед или назад [24].

Кардинальным решением синхронизации показаний двух часов является система глобального позиционирования GPS, созданная военным ведомством США. Организация RIPE NCC (Европейский сетевой координационный центр) создала программно-аппаратный комплекс для измерения параметров IP-сетей [22]. Измерительная станция представляет собой компьютер, соединенный с приемником системы GPS. Во время работы таймер компьютера выдает показания, синхронизируясь с системой GPS. Точность показаний GPSприемника настолько велика, что точность временных меток в измерительной системе начинает ограничиваться разрешением таймера и составляет около 1 мс, что вполне достаточно для практических целей. Разработанный программно-аппаратный комплекс стоит €2500 и продается фактически по себестоимости.

Организации, желающие участвовать в тестировании связи между своей сетью и остальной частью Internet, могут приобрести такой прибор и установить его на своей технической площадке. После установки прибор работает без вмешательства оператора и передает собранную статистику для анализа в RIPE NCC, делая ее доступной для всех участников измерений.

Resolution Минимальная единица времени, на которую могут (разрешение) измениться показания часов Offset (сдвиг) Accuracy (точность) (частотный Частотный сдвиг также является первой производной Drift (снос например, из-за изменения температуры в машинном зале меняется частота хода кварцевого генератора Таблица 2. Терминология, используемая при описании испытуемых часов То обстоятельство, что частотный сдвиг между часами не равен нулю, требует обязательного учета. Выражается этот недостаток часов в том, что они идут с другой скоростью (пусть, для определенности, они идут немного быстрее), чем их пара. По абсолютной величине частотный сдвиг невелик, например, в ходе измерений наблюдалось значение сдвига показаний 1 мс за каждые 5,5 с. Но за 180 секунд, которые длится измерение, показания часов сдвигались друг относительно друга на 32 мс. Этой величиной нельзя пренебречь при анализе. Тем не менее, на коротких интервалах времени, сопоставимых с длительностью измерения, частотный сдвиг часто является постоянной величиной (в ходе измерений отклонений от этого правила не было), тогда сдвиг показаний часов будет линейным, и его можно удалить после получения результатов измерений. Удаление частотного сдвига, таким образом, устраняет методическую ошибку измерений.

Выше упоминалось, что несинхронизированность часов сделала прямое использование результатов измерения невозможным.

Качественно картина выглядит следующим образом. Если сдвиг между показаниями часов составляет, допустим, 10 с, то измеренная в одну сторону задержка оказывалась равна примерно 10 с, а в другую сторону – примерно -10 с. Реального значения односторонней задержки из этих данных получить невозможно. Тем не менее, можно получить значение задержки в обе стороны. Пусть показания часов хоста B отличаются в большую сторону от показаний часов A на величину :

часам B. MGEN записывает в файл журнала разность временных меток двух хостов. Поэтому в журнале будет зафиксирована запись об односторонней задержке величиной односторонней задержки при передаче пакета от A к B будет превышать реальную задержку t latAB на величину сдвига часов двух хостов. Если мы в это же время будем посылать пакет от B к A, то MGEN, установленный на хосте A, зарегистрирует разность временных меток, равную Итак, во втором журнале зарегистрированное MGEN значение меньше реальной задержки от B к A. Сложив теперь две журналов, получим t latAB t latBA, то есть сумму двух односторонних задержек. Во время вывода данного результата существенно, что значение одинаково при измерениях в обе стороны, так как пакеты посылались в обе стороны одновременно. В противном случае, из-за ненулевого частотного сдвига часов значения были бы разными при измерении в каждую сторону.

Обычно под RTT (Round-Trip Time, “время полного оборота”) подразумевают время, которое требуется пакету, чтобы достичь адресата и вернуться обратно. Измерение RTT часто производят с помощью программы ping и подобных ей. Такие программы посылают сообщение протокола ICMP [20] “echo request”, оно достигает адресата, ядро операционной системы которого генерирует ответное сообщение ICMP “echo reply”, которое отправляется обратно. Отправитель, получив ответ на свое собственное сообщение, вычисляет, сколько времени прошло с момента отправки, и полученное значение и называется RTT. Указанный метод обладает недостатком: ICMP-пакеты не обязательно будут обслуживаться на промежуточных и конечных узлах так же, как и пакеты с данными.

Часто маршрутизаторы ограничивают пропускную способность, предоставляемую потоку ICMP-пакетов, из соображений безопасности [30]. Кроме того, IP-стек маршрутизаторов и приемника могут работать с ICMP-пакетами как с менее приоритетными и генерировать и продвигать их только в том случае, если на обслуживании нет пакетов с данными [24]. Это приводит к тому, что значения RTT, наблюдаемые при таком тестировании, отражают не время полного оборота пакетов с данными, а время полного оборота ICMP-пакетов, что исследователю вовсе не требуется. Существует улучшенный вариант этого метода, когда на передающем хосте установлен генератор пакетов с данными, но не по протоколу ICMP, а, например, по UDP. На другом хосте находится приемник. При получении пакета приемник немедленно отправляет его обратно.

Отправитель получает ответ и вычисляет значение RTT так же, как и в предыдущем случае. Особенность схемы состоит в том, что используются не пакеты ICMP, а пакеты UDP, и наблюдаемое значение RTT лучше отражает условия, в которых бы передавались пользоватльские данные. Кроме того, “зеркальное отражение” пакета делает не ядро ОС приемника, а приложение на приемнике, поэтому наблюдаемое значение RTT еще немного ближе к тому, которое испытывали бы реальные потоки данных.

В данной работе планировалось создать методику оценки RTT не одним из указанных выше методов, а путем сложения значений двух односторонних задержек. Для этого следовало поступить так: удалить частотный сдвиг из следа эксперимента, вычислить медиану наблюдаемых значений односторонней задержки от хоста “Master” к хосту “Slave”, затем аналогичным образом вычислить медиану значений односторонней задержки от “Slave” к “Master”. После этого полученные медианы сложить и, согласно методу, суть которого изложена ранее, получить в результате значение RTT для данного эксперимента. Достоинство этого метода перед рассмотренными в том, что в нем RTT вычисляется при нагруженной потоками трафика сети, в то время как измерения с использованием ping и подобных методов часто проводятся на ненагруженной сети, что дает воспользоваться этим методом не удалось: из-за отсылки пакетов пачками динамика трафика приняла сложный характер, и линейное увеличение односторонней задержки из-за частотного сдвига совершенно не прослеживалось. В результате частотный сдвиг удалялся неверно. Это привело к тому, что полученное методикой значение RTT было значительно (в два-три раза) выше того, которое сообщала для данной сети утилита ping. Чтобы упростить дальнейшие исследования, рекомендуется применять комплекс из двух программ для измерения RTT, аналогичный описанному выше. Запуск программы, отправляющей эхо-запросы, следует производить с началом измерения (то есть когда сеть будет нагружена), а после его окончания производить статистический анализ измеренных значений RTT. В данной работе не удалось реализовать эти дополнительные измерения в связи с техническими проблемами в работе хоста “Abiturient”.

Значение RTT полезно для оценки характеристик сети. Если две его составляющие – односторонние задержки в каждую сторону – примерно равны, то можно использовать RTT / 2 для оценки усредненной односторонней задержки. Сравнив это значение с критическим значением сетевой задержки для данного метода кодирования, после которого качество восприятия мультимедийного потока в интерактивном приложении резко падает, можно оценить качество компьютерной сети.

Так как без синхронизированных часов не существует способа оценить, насколько близки друг к другу значения двух односторонних задержек, а, значит, законно ли использовать RTT / 2 как оценку односторонней задержки, можно воспользоваться косвенным методом: построив топологическую карту сети и оценив асимметричность маршрутизации. Метод построения топологической карты сети, который здесь предлагается, по своей природе будет неточным из-за недостатка информации, но пример, приведенный ниже, показывает, что асимметричность с его помощью можно обнаруживать и оценивать. Карта сети строится по результатам анализа данных, выводимых утилитой traceroute [23], при трассировке от одного хоста к другому и затем обратно. Построенная карта отражает состояние сети лишь на момент построения: в любой другой момент времени связи между маршрутизаторами могут измениться, и карту придется строить заново. Однако, маршруты в глобальных сетях обычно либо относительно стабильны (остаются постоянными по крайней мере на несколько дней), либо постоянно имеется более чем один маршрут от источника до приемника, и передаваемые пакеты задействуют все эти маршруты. Более подробные сведения о характеристиках маршрутов глобальных сетей содержатся в [24]. На рис. 3 приведены результаты выполнения traceroute по обоим маршрутам. На рис. 4 представлена построенная на основе этих данных карта сети.

[alice04]$ traceroute abiturient.stu.neva.ru traceroute to abiturient.stu.neva.ru (194.85.96.169), 30 hops max, 38 byte packets 1 wrk-ptc (195.19.225.65) 1.467 ms 1.320 ms 1.341 ms 2 CH0.LE-PTC.spbu.ru (195.19.224.18) 3.119 ms 5.414 ms 3.280 ms 3 spb-4-gw.runnet.ru (194.190.255.157) 6.063 ms 36.462 ms 16.570 ms 4 spb-gw.runnet.ru (194.85.36.41) 131.024 ms 14.295 ms 19.970 ms 5 RUSnet-gw.runnet.ru (194.190.255.142) 12.401 ms 13.164 ms 7.990 ms 6 filter.stu.neva.ru (194.85.4.8) 12.361 ms 14.536 ms 13.515 ms 7 abiturient.stu.neva.ru (194.85.96.169) 15.062 ms 8.504 ms 7.779 ms [abiturient]$ traceroute alice04.spbu.ru traceroute to alice04.spbu.ru (195.19.225.94), 30 hops max, 38 byte packets 1 RUSnet-SPbGPU-gw.neva.ru (194.85.96.62) 0.278 ms 0.229 ms 0.162 ms 2 INT-6.100M.le-gw.RUSnet.ru (194.85.4.242) 1.704 ms 1.619 ms 1.661 ms 3 INT-1.100M.le-gw2.RUSnet.ru (194.85.4.12) 0.606 ms 0.632 ms 0.584 ms 4 spb-gw.runnet.ru (194.190.255.141) 2.393 ms 3.076 ms 3.678 ms 5 spb-ix.runnet.ru (194.85.36.42) 3.300 ms 3.033 ms 4.419 ms 6 ptc.spbu.ru (194.190.255.158) 11.430 ms 3.808 ms 3.956 ms 7 PTCgate.spbu.ru (195.19.224.25) 8.756 ms 6.787 ms 7.573 ms 8 alice04.spbu.ru (195.19.225.94) 7.634 ms 21.700 ms 26.742 ms Рис. 2. Данные утилиты traceroute при трассировке в обе стороны.

На рис. 4 прямоугольники обозначают маршрутизаторы, знаками вопроса обозначены те IP-адреса интерфейсов, которые не удалось определить по данным traceroute. Асимметричность наблюдается в сегменте сети провайдера RusNet. Так как разница в числе переходов для маршрутов в обе стороны равна 8-7=1, такая асимметричность вряд ли препятствует использовать значение RTT / 2 как оценку для односторонней задержки.

Рис. 3. Топологическая карта сети, построенная на основе данных traceroute Трафик, генерируемый каждым хостом, формировался следующим образом: генерировалась пачка из 10 пакетов по байт каждый, затем следовала пауза в 1 с. Этот поток похож на трафик RealAudio, но создает большую нагрузку на сеть. Средняя битовая скорость его составляет около 67 Кбит/сек (в каждую из двух сторон). Этого достаточно для передачи около 10 потоков RealAudio с низким качеством трансляции речи (6,5 Кбит/сек), или около потоков RealAudio с музыкальной информацией в среднем качестве (16 Кбит/сек), или для одного видеопотока со звуком низкого качества. Каждое измерение длилось 180 с. Размер пакета был выбран большим, чтобы можно было оценить битовую скорость узкого места сети (см. далее), но при возможности провести больше измерений следует выбирать размер пакета, типичный для приложения, которое планируется использовать в исследуемой сети. Кроме того, следует устанавливать битовую скорость потока в соответствии с ожидаемой нагрузкой на сеть.

Для каждого следа эксперимента вычислялись следующие параметры компьютерной сети:

1. Интерквартильный промежуток для наблюдаемых значений интервалов между поступлениями пакетов по данным MGEN – вычислялся для обоих направлений потока и являлся мерой проявления “дрожания” (неравномерности поступления пакетов). Так как пакеты высылались пачками по 10 штук, то интервалы между поступлениями соседних пакетов в пачке были малы и определялись передачей пакетов по сети, а интервал между последним пакетом пачки и первым пакетом следующей пачки составлял около 1 с и определялся паузами между пачками. Поэтому все интервалы более 0,9 с не учитывались при анализе в целях упрощения.

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

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

Интервалы между прибытиями пакетов отклоняются от своего среднего значения из-за природы сети с пакетной коммутацией: чем больше заняты промежуточные маршрутизаторы, чем длиннее в них очереди, тем больше задерживаются пакеты по сравнению со своими соседями. Робастной оценкой для отклонений интервалов между прибытиями от среднего значения является интерквантильный промежуток выборки. Поэтому при заданном типе трафика изменение интерквантильного промежутка с течением времени характеризует загруженность сети.

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

Из графиков потерь видно, что всплески потерь, усредненные за 5 с (изображены сплошной линией) имеют место на маршруте от хоста “Abiturient” до хоста “Alice” в пик рабочего времени: 14 часов дня. В остальное время суток уровень потерь значительно ниже. При этом даже пик потерь вряд ли серьезно помешает использованию мультимедийных приложений. Уровень потерь при усреднении за длительность всего измерения всюду не выше 3%, что является хорошим показателем. В обратном направлении, от “Alice” к “Abiturient”, уровень потерь постоянно ниже и пик всплесков здесь почти вдвое меньше. Возможно, это связано с асимметричной топологией сети: в этом направлении трафик проходит через один транзитный маршрутизатор, а не через два.

Длительность интерквантильного промежутка для выборки интервалов между поступлениями пакетов косвенно характеризует загруженность сети. На маршруте от “Abiturient” к “Alice” уровень имеет пик в области 14 часов дня, как и на графике потерь, а также уровень довольно высок в рабочие часы с 13 до 18, затем падает, остается на среднем уровне ночью, от 22 до 2 часов ночи, и почти нулевой с 3 до 9 часов утра. Видимо, ночью средний уровень сохраняется за счет работы автоматизированных средств получения файлов, которые активизируются после рабочего дня. К таким средствам могут относиться обновления операционных систем и доступ к крупным файлам, в том числе мультимедийным, не в реальном масштабе времени. На маршруте в обратном направлении уровень IQR почти всюду одинаков, но наблюдается его резкое увеличение в районе 16-19 часов дня. Это явление сложно объяснить, но можно утверждать, что оно связано с асимметричностью маршрутизации, так как в обратном направлении подобного явления не наблюдалось.

По возможности рекомендуется проводить измерения в течение более длительного срока, пусть это и оказывает дополнительную нагрузку на сеть.

Если в сети есть узкое место, обычно маршрутизатор с низкой пропускной способностью канала связи, то в независимости от интенсивности поступления на него трафика, исходящие пакеты всегда будут отстоять друг от друга на интервал, определяемый битовой скоростью канала связи. Подробное описание этого явления можно найти в работе [24]. Если принять, что в сети почти нет другого трафика, то интервалы между последовательными поступлениями пакетов на хост назначения могут позволить вычислить битовую скорость узкого места в сети. Анализ всех следов измерений за сутки показал, что около 50% всех пакетов поступало на хост назначения через интервал 10..11 мс. На гистограмме при этом наблюдается очевидный всплеск, который говорит сам за себя. Если принять, что пакет размером 1400 байт передавался по линии связи в узком месте сети в течение 10 мс, то битовая скорость узкого места составит 1,12 Мбит/сек. В ходе работы не удалось выяснить, действительно ли канал связи с минимальной битовой скоростью имеет именно такую скорость, как было подсчитано. Это предстоит узнать путем общения с представителями провайдеров, обслуживающих исследуемый сегмент сети.

3. ЗАКЛЮЧЕНИЕ И АНАЛИЗ РЕЗУЛЬТАТОВ РАБОТЫ

рассматриваются:

1. Доля потерь пакетов во время измерения, усредненная за время 5 с (характеризует всплески потерь) 2. Доля потерь пакетов, усредненная по времени всего измерения (характеризует общий уровень потерь) интервалов между поступлениями последовательных пакетов (является оценкой “дрожания” (jitter) и косвенно характеризует загруженность сети) 4. Битовая скорость узкого места сети (определяется по анализу интервалов между поступлениями последовательных пакетов) К этому списку следует добавить время полного оборота (RTT), методику измерения которого из-за технических проблем не удалось реализовать, что предстоит сделать в будущем. Также в числе дальнейших направлений работы можно назвать улучшение методики определения битовой скорости узкого места сети и автоматизацию анализа данных, собранных на протяжении больших периодов времени.

В перспективе представляется разумным вместо измерения RTT связать хост с GPS-приемником, чтобы иметь возможность измерять топологической асимметричностью маршрутов сети.

Рис. 4. Уровень потерь пакетов за сутки: от Abiturient к Alice (а) и в обратном направлении (б) Рис. 6. Интерквартильный промежуток для интервалов между прибытиями соседних пакетов за сутки: от Abiturient к Alice (а) и в обратном направлении (б)

СПИСОК ЛИТЕРАТУРЫ

University Colledge London, 2000.

2. Art Mena and John Heidemann. "An Empirical Study of Real Audio Traffic", in Proceedings of the IEEE Infocom, Tel-Aviv, Israel, Mar.

2000, USC/Information Sciences Institute, pp. 101-110, IEEE 3. H. Schulzrinne, A. Rao, R. Lanphier. Real Time Streaming Protocol (RTSP). April 1998.

4. Internet Engineering Task Force, http://www.ietf.org/ 5. ITU-T P.800 Methods for subjective determination of transmission quality. http://www.itu.int/publications/itu-t/iturec.htm 6. Kun-chan Lan, John Heidemann. "Structural Modeling of RealAudio traffic". USC/Information Sciences Institute, 2001.

7. Maureen Chesire, Alec Wolman, Geoffrey M. Voelker, and Henry M.

Levy. "Measurement and Analysis of a Streaming-Media Workload", 2001.

8. MGEN, http://mgen.itd.nrl.navy.mil/ 9. Network Simulator ns-2, http://www.isi.edu/nsnam/ns/ 10.OpenSSH, http://www.openssh.org/ 11.R.Wolff, "Poisson Arrivals See Time Averages", Operations Research, 30(2), pp. 223-231, 1982.

12.RealNetworks, "RealNetworks documentation library", http://service.real.com/help/library/ 13.RFC1305. Network Time Protocol (Version 3). Specification, Implementation. D. Mills. March 1992.

14.RFC2205. Resource ReSerVation Protocol (RSVP) -- Version Functional Specification. R. Braden, Ed., L. Zhang, S. Berson, S.

Herzog, S. Jamin. September 1997.

15.RFC2330. Framework for IP Performance Metrics. V. Paxson, G.

Almes, J.Mahdavi, M. Mathis. May 1998.

16.RFC2474. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, D. Black.

December 1998.

17.RFC2679. A One-way Delay Metric for IPPM. G. Almes, S. Kalidindi, M.Zekauskas. September 1999.

18.RFC2680. A One-way Packet Loss Metric for IPPM. G. Almes, S.

Kalidindi, M.Zekauskas. September 1999.

19.RFC2681. A Round-trip Delay Metric for IPPM. G. Almes, S.

Kalidindi, M.Zekauskas. September 1999.

20.RFC777. Internet Control Message Protocol. J. Postel. Apr-01-1981.

21.RFC791. Internet Protocol. J. Postel. Sep-01-1981.

22.RIPE NCC, http://www.ripe.net/ 23.traceroute. ftp://ftp.ee.lbl.gov/ 24.Vern Paxson, "Measurements and Analysis of End-to-End Internet Dynamics". University of California, Berkeley, 1997.

25.Vern Paxson, Sally Floyd. "Why we don't know how to simulate the Internet". Proceedings of the 1997 Winter Simulation Conference.

26.А.Г.Жданов, Д.А.Рассказов, Д.А.Смирнов, М.М.Шипилов.

"Передача речи по сетям с коммутацией пакетов (IP-телефония)".

телекоммунникаций им. проф. М.А.Бонч-Бруевича. 2001 г.

27.В.Г.Олифер, Н.А.Олифер. "Новые технологии и оборудование IPсетей". СПб.: БХВ-Петербург, 2001 г.- 512 с., ил.

28.В.Г.Олифер, Н.А.Олифер. Компьютерные сети. Принципы, технологии, протоколы. СПб: Питер, 2001. - 672 с., ил.

29.И.В.Стручков, "Исследование характеристик показателей качества сервисов реального времени в ip-сетях". СПбГПУ, 2002.

30.И.Д.Медведовский, П.В.Семьянов, Д.Г.Леонов, А.В.Лукацкий.

"Атака из Internet". М.: СОЛОН-Р, 2002. 368 с.

31.К.С.Солнушкин, М.В.Хлудова. "Поддержка сигналов реального времени стандарта POSIX 1003.1b в операционных системах Linux и SunOS", в печати. http://Konstantin.Solnushkin.ru/files/ 32.Компания "RealNetworks" http://www.real.com/ 33.Л. Клейнрок. Теория массового обслуживания. М.:

Машиностроение, 1979. - 432 с., ил.

34.Л.Форд, Д.Фалкерсон. "Потоки в сетях". М.: "Мир", 1966 г.