4. PAWS -- Protect Against Wrapped Sequence Numbers (PAWS -- Schutz gegen Überlauf von Sequenznummern)

4. PAWS: Protect Against Wrapped Sequence Numbers (PAWS: Schutz gegen Überlauf von Sequenznummern)

4.1 Introduction (Einführung)

Section 4.2 describes a simple mechanism to reject old duplicate segments that might corrupt an open TCP connection; we call this mechanism PAWS (Protect Against Wrapped Sequence numbers). PAWS operates within a single TCP connection, using state that is saved in the connection control block. Section 4.3 and Appendix C discuss the implications of the PAWS mechanism for avoiding old duplicates from previous incarnations of the same connection.

Abschnitt 4.2 beschreibt einen einfachen Mechanismus zum Ablehnen alter doppelter Segmente, die eine offene TCP-Verbindung beschädigen könnten; wir nennen diesen Mechanismus PAWS (Protect Against Wrapped Sequence numbers, Schutz gegen Überlauf von Sequenznummern). PAWS arbeitet innerhalb einer einzelnen TCP-Verbindung und verwendet Zustände, die im Verbindungssteuerblock gespeichert sind. Abschnitt 4.3 und Anhang C diskutieren die Auswirkungen des PAWS-Mechanismus zur Vermeidung alter Duplikate aus früheren Inkarnationen derselben Verbindung.

4.2 The PAWS Mechanism (Der PAWS-Mechanismus)

PAWS uses the same TCP Timestamps option as the RTTM mechanism described earlier, and assumes that every received TCP segment (including data and ACK segments) contains a timestamp SEG.TSval whose values are monotone non-decreasing in time. The basic idea is that a segment can be discarded as an old duplicate if it is received with a timestamp SEG.TSval less than some timestamp recently received on this connection.

PAWS verwendet dieselbe TCP Timestamps-Option wie der zuvor beschriebene RTTM-Mechanismus und geht davon aus, dass jedes empfangene TCP-Segment (einschließlich Daten- und ACK-Segmente) einen Zeitstempel SEG.TSval enthält, dessen Werte in der Zeit monoton nicht abnehmend sind. Die Grundidee ist, dass ein Segment als altes Duplikat verworfen werden kann, wenn es mit einem Zeitstempel SEG.TSval empfangen wird, der kleiner ist als ein kürzlich auf dieser Verbindung empfangener Zeitstempel.

In both the PAWS and the RTTM mechanism, the "timestamps" are 32-bit unsigned integers in a modular 32-bit space. Thus, "less than" is defined the same way it is for TCP sequence numbers, and the same implementation techniques apply. If s and t are timestamp values, s < t if 0 < (t - s) < 2**31, computed in unsigned 32-bit arithmetic.

Sowohl im PAWS- als auch im RTTM-Mechanismus sind die "Zeitstempel (timestamps)" 32-Bit-Ganzzahlen ohne Vorzeichen in einem modularen 32-Bit-Raum. Daher wird "kleiner als (less than)" auf dieselbe Weise definiert wie für TCP-Sequenznummern, und dieselben Implementierungstechniken gelten. Wenn s und t Zeitstempelwerte sind, gilt s < t, wenn 0 < (t - s) < 2**31, berechnet in 32-Bit-Arithmetik ohne Vorzeichen.

The choice of incoming timestamps to be saved for this comparison must guarantee a value that is monotone increasing. For example, we might save the timestamp from the segment that last advanced the left edge of the receive window, i.e., the most recent in-sequence segment. Instead, we choose the value TS.Recent introduced in Section 3.4 for the RTTM mechanism, since using a common value for both PAWS and RTTM simplifies the implementation of both. As Section 3.4 explained, TS.Recent differs from the timestamp from the last in-sequence segment only in the case of delayed ACKs, and therefore by less than one window. Either choice will therefore protect against sequence number wrap-around.

Die Wahl der eingehenden Zeitstempel, die für diesen Vergleich gespeichert werden sollen, muss einen Wert garantieren, der monoton steigend ist. Zum Beispiel könnten wir den Zeitstempel aus dem Segment speichern, das zuletzt die linke Kante des Empfangsfensters vorwärts bewegt hat, d.h. das aktuellste Segment in der Reihenfolge. Stattdessen wählen wir den in Abschnitt 3.4 für den RTTM-Mechanismus eingeführten Wert TS.Recent, da die Verwendung eines gemeinsamen Werts sowohl für PAWS als auch für RTTM die Implementierung von beiden vereinfacht. Wie Abschnitt 3.4 erklärte, unterscheidet sich TS.Recent vom Zeitstempel des letzten Segments in der Reihenfolge nur im Fall verzögerter ACKs und daher um weniger als ein Fenster. Beide Optionen schützen daher vor Sequenznummernüberlauf.

