В поисках утраченного качества

Интернет не гарантирует качества. Хотя были разработаны системы обеспечения параметров качества в IP-сетях, решение этой задачи на межсетевом уровне в глобальном масштабе не представляется возможным. И тем не менее качество Интернета постоянно растет. Еще вчера высококачественное видео через Интернет казалось недоступной роскошью, а сегодня Сеть зачастую обеспечивает большую пропускную способность, чем локальный диск вашего компьютера. Но можно еще лучше, и ключ к решению лежит в методах более эффективного использования имеющейся пропускной способности.

Традиционная телефония и интернет

Если взять стандартный спектр человеческого голоса и оцифровать его, используя простейший алгоритм импульсно-кодовой модуляции (англ. PCM, https://ru.wikipedia.org/wiki/Импульсно-кодовая_модуляция), то для передачи этой информации потребуется канал с пропускной способностью в 64 Кбит/с. Первые цифровые голосовые каналы обладали именно такой емкостью. Конечно, 64 Кбит/с - это роскошь, и при использовании сегодняшних эффективных кодеков требуемую полосу можно значительно уменьшить. Например, кодек EFR (Enhanced Full Rate, http://ru.wikipedia.org/wiki/GSM-EFR), широко используемый в мобильной связи позволяет «сжать» голос до 12,2 Кбит/с. А один из базовых кодеков для приложений IP-телефонии, G.723.1 (http://ru.wikipedia.org/wiki/G.723.1) и вовсе использует полосу в 5,3 Кбит/с!

В традиционной телефонии каждая сеть, через которую проходит вызов, должна сначала зарезервировать канал, а затем предоставить эту емкость для соединения или разговора, если вызываемый абонент снял трубку. В результате соединение между двумя говорящими имеет гарантированные пропускную способность и другие параметры качества, как например, задержку. Задачей маршрутизации вызова и создания соединения в телефонии занимается система сигнализации ОКС-7 (англ. SS7, https://ru.wikipedia.org/wiki/ОКС-7).

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

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

Интернет коренным образом отличается от телефонных сетей. Топология и связность сетей, как правило, весьма разветвленная и нерегулярная. "Стандартной услуги" как таковой нет - различные приложения имеют различные требования к пропускной способности и качеству сети. Также Интернет является сетью пакетной передачи, где IP-дейтаграммы асинхронно передаются узлами-маршрутизаторами по каналам со значительной вариацией пропускной способности. Это, в свою очередь, выражается в нерегулярности трафика и требует использование буферов для сглаживания «всплесков». Как мы увидим дальше, буферизация и управление очередями пакетов является важным фактором качества связи.

Качественные решения

Фундаментальные технологии и протоколы Интернета, такие как IP, TCP или BGP (http://ru.wikipedia.org/wiki/TCP/IP), были разработаны в соответствии с требованиями пакетной передачи данных, и высокой стойкости в отношении отказа отдельных узлов или целых сетей. Эти технологии обеспечивали простую, но универсальную услугу - передача данных в режиме "best effort", не гарантирующим никаких параметров качества, а иногда даже и того, что пакеты будут доставлены получателю. Сеть не давала предпочтения какому-либо приложению – все пакеты подвергались одинаковой обработке.

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

На первый взгляд услуга best effort казалась довольно ограниченной, особенно во времена раннего Интернета, когда "традиционные" сети гарантировали все - от достоверной доставки, до параметров качества передачи. Однако большинство тогдашних приложений Интернета были весьма «эластичными», а именно малочувствительными к параметрам передачи. Например, обмен файлами с помощью протокола FTP или отображение веб-страницы могли занять секунды, минуты или часы, но фундаментального значения для приложения это не имело.

Другое дело приложения реального времени - голосовая связь и видео-конференции. Они требуют определенных параметров качества, ниже которых эти приложения работать просто не могут. Но для этих приложений существовали свои сети - традиционные телефонные и ISDN (http://ru.wikipedia.org/wiki/ISDN).

Однако дешевизна и растущее распространение Интернета заставило задуматься о возможности его использования также и для «качественных» приложений - видео и голоса. Это, в свою очередь, привело к разработке «качественных» решений.

IntServ или Интеграция служб

В середине 90-х годов прошлого века в IETF (www.ietf.org) была разработана концепция, получившая название Integrated Services, или IntServ (Интегрированные Службы). Как было указано в документе RFC1633 (http://datatracker.ietf.org/doc/rfc1633), описывавшем архитектуру IntServ, «это расширение [архитектуры Интернета] необходимо для удовлетворения растущих потребностей в услуге реального времени для широкого диапазона приложений, включая телеконференции, удаленные семинары и распределенное моделирование». Также IntServ должны были обеспечить возможность мультиплексирования различных классов трафика в сети, что позволило бы операторам предоставлять различные изолированные друг от друга услуги, используя общую сетевую инфраструктуру.

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

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

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

Наконец «эластичные» приложения могут продолжать пользоваться «обычным» Интернетом с его услугой best effort.

Хотя сам подход казался привлекательным, он требовал двух существенных изменений в архитектуре и функционировании Интернета. А именно, обеспечение требования контроля доступа и резервирования.

Действительно, для возможности предоставления гарантий по задержке и пропускной способности, сетевые ресурсы должны быть первоначально зарезервированы по всему пути передачи данных от источника к получателю (и обратно, поскольку большинство потоков являются дуплексными). Этот процесс очень напоминает резервирование канала в телефонии, только вариация параметров этих каналов значительно больше. Это, в свою очередь потребовало внедрения дополнительного сигнального протокола резервирования (такой протокол был разработан - RSVP http://datatracker.ietf.org/doc/rfc2205) и модификации протоколов внутри- и межсетевой маршрутизации.

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

Схематично архитектура IntServ показана на рис. 1.

Рисунок 1. Архитектура IntServ. На схеме представлено резервирование двух каналов с различными параметрами качества: для видеоконференции (зеленый цвет) и голосовой связи (красный цвет).

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

Наконец, технологии IntServ должны были быть внедрены и поддерживаться глобально, во всем Интернете. Чего стоят островки качества в океане услуг «best effort»! Как и в случае многих других глобальных технологий, преимущества от их внедрения становятся ощутимыми только когда они получают значительное распространение – своего рода замкнутый круг, который нелегко разорвать.

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

DiffServ: разделяй и властвуй

Однако идея поддержки качества в глобальной инфраструктуре Интернета была слишком заманчивой, IETF сделал вторую попытку и взялся за разработку другого подхода, целью которого было обеспечение относительного, а не абсолютного, как в случае с IntServ, качества передачи. Другими словами, приложениям реального времени гарантируется определенная емкость, в рамках которой различные потоки конкурируют между собой. Эта архитектура было названа Differentiated Services, или DiffServ.

Вместо резервирования на уровне потока/приложения, в DiffServ контроль производится на уровне достаточно статичных агрегированных «профилей» трафика. Классификация пакетов и принадлежность их к тому или иному профилю определяется по полю IP Type of Service (TOS), исторически оставшемуся в заголовке IP-пакета.

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

Масштабируемость данного подхода безусловно лучше по сравнению с IntServ. Еще важнее, что DifServ не требует динамического резервирования и сохранения состояния для каждого узла сети и каждого потока, проходящего через нее. Однако неразрешимым вопросом остается проблема предоставления определенного качества индивидуальному приложению, включая сигнализацию и гарантии. Трудно представить, что динамические требования многообразных приложений Интернета можно уложить в прокрустово ложе статической конфигурации нескольких профилей.

Рисунок 2. Система DiffServ, позволяющая управлять качеством ограниченного числа «профилей» трафика. На схеме: голосовой трафик, видео и обычный трафик «best effort».

Другими словами, и это решение не вызвало большого энтузиазма среди операторов. Ресурсы и инвестиции, требуемые для внедрения «качественных» решений нашли лучшее применение в увеличении канальной емкости, благо и стоимость этих каналов к концу 90-х прошлого века значительно упала.

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

Скрытые резервы

Колоссальный рост доступной канальной емкости и производительности сетей отодвинул проблему качества на задний план. Приложения реального времени также стали "умнее" и адаптивнее. Но по мере того, как опорные сети освобождались от заторов, узкое горлышко начало появляться ближе к самому пользователю. И проблема оказалась в самом неожиданном месте – в неоправданно больших буферах устройств передачи, собственно и призванных бороться с перегрузками в сети. Феномен этот получил название bufferbloat, или «раздутый буфер».

Bufferbloat

Для того, чтоб понять, в чем же тут дело, необходимо посмотреть, как работает фундаментальный протокол передачи данных в Интернете – транспортный протокол TCP (http://ru.wikipedia.org/wiki/TCP).

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

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

Для этого в TCP используется понятие «окна», определяющего объем данных, которые могут быть переданы без получения подтверждения. Размер окна выбирается из следующих соображений. Для получения подтверждения на переданный пакет потребуется как минимум время для путешествия данных туда и обратно, т.н. round-trip time (RTT). Если пропускная способность канала составляет BW, то объем данных, определяемый произведением RTT*BW полностью заполнит канал в интервале между подтверждениями. В этом случае отправитель будет передавать данные без остановки и канал будет полностью заполнен пакетами. Например, если RTT=100 мс, а скорость передачи 100Мбит/с, то окно будет 10Мбит, означая, что в идеале в момент, когда отправитель передаст последний бит, будет получено подтверждение и передачу можно будет продолжать.

Проблема заключается в том, что в реальности отправитель не знает ни эффективной пропускной способности пути между ним и получателем, ни RTT. Для поиска правильных параметров в TCP существует режим т.н. медленного старта (slow start), когда изначальное окно задается размером в один пакет, а затем экспоненциально растет с получением каждого последующего подтверждения. Это происходит до тех пор, пока обнаруживается потеря пакетов, после чего отправитель уменьшает скорость передачи и переходит в режим «избежания перегрузки» (congestion avoidance).

Если мы взглянем на путь передачи данных между отправителем и получателем, то скорее всего он проходит через несколько физических сетей, каждая со своей канальной емкостью и уровнем загрузки. Очевидно, что эффективная пропускная способность этого пути будет определятся участком с самой низкой пропускной способностью. Для сегодняшнего пользователя таким «узким горлышком» часто является домашний маршрутизатор или кабельный модем, где высокоскоростная беспроводная домашняя сеть (скажем 54Мбит/с) встречается с аплинком сервис-провайдера (например, 2Мбит/с). Из-за разницы в скоростях пакеты, полученные из беспроводной сети, должны ожидать, пока очередной пакет будет передан через 2Мбит/с линк. Для этого и используются буферы памяти. Буферы являются необходимым компонентом любой пакетной сети асинхронной передачи, позволяющим сгладить всплески трафика и улучшить общую производительность сети.

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

Логично предположить, что размер буфера должен быть соизмерим с размером максимального окна TCP – в этом случае буфер сможет удержать все пакеты максимального «всплеска», если таковой произойдет. Рекомендованный размер буфера – RTT*BW, где BW – пропускная способность исходящего канала (поскольку где находится истинное узкое горлышко - неизвестно), а в качестве RTT принято выбирать значение 100 мс – величину задержки трансатлантической передачи.

Удешевление компьютерной памяти и неполное понимание работы очередей привело к тому, что производители оборудования начали щедро начинять свои устройства буферами, иногда даже превышая рекомендованные размеры. И буферы стали частью канальной емкости, которую так хорошо умеет заполнять TCP!

И что же произошло? В случае появления затора буферы довольно быстро наполняются и переполняются, однако сигнал о потере (и, соответственно, о снижении скорости передачи) задерживается, поскольку пакет теперь проводит некоторое время в буфере, прежде чем продолжить свой путь к получателю и, в виде подтверждения, обратно. Для справки, для «отчистки» буфера в 128КБ при 3Мбит/с аплинке (одна из типичных конфигураций в кабельных сетях, см. Рис.3) требуется 340мс, в случае 1Мбит/с аплинка – около 1с.

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

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

Bufferbloat может приводить к существенной деградации производительности сети, особенно для приложений, чувствительных к задержкам: интерактивные приложения, VoIP и видео требуют, чтобы задержка не превышала 50-100мс.

Насколько распространена проблема можно увидеть из данных, полученных с помощью приложения Netalyzr (http://netalyzr.icsi.berkeley.edu/) для более чем 130000 тестов, проведенных пользователями по всему миру. Каждой точке на графике соответствует отдельный тест. В каждом тесте скорость передачи постоянно увеличивалась пока все буферы не оказывались заполненными. Из анализа распределения полученных пакетов исследователи делали вывод о пропускной способности канала (узкого горла) и возможном размере буфера (более подробно, см. “Netalyzr: Illuminating The Edge Network”, http://www.icir.org/christian/publications/2010-imc-netalyzr.pdf) ‎Горизонтальные группы соответствуют наиболее типичным скоростям доступа, а вертикальные группы указывают на типичные размеры буферов. Наконец, диагональные линии показывают дополнительную задержку, порожденную буферизацией.

Рисунок 3. Данные измерений пропускной полосы и возможных размеров буферов, полученные из тестов Netalyzr. Вертикальные группы указывают на типичные размеры буферов в сети. (Источник, блог Jim Gettys, http://gettys.wordpress.com/2012/02/20/diagnosing-bufferbloat/)

Как управлять очередями

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

Более основательное решение лежит в использовании алгоритмов активного управления очередями, или AQM (Active Queue Management). Первый из таких алгоритмов, RED (Random Early Detection, Произвольное Раннее Обнаружение, http://ru.wikipedia.org/wiki/Random_early_detection), был разработан еще 1993 году, когда проблема переполненных буферов впервые встала на повестку дня. Суть алгоритмов семейства RED заключается в постоянном мониторинге динамики уровня заполненности буфера и своевременной сигнализации различным TCP потокам о необходимости снижения скорости путем маркировки или просто отброса пакета. К сожалению, уровень внедрения этих технологий остался невысок ввиду сложности настройки и негативном результате в случае неправильно выбранных параметров (а во многих случаях и ввиду невозможности выбора оптимальных параметров для всех ситуаций).

Контроль задержки: CoDel

Основываясь на опыте RED, Kathie Nichols и Van Jacobson предложили новый алгоритм, в отличие от предшественников не требующих ручной настройки. Алгоритм был назван CoDel от Controlled Delay, или контролируемая задержка, поскольку единственным целевым параметром является не размер очереди или ее статистические параметры, и не утилизация линка или степень отброса пакетов, а минимальная задержка, которой подверглись пакеты в буфере.

Целью алгоритма является поддержание минимальной задержки ниже установленного параметра (5мс). Если за определенный интервал, который изначально равен 100мс, минимальная задержка превышает это значение, последний пакет, покинувший очередь отбрасывается, а интервал уменьшается в соответствии с формулой, отражающей число последовательных отбросов пакетов (более подробно, см. “Controlling Queue Delay”, http://queue.acm.org/detail.cfm?id=2209336). Как только минимальная задержка опять достигает заданного значения, отбрасывание пакетов прекращается и интервал принимает первоначальное значение в 100мс.

Тестирование алгоритма показало хорошие результаты. ColDel позволяет удерживать задержку в районе заданного параметра для широкого спектра скоростей – от 3 до 100 Мбит/с. При этом утилизация канала составляет почти 100%.

Внедрение CoDel только начинается. На настоящее время этот алгоритм доступен для ОС Linux и OpenWrt (https://openwrt.org/). К сожалению, в реальной жизни скорость внедрения соответствует циклу обновления пользовательского оконечного оборудования, который может составлять 4-5 лет, а иногда и больше. Многое из сегодняшнего оконечного оборудования серьезно устарело и не позволяет внедрить новую функциональность путем простого апгрейда программного обеспечения. Так что, хотя рассчитывать на быстрое решение проблемы не приходится, операторы должны иметь эти проблемы в виду и не упустить очередного шанса улучшить качество предоставляемых услуг.

Управление потоками

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

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

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

Такой подход был применен крупным оператором широкополосного доступа в США – Comcast (www.comcast.com). Собственно, новая система была внедрена в ответ на претензии со стороны пользователей и регулятора (Федерального Агентства по Связи США) в отношении старой системы, которая для борьбы с перегрузками в сети осуществляла фильтрацию избыточного P2P трафика, в частности - BitTorrent.

Новая система, внедренная в 2008 году и подробно описанная в RFC6057 (http://datatracker.ietf.org/doc/rfc6057), классифицирует трафик пользователя в зависимости от его вклада в перегрузку в сети (когда такая случается). Работает система следующим образом:

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

Рисунок 4. Упрощенная схема сети широкополосного доступа компании Comcast и системы управления заторами. Источник: http://downloads.comcast.net/docs/Attachment_B_Future_Practices.pdf

ECN и Conex

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

Поэтому встает вопрос – нельзя ли сигнализировать о перегрузке каким-либо другим способом, без потери данных?

Для этого в IETF был разработан другой механизм, получивший название Explicit Congestion Notification (ECN, или «явное уведомление о перегрузке», http://datatracker.ietf.org/doc/rfc3168). ECN основан на маркировке пакетов специальным флагом вместо отбрасывания пакета в режиме перегрузки. Маркировка пакетов происходит на уровне IP путем установки соответствующих битов в IP-заголовке пакета, поскольку перегрузка обслуживается маршрутизаторами именно на этом уровне.

Использование ECN не обязательно. В момент установления TCP-соединения отправитель и получатель могут договориться от его использовании. В этом случае все пакеты отправителя для данного соединения будут содержать бит ECT (ECN Capable Transport) в IP-заголовке. В случае перегрузки в сети для пакетов ECN промежуточные маршрутизаторы вместо отбрасывания пакета могут установить флаг CE (Congestion Encountered).

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

Участники рабочей группы IETF Conex (Congestion Exposure, http://datatracker.ietf.org/wg/conex/charter/) пошли еще дальше, поставив перед собой задачу сделать информацию о сквозной перегрузке всего пути видимой не только отправителю и получателю, но и сетям, через которые этот трафик проходит.

Согласно Conex отправитель данных указывает уровень перегрузки для данного потока по всему пути, основываясь на информации, переданной получателем. Получателем этот уровень определяется на основе полученных пакетов с маркировкой ECN (CE), а также потерянных пакетов. Хотя эта информация относится к недавнему прошлому (поскольку поступает с задержкой в RTT), это все же лучше чем ничего.

Теперь любой маршрутизатор по пути следования трафика может определить не только уровень перегрузки на собственном участке, но и на других отрезках пути, находящихся как вверх, так и вниз по потоку. Для определения перегрузки вверх по потоку маршрутизатору достаточно взглянуть на уровень пакетов с маркировкой CE/ECN, а вычтя это значение из предполагаемой перегрузки для всего пути (как указано отправителем) – получит уровень перегрузки вниз по потоку.

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

Заключение

Хотя качество сеанса связи в Интернете не предсказуемо, можно определенно говорить о его постоянном улучшении. Качество телеконференции Skype не уступает, а подчас и превосходит привычное качество традиционной телефонной связи. Широкое распространение онлайн игр и других интерактивных приложений говорит скорее о колоссальных возможностях Интернета, чем о его ограничениях. И все же отсутствие базовой инфраструктуры, гарантирующей качество, подчас вселяет некоторый дискомфорт.

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

 

Андрей Робачевский

Мнения, представленные в статье, не обязательно отражают официальную позицию Internet Society