Zusammenfassung

  • RFC 1016 schlug SQuID vor: Das IP-Modul des Quellhosts sollte für kürzlich kontaktierte Ziele eine Verzögerung D zwischen Datagrammen speichern. Normalerweise war D null; nur verlangsamte Ziele belegten einen Eintrag.
  • Die Beispielwerte setzten D nach einem Warnereignis auf mindestens 75 ms, erhöhten es bei einem weiteren Ereignis um 20 ms, fassten Warnungen in zwei Sekunden zusammen und senkten es bei anstehenden Daten nach einer geeigneten Sekunde um 1 ms. Die Autoren untersuchten das Verfahren in einer C-Simulation.

Ein schnelles lokales Netz konnte Daten an ein Gateway liefern, als gäbe es hinter ihm ebenfalls eine breite Straße. Dort konnte aber eine Leitung mit 56 kb/s warten. W. Prue und Jon Postel rechneten im RFC 1016 vor: Wenn ein Megabyte für eine solche Leitung aufgestaut war, wartete das letzte Datagramm über zwei Minuten auf seinen Abgang. Bei Platzmangel konnte ein Gateway Pakete verwerfen und dem Quellhost per ICMP Source Quench melden, er solle zum betroffenen Ziel langsamer senden. Die Meldung lieferte den Anlass, aber keinen Zeigerstand für die Stoppuhr.

Diesen Zeigerstand sollte SQuID liefern, ausgeschrieben Source Quench Introduced Delay. Das IP-Modul des Senders führte für ein Ziel eine Zeit D zwischen zwei Datagrammen. Der Normalwert war null. Für kürzlich kontaktierte Ziele mit positivem D wurde ein Eintrag gespeichert; die anderen brauchten keinen. Während ein Ziel warten musste, konnte ein Paket für ein anderes Ziel vorankommen. Die Engstelle auf einer Route verwandelte sich so nicht in eine allgemeine Ausgangssperre.

Der Vorschlag drückte kräftig auf die Bremse und löste sie behutsam. Nach einem Source-Quench-Ereignis nahm D den größeren Wert aus dem bisherigen D plus 20 Millisekunden und einem Mindestwert von 75 Millisekunden an. Mehrere Warnungen innerhalb von zwei Sekunden galten als ein Ereignis. Ein Gateway, das einen ganzen Schwall meldete, sollte den Host nicht mit jedem einzelnen Ruf weiter abbremsen. War nach der letzten Senkung eine passende Sekunde vergangen und gab es Daten zu senden, sank D um eine Millisekunde, höchstens bis null. Für ein gerade stilles Ziel lief keine automatische Vergebung im Hintergrund.

Die Zeitwerte wirken klein, bis man sie zwischen jedes Datagramm einer schnellen Quelle setzt. Eine kurze Pause wiederholt sich dann so oft, dass eine Salve nicht mehr in einem Atemzug am schmalen Ausgang ankommt. Prue und Postel nannten ihr Memorandum selbst ein verrücktes Ideenpapier, das zur Diskussion aufforderte. Mit D, dem Zweiminutenfenster und den Schritten von 20 und 1 Millisekunde hatte die Idee bereits Stellschrauben, über die ein Implementierer konkret reden konnte.

Auch für das Gateway gab es einen Plan mit Stufen. Bei den Beispielschwellen sollte es ab 70 Prozent Füllstand Source Quench senden, das betreffende Datagramm aber noch weiterleiten. Bei 95 Prozent sollte es Daten verwerfen. Die Warnungen sollten bis unter eine untere Marke von 50 Prozent weiterlaufen. Damit bekam der Sender ein Signal, bevor die Schlange vollständig überlief, und das Signal verstummte erst nach spürbarer Entlastung. Das Gateway beobachtete seine Warteschlange; der Quellhost bestimmte den Zeitpunkt seiner nächsten Abfahrten.

Die Autoren bauten ein Internetmodell in C, um diese Arbeitsteilung mit TCP-Verkehr zu prüfen. Zwei lokale Netze mit je 10 Mb/s lagen an den Enden einer 56-kb/s-Strecke. Das Modell schickte Datagramme von 512 Bytes durch Warteschlangen mit festem Routing; Fragmentierung und TTL-Verhalten fehlten darin. Alle getesteten Verfahren schwankten. Wurde D nur vorsichtig erhöht und schnell gesenkt, blieb die Last zu lange über dem, was das Netz aufnehmen konnte. Eine deutlichere Erhöhung und langsame Verringerung sah in dieser Simulation besser aus. Warnungen in einem kurzen Schwall mussten zusammengefasst werden.

Eine Salve von zwanzig Datagrammen macht den Konflikt greifbar. Unter den Modellannahmen des RFC erreichten sie das Gateway in 81 Millisekunden. Die nächste Strecke brauchte etwa 73 Millisekunden pro Datagramm. Bei der gewählten Warteschlangengröße gingen die Nummern 17 bis 20 der Salve verloren. Das TCP-Fenster erlaubte zwanzig Sendungen; die Leitung dahinter hatte deshalb noch lange keinen Platz für alle zwanzig auf einmal. SQuID wollte die Abfahrten an der Quelle entzerren, ehe die Pakete vor der Engstelle Schlange standen.

Viele TCP-Implementierungen erhielten laut RFC aus IP und ICMP keine klar definierte Source-Quench-Benachrichtigung. Die Reaktion im Quell-IP anzusiedeln, gab dem Warnsignal einen unmittelbaren Weg zur Sendereihenfolge. Die Simulation deutete darauf hin, dass frühe Warnungen vor dem Verwerfen den effektiven Durchsatz verbessern könnten. Ihr festes Routing und der vereinfachte Verkehr begrenzten die Aussage; Messungen in laufenden Netzen wären der nächste Beleg. Die eigentliche Pointe bleibt die Zuständigkeit: Das Gateway durfte Stau melden. Die Millisekunden musste der Sender selbst festlegen.