RTTM was specified in a symmetrical manner, so that TSval timestamps are carried in both data and ACK segments and are echoed in TSecr fields carried in returning ACK or data segments. PAWS submits all incoming segments to the same test, and therefore protects against duplicate ACK segments as well as data segments. (An alternative un-symmetric algorithm would protect against old duplicate ACKs: the sender of data would reject incoming ACK segments whose TSecr values were less than the TSecr saved from the last segment whose ACK field advanced the left edge of the send window. This algorithm was deemed to lack economy of mechanism and symmetry.)

RTTM wurde auf symmetrische Weise spezifiziert, sodass TSval-Zeitstempel sowohl in Daten- als auch in ACK-Segmenten getragen und in TSecr-Feldern zurückgesendet werden, die in zurückkehrenden ACK- oder Datensegmenten getragen werden. PAWS unterwirft alle eingehenden Segmente demselben Test und schützt daher sowohl gegen doppelte ACK-Segmente als auch gegen Datensegmente. (Ein alternativer asymmetrischer Algorithmus würde gegen alte doppelte ACKs schützen: Der Absender von Daten würde eingehende ACK-Segmente ablehnen, deren TSecr-Werte kleiner waren als der TSecr, der aus dem letzten Segment gespeichert wurde, dessen ACK-Feld die linke Kante des Sendefensters vorwärts bewegt hat. Dieser Algorithmus wurde als mangelhaft an Mechanismusökonomie und Symmetrie angesehen.)

TSval timestamps sent on {SYN} and {SYN,ACK} segments are used to initialize PAWS. PAWS protects against old duplicate non-SYN segments, and duplicate SYN segments received while there is a synchronized connection. Duplicate {SYN} and {SYN,ACK} segments received when there is no connection will be discarded by the normal 3-way handshake and sequence number checks of TCP.

TSval-Zeitstempel, die auf {SYN}- und {SYN,ACK}-Segmenten gesendet werden, werden zur Initialisierung von PAWS verwendet. PAWS schützt gegen alte doppelte Nicht-SYN-Segmente und doppelte SYN-Segmente, die empfangen werden, während eine synchronisierte Verbindung besteht. Doppelte {SYN}- und {SYN,ACK}-Segmente, die empfangen werden, wenn keine Verbindung besteht, werden durch den normalen 3-Wege-Handshake und Sequenznummernprüfungen von TCP verworfen.

It is recommended that RST segments NOT carry timestamps, and that RST segments be acceptable regardless of their timestamp. Old duplicate RST segments should be exceedingly unlikely, and their cleanup function should take precedence over timestamps.

Es wird empfohlen, dass RST-Segmente KEINE Zeitstempel tragen und dass RST-Segmente unabhängig von ihrem Zeitstempel akzeptabel sind. Alte doppelte RST-Segmente sollten äußerst unwahrscheinlich sein, und ihre Bereinigungsfunktion sollte Vorrang vor Zeitstempeln haben.

4.2.1 Basic PAWS Algorithm (Grundlegender PAWS-Algorithmus)

The PAWS algorithm requires the following processing to be performed on all incoming segments for a synchronized connection:

Der PAWS-Algorithmus erfordert, dass die folgende Verarbeitung für alle eingehenden Segmente einer synchronisierten Verbindung durchgeführt wird:

R1) If there is a Timestamps option in the arriving segment and SEG.TSval < TS.Recent and if TS.Recent is valid (see later discussion), then treat the arriving segment as not acceptable:

Wenn es eine Timestamps-Option im ankommenden Segment gibt und SEG.TSval < TS.Recent und wenn TS.Recent gültig ist (siehe spätere Diskussion), dann behandeln Sie das ankommende Segment als nicht akzeptabel:

Send an acknowledgement in reply as specified in RFC-793 page 69 and drop the segment.

Senden Sie eine Bestätigung als Antwort, wie in RFC-793 Seite 69 angegeben, und verwerfen Sie das Segment.

Note: it is necessary to send an ACK segment in order to retain TCP's mechanisms for detecting and recovering from half-open connections. For example, see Figure 10 of RFC-793.

Hinweis: Es ist notwendig, ein ACK-Segment zu senden, um die Mechanismen von TCP zur Erkennung und Wiederherstellung von halb offenen Verbindungen beizubehalten. Siehe beispielsweise Abbildung 10 von RFC-793.

R2) If the segment is outside the window, reject it (normal TCP processing)

Wenn das Segment außerhalb des Fensters liegt, lehnen Sie es ab (normale TCP-Verarbeitung)

