Zusammenfassung

  • Ein verspätetes ACK konnte beide Endpunkte dazu bringen, ihre jeweils aktuellen Pakete erneut zu senden und Duplikate über weitere Blöcke auszulösen.
  • RFC 1123 untersagte dem DATA-Sender die Wiederholung des aktuellen Blocks als Reaktion auf ein doppeltes ACK. Gefährdet war der Abschluss unter Überlastung, nicht die Integrität einer vollständig empfangenen Datei.

Ein Block, eine Bestätigung

Die zweite Fassung des Trivial File Transfer Protocol erschien 1981. „Trivial“ stand für einen kleinen Austausch: Ein Client forderte eine Datei zum Lesen oder Schreiben an, die Daten kamen in Blöcken von höchstens 512 Byte, und jeder Block wurde bestätigt, bevor der nächste folgte. Der Sender musste nur den gerade aktiven Block für eine Wiederholung behalten. Das sparte Speicher und Implementierungsaufwand – nützlich für Rechner, die ihr Betriebssystem erst über das Netz laden mussten.

RFC 1123 bezeichnete 1989 das Bootstrapping in einem lokalen Netz als wichtigsten TFTP-Einsatz und verwies darauf, dass eine kleine Implementierung in EPROM passte. BOOTP konnte Konfiguration liefern; TFTP übertrug anschließend das Systemabbild. Diese Schritte ergänzten einander, lösten aber unterschiedliche Aufgaben. Auch ein korrekt konfigurierter Host war beim Dateitransfer von rechtzeitigen Bestätigungen abhängig.

TFTP lief über UDP und regelte Wiederholungen selbst. Blieb die erwartete Antwort bis zum Ablauf des Timers aus, konnte der Sender sein noch offenes DATA erneut schicken. Bei einem verlorenen Paket war das plausibel. Eine verspätete Antwort erzeugte jedoch eine andere Reihenfolge.

Ein altes ACK trifft auf einen neuen Zustand

Angenommen, A sendet DATA 20 und B antwortet mit ACK 20. Die Bestätigung bleibt unterwegs liegen. A läuft in den Timeout und sendet DATA 20 erneut. B erkennt den bereits angenommenen Block und sendet noch einmal ACK 20. Als das erste ACK schließlich bei A eintrifft, geht A zu DATA 21 über. Danach kommt das zweite, alte ACK 20. Die ursprüngliche Regel lässt A nun das DATA wiederholen, das es gerade aktuell hält: Block 21.

B erhält DATA 21 zweimal und sendet zweimal ACK 21. Trifft eines dieser ACKs erst ein, nachdem A zu DATA 22 weitergegangen ist, kann es die nächste Wiederholung auslösen. Das alte Paket setzt also nicht nur einen alten Zustand zurück. Jede Seite antwortet aus ihrem gegenwärtigen Zustand. Ein Duplikat erzeugt beim Gegenüber ein neues Duplikat.

Robert Braden nannte das in RFC 1123 das „Sorcerer’s Apprentice syndrome“. Sein Ablauf zeigt, dass die restlichen Pakete doppelt gesendet werden können, bis ein Datagrammverlust die Kette unterbricht. Daraus folgt nicht, dass der Dateiinhalt zwingend beschädigt wird. RFC 1123 hält fest, dass eine abgeschlossene Übertragung eine korrekte Datei ergibt. Die Duplikate verbrauchen Zeit und Kapazität und können verhindern, dass der Transfer vor dem Timeout endet.

Wenn der Pfad die Wiederholung verstärkt

Überlastung konnte den Ablauf sowohl anstoßen als auch verschärfen. Ein voller Pfad verzögert das ACK; zusätzliches DATA und seine ACKs belegen wiederum mehr Kapazität und erhöhen die Wahrscheinlichkeit weiterer Verzögerungen. Der RFC warnt deshalb vor zusätzlicher Überlastung. Er behauptet weder, jeder langsame Transfer verfalle in diesen Zustand, noch belegt er damit einen bestimmten historischen Ausfall. Beschrieben ist ein Rückkopplungsmechanismus des Protokolls.

RFC 1123 verlangte anpassbare Timer und empfahl exponentielles Backoff. Andere Timerwerte beseitigen jedoch nicht die Regel, nach der ein altes ACK den aktuellen Block erneut auslösen kann. Die verbindliche Korrektur war eng gefasst: Der DATA-Sender darf sein aktuelles DATA nach einem doppelten ACK nicht erneut senden. Dadurch kann eine alte Bestätigung keine neue Kopie des folgenden Blocks mehr starten. Der ACK-Timer auf Empfängerseite kann entfallen, wenn diese Invariante gilt; er darf zur Ersetzung eines tatsächlich verlorenen ACKs bleiben. Der DATA-Sender benötigt seinen Timer weiterhin.

Eine gezielte Korrektur vor der Revision

Noel Chiappa nahm die Korrektur im Mai 1992 in eine Protokollrevision auf. RFC 1350 erschien im Juli, ersetzte RFC 783 und vermerkte die Änderung. RFC 1123 hatte das notwendige Hostverhalten bereits 1989 festgelegt; die spätere Revision führte es in die TFTP-Spezifikation ein. Daraus lässt sich nicht ableiten, wann jede einzelne Implementierung aktualisiert wurde.

Spätere Optionen lösten ein anderes Problem. Größere Blöcke und mehrere gleichzeitig ausstehende Blöcke steigern den Durchsatz, wenn Stop-and-wait zu langsam ist. Sie ersetzen nicht die Regel gegen die Wiederholung nach einem alten ACK. TFTP zeigt, dass ein minimalistisches Paketformat Komplexität in die Zustandsübergänge verlagern kann. Die Korrektur ließ das Ein-Block-Modell bestehen und entfernte eine Antwort, die Duplikate vervielfachte.

Sources