Multipath TCP para Linux (2022)

Visão geral do Multipath TCP

• Multipath TCP (MPTCP) é uma extensão do TCP padrão, descrita na RFC 8684
• Permite que um dispositivo use várias interfaces ao mesmo tempo para enviar e receber pacotes TCP por meio de uma única conexão MPTCP
• O MPTCP pode agregar a largura de banda de várias interfaces ou priorizar a interface com a menor latência
• Também permite failover caso um dos caminhos caia, com o tráfego sendo reinjetado suavemente por outros caminhos

Casos de uso do MPTCP

• Ao permitir o uso de vários caminhos em paralelo ou simultaneamente, o MPTCP cria novos casos de uso em comparação com o TCP:
  • Seamless handovers: alternar de um caminho para outro mantendo a conexão. A Apple usa MPTCP principalmente em smartphones por esse motivo desde 2013.
  • Best network selection: usar o caminho "melhor" com base em certas condições, como latência, perda, custo e largura de banda.
  • Network aggregation: usar vários caminhos ao mesmo tempo para obter maior throughput. Ex.: combinar redes fixa e móvel para enviar arquivos mais rapidamente.

Conceitos do MPTCP

• Ao criar um novo socket com o protocolo IPPROTO_MPTCP (exclusivo do Linux), é criado um subfluxo (ou caminho) composto por uma conexão TCP comum, usada para transmitir dados por uma única interface
• Subfluxos adicionais podem ser negociados posteriormente entre os hosts
• Um novo campo é adicionado ao campo de opções TCP do subfluxo TCP principal para que o host remoto possa detectar o uso de MPTCP
• Esse campo inclui opções como MP_CAPABLE, que informa ao outro host para usar MPTCP caso ele tenha suporte
• Se o host remoto ou algum middlebox no caminho não oferecer suporte a MPTCP, o campo de opções TCP do pacote SYN+ACK retornado não incluirá opções MPTCP
• Nesse caso, a conexão é "rebaixada" para TCP comum e continua por um único caminho

Esse comportamento é possível graças a dois componentes internos: Path Manager e Packet Scheduler.

Path Manager

• O Path Manager é responsável pelos subfluxos, desde a criação até a remoção, e também pelo anúncio de endereços
• Em geral, o lado cliente inicia os subfluxos, e o lado servidor anuncia endereços adicionais por meio das opções ADD_ADDR e REMOVE_ADDR
• A partir do Linux v5.19, existem 2 Path Managers controlados pelo parâmetro net.mptcp.pm_type do sysctl:
  • in-kernel (tipo 0): aplica as mesmas regras a todas as conexões (consulte ip mptcp)
  • userspace (tipo 1): controlado por um daemon em espaço de usuário (ex.: mptcpd), permitindo aplicar regras diferentes a cada conexão

Packet Scheduler

• O Packet Scheduler é responsável por escolher, entre os subfluxos disponíveis, qual será usado para enviar o próximo pacote de dados
• Pode maximizar o uso da largura de banda disponível, selecionar apenas o caminho com menor latência ou definir outras políticas conforme a configuração
• A partir do Linux v6.8, existe apenas um Packet Scheduler, controlado por parâmetros net.mptcp do sysctl

Principais características do MPTCP (a partir do Linux v6.10)

• Suporte ao protocolo IPPROTO_MPTCP na chamada de sistema socket()
• Fallback de MPTCP para TCP quando o peer ou um middlebox não oferece suporte a MPTCP
• Gerenciamento de caminhos usando gerenciador de caminhos no kernel ou em espaço de usuário
• Opções de socket normalmente usadas em sockets TCP
• Recursos de depuração, incluindo contadores MIB, suporte a diag (usado no comando ss) e tracepoints

Opinião do GN⁺

• O MPTCP é uma tecnologia muito útil quando o dispositivo está conectado a várias redes. Pode ser usado com eficiência em handover entre 5G e Wi‑Fi ou em agregação de redes heterogêneas.
• No entanto, há a limitação de que tanto o servidor quanto o cliente precisam implementar suporte a MPTCP, e a rede intermediária também precisa oferecer suporte a MPTCP. Parece que ainda levará tempo até se tornar amplamente adotado.
• O protocolo QUIC, do Google, também oferece uma funcionalidade multipath semelhante, e a expectativa é que o QUIC se espalhe mais rapidamente por ser mais simples e baseado em UDP. É provável que haja competição entre MPTCP e QUIC.
• Diferentemente da implementação de MPTCP para Linux, que depende do kernel, a Apple implementa o MPTCP por conta própria em espaço de usuário e o incorpora ao iOS e ao macOS. Parece possível que o Google adote uma abordagem semelhante.
• Para que o controle de caminhos e as políticas de escalonamento do MPTCP sejam otimizados para os requisitos das aplicações, parece necessário haver troca de informações entre a aplicação e o MPTCP por meio de APIs. Pelo que se sabe, ainda não existe uma abordagem padronizada para isso.

[GN⁺]

Comentários no Hacker News

• Quando ouvi falar de MPTCP pela primeira vez em 2013, achei que seria uma grande ajuda para melhorar a experiência do usuário, já que os apps móveis lidavam mal com mudanças de rede, mas é muito decepcionante que, mesmo após 10 anos, quase não tenha recebido atenção
• Não sei o que é mais triste: o espaço de endereços de 32 bits do IPv4 ou o fato de o TCP usar os endereços IP de origem/destino na tupla da conexão. Se eu tivesse uma máquina do tempo, voltaria ao passado para mudar essas duas coisas
• O uso prático do MPTCP é aumentar a velocidade usando ao mesmo tempo redes móveis e Wi-Fi, mas, por causa dos planos de dados móveis, eu pessoalmente mantenho isso sempre desativado, então não me serve para nada
• É uma pena não haver links para projetos que usam MPTCP, como derivados do OpenWrt. Durante 2 anos no GSoC, orientei um estudante que aplicou patches de suporte a MPTCP no OpenWrt
• Se existe fallback transparente, fico me perguntando por que seria necessário um opt-in explícito da aplicação. Parece mais sensato que o kernel lide com isso de forma transparente para todas as conexões TCP, tomando decisões globais sobre agregação de caminhos e preferência de links
• Trabalhando com suporte, depuração e correção da stack de rede e dos drivers no Linux, fico surpreso com a baixa adoção do MPTCP. Parece que, como o SCTP, tudo que tentou substituir o TCP existente está destinado a ser usado apenas por alguns poucos desenvolvedores enquanto o resto do mundo esquece
• Encontrei um artigo que explica as diferenças de arquitetura entre MPTCP e QUIC, além do protocolo MPQUIC proposto pelos autores. O QUIC multiplexa streams da aplicação em um único fluxo UDP, o MPTCP divide um único stream em vários subfluxos TCP, e o MPQUIC combina os dois ao multiplexar streams da aplicação em vários subfluxos UDP
• A Apple também oferece suporte a MPTCP e o usa na Siri
• Parece bastante limitante que, se os middleboxes no caminho não suportarem a opção MPTCP, o pacote SYN+ACK não inclua a opção MPTCP. O único requisito para os middleboxes é apenas encaminhar a opção MPTCP como está?
• O MPTCP pode ajudar em configurações de segurança/privacidade. Por exemplo, se o tráfego for dividido entre vários canais de uplink, fica mais difícil para o firewall do governo chinês recombinar o tráfego para bloqueá-lo