Multipath TCP para Linux (2022)

 (mptcp.dev)
1 pontos por GN⁺ 2024-04-21 | 1 comentários | Compartilhar no WhatsApp
  • MPTCP é uma extensão do TCP baseada na RFC 8684, em que uma única conexão usa várias interfaces de rede ao mesmo tempo para melhorar largura de banda, latência e tolerância a falhas
  • Como usa vários caminhos em paralelo, permite agregação de largura de banda, preferência por caminhos de menor latência e reinjeção por outros caminhos em caso de falha
  • No Linux, cria-se um socket com IPPROTO_MPTCP e são formados subflows, que são conexões TCP normais; se o par ou equipamentos intermediários não oferecerem suporte, há fallback automático para TCP de caminho único
  • O gerenciamento de caminhos no Linux, com base na v5.19, pode ser feito pelo modo embutido no kernel ou por daemons em espaço de usuário como o mptcpd; na v6.8, existe apenas um escalonador de pacotes, controlado por sysctl em net.mptcp
  • Na Linux v6.10, os recursos incluem suporte a socket(), fallback para TCP, gerenciamento de caminhos no kernel/em espaço de usuário, opções de socket TCP e recursos de depuração como contadores MIB, diagnósticos via ss e tracepoints

Como o MPTCP muda a forma de estabelecer conexões TCP

  • Multipath TCP (MPTCP) é uma extensão do TCP padrão, definida na RFC 8684
  • Uma única conexão MPTCP pode enviar e receber pacotes TCP usando várias interfaces ao mesmo tempo
  • É possível agregar a largura de banda de várias interfaces ou priorizar a interface com menor latência
  • Se um caminho cair, o tráfego pode ser reinjetado de forma transparente por outro caminho, realizando failover
  • Diferentemente do TCP comum, que usa um único caminho por vez, o MPTCP pode usar vários caminhos como 5G e Wi‑Fi ao mesmo tempo por meio de subflows

Casos de uso representativos

  • Handover sem interrupção

    • É possível trocar de um caminho para outro mantendo a conexão existente
    • A Apple usa o Multipath TCP em smartphones principalmente por esse motivo desde 2013

  • Seleção ideal de rede

    • Escolhe o “melhor” caminho entre os disponíveis com base em latência, perda, custo e largura de banda

  • Agregação de rede

    • É possível aumentar o throughput usando vários caminhos simultaneamente
    • Um exemplo é combinar rede fixa e rede móvel para transferir arquivos mais rapidamente

Como a conexão é estabelecida no Linux

  • Ao criar um novo socket com o protocolo específico do Linux IPPROTO_MPTCP, é criado um subflow ou path
  • Um subflow é uma conexão TCP normal que transmite dados por uma única interface
  • Depois disso, subflows adicionais podem ser criados por meio de negociação entre os hosts
  • No campo de opções TCP do subflow TCP subjacente, são adicionados novos campos para que o host remoto possa detectar o uso de MPTCP
    • Entre eles está a opção MP_CAPABLE, que informa ao par que o MPTCP está em uso
  • Se o host remoto ou um middlebox intermediário não suportar MPTCP, o pacote SYN+ACK retornado não terá opções MPTCP no campo de opções TCP
    • Nesse caso, a conexão faz fallback para TCP comum e continua em caminho único

Gerenciador de caminhos e escalonador de pacotes

  • Internamente, o MPTCP divide entre o Path Manager e o Packet Scheduler as funções de criar subflows, anunciar endereços e escolher caminhos de transmissão

  • Path Manager

    • O Path Manager gerencia os subflows da criação à remoção e também cuida do anúncio de endereços
    • Em geral, o lado cliente inicia os subflows, e o lado servidor anuncia endereços adicionais com as opções ADD_ADDR e REMOVE_ADDR
    • Na Linux v5.19, dois path managers são controlados pelo sysctl net.mptcp.pm_type
      • tipo 0: modo embutido no kernel, que aplica as mesmas regras a todas as conexões; relacionado ao ip mptcp
      • tipo 1: modo em espaço de usuário, controlado por daemons como o mptcpd, permitindo regras diferentes por conexão

  • Packet Scheduler

    • O Packet Scheduler escolhe qual subflow será usado para enviar o próximo pacote de dados
    • Ele pode maximizar a largura de banda disponível, escolher apenas caminhos com menor latência ou aplicar outras políticas conforme a configuração
    • Na Linux v6.8, existe apenas um escalonador de pacotes, controlado por sysctls em net.mptcp