R3) If an arriving segment satisfies: SEG.SEQ <= Last.ACK.sent (see Section 3.4), then record its timestamp in TS.Recent.

Wenn ein ankommendes Segment erfüllt: SEG.SEQ <= Last.ACK.sent (siehe Abschnitt 3.4), dann zeichnen Sie seinen Zeitstempel in TS.Recent auf.

R4) If an arriving segment is in-sequence (i.e., at the left window edge), then accept it normally.

Wenn ein ankommendes Segment in der Reihenfolge ist (d.h. an der linken Fensterkante), dann akzeptieren Sie es normal.

R5) Otherwise, treat the segment as a normal in-window, out-of-sequence TCP segment (e.g., queue it for later delivery to the user).

Andernfalls behandeln Sie das Segment als normales Segment im Fenster, außerhalb der Reihenfolge TCP-Segment (z.B. stellen Sie es für spätere Zustellung an den Benutzer in die Warteschlange).

Steps R2, R4, and R5 are the normal TCP processing steps specified by RFC-793.

Die Schritte R2, R4 und R5 sind die normalen TCP-Verarbeitungsschritte, die von RFC-793 spezifiziert werden.

It is important to note that the timestamp is checked only when a segment first arrives at the receiver, regardless of whether it is in-sequence or it must be queued for later delivery. Consider the following example.

Es ist wichtig zu beachten, dass der Zeitstempel nur überprüft wird, wenn ein Segment zum ersten Mal beim Empfänger ankommt, unabhängig davon, ob es in der Reihenfolge ist oder für spätere Zustellung in die Warteschlange gestellt werden muss. Betrachten Sie das folgende Beispiel.

Suppose the segment sequence: A.1, B.1, C.1, ..., Z.1 has been sent, where the letter indicates the sequence number and the digit represents the timestamp. Suppose also that segment B.1 has been lost. The timestamp in TS.TStamp is 1 (from A.1), so C.1, ..., Z.1 are considered acceptable and are queued. When B is retransmitted as segment B.2 (using the latest timestamp), it fills the hole and causes all the segments through Z to be acknowledged and passed to the user. The timestamps of the queued segments are not inspected again at this time, since they have already been accepted. When B.2 is accepted, TS.Stamp is set to 2.

Angenommen, die Segmentsequenz: A.1, B.1, C.1, ..., Z.1 wurde gesendet, wobei der Buchstabe die Sequenznummer angibt und die Ziffer den Zeitstempel darstellt. Angenommen auch, dass Segment B.1 verloren gegangen ist. Der Zeitstempel in TS.TStamp ist 1 (von A.1), daher werden C.1, ..., Z.1 als akzeptabel betrachtet und in die Warteschlange gestellt. Wenn B als Segment B.2 (mit dem neuesten Zeitstempel) erneut übertragen wird, füllt es die Lücke und bewirkt, dass alle Segmente bis Z bestätigt und an den Benutzer weitergegeben werden. Die Zeitstempel der in der Warteschlange befindlichen Segmente werden zu diesem Zeitpunkt nicht erneut überprüft, da sie bereits akzeptiert wurden. Wenn B.2 akzeptiert wird, wird TS.Stamp auf 2 gesetzt.

This rule allows reasonable performance under loss. A full window of data is in transit at all times, and after a loss a full window less one packet will show up out-of-sequence to be queued at the receiver (e.g., up to ~2**30 bytes of data); the timestamp option must not result in discarding this data.

Diese Regel ermöglicht eine angemessene Leistung bei Verlust. Ein vollständiges Datenfenster ist jederzeit unterwegs, und nach einem Verlust wird ein vollständiges Fenster minus ein Paket außerhalb der Reihenfolge erscheinen, um beim Empfänger in die Warteschlange gestellt zu werden (z.B. bis zu ~2**30 Bytes Daten); die Zeitstempeloption darf nicht dazu führen, dass diese Daten verworfen werden.

In certain unlikely circumstances, the algorithm of rules R1-R4 could lead to discarding some segments unnecessarily, as shown in the following example:

Unter bestimmten unwahrscheinlichen Umständen könnte der Algorithmus der Regeln R1-R4 dazu führen, dass einige Segmente unnötigerweise verworfen werden, wie das folgende Beispiel zeigt:

Suppose again that segments: A.1, B.1, C.1, ..., Z.1 have been sent in sequence and that segment B.1 has been lost. Furthermore, suppose delivery of some of C.1, ... Z.1 is delayed until AFTER the retransmission B.2 arrives at the receiver. These delayed segments will be discarded unnecessarily when they do arrive, since their timestamps are now out of date.

