Resumo

  • A numeração do DCCP inclui confirmações sem dados. Um emissor pode, assim, identificar qual relatório de recepção recebeu e permitir que o receptor descarte estado antigo.
  • O CCID 2 exige retorno confiável sobre recepção e congestionamento, mas não retransmite os dados da aplicação que se perderam. São compromissos distintos.
  • Se a confirmação do relatório se perde, o histórico permanece por mais tempo. Não surge uma obrigação de confirmar uma terceira vez; tampouco todos os perfis de congestionamento precisam da mesma estratégia.

Um documento que podia ser citado

O RFC 4340 numera cada pacote DCCP, inclusive o DCCP-Ack que não leva conteúdo da aplicação. O número seguinte avança por pacote, não por byte. A confirmação deixa de ser apenas uma referência a dados anteriores: ela própria se torna algo que o correspondente pode identificar.

Isso faz diferença quando o receptor guarda um histórico para explicar o que chegou, o que ainda falta e o que veio marcado por congestionamento. Enviar o relatório não prova que o emissor o recebeu. Para deixar de repetir uma informação, o receptor precisa associá-la a um relatório cuja chegada foi confirmada.

A numeração dá um endereço a essa segunda notícia. Não é um sistema de recibos comerciais, nem comprova que uma aplicação concluiu seu trabalho. É um mecanismo para encerrar uma responsabilidade dentro do transporte.

Dados descartáveis, informação necessária

O problema que motivou o DCCP aparece no RFC 4336, de março de 2006. Aplicações de voz e jogos podem precisar de dados recentes mais do que de uma reconstrução completa do passado. Uma amostra de áudio que perdeu a hora de tocar ou uma posição antiga talvez não mereça ocupar a próxima oportunidade de transmissão.

Ao mesmo tempo, esses fluxos precisam reagir ao congestionamento. A aplicação pode escolher o conteúdo do próximo datagrama, mas não deve tratar a capacidade do caminho como ilimitada. O DCCP separa o controle da taxa de envio da obrigação de reenviar conteúdo perdido.

O protocolo não retransmite os dados da aplicação. Uma recuperação seletiva pode ser adicionada pela própria aplicação, conforme sua necessidade. Mas, no CCID 2, as informações sobre recepção precisam chegar de forma confiável ao emissor. É possível dispensar a recuperação de uma informação antiga de jogo sem dispensar o conhecimento de que o caminho perdeu pacotes.

Essa separação explica por que um transporte não confiável ainda tem memória a conservar. O que se conserva não é necessariamente uma dívida de entrega do conteúdo, mas uma dívida de informação sobre o comportamento da rede.

O maior número não era uma linha de chegada

O campo Acknowledgement Number do DCCP indica o maior número de sequência recebido. Ele não afirma que todos os anteriores chegaram. Para conhecer as lacunas, o emissor depende das opções que descrevem a recepção.

Ack Vector faz isso com estados comprimidos por sequências. Cada byte reúne dois bits de estado e seis de comprimento. Há estados para recebido, recebido com marca ECN, reservado e ainda não recebido. Comprimento zero representa um pacote; 63 representa 64. A descrição começa no número de confirmação e caminha para trás.

Uma sequência longa de recepções iguais pode ocupar pouco espaço. Ainda assim, compactar não significa quitar a obrigação de relatar. Enquanto a notícia não chega, pode ser necessário enviá-la novamente. O tamanho do registro e sua utilidade são perguntas diferentes.

Também seria errado ler uma lacuna como uma quantidade exata de conteúdo perdido. Pacotes de controle usam a mesma sequência. Com a função correspondente habilitada, NDP Count informa quantos pacotes sem dados formaram a sequência imediatamente anterior e ajuda a interpretar um buraco. Não fornece uma contagem geral dos bytes de aplicação que faltam.

Mesmo o estado recebido é delimitado. As opções do pacote foram processadas pelo DCCP, mas os dados podem ter sido descartados no buffer da aplicação. Esse descarte não deve ser apresentado como se o pacote nunca tivesse atravessado a rede. Data Dropped permite informar a diferença.

Quando sobra apenas o caminho de ida dos dados

Enquanto as duas aplicações enviam, suas trocas normalmente carregam as confirmações necessárias. A mudança ocorre quando B deixa de enviar dados, mas continua recebendo os de A. B segue produzindo Ack Vectors. Se A enviar apenas DCCP-Data, B fica sem saber quais desses relatórios chegaram.

