Summary

  • RFC 5238 warnt vor der Wiederholung einer Anfrage, die DCCP eingereiht, aber noch nicht übertragen hat. Wenn verfügbar, sollte erst die Übergabe von DCCP an IP den DTLS-Timer starten.
  • Annahme, untere Übergabe, Aussendung, Empfang, DCCP-Abschluss, DTLS-Fortschritt und Anwendungsbereitschaft brauchen eigene Nachweise.

Verlust ohne ausgesandtes Paket

DTLS übergibt einen Datensatz. DCCP nimmt ihn an, doch die Staukontrolle hält ihn zurück. Beginnt die obere Frist bei der Annahme, umfasst sie lokale Wartezeit und Netzweg. Ihr Ablauf meldet fehlende Antwort, ohne eine Sendung zu belegen.

Die Wiederholung landet in derselben Schlange und konkurriert mit dem Original. Warten begründet Duplizierung; Duplizierung erzeugt weiteres Warten.

RFC 5238 nennt die passendere Grenze: DTLS kann den Timer erst starten, wenn DCCP die Übergabe an die IP-Schicht meldet.

Zwei zuverlässige Abläufe bleiben getrennt

DCCP und DTLS besitzen je einen Handshake. DTLS-Datensätze dürfen in DCCP-Request oder Response liegen, um beide teilweise zu überlappen. Die Zuverlässigkeit des DCCP-Handshakes schützt die eingebetteten Application Data jedoch nicht zwingend. Ein Server darf sie verwerfen; eine DCCP-Wiederholung darf sie auslassen.

DTLS behält deshalb eigene Wiederholungen. Der eingebettete Datensatz kann aber erst nach Abschluss des DCCP-Handshakes als normale Nutzlast erneut gesendet werden. Bis dahin muss der obere Timer warten, damit keine unversendbaren Kopien entstehen.

Ähnliche Uhren verstärken sich

Beide Schichten nutzen Fristen und Rücknahme, beobachten aber verschiedene Gegenstände. DCCP-Ablauf beweist keinen Verlust des DTLS-Datensatzes; DTLS-Schweigen lokalisiert keinen Netzverlust.

Große Handshake-Nachrichten können durch DCCP lange genug gedrosselt werden, um oben eine Wiederholung auszulösen. Zusätzlicher Verkehr kann die Herstellung weiter verzögern. Wiederholung nach nachgewiesener Freigabe ist Erholung; Wiederholung während lokaler Wartezeit ist Spekulation.

Nummern behalten ihren Geltungsbereich

Laut RFC 5238 gibt es keine Verbindung zwischen DCCP-Paketnummer und DTLS-Datensatznummer sowie keine zwischen DCCP-Synchronisierung und DTLS-Anti-Replay. Gemeinsamer Transport verleiht keinen gemeinsamen Beweiswert.

Ein DTLS-Datensatz muss außerdem in ein DCCP-Paket passen und darf die aktuell gültige Maximalgröße nicht überschreiten. Diese kann sich mit dem Stauzustand ändern.

Der Handshake prägt den Folgezustand

Handshake-Verkehr kann die Staukontrolle ungeeignet für die Anwendung zurücklassen. Bei CCID 2 kann eine große Aushandlung eine multiplikative Absenkung auslösen; die Anwendung wartet dann auf additive Erholung. CCID 3 kann bei gewünschter sanfterer Änderung erwogen werden. Das ist keine allgemeine Rangliste.

Sicherheit hergestellt und Durchsatz bereit sind zwei Aussagen.

Grenzen der Quellen

Die Standards zeigen kein aktuelles Produkt, Netz, Ereignis, Messwert oder Marktbild. IANA registriert Parameter, nicht Nutzung. Spätere DTLS-Versionen beweisen keine Einführung über DCCP.

Auch die Übergabe an IP beweist keine physische Aussendung, keinen Empfang und keine fertige Sitzung. Sie ist nur ein genauerer Startpunkt als lokale Annahme.

Jeder Uhr ein Ereignis und ein Eigentümer

Erfassen Sie Einreichung, Warteschlange, Stauentscheidung, IP-Übergabe, Sequenzidentität, beobachtbare Sendung, Antwort, DCCP-Zustand, DTLS-Flug und Freigabe der Anwendung. Bestimmen Sie, was jede Frist startet, pausiert und löscht.

Unterdrücken Sie obere Kopien, solange das Original als wartend gilt. Bewahren Sie späte Antworten und abgelöste Versuche, statt alles als Netzverlust zu zählen.

Lu Hengs Vorrang der laufenden Wirklichkeit gilt unmittelbar: API-Annahme ist keine Ausführung. Wer den Timer besitzt, verantwortet seine Beweisgrenze, denn der Timer erzeugt auch Verkehr.

Sources

Ergänzende Standardsnachweise

  1. RFC 5238 Text
  2. RFC 5238 Information
  3. RFC 5238 Datatracker
  4. RFC 5238 Historie
  5. RFC 5238 Errata
  6. Referenzierende Dokumente