Angenommen wiederum, dass Segmente: A.1, B.1, C.1, ..., Z.1 in der Reihenfolge gesendet wurden und dass Segment B.1 verloren gegangen ist. Angenommen ferner, dass die Zustellung einiger der C.1, ... Z.1 verzögert wird, bis NACH der Neuübertragung B.2 beim Empfänger ankommt. Diese verzögerten Segmente werden unnötigerweise verworfen, wenn sie ankommen, da ihre Zeitstempel jetzt veraltet sind.

This case is very unlikely to occur. If the retransmission was triggered by a timeout, some of the segments C.1, ... Z.1 must have been delayed longer than the RTO time. This is presumably an unlikely event, or there would be many spurious timeouts and retransmissions. If B's retransmission was triggered by the "fast retransmit" algorithm, i.e., by duplicate ACKs, then the queued segments that caused these ACKs must have been received already.

Dieser Fall tritt sehr unwahrscheinlich auf. Wenn die Neuübertragung durch ein Timeout ausgelöst wurde, müssen einige der Segmente C.1, ... Z.1 länger als die RTO-Zeit verzögert worden sein. Dies ist vermutlich ein unwahrscheinliches Ereignis, sonst würde es viele falsche Timeouts und Neuübertragungen geben. Wenn die Neuübertragung von B durch den "Schnelle Neuübertragung (fast retransmit)"-Algorithmus ausgelöst wurde, d.h. durch doppelte ACKs, dann müssen die in der Warteschlange befindlichen Segmente, die diese ACKs verursacht haben, bereits empfangen worden sein.

Even if a segment were delayed past the RTO, the Fast Retransmit mechanism [Jacobson90c] will cause the delayed packets to be retransmitted at the same time as B.2, avoiding an extra RTT and therefore causing a very small performance penalty.

Selbst wenn ein Segment über das RTO hinaus verzögert wurde, wird der Schnelle Neuübertragungsmechanismus [Jacobson90c] dazu führen, dass die verzögerten Pakete zur gleichen Zeit wie B.2 neu übertragen werden, wodurch ein zusätzliches RTT vermieden wird und daher eine sehr geringe Leistungseinbuße verursacht wird.

We know of no case with a significant probability of occurrence in which timestamps will cause performance degradation by unnecessarily discarding segments.

Wir kennen keinen Fall mit einer signifikanten Auftretenswahrscheinlichkeit, in dem Zeitstempel durch unnötiges Verwerfen von Segmenten zu Leistungseinbußen führen werden.

4.2.2 Timestamp Clock (Zeitstempeluhr)

It is important to understand that the PAWS algorithm does not require clock synchronization between sender and receiver. The sender's timestamp clock is used to stamp the segments, and the sender uses the echoed timestamp to measure RTT's. However, the receiver treats the timestamp as simply a monotone-increasing serial number, without any necessary connection to its clock. From the receiver's viewpoint, the timestamp is acting as a logical extension of the high-order bits of the sequence number.

Es ist wichtig zu verstehen, dass der PAWS-Algorithmus keine Uhrsynchronisation zwischen Sender und Empfänger erfordert. Die Zeitstempeluhr des Senders wird verwendet, um die Segmente zu stempeln, und der Sender verwendet den zurückgesendeten Zeitstempel, um RTTs zu messen. Der Empfänger behandelt den Zeitstempel jedoch einfach als eine monoton steigende Seriennummer, ohne notwendige Verbindung zu seiner Uhr. Aus Sicht des Empfängers wirkt der Zeitstempel als logische Erweiterung der höherwertigen Bits der Sequenznummer.

The receiver algorithm does place some requirements on the frequency of the timestamp clock.

Der Empfängeralgorithmus stellt einige Anforderungen an die Frequenz der Zeitstempeluhr.

(a) The timestamp clock must not be "too slow".

Die Zeitstempeluhr darf nicht "zu langsam" sein.

It must tick at least once for each 231 bytes sent. In fact, in order to be useful to the sender for round trip timing, the clock should tick at least once per window's worth of data, and even with the RFC-1072 window extension, 231 bytes must be at least two windows.

Sie muss mindestens einmal für jede 231 gesendeten Bytes ticken. Tatsächlich sollte die Uhr, um für den Sender für die Rundlaufzeitmessung nützlich zu sein, mindestens einmal pro Fenster an Daten ticken, und selbst mit der RFC-1072-Fenstererweiterung müssen 231 Bytes mindestens zwei Fenster sein.

To make this more quantitative, any clock faster than 1 tick/sec will reject old duplicate segments for link speeds of ~8 Gbps. A 1ms timestamp clock will work at link speeds up to 8 Tbps (8*10**12) bps!

