10. Specific Packetization Layers (Spezifische Paketisierungsschichten)

Alle Paketisierungsschicht-Protokolle müssen alle in Abschnitt 6 diskutierten Probleme berücksichtigen. Für viele Protokolle ist es unkompliziert, diese Probleme anzugehen. Dieser Abschnitt diskutiert spezifische Details zur Implementierung von PLPMTUD mit einigen Protokollen. Es wird gehofft, dass die hier gegebenen Beschreibungen ausreichende Illustrationen für Implementierer sein werden, um sich an zusätzliche Protokolle anzupassen.

10.1. Sondierungsmethode mit TCP

TCP hat keinen Mechanismus, um In-Band-Daten von Padding zu unterscheiden. Daher muss TCP Sondierungen durch angemessene Segmentierung von Daten generieren. Es gibt zwei Ansätze zur Segmentierung: überlappend und nicht überlappend.

Nicht-überlappende Methode

Bei der nicht-überlappenden Methode werden Daten so segmentiert, dass die Sondierung und alle nachfolgenden Segmente keine überlappenden Daten enthalten. Wenn die Sondierung verloren geht, wird die "Sondierungslücke" eine vollständige Sondierungsgröße minus Header sein. Daten in der Sondierungslücke müssen mit mehreren kleineren Segmenten erneut übertragen werden.

TCP-Sequenznummer

t   <---->
i         <-------->           (Sondierung)
m                   <---->
e
                .
                .                (Sondierung verloren)
                .

            <---->               (Sondierungslücke erneut übertragen)
                  <-->

Überlappende Methode

Ein alternativer Ansatz besteht darin, nachfolgende Daten zu senden, die die Sondierung überlappen, sodass die Sondierungslücke in der Länge gleich dem aktuellen MSS ist. Im Falle einer erfolgreichen Sondierung hat dies zusätzlichen Overhead, da einige Daten zweimal gesendet werden, aber es muss nur ein Segment nach einer verlorenen Sondierung erneut übertragen werden. Wenn eine Sondierung erfolgreich ist, werden wahrscheinlich einige Duplikat-Bestätigungen aufgrund der gesendeten Duplikatdaten generiert. Es ist wichtig, dass diese Duplikat-Bestätigungen Fast Retransmit nicht auslösen. Daher SOLLTE eine Implementierung, die diesen Ansatz verwendet, die Sondierungsgröße auf das Dreifache des aktuellen MSS begrenzen (was höchstens 2 Duplikat-Bestätigungen verursacht) oder ihren Duplikat-Bestätigungsschwellenwert für Daten unmittelbar nach einer erfolgreichen Sondierung angemessen anpassen.

TCP-Sequenznummer

t   <---->
i         <-------->           (Sondierung)
m               <---->
e                     <---->

                .
                .                (Sondierung verloren)
                .

            <---->               (Sondierungslücke erneut übertragen)

Die Wahl, welche Segmentierungsmethode verwendet werden soll, sollte auf dem basieren, was für eine bestimmte TCP-Implementierung am einfachsten und effizientesten ist.

10.2. Sondierungsmethode mit SCTP

Im Stream Control Transmission Protocol (SCTP) [RFC2960] schreibt die Anwendung Nachrichten an SCTP, das die Daten in kleinere "Chunks" aufteilt, die für die Übertragung über das Netzwerk geeignet sind. Jeder Chunk erhält eine Transmission Sequence Number (TSN). Sobald eine TSN übertragen wurde, kann SCTP die Chunkgröße nicht mehr ändern. SCTP-Multipfad-Unterstützung erfordert normalerweise, dass SCTP eine Chunkgröße wählt, sodass seine Nachrichten auf den kleinsten PMTU aller Pfade passen. Obwohl nicht erforderlich, können Implementierungen mehrere Datenchunks zusammenbündeln, um größere IP-Pakete zu erstellen, die auf Pfaden mit einem größeren PMTU gesendet werden. Beachten Sie, dass SCTP den PMTU auf jedem Pfad zum Peer unabhängig sondieren muss.

Die EMPFOHLENE Methode zur Generierung von Sondierungen besteht darin, einen Chunk, der nur aus Padding besteht, zu einer SCTP-Nachricht hinzuzufügen. Der in [RFC4820] definierte PAD-Chunk SOLLTE an einen HEARTBEAT (HB)-Chunk mit minimaler Länge angehängt werden, um ein Sondierungspaket zu erstellen. Diese Methode ist vollständig kompatibel mit allen aktuellen SCTP-Implementierungen.

