Практически в любой сети возможен сценарий, когда система распределения трафика оказывается неэффективна. По крайней мере, так утверждают инженеры из MIT. Разбираемся, в чем заключается проблема и насколько она реальна.
Первая перегрузка
На заре сетевой эпохи никто не занимался вопросами QoS. В этом не было смысла, так как соединения были прокинуты между институтами и государственными организациями с небольшим количеством пользователей. Однако ситуация изменилась во второй половине 1980-х, когда в ARPAnet произошел первый сетевой коллапс. Тогда скорость подключения между Национальной лабораторией имени Лоуренса и Калифорнийским университетом в Беркли упала в тысячу раз — с 32 Кбит/с до 40 бит/с. Часть пользователей заняла практически весь сетевой канал, резко сократив доступные ресурсы.
Этот инцидент подтолкнул сообщество в сторону механизмов контроля перегрузки сетей. Сегодня в качестве маркеров перегрузки классические алгоритмы типа Reno и CUBIC используют частоту потерь пакетов. Так, если большое их количество не доходит до получателей, скорость передачи сокращается. Более продвинутые решения вроде BBR применяют методы моделирования каналов связи и строят прогнозы на основе показателей RTT. Но даже современные подходы не способны решить проблему на 100%, хотя и подбираются к этой планке очень близко. Инженеры из MIT считают, что причина кроется в изменчивой природе задержек.
Без серебряной пули
Специалисты Массачусетского технологического института утверждают, что алгоритмы BBR и PCC не исключают вероятность «сетевого голода». Это состояние, когда один или несколько клиентов не получают ресурсы из-за чрезмерной загруженности сети.
По словам исследователей, причиной такого поведения являются джиттеры в сети. Это — задержки, которые не связаны с переполнением канала и вызванные проблемами на физическом уровне. На их фоне доставка пакетов может неожиданно замедляться на десятки миллисекунд и непредсказуемо влиять на поведение сети. Существующие алгоритмы не в состоянии дифференцировать джиттеры, что приводит к ошибкам при управлении трафиком, как следствие, — «сетевому голоду».
В своих экспериментах исследователи использовали следующую сетевую модель:
Два потока имели общую FIFO-очередь. Пакеты покидали её с постоянной частотой C бит/с и постоянным значением RTT — Rm. Затем они проходили через компонент, имитирующий задержку, не связанную с переполнением каналов. Этот компонент «тормозил» пакеты на [0, D] секунд, не изменяя их последовательность.
Просто больше скорости
Исследование специалистов из MIT привлекло внимание резидентов Hacker News. И некоторые пользователи площадки высказали мнение, что для решения проблем перегрузки каналов достаточно повысить пропускную способность. Такой подход должен помочь сгладить углы и недостатки алгоритмов контроля трафика.
Хотя и здесь не все так однозначно. В США пользователи даже с самым быстрым интернетом сталкиваются с проблемами при просмотре стримов и другого тяжеловесного контента. При этом они могут задействовать порядка 2–5% всей доступной пропускной способности.
Даже если учитывать, что текущие инструменты контроля трафика неидеальны, это не значит, что интернет-провайдерам можно от них отказаться и направить усилия на повышение пропускной способности. Ограничения, с которыми сталкиваются современные алгоритмы контроля трафика, неэффективны только в специфических сценариях. QoS-решения позволяют телекомам управлять пропускной способностью полосы для абонентов. В итоге клиенты получают высокую скорость загрузки и минимально возможную задержку.
В любос случае исследователи из MIT считают, что в перспективе будут разработаны новые алгоритмы, построенные на методах математического моделирования. Они позволят избежать сетевой перегрузки. Но если такие решения появятся, задача их внедрения тоже будет сложной.
Чтение по теме из корпоративного блога VAS Experts:
Комментарии (2)
Sadok
09.04.2023 09:20не очень понятно, что открыли инженеры MIT. что у дяди Васи есть экскаватор и он может внезапно копнуть так, что вся "физика" улетит к чертям?
saege5b
Если один клиент может выкушать 5% ресурса, как ни крутись, а 20 подобных клиентов скушают весь ресурс.
Тут или резко поднимать производительность, или ограничивать аппетиты клиентов.