Um dies quantitativer zu machen, wird jede Uhr, die schneller als 1 Tick/Sek ist, alte doppelte Segmente für Verbindungsgeschwindigkeiten von ~8 Gbps ablehnen. Eine 1ms-Zeitstempeluhr funktioniert bei Verbindungsgeschwindigkeiten bis zu 8 Tbps (8*10**12) bps!

(b) The timestamp clock must not be "too fast".

Die Zeitstempeluhr darf nicht "zu schnell" sein.

Its recycling time must be greater than MSL seconds. Since the clock (timestamp) is 32 bits and the worst-case MSL is 255 seconds, the maximum acceptable clock frequency is one tick every 59 ns.

Ihre Recyclingzeit muss größer als MSL Sekunden sein. Da die Uhr (Zeitstempel) 32 Bit beträgt und die MSL im schlimmsten Fall 255 Sekunden beträgt, ist die maximal akzeptable Uhrfrequenz ein Tick alle 59 ns.

However, it is desirable to establish a much longer recycle period, in order to handle outdated timestamps on idle connections (see Section 4.2.3), and to relax the MSL requirement for preventing sequence number wrap-around. With a 1 ms timestamp clock, the 32-bit timestamp will wrap its sign bit in 24.8 days. Thus, it will reject old duplicates on the same connection if MSL is 24.8 days or less. This appears to be a very safe figure; an MSL of 24.8 days or longer can probably be assumed by the gateway system without requiring precise MSL enforcement by the TTL value in the IP layer.

Es ist jedoch wünschenswert, eine viel längere Recyclingperiode festzulegen, um veraltete Zeitstempel bei inaktiven Verbindungen zu handhaben (siehe Abschnitt 4.2.3) und die MSL-Anforderung zur Verhinderung von Sequenznummernüberlauf zu lockern. Mit einer 1-ms-Zeitstempeluhr wird der 32-Bit-Zeitstempel sein Vorzeichenbit in 24,8 Tagen überlaufen. Daher wird er alte Duplikate auf derselben Verbindung ablehnen, wenn MSL 24,8 Tage oder weniger beträgt. Dies scheint eine sehr sichere Zahl zu sein; eine MSL von 24,8 Tagen oder länger kann wahrscheinlich vom Gateway-System angenommen werden, ohne eine präzise MSL-Durchsetzung durch den TTL-Wert in der IP-Schicht zu erfordern.

Based upon these considerations, we choose a timestamp clock frequency in the range 1 ms to 1 sec per tick. This range also matches the requirements of the RTTM mechanism, which does not need much more resolution than the granularity of the retransmit timer, e.g., tens or hundreds of milliseconds.

Basierend auf diesen Überlegungen wählen wir eine Zeitstempeluhrfrequenz im Bereich von 1 ms bis 1 Sek pro Tick. Dieser Bereich entspricht auch den Anforderungen des RTTM-Mechanismus, der nicht viel mehr Auflösung als die Granularität des Neuübertragungstimers benötigt, z.B. Dutzende oder Hunderte von Millisekunden.

The PAWS mechanism also puts a strong monotonicity requirement on the sender's timestamp clock. The method of implementation of the timestamp clock to meet this requirement depends upon the system hardware and software.

Der PAWS-Mechanismus stellt auch eine starke Monotonieanforderung an die Zeitstempeluhr des Senders. Die Implementierungsmethode der Zeitstempeluhr zur Erfüllung dieser Anforderung hängt von der Systemhardware und -software ab.

• Some hosts have a hardware clock that is guaranteed to be monotonic between hardware resets.

  Einige Hosts haben eine Hardwareuhr, die garantiert zwischen Hardware-Resets monoton ist.

• A clock interrupt may be used to simply increment a binary integer by 1 periodically.

  Ein Uhrinterrupt kann verwendet werden, um einfach eine binäre Ganzzahl periodisch um 1 zu erhöhen.

• The timestamp clock may be derived from a system clock that is subject to being abruptly changed, by adding a variable offset value. This offset is initialized to zero. When a new timestamp clock value is needed, the offset can be adjusted as necessary to make the new value equal to or larger than the previous value (which was saved for this purpose).

  Die Zeitstempeluhr kann von einer Systemuhr abgeleitet werden, die abrupt geändert werden kann, indem ein variabler Offset-Wert hinzugefügt wird. Dieser Offset wird auf Null initialisiert. Wenn ein neuer Zeitstempeluhrwert benötigt wird, kann der Offset bei Bedarf angepasst werden, um den neuen Wert gleich oder größer als den vorherigen Wert zu machen (der für diesen Zweck gespeichert wurde).

4.2.3 Outdated Timestamps (Veraltete Zeitstempel)