SCTP KANN auch mit einer Methode ähnlich der oben beschriebenen TCP-Methode sondieren, wobei Inline-Daten verwendet werden. Die Verwendung einer solchen Methode hat den Vorteil, dass erfolgreiche Sondierungen keinen zusätzlichen Overhead haben; fehlgeschlagene Sondierungen erfordern jedoch die erneute Übertragung von Daten, was die Flussleistung beeinträchtigen kann.

10.3. Sondierungsmethode für IP-Fragmentierung

Es gibt einige Protokolle und Anwendungen, die normalerweise große Datagramme senden und sich auf IP-Fragmentierung verlassen, um sie zuzustellen. Es ist seit langem bekannt, dass dies einige unerwünschte Folgen hat [Kent87]. In jüngerer Zeit hat sich herausgestellt, dass IPv4-Fragmentierung für den allgemeinen Gebrauch im heutigen Internet nicht ausreichend robust ist. Das 16-Bit-IP-Identifikationsfeld ist nicht groß genug, um häufige falsch zugeordnete IP-Fragmente zu verhindern, und die TCP- und UDP-Prüfsummen reichen nicht aus, um zu verhindern, dass die resultierenden beschädigten Daten an höhere Protokollschichten geliefert werden [frag-errors].

Wie in Abschnitt 8 erwähnt, könnten Datagrammprotokolle (wie UDP) sich auf IP-Fragmentierung als Paketisierungsschicht verlassen. Die Verwendung von IP-Fragmentierung zur Implementierung von PLPMTUD ist jedoch problematisch, da die IP-Schicht keinen Mechanismus hat, um zu bestimmen, ob die Pakete letztendlich zum entfernten Knoten geliefert werden, ohne direkte Beteiligung der Anwendung.

Um IP-Fragmentierung als Paketisierungsschicht unter einer unveränderten Anwendung zu unterstützen, SOLLTE eine Implementierung sich auf das in Abschnitt 5.2 beschriebene Path MTU-Sharing plus ein Zusatzprotokoll verlassen, um den Path MTU zu sondieren. Es gibt eine Reihe von Protokollen, die zu diesem Zweck verwendet werden könnten, wie ICMP ECHO und ECHO REPLY oder "traceroute"-Stil-UDP-Datagramme, die ICMP-Nachrichten auslösen. Die Verwendung von ICMP ECHO und ECHO REPLY wird sowohl Vorwärts- als auch Rückwärtspfade sondieren, sodass der Absender nur das Minimum der beiden nutzen kann. Andere Methoden, die nur den Vorwärtspfad sondieren, werden bevorzugt, wenn verfügbar.

Alle diese Ansätze haben eine Reihe potenzieller Robustheitsprobleme. Die wahrscheinlichsten Fehler sind auf Verluste zurückzuführen, die nicht mit MTU zusammenhängen (z. B. Knoten, die einige Protokolltypen verwerfen). Diese nicht-MTU-bezogenen Verluste können verhindern, dass PLPMTUD den MTU erhöht, was IP-Fragmentierung zwingt, einen kleineren MTU als notwendig zu verwenden. Da diese Fehler wahrscheinlich keine Interoperabilitätsprobleme verursachen, sind sie relativ harmlos.

Es existieren jedoch andere schwerwiegendere Fehlermodi, wie solche, die möglicherweise durch Middleboxes oder Router der oberen Schicht verursacht werden, die für verschiedene Protokolltypen oder Sitzungen unterschiedliche Pfade wählen. In solchen Umgebungen können Zusatzprotokolle legitimerweise einen anderen Path MTU als das primäre Protokoll erfahren. Wenn das Zusatzprotokoll einen größeren MTU als das primäre Protokoll findet, kann PLPMTUD einen MTU auswählen, der vom primären Protokoll nicht verwendet werden kann. Obwohl dies ein potenziell ernstes Problem ist, wird diese Art von Situation wahrscheinlich von einer großen Anzahl von Beobachtern als falsch angesehen, und es wird daher eine starke Motivation geben, sie zu korrigieren.

