Resumo

  • O RFC 3758 deixou para o serviço a regra que decide quando abandonar cada mensagem e definiu um sinal genérico para o avanço da sequência.
  • A confiabilidade temporizada não obriga o SCTP a avaliar a mensagem no exato instante em que seu prazo vence.

O prazo acabou, mas a pilha SCTP ainda podia levar um pouco para conferir. O RFC 3758 permite essa diferença porque não tratou o relógio da aplicação e o ciclo de processamento do transporte como o mesmo mecanismo.

A extensão de confiabilidade parcial não tornou todo o SCTP “best effort”. Ela permitiu que a camada superior especificasse, mensagem a mensagem, por quanto tempo o transporte deveria tentar enviar ou retransmitir o conteúdo. Se os dois lados negociarem suporte ao FORWARD TSN durante o estabelecimento da associação, o remetente poderá abandonar uma mensagem e pedir ao receptor que avance seu ponto cumulativo de números de sequência de transmissão (TSN). Para dados ordenados, a sinalização também traz números de sequência do fluxo, ajudando a liberar mensagens que ficaram presas atrás da lacuna.

A política que autoriza a desistência é diferente do sinal que resolve a lacuna. O receptor não precisa saber se a decisão veio de um prazo, de um limite de retransmissões ou de outra regra do serviço. Ele precisa saber que determinados TSNs não devem mais ser aguardados e quais mensagens ordenadas podem prosseguir. O FORWARD TSN carrega a consequência, não a justificativa da aplicação.

O contraste com o SCTP original explica por que o RFC 3758 foi necessário. No modelo descrito pelo RFC 2960, o parâmetro de vida útil impedia que um dado ainda não transmitido fosse enviado depois de vencido. Mas, se a primeira transmissão tivesse ocorrido antes do vencimento, o conteúdo se tornava uma mensagem confiável normal e continuava sujeito a retransmissões. O serviço de confiabilidade temporizada removeu essa restrição: mesmo depois da primeira transmissão, a mensagem podia ser abandonada.

Isso não tornou o vencimento uma interrupção instantânea. A pilha deve avaliar a vida útil antes de atribuir um TSN e também antes de transmitir ou retransmitir uma mensagem cujo TSN já foi atribuído. Ao mesmo tempo, o RFC observa que não é preciso manter um temporizador separado para cada mensagem. A implementação pode avaliar a vida útil em pontos já existentes do processamento — como a atribuição, o envio ou a expiração de um temporizador de retransmissão — e também em outra oportunidade conveniente. Ela não precisa fazer a verificação no instante exato em que o prazo termina.

Por isso, um parâmetro chamado lifetime em uma API não é, por si só, uma garantia de prazo rígido. Ele pode definir que o dado já não deve ser enviado quando a pilha o avaliar; não necessariamente define quando essa avaliação acontecerá. Se um produto depende de uma fronteira temporal precisa, deve explicitar como a pilha detecta o vencimento e o que a aplicação recebe quando ocorre o abandono.

A fase do envio também altera o trabalho necessário. Se o conteúdo vencer antes da atribuição do TSN, o remetente pode descartá-lo sem criar uma lacuna na sequência. Depois de atribuído, o TSN ocupa espaço compartilhado pela associação e o remetente pode precisar avisar o receptor com FORWARD TSN. Se um fragmento de uma mensagem for abandonado, todos os demais fragmentos dessa mensagem também devem ser abandonados. A sequência TSN da associação e a ordem interna de cada fluxo são contabilidades diferentes; o chunk conecta as duas sem fingir que o payload ausente foi recebido.

FORWARD TSN não é comprovante de entrega. Ele mostra que o remetente deixará de perseguir determinados números de sequência e pede ao receptor que siga adiante. Não prova que os dados abandonados chegaram, que a aplicação aceitou a próxima mensagem nem que o serviço cumpriu seu prazo de ponta a ponta. O controle de congestionamento continua: dados abandonados não aumentam a janela de congestionamento, e os ajustes associados a eventos de retransmissão continuam valendo.

Há ainda uma condição de negociação. Se o par não anunciar suporte a FORWARD TSN, a associação não pode usar a extensão. A aplicação que depende de confiabilidade parcial precisa conhecer esse resultado e decidir se aborta, escolhe outro serviço ou continua sem essa capacidade. Suporte local não é compatibilidade negociada.

O RFC 7496 acrescentou depois políticas de limite de retransmissões e de prioridade. O fato de novas regras poderem reutilizar o mesmo sinal ilustra a divisão central do desenho: a camada de serviço decide quando abandonar; o transporte explica ao par como avançar depois disso.

Fontes