Summary

  • RFC 5238 recomenda impedir a retransmissão de uma solicitação enfileirada, mas ainda não transmitida pelo DCCP. Quando disponível, a passagem do DCCP ao IP é o evento apropriado para iniciar o relógio DTLS.
  • Aceitação na fila, liberação inferior, envio, recepção, conclusão do DCCP, avanço do DTLS e prontidão da aplicação são fatos diferentes e não cabem em um único indicador.

Um timeout criado antes da rede

DTLS entrega um registro; DCCP o aceita, porém sua disciplina de congestionamento segura a saída. Se o relógio superior começa na aceitação, seu prazo inclui espera local e percurso externo. A expiração parece dizer que a rede perdeu algo que talvez nunca tenha deixado a máquina.

A cópia entra na mesma fila e disputa a oportunidade escassa do original. O atraso autoriza duplicação; a duplicação produz mais atraso.

RFC 5238 propõe uma fronteira melhor: quando a implementação informa o evento, DTLS pode aguardar a transferência do DCCP para a camada IP antes de armar sua retransmissão.

Duas negociações mantêm garantias diferentes

DCCP estabelece uma conexão e DTLS estabelece a proteção. O caminho simples é serial, mas registros DTLS podem viajar em DCCP-Request e DCCP-Response para sobrepor parte das negociações.

Isso não torna confiáveis os dados incorporados. O servidor pode descartar Application Data recebido no pedido; uma repetição DCCP pode omitir o conteúdo incluído na primeira tentativa. DTLS mantém, portanto, sua própria recuperação.

O registro superior não pode voltar como dado comum até o estabelecimento DCCP terminar. O RFC exige que o timer DTLS aguarde esse ponto antes de reiniciar, evitando que várias cópias se acumulem sem possibilidade de sair.

Relógios parecidos podem amplificar a causa

As duas camadas usam prazos e recuo exponencial, mas observam sujeitos distintos. Um timeout DCCP não comprova perda do registro DTLS; silêncio DTLS não localiza automaticamente uma perda na rede.

Mensagens grandes da negociação podem ser limitadas pelo DCCP até ativarem o prazo superior. Novas cópias podem piorar o congestionamento. Retransmitir depois de uma tentativa efetivamente liberada é recuperação; fazê-lo enquanto o original espera é duplicação especulativa.

Sequências não emprestam autoridade

RFC 5238 afirma que não existe ligação entre o número do pacote DCCP e o número do registro DTLS, nem entre sincronização DCCP e proteção antirrepetição DTLS. Compartilhar encapsulamento não compartilha significado.

O tamanho também depende do estado atual. Cada registro DTLS deve caber em um único pacote DCCP e respeitar o máximo vigente, que pode mudar com as condições de congestionamento.

A negociação deixa estado para o serviço

O tráfego inicial pode deixar o controlador de congestionamento inadequado à carga seguinte. Em CCID 2, uma negociação volumosa pode causar redução multiplicativa e obrigar a aplicação a esperar a recuperação aditiva. RFC 5238 sugere considerar CCID 3 quando variações mais lentas forem desejáveis, sem declarar uma solução universal.

Segurança estabelecida e capacidade adequada à aplicação são dois recibos.

Limites do registro

As fontes não mostram produto atual, implantação, captura, incidente, medição ou adoção. O registro da IANA prova parâmetros, não uso. RFCs posteriores de DTLS mostram evolução normativa, não adoção sobre DCCP.

A entrega ao IP tampouco prova transmissão física, recepção ou sessão pronta. É um começo mais fiel que a admissão local, não o fim da cadeia.

Dar um evento a cada relógio

Registre submissão, entrada na fila, decisão de congestionamento, entrega ao IP, identidade de sequência, envio observável, resposta, estado DCCP, voo DTLS e liberação da aplicação. Nomeie o componente responsável pelo início, pausa e cancelamento de cada prazo.

Suprima cópias superiores enquanto o original permanecer enfileirado. Preserve cancelamentos e respostas tardias, sem reclassificá-los como perda externa.

A primazia da realidade operacional de Lu Heng é concreta: uma API aceitar trabalho não significa que o trabalho foi executado. O dono do timer deve responder pelo limite de evidência porque seu relógio também cria tráfego.

Sources

Registro normativo adicional

  1. Texto do RFC 5238
  2. Página informativa
  3. RFC 5238 no Datatracker
  4. Histórico
  5. Errata
  6. Referências ao RFC 5238