6.4 TCP Layer Actions (TCP-Schicht-Aktionen)
6.4 TCP Layer Actions (TCP-Schicht-Aktionen)
Die TCP-Schicht muss die PMTU für das Ziel einer Verbindung verfolgen; sie sollte keine Datagramme senden, die größer sind als dies. Eine einfache Implementierung könnte jedes Mal, wenn sie ein neues Segment erstellt, die IP-Schicht nach diesem Wert fragen (unter Verwendung der in [1] beschriebenen GET_MAXSIZES-Schnittstelle), aber dies könnte ineffizient sein. Darüber hinaus berechnen und cachen TCP-Implementierungen, die dem "slow-start" (langsamer Start) Stauungsvermeidungsalgorithmus [4] folgen, typischerweise mehrere andere von der PMTU abgeleitete Werte. Es kann einfacher sein, eine asynchrone Benachrichtigung zu erhalten, wenn sich die PMTU ändert, damit diese Variablen aktualisiert werden können.
Eine TCP-Implementierung muss auch den von ihrem Peer empfangenen MSS-Wert speichern (der standardmäßig 536 beträgt) und darf unabhängig von der PMTU kein Segment senden, das größer als diese MSS ist. In 4.xBSD-abgeleiteten Implementierungen erfordert dies das Hinzufügen eines zusätzlichen Feldes zum TCP-Zustandsdatensatz.
Schließlich bedeutet es, wenn eine Datagram Too Big Nachricht empfangen wird, dass ein Datagramm von dem Router verworfen wurde, der die ICMP-Nachricht gesendet hat. Es reicht aus, dies wie jedes andere verworfene Segment zu behandeln und zu warten, bis der Neuübertragungstimer abläuft, um die Neuübertragung des Segments zu veranlassen. Wenn der PMTU Discovery Prozess mehrere Schritte erfordert, um die richtige PMTU zu schätzen, könnte dies die Verbindung um viele Rundlaufzeiten verzögern.
Alternativ könnte die Neuübertragung als sofortige Reaktion auf eine Benachrichtigung erfolgen, dass sich die Path MTU geändert hat, aber nur für die spezifische Verbindung, die durch die Datagram Too Big Nachricht angegeben wird. Die in der Neuübertragung verwendete Datagrammgröße sollte natürlich nicht größer als die neue PMTU sein.
Hinweis: Man DARF NICHT als Reaktion auf jede Datagram Too Big Nachricht neu übertragen, da ein Burst mehrerer übergroßer Segmente zu mehreren solchen Nachrichten und damit zu mehreren Neuübertragungen derselben Daten führen wird. Wenn die neue geschätzte PMTU immer noch falsch ist, wiederholt sich der Prozess, und es gibt ein exponentielles Wachstum der Anzahl überflüssiger gesendeter Segmente!
Dies bedeutet, dass die TCP-Schicht in der Lage sein muss zu erkennen, wann eine Datagram Too Big Benachrichtigung tatsächlich die PMTU verringert, die sie bereits zum Senden eines Datagramms auf der gegebenen Verbindung verwendet hat, und sollte alle anderen Benachrichtigungen ignorieren.
Moderne TCP-Implementierungen integrieren "congestion avoidance" (Stauungsvermeidung) und "slow-start" (langsamer Start) Algorithmen zur Leistungsverbesserung [4]. Im Gegensatz zu einer durch ein TCP-Neuübertragungstimeout verursachten Neuübertragung sollte eine durch eine Datagram Too Big Nachricht verursachte Neuübertragung das Stauungsfenster nicht ändern. Sie sollte jedoch den Slow-Start-Mechanismus auslösen (d.h., es sollte nur ein Segment neu übertragen werden, bis Bestätigungen wieder eintreffen beginnen).
Die TCP-Leistung kann reduziert werden, wenn die maximale Fenstergröße des Senders kein exaktes Vielfaches der verwendeten Segmentgröße ist (dies ist nicht die Stauungsfenstergröße, die immer ein Vielfaches der Segmentgröße ist). In vielen Systemen (wie denen, die von 4.2BSD abgeleitet sind) wird die Segmentgröße oft auf 1024 Oktette gesetzt, und die maximale Fenstergröße (der "send space" (Sendebereich)) ist normalerweise ein Vielfaches von 1024 Oktetten, sodass die richtige Beziehung standardmäßig besteht. Wenn jedoch PMTU Discovery verwendet wird, ist die Segmentgröße möglicherweise kein Submultiplikator des Sendebereichs, und sie kann sich während einer Verbindung ändern; dies bedeutet, dass die TCP-Schicht möglicherweise die Übertragungsfenstergröße ändern muss, wenn PMTU Discovery den PMTU-Wert ändert. Die maximale Fenstergröße sollte auf das größte Vielfache der Segmentgröße (PMTU - 40) gesetzt werden, das kleiner oder gleich der Pufferbereichsgröße des Senders ist.
PMTU Discovery beeinflusst nicht den in der TCP MSS Option gesendeten Wert, da dieser Wert vom anderen Ende der Verbindung verwendet wird, das möglicherweise einen nicht verwandten PMTU-Wert verwendet.