Recursos na Linux v6.10

  • Na Linux v6.10, o MPTCP oferece os seguintes recursos
    • suporte ao protocolo IPPROTO_MPTCP na chamada de sistema socket()
    • fallback de MPTCP para TCP quando o par ou um middlebox não suporta MPTCP
    • gerenciamento de caminhos com path manager embutido no kernel ou em espaço de usuário
    • opções de socket normalmente usadas em sockets TCP
    • contadores MIB, suporte a diag usado pelo comando ss e recursos de depuração incluindo tracepoints
  • Mais detalhes sobre as mudanças podem ser vistos no ChangeLog

Comunicação e projetos relacionados

Recursos para desenvolvimento de kernel

Leituras relacionadas

1 comentários

 
GN⁺ 2024-04-21
Opiniões do Hacker News

  • Já tinha ouvido falar de MPTCP em 2013
    Considerando que, na época, apps móveis não eram muito robustos a mudanças de rede, achei que ele seria adotado rapidamente, pois a melhoria de UX seria grande
    Mas ele quase não ganhou tração nos últimos 10 anos, e é bem deprimente ver que só agora aparece como uma opção do kernel. Nesse meio-tempo, todo mundo envolveu chamadas HTTP em vários tratadores de retry, e os sistemas operacionais móveis abstraíram tanto a conectividade de rede que a sensação ficou mais próxima de usar zeromq do que TCP

    • Parece que muita energia de inovação migrou para o QUIC. Isso porque, no TCP, mesmo que você crie uma nova variante bem-feita, equipamentos intermediários podem quebrá-la arbitrariamente
      Veja o exemplo em https://blog.apnic.net/2021/12/08/efficient-multipath-transp...
    • Eu queria gostar disso, e a Apple também colocou no iOS, mas era difícil demais oferecer suporte em servidores reais
      Quando implantamos no FreeBSD sem load balancer, não havia os patches mais recentes; e, mesmo que houvesse, exigiria bastante trabalho para não anunciar IPs de redes privadas como rotas alternativas
      No Linux, atrás de um load balancer, era complicado demais enviar o stream para o lugar certo, e o load balancer também não queria fazer isso
      Processar dois streams juntos coloca muita complexidade em um caminho de alto throughput, então o risco é grande, e mudanças também exigem reinicialização
      Mesmo fazendo tudo isso, o benefício vai principalmente para usuários de iOS, que, para começo de conversa, tendem a usar redes melhores
    • O SCTP, lançado em 2000, também merece atenção. Ele também quase não foi adotado até hoje
      https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
    • Ao criar robôs de entrega, eu apostei no MPTCP porque queria failover instantâneo com 2 modems celulares
      No fim, para economizar tempo de desenvolvimento, usei o SpeedFusion da PepLink, mas o custo de licença era caro. Espero que no futuro surja uma solução gratuita para usar 2 redes celulares e failover abaixo de 50 ms
      UDP multipath + OpenVPN provavelmente também pode ser uma solução prática
    • O deprimente, na verdade, é isso receber uma atenção que não merece. Em ambientes modernos, o TCP deveria ser substituído pelo SCTP, em vez de receber mais um hack que só se encaixa mais ou menos em metade dos casos de uso e deixar que escolham combinações

  • Não sei o que é mais triste: o espaço de endereços IPv4 ter apenas 32 bits, ou o TCP usar os endereços IP de origem/destino na tupla da conexão
    Se eu tivesse uma máquina do tempo, voltaria até Cerf e Kahn para fazê-los mudar as duas coisas

    • Fiquei curioso sobre o que você quer dizer com mudar o TCP
      Você está falando da estrutura que precisa rastrear a conexão por quatro campos: os endereços IP e portas dos dois lados?
    • Acho que eles diriam que já nos deram source routing, que isso é metade do que você quer e que está corretamente especificado como opção

  • É uma pena não haver links para projetos que usam MPTCP, por exemplo projetos derivados do OpenWrt
    Durante 2 anos, no GSOC, mentorei um estudante que aplicou patches de MPTCP ao OpenWrt
    https://blog.freifunk.net/2017/05/29/gsoc-2017-add-mptcp-sup...

  • Se existe uma rota alternativa transparente, não entendo por que seria necessária uma escolha explícita pela aplicação
    Talvez o kernel devesse tratar isso de forma transparente para todas as conexões TCP, para conseguir tomar melhor decisões globais como agregação de rotas ou preferência de links

    • Entendo que essa foi uma condição praticamente imposta pelos mantenedores do subsistema TCP/rede do Linux. Nas discussões iniciais de upstream[1], isso já aparecia como regra básica
      A implementação antiga de TCP multipath antes do upstream foi pensada para ser totalmente transparente para a aplicação, e acho que isso combina mais com o objetivo do protocolo
      Claro que, em muitos casos, o MPTCP pode ser melhor com instruções da aplicação, mas, por exemplo, só uma abordagem padrão do sistema que criasse um subfluxo na conexão LTE para deixar o failover automático pronto, sem enviar dados por esse subfluxo, já teria sido suficiente em 95% dos casos
      [1] https://lore.kernel.org/all/alpine.OSX.2.21.1707181728570.11...
    • Usar isso significa que vários IPs podem ficar associados a cada extremidade de uma única conexão TCP. Em muitos casos, isso passa a exigir suporte ou consciência explícita da aplicação
    • Permitir que vários IPs se comuniquem sobre a mesma conexão TCP pode criar novas brechas de segurança
      Por exemplo, dá para imaginar uma aplicação que, no momento da conexão, compara o IP do cliente com uma whitelist e depois assume que ele não vai mudar

  • Para mim, o único uso prático do MPTCP é aumentar a velocidade usando a rede móvel e o Wi-Fi juntos. Tanto o iOS quanto o WeChat dão suporte a isso
    Mas a rede móvel é cobrada por uso, então deixo sempre desligada. Por isso, pessoalmente, o MPTCP não me serve

    • Já lidei com esse problema. Internamente, chamávamos de bug do estacionamento
      É a situação em que o sinal de Wi-Fi ainda aparece, mas a conexão não funciona direito. Com MPTCP, há failover para o celular

  • Trabalho dando suporte, depurando e corrigindo a stack de rede e drivers do Linux, e me surpreende que isso tenha sido tão pouco adotado
    Assim como coisas que tentaram substituir o TCP comum, como o SCTP, o MPTCP parece ter ficado como uma tecnologia de nicho que alguns desenvolvedores de aplicações continuam usando, enquanto o resto do mundo esqueceu

    • O Apple Siri usa MPTCP, então, pensando no número de dispositivos, não dá exatamente para chamar só de nicho

  • Encontrei um material que explica as diferenças estruturais entre MPTCP e QUIC e também apresenta o protocolo MPQUIC proposto pelos autores
    O QUIC multiplexa streams de aplicação sobre um único fluxo UDP, e o MPTCP divide um único stream em vários subfluxos TCP. O MPQUIC combina as duas características, multiplexando streams de aplicação sobre vários subfluxos UDP
    [1]: "Multipath QUIC: A Deployable Multipath Transport Protocol" https://www.researchgate.net/publication/327122884_Multipath...
    Agora fico curioso para saber como esses protocolos se comparam em ambientes de produção. Alguém já usou os dois?

    • O MPQUIC ainda está em discussão no IETF. Na última reunião do IETF, mais mudanças também foram discutidas e, infelizmente, isso está deixando a adoção mais lenta
      https://lwn.net/Articles/964377/
      Os dois tentam atingir o mesmo objetivo. Tecnicamente, é possível criar comportamentos muito parecidos. O MPTCP é implementado no kernel Linux, enquanto o QUIC fica no espaço de usuário

  • A Apple também dá suporte e usa no Siri
    https://developer.apple.com/documentation/foundation/urlsess...

    • Também dá para usar em outros apps com bastante facilidade. Está incluído nos recursos básicos
      Em 2011, fiquei surpreso ao ver nosso app de VoIP funcionando de forma bem robusta :D

  • Se qualquer equipamento intermediário não der suporte, o fato de o pacote SYN+ACK retornado não ter a opção MPTCP no campo de opções TCP parece bastante limitante
    O único requisito para os equipamentos intermediários é simplesmente repassar a opção MPTCP sem alterações?

  • Pode ajudar em configurações de segurança e privacidade
    Por exemplo, pensando no Great Firewall da China, se for possível dividir o tráfego por vários canais de uplink, isso não dificultaria para o firewall remontá-lo e aplicar as regras?

    • Se for tráfego desconhecido, basta bloquear ou aplicar um limite de velocidade pesado