Resumo

  • Depois do fallback por mapeamento infinito, a mesma conexão não pode voltar a operar como MPTCP, mesmo que a rede melhore.
  • Buscar novamente a capacidade multipercurso exige outra conexão, sem garantia de negociação bem-sucedida ou de repetição segura do trabalho da aplicação.

Manter uma sessão aberta costuma ser tratado como sinal de recuperação. Há, porém, um caso no MPTCP em que a sessão de transporte continua justamente porque deixou para trás uma capacidade importante. O fluxo pode seguir como TCP convencional, mas a conexão que fez essa transição não pode recuperar o MPTCP durante o restante de sua vida.

A restrição aparece no procedimento de fallback por mapeamento infinito da RFC 8684. Não se trata de uma proibição permanente para o equipamento. O host pode estabelecer outras conexões. O que não pode acontecer é a conexão já convertida voltar ao MPTCP apenas porque uma interface melhorou, um endereço adicional reapareceu ou o tráfego voltou a apresentar um comportamento confortável.

Isso cria uma separação operacional que um indicador de disponibilidade pode esconder. Preservar o trabalho em andamento e restaurar a capacidade de usar múltiplos caminhos deixam de ser a mesma ação. A primeira pode ter funcionado; a segunda exige decidir quando abrir outra conexão e o que fazer com a atividade ainda dependente da anterior.

O que muda no compromisso de entrega

MPTCP oferece um fluxo ordenado de bytes usando subfluxos TCP. Cada subfluxo tem seu próprio espaço de sequência. O sinal DSS informa como esses números se relacionam com a sequência de dados da conexão inteira. Essa correspondência permite organizar os dados recebidos sem tomar a ordem de um subfluxo pela ordem do conjunto.

A confirmação também ocorre em níveis distintos. Durante a operação normal de MPTCP, o emissor não pode liberar dados do buffer somente porque recebeu um ACK de um subfluxo. É necessário o reconhecimento no nível da conexão e em todos os subfluxos pelos quais aqueles dados foram enviados. Um receptor pode reconhecer o segmento TCP e, depois, descartar dados que estavam retidos para a conexão, por exemplo diante de pressão de memória.

O mapeamento infinito altera esse regime. Ele utiliza o valor reservado zero no comprimento de dados para estabelecer um mapeamento válido pelo restante da conexão. Depois do fallback, o emissor usa apenas os ACKs do subfluxo para limpar o buffer; o receptor deveria deixar de enviar Data ACKs do MPTCP. A comunicação passa a seguir as regras de TCP convencional.

Portanto, a mudança não é apenas uma decisão temporária do escalonador de usar um caminho. Muda a regra pela qual o emissor pode deixar de guardar os dados. Essa fronteira está descrita nas seções 3.3 e 3.7 da RFC 8684. Nenhum desses reconhecimentos, contudo, equivale à confirmação de conclusão de uma operação de negócio.

O erro de checksum não tem uma única consequência

O desenho leva em conta equipamentos intermediários que removem opções ou modificam a carga útil. Essas intervenções podem romper a correspondência entre a sequência do subfluxo e a sequência da conexão. Quando negociado, o checksum permite detectar problemas relevantes. Ele não é autenticação criptográfica nem demonstra intenção maliciosa.

Se houver vários subfluxos, uma falha de checksum pode ser tratada pelo fechamento do subfluxo afetado e pela retransmissão dos dados nos demais. Os dados do mapeamento que falhou não são reconhecidos no nível da conexão. Assim, o MPTCP pode sobreviver à perda de uma parte dos seus caminhos. Não seria correto classificar toda falha desse tipo como fallback da conexão inteira.

O caso de um único subfluxo exige cuidado adicional. Para usar o mapeamento infinito sem fechá-lo antes, os dados em trânsito ainda não reconhecidos precisam ser conhecidos como contíguos. O contador de subfluxos não comprova isso. Podem existir retransmissões relacionadas a outro subfluxo que terminou de forma anormal.

MP_FAIL indica o início do mapeamento problemático no espaço de sequência de dados. No intercâmbio de fallback aplicável, o sentido inverso também retorna ao TCP convencional. Se os dados não forem contíguos, a especificação prevê uma situação com reset e eventual criação de um novo subfluxo, ao qual se aplica imediatamente um mapeamento infinito. Esse subfluxo novo ainda pertence à conexão antiga. Ele não restaura sua capacidade multipercurso.

Perder opções na negociação inicial e perder informações de mapeamento depois do estabelecimento também não são situações idênticas. Algumas respostas consistem em abandonar o subfluxo problemático. O protocolo não fornece uma conversão sem condições para qualquer conexão danificada. Se o checksum não foi negociado, detectar alterações de carga útil para essa finalidade depende de um sinal de outra camada.

Um subfluxo não é um diagnóstico

Uma conexão que continua sendo MPTCP pode ter apenas um subfluxo e ainda preservar a possibilidade de estabelecer outros. Já após o mapeamento infinito, somente um pode transmitir, os demais devem ser encerrados e o retorno ao MPTCP na mesma conexão é proibido. O número observado pode ser igual, mas as opções futuras não são.

Consultar endereços não resolve necessariamente a diferença. A RFC 6897 discute uma API abstrata: habilitar MPTCP antes do estabelecimento, consultar o suporte depois e obter os endereços dos subfluxos estabelecidos. Não se pode concluir que um sistema operacional atual implemente esses nomes simbólicos ou exponha, por eles, uma notificação confiável de fallback posterior.

O documento alerta que uma lista de subfluxos pode ficar desatualizada. As consultas de endereço herdadas mantêm os dados do primeiro subfluxo, mesmo quando ele já não é utilizado. Encontrar o endereço habitual em um registro não é evidência suficiente do caminho corrente. As notificações avançadas discutidas no apêndice eram temas para trabalho futuro, não garantias da API básica.

A cronologia das fontes delimita a conclusão. O registro da RFC 8684 identifica uma Proposed Standard de março de 2020, que substituiu a versão anterior do MPTCP. A errata verificada corrige um exemplo de TCP Fast Open com reconhecimento prematuro, sem alterar a regra da seção 3.7. A RFC 6897 está registrada como Informational de março de 2013, e sua consulta de erratas não encontrou entradas correspondentes. Esses documentos sustentam uma análise do projeto, não estatísticas de comportamento de uma frota em produção.

A renovação tem uma conta própria

A necessidade de outra conexão para recuperar MPTCP é consequência da proibição de reversão na conexão existente. Não é promessa de que a próxima negociação funcionará. O equipamento intermediário ou a condição de caminho que provocou o problema pode continuar presente.

Uma transferência finita pode terminar no fluxo preservado antes de uma renovação natural. Uma sessão longa pode justificar uma fronteira explícita de substituição. Em ambos os casos, a aplicação precisa definir o que pode ser retomado e o que não deve ser repetido enquanto o resultado anterior é incerto. Reabrir um socket não resolve, por si só, essa ambiguidade.

A análise de agência de Lu Heng chama atenção para a relação entre poder de decisão e exposição às consequências. Seu texto sobre o propósito da BTW privilegia a descrição da estrutura. Aqui, a estrutura relevante inclui tanto o trabalho que o fallback preserva quanto a decisão de capacidade que ele deixa pendente.