If a connection remains idle long enough for the timestamp clock of the other TCP to wrap its sign bit, then the value saved in TS.Recent will become too old; as a result, the PAWS mechanism will cause all subsequent segments to be rejected, freezing the connection (until the timestamp clock wraps its sign bit again).

Wenn eine Verbindung lange genug inaktiv bleibt, damit die Zeitstempeluhr des anderen TCP sein Vorzeichenbit überläuft, wird der in TS.Recent gespeicherte Wert zu alt; infolgedessen wird der PAWS-Mechanismus dazu führen, dass alle nachfolgenden Segmente abgelehnt werden, wodurch die Verbindung eingefroren wird (bis die Zeitstempeluhr ihr Vorzeichenbit erneut überläuft).

With the chosen range of timestamp clock frequencies (1 sec to 1 ms), the time to wrap the sign bit will be between 24.8 days and 24800 days. A TCP connection that is idle for more than 24 days and then comes to life is exceedingly unusual. However, it is undesirable in principle to place any limitation on TCP connection lifetimes.

Mit dem gewählten Bereich von Zeitstempeluhrfrequenzen (1 Sek bis 1 ms) liegt die Zeit zum Überlaufen des Vorzeichenbits zwischen 24,8 Tagen und 24800 Tagen. Eine TCP-Verbindung, die länger als 24 Tage inaktiv ist und dann zum Leben erwacht, ist äußerst ungewöhnlich. Es ist jedoch prinzipiell unerwünscht, irgendeine Einschränkung der Lebensdauer von TCP-Verbindungen vorzunehmen.

We therefore require that an implementation of PAWS include a mechanism to "invalidate" the TS.Recent value when a connection is idle for more than 24 days. (An alternative solution to the problem of outdated timestamps would be to send keepalive segments at a very low rate, but still more often than the wrap-around time for timestamps, e.g., once a day. This would impose negligible overhead. However, the TCP specification has never included keepalives, so the solution based upon invalidation was chosen.)

Wir fordern daher, dass eine Implementierung von PAWS einen Mechanismus enthält, um den TS.Recent-Wert zu "invalidieren (invalidate)", wenn eine Verbindung länger als 24 Tage inaktiv ist. (Eine alternative Lösung für das Problem veralteter Zeitstempel wäre das Senden von Keepalive-Segmenten mit einer sehr niedrigen Rate, aber immer noch häufiger als die Überlaufzeit für Zeitstempel, z.B. einmal pro Tag. Dies würde einen vernachlässigbaren Overhead auferlegen. Die TCP-Spezifikation hat jedoch nie Keepalives enthalten, daher wurde die Lösung basierend auf Invalidierung gewählt.)

Note that a TCP does not know the frequency, and therefore, the wraparound time, of the other TCP, so it must assume the worst. The validity of TS.Recent needs to be checked only if the basic PAWS timestamp check fails, i.e., only if SEG.TSval < TS.Recent. If TS.Recent is found to be invalid, then the segment is accepted, regardless of the failure of the timestamp check, and rule R3 updates TS.Recent with the TSval from the new segment.

Beachten Sie, dass ein TCP die Frequenz und daher die Überlaufzeit des anderen TCP nicht kennt, daher muss es vom Schlimmsten ausgehen. Die Gültigkeit von TS.Recent muss nur überprüft werden, wenn die grundlegende PAWS-Zeitstempelprüfung fehlschlägt, d.h. nur wenn SEG.TSval < TS.Recent. Wenn TS.Recent als ungültig befunden wird, wird das Segment akzeptiert, unabhängig vom Fehler der Zeitstempelprüfung, und Regel R3 aktualisiert TS.Recent mit dem TSval aus dem neuen Segment.

To detect how long the connection has been idle, the TCP may update a clock or timestamp value associated with the connection whenever TS.Recent is updated, for example. The details will be implementation-dependent.

Um zu erkennen, wie lange die Verbindung inaktiv war, kann das TCP beispielsweise jedes Mal, wenn TS.Recent aktualisiert wird, eine Uhr oder einen Zeitstempelwert aktualisieren, der mit der Verbindung verbunden ist. Die Details sind implementierungsabhängig.

4.2.4 Header Prediction (Header-Vorhersage)

"Header prediction" [Jacobson90a] is a high-performance transport protocol implementation technique that is most important for high-speed links. This technique optimizes the code for the most common case, receiving a segment correctly and in order. Using header prediction, the receiver asks the question, "Is this segment the next in sequence?" This question can be answered in fewer machine instructions than the question, "Is this segment within the window?"

