Entrevista com Dr. Nitinder Mohan: Edge, satélites e a realidade por trás do desempenho da Internet

Entrevista com Dr. Nitinder Mohan: Edge, satélites e a realidade por trás do desempenho da Internet é perfilada pela BTW Media porque evidências publicadas a vinculam à infraestrutura de internet, governança, dependências operacionais ou visibilidade de mercado.

• O SPEAR Lab constrói sistemas reais e realiza medições para resolver lacunas de desempenho em edge computing e protocolos de internet modernos.
• Redes de satélites LEO sofrem com entrega de conteúdo ruim quando falta infraestrutura terrestre local e coordenação integrada de DNS/CDN.
• Medições de internet revelam que a implantação real de protocolos como Multipath TCP permanece limitada devido à incompatibilidade com middleboxes.

À medida que a edge computing e a conectividade por satélite remodelam a Internet, pesquisadores comoDr. Nitinder Mohanestão repensando como as redes funcionam no mundo real. Dr. Mohan é professor assistente noDepartamento de Engenharia Elétrica, Matemática e Ciência da ComputaçãodaUniversidade de Tecnologia de Delft. Ele lidera o laboratório Systems and Protocols for Edge-Enabled Internet (SPEAR), onde sua pesquisa se concentra em edge computing, protocolos de rede de próxima geração, medições em toda a Internet e implantação e gerenciamento de aplicações críticas. Com experiência em pesquisa de sistemas acadêmicos e aplicados, o trabalho do Dr. Mohan preenche a lacuna entre a pesquisa acadêmica e as realidades operacionais da Internet de hoje e de amanhã.

Q1. Ao liderar o laboratório SPEAR, você poderia apresentar brevemente suas principais áreas de foco, especialmente em edge computing? Qual você diria que é o maior desafio atualmente?

Mohan:Eu lidero o laboratório Systems and Protocols for Edge-Enabled Internet, ou laboratório SPEAR. Embora o laboratório em si seja relativamente novo, a pesquisa por trás dele está em andamento desde que concluí meu doutorado. Nosso trabalho se situa na interseção entre sistemas de edge computing e medições de Internet em larga escala.

A motivação central do laboratório é entender e abordar como a computação em nuvem tradicional e as tecnologias de Internet estão começando a convergir. Embora essa convergência esteja acontecendo em conceito, ainda observamos uma divisão clara entre as comunidades que trabalham com sistemas de nuvem e aquelas focadas na infraestrutura da Internet. Essa lacuna se torna mais aparente à medida que vemos os recursos de computação se aproximando dos usuários finais. Nos últimos anos, os servidores de computação não estão mais localizados apenas em Data Centers distantes.

Cada vez mais, eles estão sendo implantados dentro das redes dos ISPs, bem na borda.

Ao mesmo tempo, a própria Internet está evoluindo. Ela não é mais simplesmente uma ferramenta para conectar usuários a servidores remotos. Agora inclui elementos intermediários, como middleboxes, que podem realizar computações enquanto os dados ainda estão em trânsito. Essa evolução se torna especialmente importante quando pensamos em novas aplicações como jogos em nuvem, realidade aumentada e realidade virtual. Essas aplicações exigem latência extremamente baixa e não podem mais depender de modelos tradicionais onde todo o processamento acontece em um local central.

Em vez disso, exigem que a computação aconteça muito mais próxima do usuário, possivelmente até mesmo ao longo do caminho da rede.

Essa mudança cria um desafio claro. Há uma incompatibilidade crescente entre as demandas das aplicações modernas e as capacidades da infraestrutura de rede atual. No laboratório SPEAR, abordamos isso construindo sistemas reais que suportam edge computing, com foco particular em orquestração. Além disso, realizamos medições em toda a Internet para entender melhor como a rede se comporta na prática. Estudamos o desempenho de protocolos de transporte, desempenho de ISPs e desempenho de aplicações em escala.

É essencialmente um ciclo — construímos sistemas, medimos seu desempenho e depois melhoramos esses sistemas com base no que aprendemos.

Dr. Nitinder Mohan, professor assistente na Universidade de Tecnologia de Delft

Usamos as descobertas dessas medições para melhorar os sistemas que projetamos. É um ciclo contínuo. Construímos sistemas, observamos como eles funcionam em toda a Internet e usamos essas percepções para torná-los mais eficazes em ambientes reais.

Leia também:Edge computing vs. cloud computing: qual é a diferença?

Leia também:Deutsche Telekom cria unidade de nuvem soberana

Q2. Você mencionou que protocolos tradicionais como TCP estão enfrentando dificuldades em ambientes modernos. No contexto de redes de satélites LEO, quais você diria que são as lacunas de desempenho mais críticas?