Da verbindungslose Protokolle möglicherweise nicht genügend Zustand behalten, um MTU-Black-Holes effektiv zu diagnostizieren, wäre es robuster, auf der Seite der Verwendung eines zu kleinen anfänglichen MTU zu irren (z. B. 1 kByte oder weniger), bevor ein Pfad gesondert wird, um den MTU zu messen. Aus diesem Grund SOLLTEN Implementierungen, die IP-Fragmentierung verwenden, einen anfänglichen eff_pmtu verwenden, der wie in Abschnitt 7.2 beschrieben ausgewählt wird, außer dass eine separate globale Steuerung für den Standard-Anfangswert eff_mtu für verbindungslose Protokolle verwendet wird.

Verbindungslose Protokolle führen auch ein zusätzliches Problem bei der Aufrechterhaltung des Pfadinformations-Caches ein: Es gibt keine Ereignisse, die Verbindungsaufbau und -abbau entsprechen, um den Cache selbst zu verwalten. Ein natürlicher Ansatz wäre, einen unveränderlichen Cache-Eintrag für den "Standardpfad" zu behalten, der einen eff_pmtu hat, der auf den Anfangswert für verbindungslose Protokolle festgelegt ist. Das Zusatz-Path MTU Discovery-Protokoll würde aufgerufen, sobald die Anzahl fragmentierter Datagramme zu einem bestimmten Ziel einen konfigurierbaren Schwellenwert erreicht (z. B. 5 Datagramme). Ein neuer Pfad-Cache-Eintrag würde erstellt, wenn das Zusatzprotokoll eff_pmtu aktualisiert, und auf der Grundlage eines Timers oder eines Least Recently Used Cache-Ersetzungsalgorithmus gelöscht.

10.4. Sondierungsmethode mit Anwendungen

Die Nachteile, sich auf IP-Fragmentierung und ein Zusatzprotokoll zu verlassen, um Path MTU Discovery durchzuführen, können überwunden werden, indem Path MTU Discovery innerhalb der Anwendung selbst implementiert wird, wobei das eigene Protokoll der Anwendung verwendet wird. Die Anwendung muss eine geeignete Methode zur Generierung von Sondierungen haben und einen genauen und zeitnahen Mechanismus, um zu bestimmen, ob die Sondierungen verloren gingen.

Idealerweise enthält das Anwendungsprotokoll eine leichtgewichtige Echo-Funktion, die die Nachrichtenzustellung bestätigt, plus einen Mechanismus zum Auffüllen der Nachrichten auf die gewünschte Sondierungsgröße, sodass das Padding nicht zurückgegeben wird. Diese Kombination (ähnlich dem SCTP HB plus PAD) wird EMPFOHLEN, da eine Anwendung den MTU jeder Richtung auf einem Pfad mit asymmetrischen MTUs separat messen kann.

Für Protokolle, die PLPMTUD nicht mit "Echo plus Padding" implementieren können, gibt es oft alternative Methoden zur Generierung von Sondierungen. Zum Beispiel kann das Protokoll ein Echo variabler Länge haben, das effektiv den minimalen MTU sowohl des Vorwärts- als auch des Rückwärtspfads misst, oder es kann eine Möglichkeit geben, Padding zu regulären Nachrichten hinzuzufügen, die echte Anwendungsdaten tragen. Es kann auch alternative Möglichkeiten geben, Anwendungsdaten zu segmentieren, um Sondierungen zu generieren, oder als letzter Ausweg kann es machbar sein, das Protokoll mit neuen Nachrichtentypen zu erweitern, die speziell zur Unterstützung von MTU Discovery entwickelt wurden.

Beachten Sie, dass, wenn es notwendig ist, neue Nachrichtentypen hinzuzufügen, um PLPMTUD zu unterstützen, der allgemeinste Ansatz darin besteht, ECHO- und PAD-Nachrichten hinzuzufügen, die die größtmögliche Freiheit in der Art und Weise ermöglichen, wie eine anwendungsspezifische Implementierung von PLPMTUD mit anderen Anwendungen und Protokollen auf demselben Endsystem interagiert.

Alle Anwendungssondierungstechniken erfordern die Fähigkeit, Nachrichten zu senden, die größer als der aktuelle eff_pmtu sind, wie in Abschnitt 9 beschrieben.