"Header-Vorhersage (Header prediction)" [Jacobson90a] ist eine Hochleistungs-Transportprotokoll-Implementierungstechnik, die für Hochgeschwindigkeitsverbindungen am wichtigsten ist. Diese Technik optimiert den Code für den häufigsten Fall, ein Segment korrekt und in der Reihenfolge zu empfangen. Mit Header-Vorhersage stellt der Empfänger die Frage: "Ist dieses Segment das nächste in der Reihenfolge?" Diese Frage kann in weniger Maschinenanweisungen beantwortet werden als die Frage "Ist dieses Segment im Fenster?"

Adding header prediction to our timestamp procedure leads to the following recommended sequence for processing an arriving TCP segment:

Das Hinzufügen der Header-Vorhersage zu unserem Zeitstempelverfahren führt zu der folgenden empfohlenen Sequenz für die Verarbeitung eines ankommenden TCP-Segments:

H1) Check timestamp (same as step R1 above)

Zeitstempel prüfen (wie Schritt R1 oben)

H2) Do header prediction: if segment is next in sequence and if there are no special conditions requiring additional processing, accept the segment, record its timestamp, and skip H3.

Header-Vorhersage durchführen: Wenn das Segment das nächste in der Reihenfolge ist und wenn es keine besonderen Bedingungen gibt, die zusätzliche Verarbeitung erfordern, akzeptieren Sie das Segment, zeichnen Sie seinen Zeitstempel auf und überspringen Sie H3.

H3) Process the segment normally, as specified in RFC-793. This includes dropping segments that are outside the window and possibly sending acknowledgments, and queueing in-window, out-of-sequence segments.

Das Segment normal verarbeiten, wie in RFC-793 angegeben. Dies umfasst das Verwerfen von Segmenten, die außerhalb des Fensters liegen, und möglicherweise das Senden von Bestätigungen sowie das Einreihen von Segmenten im Fenster, die außerhalb der Reihenfolge liegen.

Another possibility would be to interchange steps H1 and H2, i.e., to perform the header prediction step H2 FIRST, and perform H1 and H3 only when header prediction fails. This could be a performance improvement, since the timestamp check in step H1 is very unlikely to fail, and it requires interval arithmetic on a finite field, a relatively expensive operation. To perform this check on every single segment is contrary to the philosophy of header prediction. We believe that this change might reduce CPU time for TCP protocol processing by up to 5-10% on high-speed networks.

Eine andere Möglichkeit wäre, die Schritte H1 und H2 zu vertauschen, d.h. den Header-Vorhersage-Schritt H2 ZUERST durchzuführen und H1 und H3 nur durchzuführen, wenn die Header-Vorhersage fehlschlägt. Dies könnte eine Leistungsverbesserung sein, da die Zeitstempelprüfung in Schritt H1 sehr unwahrscheinlich fehlschlägt und sie Intervall-Arithmetik auf einem endlichen Feld erfordert, eine relativ teure Operation. Diese Prüfung bei jedem einzelnen Segment durchzuführen, widerspricht der Philosophie der Header-Vorhersage. Wir glauben, dass diese Änderung die CPU-Zeit für die TCP-Protokollverarbeitung in Hochgeschwindigkeitsnetzwerken um bis zu 5-10% reduzieren könnte.

However, putting H2 first would create a hazard: a segment from 2**32 bytes in the past might arrive at exactly the wrong time and be accepted mistakenly by the header-prediction step. The following reasoning has been introduced [Jacobson90b] to show that the probability of this failure is negligible.

Das Voranstellen von H2 würde jedoch eine Gefahr schaffen: Ein Segment von 2**32 Bytes in der Vergangenheit könnte genau zur falschen Zeit ankommen und fälschlicherweise durch den Header-Vorhersage-Schritt akzeptiert werden. Die folgende Argumentation wurde eingeführt [Jacobson90b], um zu zeigen, dass die Wahrscheinlichkeit dieses Fehlers vernachlässigbar ist.

If all segments are equally likely to show up as old duplicates, then the probability of an old duplicate exactly matching the left window edge is the maximum segment size (MSS) divided by the size of the sequence space. This ratio must be less than 2**-16, since MSS must be < 216; for example, it will be (212)/(232) = 2-20 for an FDDI link. However, the older a segment is, the less likely it is to be retained in the Internet, and under any reasonable model of segment lifetime the probability of an old duplicate exactly at the left window edge must be much smaller than 2**-16.

