Summary

  • RFC 5238 recommande de ne pas retransmettre une requête que DCCP a placée en file mais n'a pas réellement transmise ; le délai DTLS peut commencer lorsque DCCP remet le message à IP.
  • L'admission dans une file, la remise à la couche inférieure, l'envoi, la réception, l'achèvement des deux poignées de main et la disponibilité applicative exigent des reçus différents.

Une perte inventée dans la machine locale

La couche DTLS soumet un message. DCCP l'accepte, mais son contrôle de congestion retarde la sortie. Si le délai supérieur part à cet instant, il mesure à la fois l'attente locale et le trajet réseau. Son expiration semble signaler une perte alors qu'aucun paquet n'a peut-être quitté l'hôte.

La relance rejoint alors la même file. Elle consomme la capacité dont manquait déjà l'original. Le système transforme son propre temps d'attente en justification pour produire davantage de trafic.

RFC 5238 propose une frontière observable : lorsque l'interface le permet, DTLS peut attendre que DCCP indique la remise du message à la couche IP avant d'armer son délai de retransmission.

Deux procédures fiables, deux sujets

DCCP établit d'abord une connexion ; DTLS établit ensuite une connexion protégée. Le document autorise toutefois des enregistrements de négociation DTLS dans DCCP-Request ou DCCP-Response afin de chevaucher partiellement les procédures.

Ce raccourci ne fusionne pas les garanties. La poignée de main DCCP est fiable, mais les données applicatives qu'elle transporte ne le sont pas nécessairement. Un serveur peut les ignorer ; une retransmission DCCP peut omettre les données présentes dans le premier paquet.

DTLS garde donc son propre mécanisme fiable. Mais une relance de l'enregistrement embarqué ne peut partir comme donnée ordinaire avant la fin de la poignée DCCP. Pour éviter l'accumulation de plusieurs relances impossibles à envoyer, RFC 5238 impose d'attendre cet achèvement avant de redémarrer le délai DTLS.

Des horloges voisines peuvent se nourrir

Les deux protocoles utilisent des temporisations et des reculs exponentiels comparables. Chaque horloge protège cependant une progression différente. L'expiration de l'une ne prouve pas l'échec de l'objet surveillé par l'autre.

De gros messages DTLS peuvent être ralentis par le contrôle de congestion au-delà du délai supérieur. Les retransmettre peut alors accentuer la congestion et repousser davantage l'établissement. La retransmission reste utile après un défaut de réponse crédible ; elle devient spéculative si l'original n'a pas encore franchi sa file.

Le point de départ définit la question. Depuis la remise à IP : « depuis combien de temps cette tentative a-t-elle quitté la file ? » Depuis la soumission : « depuis combien de temps l'application a-t-elle demandé du service ? » Ces durées n'autorisent pas la même action.

Les numéros de séquence ne se cautionnent pas

DCCP et DTLS numérotent tous deux leurs unités. Le RFC précise qu'aucun lien n'existe entre le numéro du paquet DCCP et celui de l'enregistrement DTLS, ni entre la synchronisation DCCP et la protection anti-rejeu DTLS.

La proximité technique ne crée pas une identité de sens. Une preuve d'ordre à la couche inférieure ne peut pas être empruntée pour certifier l'état de sécurité supérieur.

La taille suit la même discipline. Un enregistrement DTLS doit tenir dans un seul paquet DCCP et respecter la taille maximale actuellement autorisée, laquelle peut varier avec la congestion. Une capacité passée ne garantit pas une capacité présente.

Le démarrage peut déformer le régime suivant

Le coût de la négociation survit parfois à son achèvement. Avec CCID 2, un échange volumineux peut provoquer une diminution multiplicative que le trafic applicatif n'aurait pas provoquée. Le débit se rétablit ensuite par augmentation additive. RFC 5238 suggère d'envisager CCID 3 lorsque des variations plus lentes conviennent mieux.

Il ne démontre pas la supériorité universelle d'un profil. Il sépare deux états : sécurité établie et contrôle de congestion prêt pour la charge applicative.

Limites de la preuve

Les sources ne nomment aucun produit actuel, déploiement, trace, incident ou mesure. Le registre IANA prouve l'existence de paramètres, pas leur utilisation. Les versions ultérieures de DTLS prouvent une évolution normative, pas l'adoption de DTLS sur DCCP.

La remise de DCCP à IP ne prouve pas non plus une émission physique, une réception distante ou une session opérationnelle. Elle constitue seulement un événement de départ plus fidèle que l'admission locale.

Attribuer un événement à chaque délai

Pour chaque tentative, conservez la soumission, l'admission, la décision du contrôle de congestion, la remise à IP, l'identité de séquence, l'observation d'envoi si elle existe, la réponse distante, l'état DCCP, le vol DTLS et la libération de l'application.

Nommez le composant responsable de chaque délai. Suspendez les relances supérieures tant que l'original est signalé en file. Conservez les annulations, réponses tardives et tentatives supplantées au lieu de les compter comme pertes réseau.

La priorité donnée par Lu Heng à la réalité d'exécution s'applique directement : accepter une tâche par API n'est pas l'exécuter. Le responsable du délai doit répondre de cette frontière, car son automatisation crée du trafic autant qu'elle mesure le temps.

Sources

Dossier normatif complémentaire

  1. Texte brut RFC 5238
  2. Fiche RFC 5238
  3. RFC 5238 dans Datatracker
  4. Historique RFC 5238
  5. Errata RFC 5238
  6. Documents citant RFC 5238