O RFC 4341 exige que um emissor ativo confirme ocasionalmente as confirmações do receptor. Usar DCCP-DataAck em vez de DCCP-Data é uma possibilidade. A recomendação é fazê-lo ao menos uma vez por janela de congestionamento, não emitir obrigatoriamente um novo pacote para cada aviso recebido.

Esse retorno permite liberar estado antigo. Sem ele, o receptor poderia continuar incluindo nos relatórios informações desde o começo da conexão. A janela de informações pendentes cresce com novos recebimentos e encolhe quando o outro lado confirma relatórios anteriores.

Se as duas aplicações ficam silenciosas, o emissor pode esperar por tempo indeterminado. Não há motivo para fabricar uma conversa sem fim apenas para registrar o silêncio. Mas essa liberdade não elimina as obrigações do emissor que continua transmitindo dados ativamente.

Um silêncio que precisava de duas provas

No CCID 2, o intervalo usado para detectar quietude é o maior entre 0,2 segundo e duas vezes o tempo de ida e volta. O relógio, sozinho, não encerra a avaliação. O emissor também precisa ter confirmado os vetores que cobrem todos os dados recebidos.

O uso de duas condições evita tratar a falta momentânea de novos dados como prova de que não há mais informação de recepção pendente. Se o RTT é desconhecido, o valor padrão é 0,2 segundo, de modo que o termo de dois RTTs vale 0,4 segundo. Não se trata de um temporizador fixo de 200 milissegundos.

Os sentidos podem usar perfis diferentes. O perfil de uma direção define sua quietude; o da direção contrária determina como confirmar os relatórios depois dessa mudança. Chamar a conexão inteira de ociosa pode esconder qual lado ainda deve algo ao outro.

A perda que só adiava o encerramento

Confirmar uma confirmação parece convidar a uma terceira confirmação. O DCCP interrompe essa sequência ao não exigir entrega confiável do segundo aviso.

Se ele se perde, o receptor mantém e volta a enviar seu estado por mais algum tempo. A falha adia a limpeza. Não convence o receptor a apagar uma informação que ainda precisa comunicar. Como a consequência é prolongar uma obrigação existente, não é necessário criar outra cadeia confiável para encerrá-la.

Isso não torna perdas repetidas inofensivas. Elas têm custo de memória, tráfego de retorno e demora na atualização do controle. O ponto é que nem toda incerteza exige o mesmo remédio. Algumas precisam de repetição até a entrega; outra pode ser tolerada como conservação adicional.

Uma chegada atrasada exige mais cuidado. O receptor pode ter informado que um pacote não chegou e recebê-lo antes da confirmação daquele relatório antigo. Apagar o registro nesse momento destruiria uma notícia nova, ainda desconhecida do emissor.

O apêndice A.3 do RFC 4340 ilustra uma implementação que limita a fronteira de liberação nessas circunstâncias. Não impõe um único desenho de buffer. Mostra por que a confirmação de uma versão antiga da história não autoriza eliminar fatos posteriores. As regras de combinação de estados também lidam com relatórios que chegam fora de ordem.

A comparação que impede uma regra universal

O RFC 4342 define CCID 3, baseado em TFRC. Ele procura suavizar as mudanças de taxa, aceitando uma resposta mais lenta às mudanças de capacidade. Segundo o RFC de base, seu estado de confirmação geralmente é limitado; portanto, não exige o mesmo mecanismo de confirmação das confirmações. Isso não quer dizer ausência de estado ou de retorno.

As erratas verificadas do RFC 4342 mostram que a utilidade de um relatório depende do intervalo que ele representa. A taxa recebida deve se referir ao último RTT, não a todo o período desde o aviso anterior. Em uma situação prevista sem dados no intervalo, o emissor pode ignorar um segundo Receive Rate, mas não deve reiniciar por isso o temporizador de ausência de retorno.

As erratas do RFC 4340 corrigem, entre outros detalhes, um exemplo que dizia indevidamente ser inválido o valor zero de Ack Ratio. O RFC 8311, de 2018, retira a discussão de ECN Nonce de três perfis DCCP. Uma descrição histórica precisa não transforma texto antigo, sem suas atualizações, em orientação atual de operação.

Em 2012, o RFC 6773 acrescentou encapsulamento UDP para lidar com equipamentos que aceitavam UDP, mas não DCCP nativo. Isso adaptava o transporte a certas limitações do caminho; não garantia a entrega dos dados. O registro da IANA identifica os perfis, mas não mede quantas redes os executam.

Não há nessas fontes uma participação de mercado atual, um ganho universal de velocidade ou a história de um produto específico. Há uma engenharia de responsabilidades: numerar o relatório torna possível citar o conhecimento recebido e dar fim, com precisão, à memória que o sustentava.