Wenn alle Segmente gleich wahrscheinlich als alte Duplikate auftauchen, dann ist die Wahrscheinlichkeit, dass ein altes Duplikat genau mit der linken Fensterkante übereinstimmt, die maximale Segmentgröße (MSS) geteilt durch die Größe des Sequenzraums. Dieses Verhältnis muss kleiner als 2**-16 sein, da MSS < 216 sein muss; zum Beispiel wird es (212)/(232) = 2-20 für eine FDDI-Verbindung sein. Je älter jedoch ein Segment ist, desto weniger wahrscheinlich ist es, dass es im Internet beibehalten wird, und unter jedem vernünftigen Modell der Segmentlebensdauer muss die Wahrscheinlichkeit eines alten Duplikats genau an der linken Fensterkante viel kleiner als 2**-16 sein.

The 16 bit TCP checksum also allows a basic unreliability of one part in 2**16. A protocol mechanism whose reliability exceeds the reliability of the TCP checksum should be considered "good enough", i.e., it won't contribute significantly to the overall error rate. We therefore believe we can ignore the problem of an old duplicate being accepted by doing header prediction before checking the timestamp.

Die 16-Bit-TCP-Prüfsumme ermöglicht auch eine grundlegende Unzuverlässigkeit von einem Teil in 2**16. Ein Protokollmechanismus, dessen Zuverlässigkeit die Zuverlässigkeit der TCP-Prüfsumme übertrifft, sollte als "gut genug" betrachtet werden, d.h. er wird nicht wesentlich zur Gesamtfehlerrate beitragen. Wir glauben daher, dass wir das Problem eines alten Duplikats, das akzeptiert wird, ignorieren können, indem wir Header-Vorhersage vor der Überprüfung des Zeitstempels durchführen.

However, this probabilistic argument is not universally accepted, and the consensus at present is that the performance gain does not justify the hazard in the general case. It is therefore recommended that H2 follow H1.

Dieses probabilistische Argument wird jedoch nicht allgemein akzeptiert, und der gegenwärtige Konsens ist, dass der Leistungsgewinn die Gefahr im Allgemeinen nicht rechtfertigt. Es wird daher empfohlen, dass H2 auf H1 folgt.

4.3 Duplicates from Earlier Incarnations of Connection (Duplikate aus früheren Inkarnationen der Verbindung)

The PAWS mechanism protects against errors due to sequence number wrap-around on high-speed connection. Segments from an earlier incarnation of the same connection are also a potential cause of old duplicate errors. In both cases, the TCP mechanisms to prevent such errors depend upon the enforcement of a maximum segment lifetime (MSL) by the Internet (IP) layer (see Appendix of RFC-1185 for a detailed discussion). Unlike the case of sequence space wrap-around, the MSL required to prevent old duplicate errors from earlier incarnations does not depend upon the transfer rate. If the IP layer enforces the recommended 2 minute MSL of TCP, and if the TCP rules are followed, TCP connections will be safe from earlier incarnations, no matter how high the network speed. Thus, the PAWS mechanism is not required for this case.

Der PAWS-Mechanismus schützt vor Fehlern aufgrund von Sequenznummernüberlauf bei Hochgeschwindigkeitsverbindungen. Segmente aus einer früheren Inkarnation derselben Verbindung sind ebenfalls eine potenzielle Ursache für alte Duplikatfehler. In beiden Fällen hängen die TCP-Mechanismen zur Verhinderung solcher Fehler von der Durchsetzung einer maximalen Segmentlebensdauer (MSL) durch die Internet-(IP-)Schicht ab (siehe Anhang von RFC-1185 für eine ausführliche Diskussion). Im Gegensatz zum Fall des Sequenzraum-Überlaufs hängt die MSL, die erforderlich ist, um alte Duplikatfehler aus früheren Inkarnationen zu verhindern, nicht von der Übertragungsrate ab. Wenn die IP-Schicht die empfohlene 2-Minuten-MSL von TCP durchsetzt und wenn die TCP-Regeln befolgt werden, sind TCP-Verbindungen vor früheren Inkarnationen sicher, unabhängig davon, wie hoch die Netzwerkgeschwindigkeit ist. Daher ist der PAWS-Mechanismus für diesen Fall nicht erforderlich.

We may still ask whether the PAWS mechanism can provide additional security against old duplicates from earlier connections, allowing us to relax the enforcement of MSL by the IP layer. Appendix B explores this question, showing that further assumptions and/or mechanisms are required, beyond those of PAWS. This is not part of the current extension.

Wir können immer noch fragen, ob der PAWS-Mechanismus zusätzliche Sicherheit gegen alte Duplikate aus früheren Verbindungen bieten kann, was es uns ermöglicht, die Durchsetzung der MSL durch die IP-Schicht zu lockern. Anhang B untersucht diese Frage und zeigt, dass weitere Annahmen und/oder Mechanismen über die von PAWS hinaus erforderlich sind. Dies ist nicht Teil der aktuellen Erweiterung.