Предоставление индивидуального
Можно пойти и дальше в детализации требований к пропускной способности. В конце концов пропускная способность каналов связи нужна не компьютеру в целом, а отдельным приложениям, которые выполняются на этом компьютере. У файлового сервиса одни требования к пропускной способности, у электронной почты - другие, а у сервиса интерактивных видеоконференций - третьи. Особенно остро эти различия стали ощущаться с начала 90-х годов, когда наряду с традиционным файловым сервисом и сервисом печати в локальных сетях стали использоваться новые виды сервисов, порождающих трафик реального времени, очень чувствительного к задержкам. Типичным представителем такого сервиса является компьютерная телефония. Каждый телефонный разговор двух абонентов порождает в сети трафик, имеющий постоянную битовую скорость, чаще всего 64 Кб/с (рис.1.5), когда источник голосовой информации порождает поток байт с частотой 8 КГц.
Более сложные методы кодирования могут уменьшить интенсивность голосового трафика до 9.6 Кб/с, и даже до 4 - 5 Кб/с.
Независимо от способа кодирования и интенсивности трафика, качество воспроизводимого на приемном конце голоса очень зависит от задержек поступления байт, несущих замеры амплитуды голоса. Вся техника передачи голоса в цифровой форме основана на том, что замеры должны поступать на воспроизводящее устройство через те же интервалы, через которые они производились на приемном устройстве, которое преобразовывало голос в последовательность чисел. Задержка поступления очередного байта более чем на 10 мс может привести к появлениям эффекта эха, большие задержки могут исказить тембр голоса до неузнаваемости или привести к затруднениям в распознавании слов. Компьютерные сети - как локальные, так и глобальные - это сети с коммутацией пакетов, в которых задержки передачи пакетов трудно предсказать. В силу самого способа буферизации пакетов в промежуточных коммутаторах и маршрутизаторах задержки в компьютерных сетях имеют переменный характер, так как пульсирующий характер файлового сервиса, Web-сервиса и многих других популярных компьютерных сервисов создают постоянно меняющуюся загрузку коммутаторов и маршрутизаторов.
Рис. 1.5. Трафик, порождаемый в сети при передаче телефонного разговора
Особенно большие проблемы создает интерактивный обмен голосовыми сообщениями, проще говоря - обычный разговор. При передаче голоса только в одну сторону, например, при воспроизведении заранее записанной музыки, на приемном конце можно поставить буфер, в котором будут накапливаться неравномерно поступающие замеры звука, которые с некоторой задержкой затем будут извлекаться из буфера строго с частотой 8 КГц (рис.1.6).
Рис. 1.6. Сглаживание неравномерности задержек, вносимых сетью
Такой буфер обычно называется устройством эхоподавления и используется в протяженных цифровых телефонных сетях. При интерактивном обмене постоянные значительные задержки, вносимые буфером в разговор, становятся очень неудобными для собеседников - приходится долго ждать ответа, как при разговоре с космонавтами.
Аналогичные требования к передаче своих данных предъявляет и трафик, переносящий видеоизображение. Трафик, требующий, чтобы его данные поступали к приемному узлу через строго определенные промежутки времени, называется синхронным в отличие от асинхронного трафика, мало чувствительного к задержкам его данных. Почти весь трафик традиционных сервисов компьютерных сетей является асинхронным - задержка передачи части файла даже на 200 мс будет мало заметна для пользователя.
Как правило, асинхронный и синхронный виды трафика существенно отличаются и еще в одном важном отношении - чувствительности к потере пакетов. Асинхронный трафик очень чувствителен к таким потерям, так как потеря даже небольшой части файла делает всю операцию передачи файла по сети бессмысленной - файл или его потерянную часть обязательно нужно передавать заново. Потеря же одного замера голоса или одного кадра изображения не очень заметно сказывается на качестве воспроизводимого сигнала, так как инерционный характер физических процессов приводит к тому, что два последовательных замера не очень отличаются друг от друга, поэтому воспроизводящему устройству не составляет труда восстановить, хотя и приблизительно, потерянную информацию.
Использование мультимедийной информации и интерактивных сервисов в компьютерных сетях создало сложную проблему совмещения двух очень разных по требованиям к характеру передачи пакетов через сеть типов данных. Сложности совмещения синхронного и асинхронного трафика в одной сети коммутации пакетов иллюстрирует рисунок 1.7.
Рис. 1.7. Проблема совмещения синхронного и асинхронного трафика в одной сети с коммутацией пакетов
При передаче синхронных данных в обычных пакетах и кадрах локальной сети, такие пакеты будут встречаться во внутренних очередях коммутаторов и маршрутизатров с пакетами обычного асинхронного компьютерного трафика. Если коммутатор или маршрутизатор не делает различий между пакетами синхронного и асинхронного трафика, то задержки могут быть очень большими и очень неравномерными, особенно при загрузке коммуникационного устройства, близкой к его максимальным возможностям обработки пакетов. Естественным выходом из этой ситуации является приоритетная обработка пакетов синхронного трафика - и это очень распространенный прием, применяемый многими производителями коммутаторов, маршрутизаторов, а также разработчиками новых протоколов локальных сетей, например, протокола 100VG-AnyLAN, в котором существует два уровня приоритетов.
Однако, даже при приоритетной обработке пакеты синхронного трафика могут задерживаться в коммуникационных устройствах, так как в них можно реализовать только алгоритмы обработки с относительными приоритетами, а не с абсолютными. Это значит, что если низкоприоритетный пакет уже начал передаваться в сеть, то устройство не может прервать его передачу при приходе в это время высокоприоритетного пакета. Поэтому максимальное время ожидания синхронного пакета всегда равно времени передачи пакета максимальной длины, которую допускает тот или иной протокол или действующая конфигурация сети.
Так, для классического 10-Мегабитного Ethernet'а максимальный размер пакета равен 1526 байт (со всеми служебными полями и преамбулой). Значит, максимальное время его передачи составит 1.2 мс.
Это не так много для большинства видов синхронного мультимедийного трафика. Хуже обстоят дела в сетях TokenRing, где кадры могут достигать размера в 16 Кбайт. При скорости в 16 Мб/с это может привести к задержке в 8 мс, уже оказывающей заметное влияние на качество голоса или изображения. Для сетей FDDI с битовой скоростью 100 Мб/с и максимальным размером кадра 4500 байт задержка составит всего 0.36 мс, для сетей Fast Ethernet - 0.12 мс, GigabitEthernet - 0.012 мс, а АТМ при скорости 155 Мб/c и размере ячейки в 53 байта - всего 2.7 мкс.
Однако, этот идеальный случай соответствует полностью свободной в любой момент времени среде передачи данных на выходном порту коммутатора или маршрутизатора. Такая ситуация встречается в локальных сетях не часто, так как микросегментация, когда каждый компьютер связан с сетью своей индивидуальной линией связи, пока еще слишком дорогое удовольствие для применения его во всех сегментах сети. При использовании в сегменте разделяемой среды высокоприоритетный пакет должен ждать не только завершения передачи низкоприоритетного пакета, но и освобождения разделяемой среды, а это составляющая является чисто случайной и с ней бороться можно только уменьшая загрузку сегмента.
Разделяемые среды передачи данных традиционно использовались в локальных сетях для уменьшения стоимости сетевого оборудования. Практически все протоколы локальных сетей - от Ethernet до 100VG-AnyLAN и GigabitEthernet (АТМ не относится к протоколам, разработанным для локальных сетей, эта технология в гораздо большей степени близка к технологиям передачи данных в глобальных сетях) могут работать на разделяемых средах передачи данных.
В разных протоколах локальных сетей реализованы разные методы доступа к разделяемой среде. В некоторых новых протоколах предусмотрен механизм приоритетного предоставления доступа к среде. Обычно, разработчики протокола ограничиваются двумя уровнями приоритетов - один, низкий, для асинхронного трафика, и второй, высокий, для синхронного. Так поступили разработчики протоколов FDDI и 100VG-AnyLAN.
В протоколе TokenRing существует 8 уровней приоритетов, а во всех протоколах семейства Ethernet - FastEthernet - GigabitEthernet понятие приоритета кадра отсутствует. Безусловно, приоритетное предоставление доступа к разделяемой среде намного уменьшает задержки доставки пакетов к узлу назначения.
Однако, какой бы метод доступа к разделяемой среде передачи данных не использовался, возможна ситуация, когда несколько узлов с высоким приоритетом будут требовать одновременный доступ к разделяемой среде. Протоколы локальных сетей, даже самые последние, не решают задачу предоставления каких-то гарантий в распределении полосы пропускания общего канала передачи данных между равноприоритетными узлами. И, если все узлы сети будут иметь равные приоритеты, то разделяемая среда по-прежнему будет предоставлять каждому узлу заранее неизвестную часть своей пропускной способности.
Обеспечение для абонентов сети требуемого уровня задержек - это частный случай обеспечения нужного качества обслуживания - QualityofService, QoS. Анализ типов трафика, создаваемого современными приложениями, позволил выделить несколько основных типов, для которых понятие QoS имеет различный смысл и характеризуется различными параметрами.
Трафик реального времени с постоянной битовой скоростью обычно требует предоставления ему постоянной полосы пропускания, причем в понятие качества обслуживания входит не только величина предоставляемой ему пропускной способности, но и величина задержек передачи каждого пакета - обычно среднее время задержки и величина ее вариации. Типичный представитель этого типа трафика - голосовой трафик.
Существует также тип трафика реального времени, создающий поток данных с пульсирующей битовой скоростью, но так же чувствительный к задержкам передачи пакетов. Такой трафик создают источники, выполняющие компрессию голоса или видеоизображения, когда, например, при неизменной картинке интенсивность потока данных резко уменьшается. Для такого трафика в понятие качества обслуживание по прежнему входят средняя величина и вариация задержек, а вместо одного параметра пропускной способности обычно от сети требуется обеспечить два - среднюю скорость передачи данных и передачу всплеска трафика до определенной величины в течение оговоренного периода времени.
Для пульсирующего компьютерного трафика, который не является трафиком реального времени, так как нечувствителен к задержкам, обычно достаточно обеспечить аналогичные предыдущему случаю параметры пропускной способности, а о величинах задержек не заботиться.
Для случая, когда трудно точно оценить среднюю скорость передачи данных приложением и максимальный всплеск интенсивности, применяют упрощенное толкование понятия качества обслуживания - как верхний и нижний пределы пропускной способности, предоставляемой сетью абоненту в течение достаточно длительного промежутка времени.
В предыдущих примерах качество обслуживания трактовалось только относительно временных характеристик работы сети. Однако, вероятность успешной доставки данных абоненту также, естественно, может учитываться в качестве обслуживания. Для многих видов компьютерного сервиса, где потери пакетов ведут к существенному снижению полезной пропускной способности сети, надежность доставки пакета - существенная составляющая качественного обслуживания абонента сетью.
До сих пор мы больше говорили о предоставлении определенного уровня качества обслуживания узлам сети, то есть компьютерам в целом. Однако, на самом деле источником трафика с определенными требованиями к качеству его обслуживания является не компьютер, а отдельное приложение, работающее на этом компьютере. Вполне реальной является ситуации когда на одном компьютере одновременно в режиме разделения времени выполняются несколько приложений и у каждого имеются свои требования к передаче его данных через сеть. Большинство современные ОС поддерживают режим мультипрограммирования, так что сосуществование фонового приложения рассылки электронной почты или факсов с сессией видеоконференции вполне возможно. Поэтому современная сеть должна допускать обслуживание с разными классами качества и с разными параметрами качества приложений одного и того же компьютера.
Совмещенная передача голоса и данных и гарантированное качество обслуживания в глобальных сетях
В глобальных сетях проблема совмещения голоса и данных, или, в более широкой постановке задачи, обеспечение гарантированного качества обслуживания для различных классов трафика стоит еще более остро. Это объясняется тем, что глобальные каналы связи существенно дороже локальных, поэтому гораздо сильнее стимулы для использования одной и той же транспортной инфраструктуры для передачи компьютерного трафика и трафика, который обычно передается через телефонные сети.
Попытки обеспечить приемлемое качество обслуживания для голосового и компьютерного трафика делались в территориальных сетях уже давно - практически с самого начала внедрения глобальных компьютерных сетей. Компьютерный трафик при отсутствие специальных каналов связи передавали по телефонным каналам с помощью модемов. Телефонные сети всегда работали по технологии коммутации каналов, поэтому проблема задержек голосовых данных длинными компьютерными пакетами здесь не возникала - после коммутации составной канал оказывался полностью в распоряжении либо компьютерного, либо голосового трафика.
Однако, при этом определенные неудобства испытывали компьютерные абоненты сети - канал с постоянной пропускной способностью не может хорошо передавать пульсации трафика. Если нужно передать трафик со средней интенсивностью 10 Кб/с и пульсацией до 500 Кб/с на протяжении одной секунды, то, очевидно, что канал с пропускной способностью 28.8 Кб/с не сможет хорошо справиться с этой задачей. Пакеты, принадлежащие периоду всплеска трафика, будут ждать в очереди, которая образуется на входе такого канала. В то же время в периоды трафика низкой интенсивности (а они, безусловно, будут иметь место, так как средняя интенсивность трафика всего 10 Кб/c) канал будет использоваться всего на небольшую долю своей пропускной способности, а так как в сетях с коммутацией каналов оплата всегда осуществляется на повременной основе, то и платить компьютерные абоненты всегда будут не только за полезную пропускную способность канала, но и за неиспользуемую часть времени его работы.
Такое положение дел всегда сохраняется при использовании сетей с коммутацией каналов, в том числе и сетей ISDN. Сети ISDN изначально проектировались как сети с интегральными услугами, в которых компьютерный трафик должен передаваться наравне с телефонным, трафиком факсов, службы телетекста и трафиками других служб. Однако первая попытка построения интегральной территориальной сети удалась далеко не в полной мере. Сервис коммутации пакетов, так нужный для качественной и экономной передачи пульсаций трафика, оказался в этих сетях пасынком. Только немногие провайдеры сетей ISDN предоставляют такой вид услуг своим абонентам, да и то на медленных каналах типа D в 16 Кб/с или 64 Кб/с, а такие скорости вряд ли удовлетворят пользователей современных корпоративных сетей. Поэтому для передачи компьютерного трафика через сети ISDN используется сервис коммутации каналов со скоростью до 2 Мб/с, а значит все проблемы с передачей пульсаций остаются.
При использовании же для передачи голосового и других видов трафика реального времени сетей, разработанных как чисто компьютерные, пользователи сталкиваются с той же проблемой неравномерных и значительных задержек пакетов с мультимедийными данными, которая присуща и локальным сетям. При более низких скоростях передачи данных задержки могут быть достаточно чувствительными. Даже в ненагруженной сети framerelay при скорости передачи данных по каналу в 1.5 Мб/с передача пакета компьютерных данных длиной 4096 байт может задержать пакет голосовых данных на 22 мс, что скорее всего очень сильно снизит качество передачи голоса.
Большие размеры пакетов, которые выгодны для передачи компьютерных данных, так как увеличивают полезную пропускную способность канала за счет снижения доли служебных данных в заголовках, вредно влияют на качество передачи трафика реального времени не только за счет задержек в промежуточных узлах, то есть коммутаторах и маршрутизаторах. Большое влияние на качество обслуживания может оказывать так называемая задержка пакетизации, которая тем больше, чем больше размер пакета, используемого для передачи мультимедийных данных.
Механизм возникновения задержки пакетизации иллюстрирует рисунок 1.8.
Рис. 1.8. Задержка пакетизации голосовых данных при передаче через сети коммутации пакетов
Пусть мы хотим использовать для передачи голоса сеть framerelay с максимальным размером пакета 4096 байт. Оцифрованные замеры голоса поступают на вход устройства доступа к глобальной сети - FrameRelayAccessDevice, FRAD, с частотой 8 КГц. FRAD упаковывает каждый байт в пакет, при этом первый байт, попавший в какой-либо пакет, должен ждать отправки в сеть 4095 интервалов по 125 мкс (период следования байт при частоте 8 КГц), пока пакет на заполнится полностью. Эта задержка и называется задержкой пакетизации, в данном случае она составит 511 мс, то есть полсекунды, что совершенно недопустимо. Поэтому обычно FRAD настраивается на отправку в сеть голосовых данных в пакетах гораздо меньшей длины, например, 128 байт, но и при этом задержка составит порядка 16 мс и для ее компенсации нужно устройство эхоподавления на приемном конце.
Из-за задержек пакетизации в сетях с коммутацией пакетов при необходимости совмещать передачу голоса и данных применяют пакеты небольших размеров, которые также уменьшают и задержки ожидания в коммутаторах сети. Однако, при этом уменьшается полезная пропускная способность сети для компьютерных данных.
В глобальных сетях обычно не ставится задача поддержки качества обслуживания для всех возможных типов трафика, которые были рассмотрены выше. Чаще всего, глобальная сеть считается очень хорошей, если она может дифференцированно обслуживать по крайней мере два вида трафика, голосовой и компьютерный, прием с очень упрощенной поддержкой качества обслуживания для каждого типа.
Более тонкая поддержка качества обслуживания для всех основных типов трафика обеспечивается сегодня только в сетях АТМ, и то часто потенциально, так как не все провайдеры АТМ предлагают абонентам своих сетей все возможные способы поддержки качества обслуживания, определенные в стандарте технологии АТМ.
