Resumo

  • A confiabilidade parcial do SCTP permite desistir de uma mensagem depois que seu envio começou, mantendo a associação e as obrigações relativas a outras mensagens.
  • O emissor precisa comunicar a mudança por FORWARD TSN. Parar de retransmitir, sozinho, não informa ao receptor quais lacunas deixaram de exigir espera.
  • Prazo, limite de retransmissões e prioridade de buffer são critérios locais de persistência. Não comprovam recebimento nem impõem validade à aplicação que está do outro lado.

A prioridade começa dentro de um buffer

Um novo pedido de envio chega quando não há espaço suficiente. A aplicação atribuiu prioridades às mensagens submetidas à política correspondente, e a implementação precisa decidir o que retirar do próprio buffer. O RFC 7496 permite abandonar mensagens de prioridade menor na mesma associação; mensagens confiáveis permanecem acima de todas as mensagens sujeitas a esse descarte.

Essa escolha é radicalmente local. Ela não reserva uma fila nos roteadores, não acelera um pacote no caminho e não ordena o trabalho da aplicação receptora. O algoritmo exato de seleção também fica a cargo da implementação. «Prioridade» nomeia aqui uma política para aliviar pressão no buffer de envio, não uma propriedade que acompanha a mensagem por toda a rede.

O mesmo RFC acrescenta outra política local: limitar as retransmissões de cada bloco DATA de uma mensagem. Reenvios rápidos e os provocados por temporizador entram na contagem. Se uma nova retransmissão de qualquer bloco ultrapassaria o limite, a mensagem inteira é abandonada. Limite zero ainda permite o primeiro envio; ele atua quando a primeira retransmissão seria necessária. Não prova entrega e não substitui os critérios de falha de caminho ou associação.

As duas políticas ilustram o mesmo princípio. O emissor escolhe quanto persistir a partir de recursos e utilidade que só ele conhece. A política muda a razão do abandono, mas não pode inventar um tratamento diferente para cada receptor. Para continuar a associação, todas precisam desembocar no mesmo mecanismo mínimo de sequência.

A unidade de desistência é a mensagem

O RFC 3758 define a confiabilidade parcial por mensagem de usuário. Se um fragmento é abandonado, todos os TSNs pertencentes à mensagem fragmentada também são abandonados. Retirar apenas a peça inconveniente preservaria na contabilidade uma promessa de mensagem completa que já não pode ser cumprida.

No lado emissor, cada TSN abandonado deixa de estar pendente e é tratado como «finally acknowledged» para encerrar o controle de envio. Isso não significa que o receptor o confirmou. Os bytes abandonados não podem entrar em partial_bytes_acked nem ampliar a janela de congestionamento; os ajustes de congestionamento e de temporização ainda aplicáveis continuam obrigatórios. A política local não compra crédito de rede ao descartar trabalho.

Também por isso existem duas fronteiras. A confirmação cumulativa real vem dos SACK do par. O Advanced.Peer.Ack.Point é calculado localmente sobre TSNs abandonados. No exemplo do emissor da especificação, o cumulativo está em 102; 103 e 104 foram abandonados; 105 segue confiável, sem confirmação; 106 está confirmado. O ponto avançado para em 104. Nem prioridade de buffer nem limite de retransmissão autorizam atravessar o 105 ainda devido.

Há uma diferença operacional anterior a essa sequência. As estatísticas informativas do RFC 7496 distinguem mensagens abandonadas sem que parte alguma tenha sido enviada das abandonadas depois que ao menos uma parte saiu. A unidade continua sendo a mensagem; um só fragmento transmitido coloca o abandono na segunda categoria. Essa diferença impede que uma expulsão puramente local seja confundida com uma tentativa que já pode ter produzido uma cópia em trânsito.

A continuação do receptor é compartilhada

Quando o ponto avançado supera o cumulativo informado, FORWARD TSN comunica até onde o receptor pode deixar de esperar. Ele só ultrapassa TSNs abandonados; não cruza um buraco confiável e não confirmado para alcançar dados posteriores. Para mensagens ordenadas, carrega ainda a posição de fluxo que permite liberar mensagens retidas. Dados sem exigência de ordem não pertencem a essas entradas de sequência ordenada.

