• Лаборатория SPEAR создаёт реальные системы и проводит измерения, чтобы устранить пробелы в производительности периферийных вычислений и современных интернет-протоколов.
  • Спутниковые сети LEO страдают от плохой дистрибуции контента при отсутствии локальной наземной инфраструктуры и скоординированной интеграции DNS/CDN.
  • Интернет-измерения показывают, что реальное внедрение таких протоколов, как Multipath TCP, остаётся ограниченным из-за несовместимости промежуточных устройств (middleboxes).

В то время как периферийные вычисления и спутниковая связь переопределяют интернет, такие исследователи, какDr Nitinder Mohan, переосмысляют производительность сетей в реальном мире. Dr Mohan — доцент кафедры электротехники, математики и информатикиДелфтского технического университета. Он возглавляет лабораторию Systems and Protocols for Edge-Enabled Internet (SPEAR), где его исследования посвящены периферийным вычислениям, сетевым протоколам следующего поколения, интернет-измерениям в масштабе сети, а также развёртыванию и управлению критически важными приложениями. Обладая опытом в академических и прикладных системных исследованиях, работы Dr Mohan устраняют разрыв между университетской наукой и операционными реалиями современного и будущего интернета.

Интервью с Dr Nitinder Mohan

Q1. Будучи руководителем лаборатории SPEAR, не могли бы вы кратко представить её основные направления, особенно в области периферийных вычислений? Какой вы считаете самой большой текущей проблемой?

Mohan:Я возглавляю лабораторию Systems and Protocols for Edge-Enabled Internet, или лабораторию SPEAR. Хотя сама лаборатория относительно новая, исследования, лежащие в её основе, ведутся с момента завершения моей докторской диссертации. Наши работы находятся на стыке систем периферийных вычислений и крупномасштабных интернет-измерений.

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

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

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

Это изменение создаёт очевидную проблему. Растёт разрыв между требованиями современных приложений и возможностями текущей сетевой инфраструктуры. В лаборатории SPEAR мы решаем эту проблему, создавая реальные системы, поддерживающие периферийные вычисления, с особым акцентом на оркестрацию. Параллельно мы проводим интернет-измерения, чтобы лучше понять поведение сети на практике. Мы изучаем производительность транспортных протоколов, интернет-провайдеров и приложений в больших масштабах.

По сути, это цикл: мы создаём системы, измеряем их производительность, а затем улучшаем их на основе полученных знаний.

Dr Nitinder Mohan, доцент Делфтского технического университета

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

Читайте также:Периферийные вычисления и облачные вычисления: в чём разница?

Читайте также:Deutsche Telekom создаёт подразделение суверенного облака

Q2. Вы упомянули, что традиционные протоколы, такие как TCP, сталкиваются с трудностями в современных средах. В контексте спутниковых сетей LEO, какие разрывы в производительности вы считаете наиболее критичными?

Mohan:Прежде чем перейти к проблемам, связанным с протоколом управления передачей (TCP), полезно сначала объяснить, как на самом деле работает интернет через спутники LEO. Существует распространённое представление, что такие сети полностью функционируют в космосе, обеспечивая лучшую связь просто за счёт обхода традиционной наземной инфраструктуры. Идея в том, что после развёртывания спутников на орбите Земли пользователи больше не зависят от локальных базовых станций или инфраструктуры, финансируемой правительствами. Если спутниковое покрытие достаточно плотное, люди предполагают, что смогут получить доступ в интернет откуда угодно.

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

Такая архитектура означает, что если у спутникового оператора недостаточно наземных станций или равномерно распределённых точек присутствия, общая производительность сети будет низкой. Мы наблюдали это в начале расширенияStarlink. Даже несмотря на запуск большого количества спутников, пользователи в таких регионах, как Африка и Азия, продолжали сталкиваться с плохой связью. Основной причиной было отсутствие локальной наземной инфраструктуры. Чтобы исправить это, Starlink пришлось вложить значительные средства в получение лицензий, развёртывание новых наземных станций и заключение соглашений о пиринге в этих регионах для снижения задержки и повышения общей производительности.

Читайте также:Starlink получил предупреждение от австралийского регулятора

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

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