Mohan:Antes de entrarmos nos desafios com o Transmission Control Protocol (TCP), é útil explicar primeiro como a Internet via satélite LEO realmente funciona. Há uma percepção comum de que essas redes operam inteiramente no espaço, oferecendo melhor conectividade simplesmente ignorando a infraestrutura terrestre tradicional. A ideia é que, uma vez que os satélites são implantados e orbitam a Terra, os usuários não dependem mais de estações base locais ou infraestrutura financiada pelo governo. Se a cobertura do satélite for densa o suficiente, as pessoas supõem que deveriam poder ter acesso à Internet em qualquer lugar.

No entanto, nossas medições e análises mais aprofundadas mostram que essa suposição não é precisa. Na realidade, as redes de satélite LEO ainda são muito dependentes do solo. Os satélites essencialmente funcionam como estações base móveis. Em vez de se conectar a uma torre tradicional, seu dispositivo se conecta a um satélite, que então passa os dados de volta para a Terra por meio de estações terrestres. De lá, o tráfego viaja para um Ponto de Presença antes de chegar à Internet mais ampla.

Essa arquitetura significa que, se um operador de satélite não tiver estações terrestres suficientes ou Pontos de Presença bem distribuídos, o desempenho geral da rede será ruim. Observamos isso nos estágios iniciais da expansão daStarlink. Embora eles tivessem lançado um grande número de satélites, usuários em regiões como África e Ásia ainda experimentavam conectividade ruim. A principal razão era a falta de infraestrutura terrestre local. Para melhorar isso, a Starlink teve que investir significativamente na obtenção de licenças, implantação de novas estações terrestres e construção de acordos de peering nessas regiões para reduzir a latência e melhorar o desempenho geral.

Leia também:Starlink recebe alerta do órgão regulador australiano

Agora estamos vendo mais operadores LEO entrando no espaço. Empresas comoOneWebeKuipertambém estão se preparando para lançar muitos satélites. À medida que crescem, esperamos ver uma ampla gama de abordagens e resultados de desempenho diferentes. Enquanto as redes terrestres continuam a oferecer conectividade móvel e baseada em fibra, as redes de satélite estão sendo posicionadas como uma opção mais acessível ou resiliente em áreas remotas ou mal atendidas. Nos bastidores, porém, ambos os sistemas dependem de infraestrutura de backhaul semelhante.

A forma como operam, no entanto, é bastante diferente. Os links de satélite têm suas próprias características. Eles envolvem handovers mais frequentes, latência variável e padrões de taxa de transferência diferentes em comparação com as redes tradicionais. Essa variabilidade torna difícil para protocolos como TCP funcionarem bem, porque o TCP foi originalmente projetado para conexões estáveis ​​e previsíveis.

Por exemplo, se você observar o desempenho da Starlink em regiões como Estados Unidos ou Europa, poderá ver latências na faixa de 30 a 40 milissegundos. Mas em regiões onde a infraestrutura terrestre ainda está sendo desenvolvida, como partes da África, a latência pode ser muito mais inconsistente. Isso se deve em grande parte à capacidade limitada das estações terrestres e à necessidade de alternar frequentemente entre satélites durante a transmissão.

Os protocolos de transporte e roteamento existentes simplesmente não funcionam bem em redes de satélites LEO.

Dr. Nitinder Mohan, professor assistente na Universidade de Tecnologia de Delft

Os protocolos tradicionais de transporte e roteamento não se adaptam bem a essas condições. Como resultado, o desempenho sofre. Para superar isso, precisamos de melhores métodos de integração das redes terrestres e de satélite. Somente permitindo que esses sistemas cooperem de forma mais eficaz podemos construir uma rede que ofereça desempenho consistente em diferentes regiões e casos de uso.

Leia também:Skynopy capta US$ 16 milhões para rede de estações terrestres de satélite

Q3. Quais são algumas descobertas iniciais ou direções promissoras de sua pesquisa sobre a integração de redes de satélites LEO com as operações existentes da Internet?

Mohan:Uma coisa que observamos é que há uma desconexão entre como os operadores de satélite LEO apresentam o desempenho de sua rede e como isso realmente afeta a experiência do usuário de ponta a ponta. A maioria dos operadores tende a mostrar números de latência apenas até o Ponto de Presença mais próximo. Por exemplo, no site da Starlink, você vê mapas bem ilustrados mostrando latências de cerca de 30 milissegundos em vários países. À primeira vista, parece que a rede está funcionando bem.

No entanto, esses números refletem apenas o tempo necessário para chegar ao Ponto de Presença, não o destino real do tráfego do usuário. Na prática, o caminho completo até o servidor de aplicação pode ser muito mais longo e complexo. Isso é algo que estudamos de perto no laboratório SPEAR, onde estamos interessados ​​em entender como otimizar o desempenho de aplicações de ponta a ponta, não apenas o primeiro salto.

