7. The Probing Method (Die Sondierungsmethode)
Dieser Abschnitt beschreibt die Details der MTU-Sondierungsmethode, einschließlich wie Sondierungen gesendet werden und Fehleranzeigen verarbeitet werden, die notwendig sind, um nach dem Path MTU zu suchen.
7.1. Paketgrößenbereiche
Dieses Dokument beschreibt die Sondierungsmethode unter Verwendung von drei Zustandsvariablen:
search_low: Die kleinste nützliche Sondierungsgröße minus eins. Das Netzwerk wird erwartet, Pakete der Größe search_low liefern zu können.
search_high: Die größte nützliche Sondierungsgröße. Pakete der Größe search_high werden erwartet, zu groß für das Netzwerk zu sein, um sie zu liefern.
eff_pmtu: Der effektive PMTU für diesen Fluss. Dies ist das größte Nicht-Sondierungspaket, das von PLPMTUD für den Pfad erlaubt ist.
search_low eff_pmtu search_high
| | |
...------------------------>
Nicht-Sondierungsgrößenbereich
<-------------------------------------->
Sondierungsgrößenbereich
Beim Übertragen von Nicht-Sondierungen SOLLTE die Paketisierungsschicht Pakete einer Größe kleiner oder gleich eff_pmtu erstellen.
Beim Übertragen von Sondierungen MUSS die Paketisierungsschicht eine Sondierungsgröße auswählen, die größer als search_low und kleiner oder gleich search_high ist.
Beim Aufwärtssondieren ist eff_pmtu immer gleich search_low. In anderen Zuständen, wie Anfangsbedingungen, nach ICMP PTB-Nachrichtenverarbeitung oder nach PLPMTUD auf einem anderen Fluss, der dieselbe Pfaddarstellung teilt, kann eff_pmtu von search_low verschieden sein. Normalerweise wird eff_pmtu größer oder gleich search_low und kleiner als search_high sein. Es wird allgemein erwartet, aber nicht erforderlich, dass die Sondierungsgröße größer als eff_pmtu ist.
Für Anfangsbedingungen, wenn keine Informationen über den Pfad vorhanden sind, kann eff_pmtu größer als search_low sein. Der Anfangswert von search_low SOLLTE konservativ niedrig sein, aber die Leistung kann besser sein, wenn eff_pmtu bei einem höheren, weniger konservativen Wert beginnt. Siehe Abschnitt 7.2.
Wenn eff_pmtu größer als search_low ist, ist es explizit erlaubt, Nicht-Sondierungspakete größer als search_low zu senden. Wenn ein solches Paket bestätigt wird, ist es effektiv eine "implizite Sondierung" und search_low SOLLTE auf die Größe des bestätigten Pakets erhöht werden. Wenn jedoch eine "implizite Sondierung" verloren geht, MUSS sie NICHT als Sondierungsfehler behandelt werden, wie eine echte Sondierung behandelt würde. Wenn eff_pmtu zu groß ist, wird diese Bedingung nur mit ICMP PTB-Nachrichten oder Black-Hole-Erkennung erkannt (siehe Abschnitt 7.7).
7.2. Auswahl der Anfangswerte
Der Anfangswert für search_high SOLLTE das größtmögliche Paket sein, das möglicherweise vom Fluss unterstützt wird. Dies kann durch den lokalen Interface-MTU, durch einen expliziten Protokollmechanismus wie die TCP MSS-Option oder durch eine intrinsische Grenze wie die Größe eines Protokolllängenfelds begrenzt sein. Darüber hinaus KANN der Anfangswert für search_high durch eine Konfigurationsoption begrenzt werden, um Sondierungen über eine bestimmte maximale Größe zu verhindern. Search_high wird wahrscheinlich dasselbe wie der anfängliche Path MTU sein, wie vom klassischen Path MTU Discovery-Algorithmus berechnet.
Es wird EMPFOHLEN, dass search_low anfänglich auf eine MTU-Größe gesetzt wird, die wahrscheinlich in einer sehr breiten Palette von Umgebungen funktioniert. Angesichts der heutigen Technologien ist ein Wert von 1024 Bytes wahrscheinlich sicher genug. Der Anfangswert für search_low SOLLTE konfigurierbar sein.
Ordnungsgemäß funktionierende Path MTU Discovery ist entscheidend für den robusten und effizienten Betrieb des Internets. Jede größere Änderung (wie in diesem Dokument beschrieben) hat das Potenzial, sehr störend zu sein, wenn sie unerwartete Änderungen im Protokollverhalten verursacht. Die Auswahl des Anfangswerts für eff_pmtu bestimmt, inwieweit das Verhalten einer PLPMTUD-Implementierung der klassischen PMTUD in Fällen ähnelt, in denen die klassische Methode ausreichend ist.
Eine konservative Konfiguration wäre, eff_pmtu auf search_high zu setzen und sich auf ICMP PTB-Nachrichten zu verlassen, um eff_pmtu nach Bedarf nach unten zu setzen. In dieser Konfiguration ist die klassische PMTUD voll funktionsfähig und PLPMTUD wird nur aufgerufen, um von ICMP-Black-Holes durch das in Abschnitt 7.7 beschriebene Verfahren zu erholen.
In einigen Fällen, in denen bekannt ist, dass die klassische PMTUD wahrscheinlich fehlschlägt (z. B. wenn ICMP PTB-Nachrichten aus Sicherheitsgründen administrativ deaktiviert sind), vermeidet die Verwendung eines kleinen anfänglichen eff_pmtu die kostspieligen Timeouts, die für die Black-Hole-Erkennung erforderlich sind. Der Kompromiss ist, dass die Verwendung eines kleineren als notwendigen anfänglichen eff_pmtu zu reduzierter Leistung führen könnte.
Beachten Sie, dass der anfängliche eff_pmtu jeder Wert im Bereich search_low bis search_high sein kann. Ein anfänglicher eff_pmtu von 1400 Bytes könnte ein guter Kompromiss sein, da er für fast alle Tunnel über alle gängigen Netzwerkgeräte sicher wäre und dennoch nahe am optimalen MTU für die Mehrheit der Pfade im heutigen Internet liegt. Dies könnte durch die Verwendung einiger Statistiken anderer kürzlicher Flüsse verbessert werden: Zum Beispiel könnte der anfängliche eff_pmtu für einen Fluss auf den Median der Sondierungsgröße für alle kürzlich erfolgreichen Sondierungen gesetzt werden.
Da die Kosten von PLPMTUD von den protokollspezifischen Overheads der Generierung und Verarbeitung von Sondierungen dominiert werden, ist es wahrscheinlich wünschenswert, dass jedes Protokoll seine eigenen Heuristiken zur Auswahl des anfänglichen eff_pmtu hat. Es ist besonders wichtig, dass verbindungslose Protokolle und andere Protokolle, die möglicherweise keine klaren Hinweise auf ICMP-Black-Holes erhalten, konservative (kleinere) Anfangswerte für eff_pmtu verwenden, wie in Abschnitt 10.3 beschrieben.
Es SOLLTE pro-Protokoll- und pro-Route-Konfigurationsoptionen geben, um Anfangswerte für eff_pmtu und andere PLPMTUD-Zustandsvariablen zu überschreiben.
7.3. Auswahl der Sondierungsgröße
Die Sondierung kann eine Größe irgendwo im oben beschriebenen "Sondierungsgrößenbereich" haben. Eine Reihe von Faktoren beeinflusst jedoch die Auswahl einer geeigneten Größe. Eine einfache Strategie könnte eine binäre Suche sein, die den Sondierungsgrößenbereich mit jeder Sondierung halbiert. Für einige Protokolle wie TCP sind fehlgeschlagene Sondierungen jedoch teurer als erfolgreiche, da Daten in einer fehlgeschlagenen Sondierung erneut übertragen werden müssen. Für solche Protokolle könnte eine Strategie, die die Sondierungsgröße in kleineren Inkrementen erhöht, einen niedrigeren Overhead haben. Für viele Protokolle, sowohl auf als auch über der Paketisierungsschicht, kann der Nutzen der Erhöhung von MTU-Größen einer Stufenfunktion folgen, sodass es nicht vorteilhaft ist, innerhalb bestimmter Bereiche überhaupt zu sondieren.
Als Optimierung kann es angemessen sein, bei bestimmten gängigen oder erwarteten MTU-Größen zu sondieren, zum Beispiel 1500 Bytes für Standard-Ethernet oder 1500 Bytes minus Header-Größen für Tunnelprotokolle.
Einige Protokolle können andere Mechanismen verwenden, um die Sondierungsgrößen zu wählen. Zum Beispiel könnten Protokolle mit bestimmten natürlichen Datenblockgrößen einfach Nachrichten aus einer Anzahl von Blöcken zusammenstellen, bis die Gesamtgröße kleiner als search_high ist, und wenn möglich größer als search_low.
Jede Paketisierungsschicht MUSS bestimmen, wann die Sondierung konvergiert ist, d. h. wenn der Sondierungsgrößenbereich klein genug ist, dass weitere Sondierungen ihren Kosten nicht mehr wert sind. Wenn die Sondierung konvergiert ist, SOLLTE ein Timer gesetzt werden. Wenn der Timer abläuft, sollte search_high auf seinen Anfangswert zurückgesetzt werden (oben beschrieben), damit die Sondierung fortgesetzt werden kann. Wenn sich der Pfad ändert und den Path MTU erhöht, wird der Fluss schließlich davon profitieren. Der Wert für diesen Timer MUSS NICHT weniger als 5 Minuten betragen und wird empfohlen, 10 Minuten zu sein, gemäß RFC 1981.
7.4. Sondierungsvoraussetzungen
Vor dem Senden einer Sondierung MUSS der Fluss mindestens die folgenden Bedingungen erfüllen:
- Es gibt keine ausstehenden Sondierungen oder Verluste.
- Wenn die letzte Sondierung fehlgeschlagen ist oder nicht schlüssig war, dann ist das Sondierungs-Timeout abgelaufen (siehe Abschnitt 7.6.2).
- Das verfügbare Fenster ist größer als die Sondierungsgröße.
- Für ein Protokoll, das In-Band-Daten für Sondierungen verwendet, sind genügend Daten verfügbar, um die Sondierung zu senden.
Darüber hinaus haben die zeitnahen Verlusterkennungsalgorithmen in den meisten Protokollen Voraussetzungen, die VOR dem Senden einer Sondierung erfüllt werden SOLLTEN. Zum Beispiel ist TCP Fast Retransmit nicht robust, es sei denn, es gibt ausreichend Segmente, die einer Sondierung folgen; das heißt, der Absender SOLLTE genügend Daten in der Warteschlange und ein ausreichendes Empfängerfenster haben, um die Sondierung plus mindestens Tcprexmtthresh [RFC2760] zusätzliche Segmente zu senden. Diese Einschränkung kann Sondierungen in einigen Protokollzuständen hemmen, wie zu nahe am Ende einer Verbindung oder wenn das Fenster zu klein ist.
Protokolle KÖNNEN das Senden von Nicht-Sondierungen verzögern, um genügend Daten anzusammeln, um die Voraussetzungen für Sondierungen zu erfüllen. Der verzögerte Sendungsalgorithmus SOLLTE eine selbstskalierende Technik verwenden, um die Zeit, die die Daten verzögert werden, angemessen zu begrenzen. Zum Beispiel können die zurückkehrenden ACKs verwendet werden, um zu verhindern, dass das Fenster um mehr als die für die Sondierung benötigte Datenmenge fällt.
7.5. Durchführung einer Sondierung
Sobald eine Sondierungsgröße im geeigneten Bereich ausgewählt wurde und die oben genannten Voraussetzungen erfüllt sind, KANN die Paketisierungsschicht eine Sondierung durchführen. Dazu erstellt sie ein Sondierungspaket, sodass seine Größe, einschließlich der äußersten IP-Header, gleich der Sondierungsgröße ist. Nach dem Senden der Sondierung wartet sie auf eine Antwort, die eines der folgenden Ergebnisse haben wird:
Erfolg: Die Sondierung wird als vom Remote-Host empfangen bestätigt.
Fehler: Ein Protokollmechanismus zeigt an, dass die Sondierung verloren ging, aber keine Pakete im führenden oder nachfolgenden Fenster verloren gingen.
Timeout-Fehler: Ein Protokollmechanismus zeigt an, dass die Sondierung verloren ging und keine Pakete im führenden Fenster verloren gingen, kann jedoch nicht bestimmen, ob Pakete im nachfolgenden Fenster verloren gingen. Zum Beispiel wird der Verlust durch ein Timeout erkannt und Go-Back-N-Wiederübertragung wird verwendet.
Nicht schlüssig: Die Sondierung ging zusätzlich zu anderen Paketen in den führenden oder nachfolgenden Fenstern verloren.
7.6. Antwort auf Sondierungsergebnisse
Wenn eine Sondierung abgeschlossen ist, SOLLTE das Ergebnis wie folgt verarbeitet werden, kategorisiert nach dem Ergebnistyp der Sondierung.
7.6.1. Sondierungserfolg
Wenn die Sondierung zugestellt wird, ist dies ein Hinweis darauf, dass der Path MTU mindestens so groß wie die Sondierungsgröße ist. Setzen Sie search_low auf die Sondierungsgröße. Wenn die Sondierungsgröße größer als eff_pmtu ist, erhöhen Sie eff_pmtu auf die Sondierungsgröße. Die Sondierungsgröße könnte kleiner als eff_pmtu sein, wenn der Fluss nicht den vollen MTU des Pfads verwendet, weil er einer anderen Einschränkung unterliegt, wie verfügbare Daten in einer interaktiven Sitzung.
Beachten Sie, dass wenn die Pakete eines Flusses über mehrere Pfade geroutet werden oder über einen Pfad mit einem nicht-deterministischen MTU, die Zustellung eines einzelnen Sondierungspakets nicht anzeigt, dass alle Pakete dieser Größe zugestellt werden. Um in einem solchen Fall robust zu sein, SOLLTE die Paketisierungsschicht MTU-Verifizierung durchführen, wie in Abschnitt 7.8 beschrieben.
7.6.2. Sondierungsfehler
Wenn nur die Sondierung verloren geht, wird dies als Hinweis behandelt, dass der Path MTU kleiner als die Sondierungsgröße ist. In diesem Fall allein SOLLTE der Verlust NICHT als Überlastungssignal interpretiert werden.
In Abwesenheit anderer Hinweise setzen Sie search_high auf die Sondierungsgröße minus eins. Der eff_pmtu könnte größer als die Sondierungsgröße sein, wenn der Fluss nicht den vollen MTU des Pfads verwendet, weil er einer anderen Einschränkung unterliegt, wie verfügbare Daten in einer interaktiven Sitzung. Wenn eff_pmtu größer als die Sondierungsgröße ist, MUSS eff_pmtu auf nicht größer als search_high reduziert werden und SOLLTE auf search_low reduziert werden, da eff_pmtu als ungültig bestimmt wurde, ähnlich wie nach einem vollständigen Timeout (siehe Abschnitt 7.7).
Wenn eine ICMP PTB-Nachricht empfangen wird, die dem Sondierungspaket entspricht, dann KÖNNEN search_high und eff_pmtu aus dem in der Nachricht angegebenen MTU-Wert gesetzt werden. Beachten Sie, dass die ICMP-Nachricht entweder vor oder nach der Protokollverlustanzeige empfangen werden kann.
Ein Sondierungsfehlerereignis ist die eine Situation, unter der die Paketisierungsschicht Verlust als Überlastungssignal ignorieren SOLLTE. Da es ein kleines Risiko gibt, dass die Unterdrückung der Überlastungskontrolle unerwartete Folgen haben könnte (selbst für einen isolierten Verlust), ist es ERFORDERLICH, dass Sondierungsfehlerereignisse seltener auftreten als die normale Periode für Verluste unter Standard-Überlastungskontrolle. Insbesondere nach einem Sondierungsfehlerereignis und unterdrückter Überlastungskontrolle DARF PLPMTUD NICHT erneut sondieren, bis ein Intervall, das größer ist als das erwartete Intervall zwischen Überlastungskontrollereignissen. Siehe Abschnitt 4 für Details. Die einfachste Schätzung des Intervalls bis zum nächsten Überlastungsereignis ist dieselbe Anzahl von Round-Trips wie das aktuelle Überlastungsfenster in Paketen.
7.6.3. Sondierungs-Timeout-Fehler
Wenn der Verlust mit einem Timeout erkannt und mit Go-Back-N-Wiederübertragung repariert wurde, wird eine Überlastungsfensterreduktion notwendig sein. Der relativ hohe Preis einer fehlgeschlagenen Sondierung in diesem Fall kann ein längeres Zeitintervall bis zur nächsten Sondierung rechtfertigen. Ein Zeitintervall, das das Fünffache des Nicht-Timeout-Fehlerfalls (Abschnitt 7.6.2) ist, wird EMPFOHLEN.
7.6.4. Sondierung nicht schlüssig
Das Vorhandensein anderer Verluste in der Nähe des Verlusts der Sondierung kann darauf hindeuten, dass die Sondierung aufgrund von Überlastung und nicht aufgrund einer MTU-Begrenzung verloren ging. In diesem Fall SOLLTEN die Zustandsvariablen eff_pmtu, search_low und search_high NICHT aktualisiert werden, und die Sondierung derselben Größe SOLLTE erneut versucht werden, sobald die Sondierungsvoraussetzungen erfüllt sind (d. h. sobald die Paketisierungsschicht keine ausstehenden nicht wiederhergestellten Verluste hat). An diesem Punkt ist es besonders angemessen, erneut zu sondieren, da das Überlastungsfenster des Flusses an seinem niedrigsten Punkt sein wird, was die Wahrscheinlichkeit von Überlastungsverlusten minimiert.
7.7. Vollständiger Timeout
Unter allen Bedingungen SOLLTE ein vollständiger Timeout (auch als "persistenter Timeout" in anderen Dokumenten bekannt) als Hinweis auf ein erheblich störendes Ereignis im Netzwerk behandelt werden, wie ein Routerausfall oder eine Routingänderung zu einem Pfad mit einem kleineren MTU. Für TCP tritt dies auf, wenn der R1-Timeout-Schwellenwert, der von [RFC1122] beschrieben wird, abläuft.
Wenn es einen vollständigen Timeout gibt und keine ICMP-Nachricht, die einen Grund anzeigt (PTB, Netz nicht erreichbar usw., oder die ICMP-Nachricht wurde aus irgendeinem Grund ignoriert), ist die EMPFOHLENE erste Wiederherstellungsaktion, dies als erkanntes ICMP-Black-Hole zu behandeln, wie in [RFC2923] definiert.
Die Antwort auf ein erkanntes Black-Hole hängt von den aktuellen Werten für search_low und eff_pmtu ab. Wenn eff_pmtu größer als search_low ist, setzen Sie eff_pmtu auf search_low. Andernfalls setzen Sie sowohl eff_pmtu als auch search_low auf den Anfangswert für search_low. Bei zusätzlichen aufeinanderfolgenden Timeouts SOLLTEN search_low und eff_pmtu halbiert werden, mit einer unteren Grenze von 68 Bytes für IPv4 und 1280 Bytes für IPv6. Noch niedrigere untere Grenzen KÖNNEN erlaubt sein, um begrenzten Betrieb über Links mit MTUs zu unterstützen, die kleiner sind als von den IP-Spezifikationen erlaubt.
7.8. MTU-Verifizierung
Es ist möglich, dass ein Fluss gleichzeitig mehrere Pfade durchläuft, aber eine Implementierung wird nur in der Lage sein, eine einzelne Pfaddarstellung für den Fluss zu behalten. Wenn die Pfade unterschiedliche MTUs haben, führt das Speichern des minimalen MTU aller Pfade in der Pfaddarstellung des Flusses zu korrektem Verhalten. Wenn ICMP PTB-Nachrichten zugestellt werden, funktioniert die klassische PMTUD in dieser Situation korrekt.
Wenn die ICMP-Zustellung fehlschlägt und die klassische PMTUD bricht, verlässt sich die Verbindung ausschließlich auf PLPMTUD. In diesem Fall kann PLPMTUD ebenfalls fehlschlagen, da es annimmt, dass ein Fluss einen Pfad mit einem einzelnen MTU durchläuft. Eine Sondierung mit einer Größe größer als das Minimum, aber kleiner als das Maximum der Path MTUs kann erfolgreich sein. Wenn jedoch der effektive PMTU des Flusses erhöht wird, wird die Verlustrate erheblich ansteigen. Der Fluss kann immer noch Fortschritte machen, aber die resultierende Verlustrate wird wahrscheinlich inakzeptabel sein. Zum Beispiel würden bei Verwendung von bidirektionalem Round-Robin-Striping 50% der vollständig großen Pakete verworfen werden.
Striping auf diese Weise ist aus betrieblichen Gründen oft aus anderen Gründen unerwünscht (z. B. aufgrund von Paketneuordnung) und wird normalerweise vermieden, indem jeder Fluss auf einen einzelnen Pfad gehasht wird. Um die Robustheit zu erhöhen, SOLLTE eine Implementierung jedoch eine Form der MTU-Verifizierung implementieren, sodass, wenn die Erhöhung von eff_pmtu zu einem starken Anstieg der Verlustrate führt, sie auf die Verwendung eines niedrigeren MTU zurückfällt.
Eine EMPFOHLENE Strategie wäre, den Wert von eff_pmtu vor der Erhöhung zu speichern. Dann, wenn die Verlustrate über einen Schwellenwert für einen Zeitraum ansteigt (z. B. ist die Verlustrate höher als 10% über mehrere Retransmission Timeout (RTO)-Intervalle), wird der neue MTU als falsch betrachtet. Der gespeicherte Wert von eff_pmtu SOLLTE wiederhergestellt werden, und search_high sollte auf dieselbe Weise wie bei einem Sondierungsfehler reduziert werden. PLPMTUD-Implementierungen SOLLTEN MTU-Verifizierung implementieren.