Например, если посмотреть на производительность Starlink в таких регионах, как США или Европа, можно увидеть задержку порядка 30–40 миллисекунд. Но в регионах, где наземная инфраструктура ещё развивается, например в некоторых частях Африки, задержка может быть гораздо более нерегулярной. Это во многом связано с ограниченной пропускной способностью наземных станций и необходимостью частого переключения между спутниками во время передачи.

Существующие транспортные протоколы и протоколы маршрутизации просто плохо работают в спутниковых сетях LEO.

Dr Nitinder Mohan, доцент Делфтского технического университета

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

Читайте также:Skynopy привлекает 16 миллионов долларов для сети спутниковых наземных станций

Q3. Каковы первые выводы или многообещающие направления ваших исследований по интеграции спутниковых сетей LEO с существующими интернет-операциями?

Mohan:Одна из вещей, которую мы наблюдали, — это разрыв между тем, как операторы спутниковых сетей LEO представляют производительность своей сети, и тем, как это на самом деле влияет на сквозной пользовательский опыт. Большинство операторов склонны показывать показатели задержки только до ближайшей точки присутствия. Например, на сайте Starlink вы увидите красиво оформленные карты с задержками около 30 миллисекунд в разных странах. На первый взгляд кажется, что сеть работает хорошо.

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

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

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

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

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

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

Dr Nitinder Mohan, доцент Делфтского технического университета

Чтобы решить эту проблему, нам нужна лучшая интеграция между спутниковыми и наземными системами. Это предполагает более широкое открытие наземной инфраструктуры — такой как узлы CDN и ресурсы периферийных вычислений — для операторов спутниковых сетей LEO. Благодаря лучшей координации мы сможем создавать более точные сопоставления между пользователями, контентом и вычислительными сервисами, что поможет обеспечить более быстрый и стабильный опыт в разных географических регионах.

Читайте также:Intelsat видит будущее в интеграции спутниковых и наземных систем

Q4. Вы также занимаетесь крупномасштабными интернет-измерениями. Ваши результаты уже противоречили распространённым предположениям о поведении интернета или его протоколов на практике?

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

Яркий пример — наши первые работы по периферийным вычислениям, которые в итоге были опубликованы наHotNets 2020. В то время много говорили о том, как периферийные вычисления снизят задержку. Многие считали, что размещение вычислений ближе к пользователю автоматически приведёт к гораздо более быстрому времени отклика. Чтобы проверить это, мы провели крупномасштабные измерения у семи крупных облачных провайдеров. Мы нанесли на карту соединения пользователей по всему миру — через сотовые сети, Wi-Fi и оптоволокно — до их ближайших центров обработки данных. Идея заключалась в том, чтобы увидеть, какую задержку испытывают пользователи и приведёт ли приближение вычислений к значительным изменениям.

Мы обнаружили, что большая часть задержки приходится на сеть доступа, такую как сотовое или Wi-Fi-соединение пользователя. Как только трафик достигает магистрали, задержка до облачных центров обработки данных уже довольно низкая. В таких регионах, как Европа и США, облачные провайдеры напрямую взаимодействуют с крупными интернет-провайдерами, поэтому возможностей для улучшения не так много. Если ваша цель в периферийных вычислениях — исключительно снижение задержки, это, вероятно, не та причина. Вместо этого периферийные вычисления лучше подходят для повышения производительности приложений или построения распределённых систем.

Это понимание сейчас получило более широкое признание.

Ещё один пример — наша работа над Multipath TCP, протоколом, который позволяет устройствам одновременно использовать Wi-Fi и мобильные данные. Он был стандартизирован в 2020 году, но мы обнаружили, что его внедрение было очень ограниченным. Многие промежуточные устройства (middleboxes) в интернете не распознают заголовки протокола и блокируют соединения или отвечают некорректно. Некоторые даже отправляют поддельные подтверждения, что может создавать риски для безопасности. На практике его использовало лишь небольшое число провайдеров, и основная часть внедрения приходилась наApple. После того как Apple отказалась от него, использование сократилось. Мы открыли все наши данные измерений наmptcp.io, чтобы люди могли видеть, как менялось внедрение. Это показывает, что одной стандартизации недостаточно. Протокол также должен быть совместим со всем интернетом, чтобы его можно было использовать на практике.