Veja a entrega de conteúdo como exemplo. Imagine um usuário na Nigéria usando uma conexão de satélite LEO. Se o operador não investiu em infraestrutura terrestre nessa região, o tráfego do usuário pode ser roteado por meio de links entre satélites até a estação terrestre disponível mais próxima, que pode estar na Europa. De lá, sai da rede de satélite em uma cidade como Frankfurt. Mas se o conteúdo solicitado estiver hospedado localmente na Nigéria, o tráfego então viaja de volta pelas redes terrestres para chegar ao servidor local.

Uma vez que o conteúdo é buscado, ele percorre a mesma rota ineficiente no sentido inverso – de volta para Frankfurt e, em seguida, pelo link de satélite até o usuário.

Esse processo adiciona atrasos desnecessários e cria uma experiência ruim para o usuário. Também destaca um problema mais profundo. Nossa infraestrutura atual de Internet é baseada em suposições sobre proximidade geográfica e roteamento que não se aplicam mais em contextos baseados em satélite. Sistemas como resolução de DNS e redes de entrega de conteúdo são construídos para ambientes terrestres, onde é relativamente simples determinar onde um usuário está localizado e entregar o conteúdo de acordo.

As redes LEO interrompem esse modelo. O tráfego de um usuário pode parecer originar-se de uma região completamente diferente, dependendo de onde o satélite se conecta ao solo. Isso torna difícil entregar conteúdo de forma eficiente ou posicionar serviços de computação adequadamente.

À medida que a localização do usuário se torna menos previsível, entregar desempenho consistente requer uma integração mais estreita entre a infraestrutura espacial e terrestre.

Dr. Nitinder Mohan, professor assistente na Universidade de Tecnologia de Delft

Para resolver isso, precisamos de uma melhor integração entre os sistemas de satélite e terrestres. Isso inclui expor mais a infraestrutura terrestre – como nós de CDN e recursos de edge computing – aos operadores de satélite LEO. Com melhor coordenação, podemos criar mapeamentos mais precisos entre usuários, conteúdo e serviços de computação, o que ajudará a oferecer experiências mais rápidas e consistentes em diferentes geografias.

Leia também:Intelsat vê futuro na integração satélite-terrestre

Q4. Você também trabalha com medições de Internet em larga escala. Seus resultados já contradisseram suposições comuns sobre como a Internet ou seus protocolos se comportam na prática?

Mohan:Sim, e essa é uma das principais motivações por trás do nosso trabalho de medição. Existem muitas suposições sobre como os protocolos ou tecnologias da Internet deveriam se comportar, mas quando testamos essas suposições em escala, a realidade muitas vezes acaba sendo bem diferente.

Um exemplo claro veio do nosso trabalho inicial sobre edge computing, que acabou sendo publicado naHotNets 2020. Na época, falava-se muito sobre como a edge computing reduziria a latência. Muitos acreditavam que colocar a computação mais próxima do usuário levaria automaticamente a tempos de resposta muito mais rápidos. Para testar isso, realizamos medições em larga escala em sete grandes provedores de nuvem. Mapeamos as conexões de usuários de todo o mundo, em redes celulares, Wi-Fi e fibra, até seus Data Centers mais próximos. A ideia era ver que tipo de latência os usuários estavam experimentando e se colocar a computação mais perto faria uma diferença significativa.

O que descobrimos foi que a maior parte da latência vinha da rede de acesso, como a conexão celular ou Wi-Fi do usuário. Uma vez que o tráfego chegava ao backhaul, a latência para os Data Centers em nuvem já era bastante baixa. Em lugares como Europa e Estados Unidos, os provedores de nuvem fazem peering diretamente com grandes ISPs, então não há muito espaço para melhorias. Se o seu objetivo com a edge computing é apenas reduzir a latência, provavelmente não é a razão certa. Em vez disso, a edge computing é mais adequada para melhorar o desempenho de aplicações ou construir sistemas distribuídos.

Esse entendimento tornou-se mais amplamente aceito agora.

Outro exemplo é o nosso trabalho sobre Multipath TCP, um protocolo que permite que dispositivos usem Wi-Fi e dados móveis ao mesmo tempo. Ele foi padronizado em 2020, mas descobrimos que sua adoção era muito limitada. Muitos middleboxes na Internet não reconhecem os cabeçalhos do protocolo e bloqueiam as conexões ou respondem incorretamente. Alguns até enviam confirmações falsas, o que pode criar riscos de segurança. Na prática, apenas um pequeno número de provedores estava usando-o, e a maior parte da implantação veio daApple. Como a Apple se afastou dele, o uso diminuiu. Disponibilizamos todos os nossos dados de medição em código aberto emmptcp.iopara que as pessoas possam ver como a adoção mudou. Isso mostra que a padronização não é suficiente. Um protocolo também precisa de compatibilidade em toda a Internet para ser utilizável na prática.