Max Home IndustryПрименяя машинное обучение к алгоритму контроля перегрузки TCP, команда Массачусетского технологического института превзошла аналогичные алгоритмы, разработанные людьми. Но не надейтесь понять, как это работает.
TCP — это протокол, который находится поверх базовой сети с коммутацией пакетов, чтобы гарантировать прохождение ваших данных. Сеть с коммутацией пакетов просто действует как транспорт для фрагментов данных, без гарантии того, что фрагменты действительно прибудут, или, если они действительно прибудут, что они находятся в том же порядке, в котором они были переданы.
Если вы хотите использовать быстрый, но ненадежный метод передачи данных, вы можете использовать UDP, но большинство подключений через Интернет используют TCP. Что делает TCP, так это вводит квитирование для установления и разрыва соединений. Пакеты отправляются между источником и получателем с номерами, указывающими порядок, в котором они должны быть повторно собраны, и каждый пакет должен быть подтвержден.
Это более сложный протокол, чем вы можете себе представить. Например, как долго вы ждете подтверждения, прежде чем решите отправить пакет снова? Более тонкая проблема — это перегрузка. Если вы спроектируете алгоритм TCP так, чтобы он работал как можно более агрессивно, т.е. отправлял и повторно отправлял данные как можно быстрее, то результатом могло бы быть наилучшее возможное соединение для вас, но остальные пользователи будут иметь тенденцию страдать от снижения пропускной способности и увеличенные задержки, потому что вы перегружаете полосу пропускания. Фактически, вы, вероятно, могли бы получить такое же хорошее соединение, снизив скорость отправки данных, чтобы лучше соответствовать доступной пропускной способности.
Это проблема контроля перегрузки TCP, и это настолько сложная проблема, что она все еще является предметом постоянных исследований. Большинство стеков TCP используют один из двух алгоритмов предотвращения перегрузки Compound TCP (Windows) или Cubic TCP (Linux), и этим методам всего около десяти лет. Очевидно, что есть еще возможности для улучшения, но готовы ли мы к улучшениям, разработанным с помощью компьютера?
Команда MIT использовала машинное обучение, чтобы найти лучшую политику для децентрализованного частично наблюдаемого марковского процесса. По сути, политика сводится к тому, что каждый агент либо отправляет, либо воздерживается от отправки на основе набора наблюдаемых, а политика пытается максимизировать пропускную способность и минимизировать задержки по всей сети, то есть для всех агентов.
В результате появился Remy — компьютерный алгоритм управления перегрузками — и, похоже, он работает. Если вы сравните его с существующими алгоритмами, то станет ясно, что он работает намного лучше — действительно, он занимает отдельную часть графика производительности по сравнению с другими.
Настоящая проблема этого подхода знакома в том смысле, что многие подходы ИИ страдают от проблемы «понятности» или «объяснимости». Нейронная сеть могла бы распознать кошку, но мы не совсем понимаем, с технической точки зрения, как она это делает. У экспертных систем была аналогичная проблема, заключающаяся в том, что они приходили к заключению или диагнозу, но без какого-либо обнадеживающего объяснения того, почему был сделан вывод.
Как комментирует исследовательская группа:
«Хотя кажется, что RemyCC хорошо работают в сетях, параметры которых находятся в пределах или близких к тем, к которым они были подготовлены — даже превосходя внутрисетевые схемы в своей собственной игре, и даже когда диапазон проектирования охватывает изменение параметров сети на порядок величины — мы еще не ясно понимаем, почему они работают, кроме наблюдения, что они, кажется, хорошо оптимизируют свою намеченную цель.
Мы безуспешно пытались создать алгоритмы, превосходящие созданные RemyCC. Это наводит на мысль, что Реми, возможно, добился чего-то существенного. Но разобраться в десятках правил RemyCC и выяснить их цель и функции — сложная задача в области обратного проектирования. RemyCCs, разработанные для более широких классов сетей, вероятно, будут еще более сложными, что усугубит проблему ».
Так готовы ли сетевые инженеры доверять алгоритму, который, кажется, работает, но не имеет объяснения, почему он работает, кроме оптимизации конкретной целевой функции? По мере того, как ИИ становится все более успешным, этот вопрос можно было бы задавать в более широком контексте.