Zusammenfassung

  • RFC 3366 behandelt die ARQ-Persistenz eines Links als Zeitbudget: Wie lange versucht er, einen Frame wiederherzustellen, bevor er aufgibt? Das ist kein kostenloser Zuverlässigkeitsgewinn.
  • Eine Wiederholung kann einem Fluss helfen und zugleich Verzögerung, Jitter oder Blockierung für die übrigen verursachen; eine Frame-Bestätigung beweist keine rechtzeitige Zustellung an die Anwendung.

Ein Frame ist nicht das ganze Paket

Die Geschichte beginnt unterhalb von IP. Automatic Repeat reQuest, kurz ARQ, erkennt einen fehlenden oder beschädigten Link-Frame und sendet ihn erneut. Je nach Link kann ein Frame einen Teil eines IP-Pakets, ein vollständiges Paket oder Teile mehrerer Pakete enthalten. Die Bestätigung beantwortet eine begrenzte Frage: Hat das lokale Link-Protokoll den Frame akzeptiert? Sie beweist weder die Zustellung des Pakets über den gesamten Pfad noch, dass die Anwendung es noch nutzen konnte.

RFC 3366 erschien als Best Current Practice 62 und forderte Link-Designer auf, diese Grenze ernst zu nehmen. Der Text legt weder eine bestimmte Funktechnik noch eine einheitliche Zahl von Versuchen fest. Er erklärt, wie eine lokale Reparaturschleife mit dem darüberliegenden Internetverkehr zusammenwirkt.

Das Wiederholungsbudget verbraucht gemeinsame Zeit

Das Dokument nennt die Bereitschaft zu weiteren Versuchen „Persistenz“. Ein Link kann eine feste Zahl erlauben oder Timer und Fehlererkennung entscheiden lassen, wann Schluss ist. Die Zahl ist keine Uhr: Ausbreitung, Zugriff auf ein geteiltes Medium, Warteschlangen, Frame-Größe und Verarbeitung beeinflussen die tatsächliche Dauer.

Zuverlässigkeit ist daher bedingt. Die lokale Link-Steuerung reagiert oft schneller als TCPs Ende-zu-Ende-Regelkreis und kann einen Kanalfehler reparieren, bevor der Sender erneut überträgt. Der reparierte Frame kann aber spät genug eintreffen, um den Transport-Timer zu beeinflussen. Hält der Link die Reihenfolge ein, können später vollständig empfangene Pakete hinter dem weiterhin wiederholten Frame warten. Auf einem gemeinsam genutzten Kanal verbrauchen die Versuche außerdem Sendezeit, die anderen Knoten fehlt.

Perfekte Persistenz macht den Zielkonflikt deutlich: endlos weitersenden, solange der Empfänger den Frame vielleicht noch annimmt. Für eine Übertragung, deren Zweck zuverlässige Zustellung ist, kann das sinnvoll sein. Über einen IP-Pfad aus mehreren Links kann wiederholte Reparatur jedoch Arbeit verdoppeln, die bereits Ende zu Ende geleistet wird; sie garantiert nicht dieselbe Zuverlässigkeit wie der Transport zwischen den Endsystemen. Bei Streaming und anderem zeitkritischem UDP-Verkehr ist ein verspätetes Paket womöglich weniger wert als ein verlorenes.

Was der Link sicher erkennen kann – und was nicht

Es scheint naheliegend, „zuverlässig wirkendem“ Verkehr mehr Versuche zu geben und dem Rest weniger. RFC 3366 erklärt, warum Beobachtung nicht genügt. Der Link kann ein Verhalten der Staukontrolle sehen, ohne die Frist der Anwendung oder deren Vorrang von Vollständigkeit gegenüber Aktualität zu kennen. Portnummern können irreführen oder umgeschrieben werden; Tunnel bündeln verschiedene Flüsse; Verschlüsselung begrenzt die Inspektion; eine Dienstmarkierung kann überschrieben werden oder nur lokal gelten.

Die Empfehlung ist deshalb bedingt. Kann der Link Dienstklassen sicher unterscheiden, können verschiedene Wiederholungsverhalten helfen. Andernfalls erben alle Flüsse dasselbe Verhalten. Wo sichere Klassifikation nicht praktikabel ist, bevorzugt das BCP im Allgemeinen geringe Persistenz: einige Frames retten, aber nicht ein unvollständiges Paket die Warteschlange auf unbestimmte Zeit blockieren lassen. Der Text bewahrt auch die Ausnahme: Hohe Persistenz kann TCP bei bestimmten schwankenden Fehlerraten oder nach einer vorübergehenden Unterbrechung helfen. Eine universell beste Einstellung gibt es nicht.

RFC 3819 aus dem Jahr 2004 erweitert die Hinweise für Subnetze um den Zielkonflikt zwischen Verlust, mittlerer Verzögerung und Verzögerungsschwankung. Die spätere Anleitung betont Flexibilität; sie macht aus dem Beispiel von zwei bis fünf Versuchen keine heutige Regel und keine Messung realer Verbreitung.

Die Bestätigung bleibt lokal

Die bleibende Lehre von RFC 3366 betrifft auch Belege. Ein Frame-ACK dokumentiert ein lokales Ereignis. Dass ein Paket den Link verlässt, der Transport die Daten annimmt und die Anwendung sie rechtzeitig erhält, sind spätere, getrennte Ereignisse mit jeweils eigenen Nachweisen. Wiederholung kann Kanalverluste senken und zugleich Jitter erhöhen, Rückmeldungen zur Überlast verzögern oder die Zeit anderer Flüsse verbrauchen.

Der Link-Designer setzt ein lokales Budget; der Pfad summiert seine Folgen. Ohne Kenntnis des restlichen Pfads und der Aktualitätsanforderung der Anwendung kann ein Gerät aus „mehr Versuchen“ kein Versprechen besseren Dienstes machen. BCP 62 verlangt, diese Unsicherheit in den Entwurf aufzunehmen, statt sie hinter dem Etikett „Zuverlässigkeit“ zu verstecken.

Quellen

Lu Heng hat RFC 3366 nicht verfasst. Die Essays sind ausdrücklich analytische Linsen, um Empfehlung, laufende Implementierung, Konfiguration und beobachtetes Ergebnis auseinanderzuhalten.