No exemplo do receptor do RFC 3758, o cumulativo está em 102, falta 103, chegaram 104 e 105, falta 106 e chegou 107. Uma instrução até 103 move primeiro a fronteira por autoridade de abandono. Em seguida, os dados efetivamente presentes levam o cumulativo até 105. O 106 ainda impede qualquer avanço adicional. O receptor combinou ausência autorizada com posse real; não recebeu o conteúdo de 103.

A transição inclui a limpeza do estado dependente. Um reagrupamento incompleto que ainda precisa de TSN ausente sob a nova fronteira deve ser removido. Se a entrega parcial já começou, a camada superior deveria ser avisada de que a mensagem não será completada. Um bloco que chega tarde atrás da fronteira é tratado como duplicado e descartado, mas isso não recolhe uma cópia entregue antes.

A própria notificação pode se perder. O emissor deve assegurar que o temporizador T3-rtx esteja funcionando e revisitar o avanço quando ele expira. Um FORWARD TSN antigo ou igual não faz a fronteira retroceder e pode provocar um SACK quando o anterior se perdeu. A propriedade compartilhada é a transição compreendida por ambos, não a certeza de que um único aviso foi recebido.

O suporte precisa ter sido negociado na abertura da associação. Implementação capaz que não anuncia a extensão deve operar sem ela naquela associação. Se o par não oferece suporte, a camada superior pode abandonar o estabelecimento ou continuar sem confiabilidade parcial. Capacidade disponível, capacidade negociada e política usada por uma mensagem formam três dependências diferentes.

O prazo básico e a fronteira WebRTC

A duração não surgiu do nada em 2004. O RFC 2960, de outubro de 2000, já permitia cancelar dados se a primeira transmissão não começasse dentro do prazo; depois do primeiro envio, a obrigação permanecia confiável. Os RFC 4960 e RFC 9260 conservam essa distinção na interface básica. A existência da extensão não torna toda mensagem SCTP parcialmente confiável.

O serviço temporal do RFC 3758 amplia o abandono para depois da numeração. Antes de atribuir TSN, um prazo vencido pode encerrar a mensagem sem abrir lacuna e sem exigir FORWARD TSN. Depois da atribuição, a verificação antes de transmissão ou retransmissão pode levar ao abandono compartilhado. Não é obrigatório manter um alarme por mensagem nem avaliar no instante exato do vencimento, e a aplicação não pode alterar o prazo depois de entregar o dado ao transporte.

Daí decorre um limite: o prazo mede persistência no emissor, não validade no receptor. Como hipótese analítica, uma cópia já em trânsito pode chegar antes do aviso de salto. Isso não descreve um incidente nem comprova comportamento de uma implementação específica. Apenas mostra por que a aplicação precisa de versão, tempo de aceitação ou outra regra própria quando dados antigos não podem produzir efeito.

O documento informativo RFC 6458 descreve a seleção entre serviço confiável e política temporal, com valor em milissegundos, sem estabelecer constantes ou padrões universais. É uma interface possível para escolher persistência, não uma ABI garantida em todos os sistemas.

O RFC 8831 exige políticas temporal e de retransmissões limitadas para canais de dados WebRTC. Nessa arquitetura, ordem e confiabilidade são dimensões separadas, e SCTP opera sobre DTLS sobre ICE/UDP. A exigência não inclui a política de prioridade do RFC 7496, não prova adoção atual em qualquer navegador e não transforma a escolha por mensagem em atributo fixo do fluxo.

Começar pelo buffer revela a arquitetura por inteiro. A aplicação escolhe uma persistência local; o transporte aplica o abandono no limite da mensagem; FORWARD TSN oferece a menor transição comum capaz de liberar o receptor. Nenhuma dessas etapas converte prioridade local em prioridade de rede, nem desistência em recibo.

Documentos consultados

  • RFC 2960: duração da mensagem antes do primeiro envio.
  • RFC 3758: confiabilidade parcial, abandono e FORWARD TSN.
  • RFC 4960: continuidade da interface básica.
  • RFC 6458: interface informativa de políticas de envio.
  • RFC 7496: retransmissões, prioridade de buffer e estatísticas.
  • RFC 8831: requisitos e camadas dos canais de dados WebRTC.
  • RFC 9260: especificação básica do SCTP em 2022.