DE60212104T2

DE60212104T2 - Auf Empfänger basierte Umlaufzeitmessung in TCP

Info

Publication number: DE60212104T2
Application number: DE60212104T
Authority: DE
Inventors: Fernando Berzosa; Thomas Klinner; Rolf Hakenberg; Carsten Burmeister
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp
Priority date: 2002-06-18
Filing date: 2002-06-18
Publication date: 2006-10-19
Anticipated expiration: 2022-06-19
Also published as: EP1376945B1; US7330426B2; CN1229945C; JP2004023794A; CN1467953A; US20030231636A1; KR20040002602A; DE60212104D1; KR100546927B1; EP1376945A1; JP3789120B2

Description

Diese Erfindung bezieht sich auf Paketdatenübertragungen, insbesondere auf die Übertragung von Daten unter Verwendung des Transmission Control Protocol (TCP) über Internet Protocol (IP) Netze. TCP liefert eine Stabilität von Netzen durch seine integrierte Anhäufungs- und Flusssteuermechanismen. Weitere Informationen über TCP- und IP-Netze sind, zum Beispiel, aus der US-6,298,041 B1 erhältlich.
Während die TCP-Senderate normalerweise durch den Sender gesteuert wird, sind dabei Szenarien und Umgebungen vorhanden, bei denen der Empfänger eine gewisse Kenntnis über die verwendeten Verbindungen und Bitraten besitzt, was es erstrebenswert macht, den Empfänger die Datenübertragungsrate des Senders in einem gewissen Umfang steuern zu lassen. Um diesen Mechanismus anzuwenden, sollte der Empfänger Kenntnis über den Round-Trip-Zeit-(RTT)-Wert haben, um die Bitrate des Senders zu steuern oder zu begrenzen. Als eine Folge müsste der Sender nicht die verfügbare Bitrate selbst proben müssen, was normalerweise zu Lasten von Paketverlusten geht und weniger genau als die Informationen des Empfängers ist.
Die Sende-Bitrate in dem TCP-Sender wird durch ein Gleitfenster, bezeichnet als Anhäufungs- bzw. Kongestions-Fenster, gesteuert. Der Sender sendet Daten und empfängt kumulative Quittungen. Unerledigte Daten sind die Daten, die der Sender bereits gesendet hat, allerdings nicht Quittungen dafür empfangen hat. Dem Sender wird ermöglicht, den Umfang der ausstehenden Daten gleich zu dem momentanen Wert des Anhäufungsfensters zu haben. Da die Daten gewöhnlich einer RTT quittiert werden, nachdem sie gesendet wurden, kann die zugelassene Sende-Bitrate, B_send, von der RTT, und die Anhäufungsfenstergröße, cwnd, wie: B_send = cwnd/RTT, berechnet werden. Ein Beispiel dieser typischen Werte könnte RTT = 100 ms und B_send = 64 Kbit/s sein.
Das Anhäufungsfenster an dem Server wird dynamisch entsprechend zu gesammelten Netzwerkinformationen eingestellt, z.B. in Fällen von Paketverlusten würde der TCP-Sender eine Anhäufung in dem Netzwerk annehmen und das Fenster entleeren. In Fällen ohne Paketverluste wird das Fenster leicht und regelmäßig vergrößert. Allerdings ist das Fenster, das TCP verwendet, um das Senden von Datenpaketen zu steuern, das Minimum des Anhäufungsfensters und eine andere Fenstergröße, signalisiert durch den Empfänger, bezeichnet als angezeigtes Fenster, awnd. Dies wird gewöhnlich für die Flusssteuerung von Merkmalen von TCP verwendet, d.h, um sicherzustellen, dass ein schneller TCP-Sender nicht mehr Daten empfängt als der Empfänger verbrauchen kann.
Zusammengefasst kann der Empfänger die obere Senderate des Senders einer TCP-Verbindung, unter Verwendung der integrierten Flusssteuerung, begrenzen und ein angezeigtes Fenster mit dem Wert, berechnet von RTT, und der maximalen Sende-Bitrate, senden.
Falls nur ein Verbindungselement Daten besitzt, um sie zu senden, sind RTT-Messungen für den Empfänger in einer TCP-Verbindung nur an dem Beginn einer Verbindung möglich (TCP startet mit einem 3-Weg-Handshake). Die Messung, die der Empfänger bei der Verbindungseinstellung durchführen kann, ist nicht akkurat, da sie auf kleinen Steuerpaketen basiert (gewöhnlich ungefähr 40 Bytes). Die Datenpakete sind viel größer in der Größe, z.B. 1500 Bytes, und demzufolge ist die RTT gewöhnlich viel höher als für kleine Steuerpakete.
Unter Berücksichtigung hiervon können Empfänger eine grobe RTT-Messung bei einer Verbindungseinstellung vornehmen, besitzen allerdings keine weiteren RTT-Informationen danach. Da die RTT gewöhnlich dynamisch und variabel in IP-Netzen ist, sollte der Empfänger RTT-Informationen häufiger sammeln, um eine zuverlässige Sende-Bitratensteuerung an dem Sender durchzuführen.
Wie vorstehend beschrieben ist, kann der Empfänger in einer TCP-Verbindung die Sende-Bitrate des Senders durch Signalisieren einer oberen Grenze in der Form des angezeigten Fensters steuern. Allerdings benötigt, um ein angezeigtes Fenster, das signalisiert werden soll, zu berechnen, der Empfänger eine RTT-Messung. Je besser und akkurater die Messung ist, desto besser ist die Fensterberechnung und desto besser ist die Verbindungsnutzung, nachdem der Sender die Fenstergröße anpasste.
Die EP 0948168 A1 offenbart eine Messung des RTT-Werts durch Überwachen des Zeitablaufs zwischen einem Absenden durch den Empfänger einer Quittung ACK (n), die den Empfang aller Bytes bis zu einem Byte n und den Empfang durch den Empfänger des TCP-Segments, das die Byte-Nummer n+1 abdeckt, bestätigt.
Der Artikel von M. Allman, „On Estimating End-to-End Network Path Properties", Computer Communications Review, Oktober 1999, Seiten 263-274, offenbart einen empfängerseitigen Algorithmus, wobei der Empfänger neue Segmente vorhersagen kann, die aufeinanderfolgend in Abhängigkeit der ACKs, die er sendet, gesendet werden können. Weiterhin könnte, unter Verwendung eines Zeitstempels, eingesetzt durch den Sender, der Empfänger bestimmen, welche Segmente eng beabstandet mit einer Quittung des spezifischen Algorithmus, verwendet durch den Sender, gesendet werden. Der Algorithmus arbeitet in einer Art und Weise, dass der Empfänger exakt kennt, welche neuen Segmente der Ankunft von einem seiner ACKs an dem Sender zugelassen werden. Diese Segmente werden voraussichtlich aufeinanderfolgend gesendet, so dass der Empfänger dann eine Bandbreite-Abschätzung, basierend auf deren Zeitfolge, wenn sie an dem Empfänger ankommen, bilden kann. Zu jedem Zeitpunkt, zu dem der Empfänger dann eine ACK sendet, ist ihm bekannt, dass, unter Empfang der ACK durch den Sender, das Flusssteuerfenster gleiten wird und sich das Anhäufungsfenster um ein Segment erhöhen wird.
Die Aufgabe der vorliegenden Erfindung ist es, ein Verfahren zum Durchführen von Round-Trip-Zeit-(RTT)-Messungen in einem Datenpaketempfänger in einer schnellen und zuverlässigen Art und Weise zu schaffen.
Diese Aufgabe wird durch ein Verfahren gelöst, das die Schritte aufweist, wie sie in Anspruch 1 angegeben sind. Bevorzugte Ausführungsformen des Verfahrens sind Gegenstand von verschiedenen, abhängigen Ansprüchen. Gemäß dem Verfahren der vorliegenden Erfindung bestimmt der Empfänger das Zeitintervall zwischen dem Senden einer Quittung, was das Senden eines neuen Datenpakets auslöst, und dem Zeitpunkt eines Empfangs des ausgelösten Datenpakets. Falls dieser Messungsmechanismus auf einer regelmäßigen Basis vorgenommen wird, stattet dieser den Empfänger mit einer sehr guten Abschätzung der RTT aus. Nachfolgend wird die Erfindung in weiterem Detail unter Bezugnahme auf die beigefügten Zeichnungen beschrieben, die darstellen:
1 zeigt Flussdiagramme, die verschiedene, beispielhafte Erfordernisse vor einem Starten der RTT-Messung darstellen,
2-4 zeigen beispielhafte Übertragungen von Datenpaketen von dem Sender zu dem Empfänger, um verschiedene Erfordernisse vor dem Starten der RTT-Messung darzustellen, und
5 zeigt ein Flussdiagramm der RTT-Messung gemäß der vorliegenden Erfindung.
Ein Empfänger, der eine TCP-Verbindung mit einem Sender über ein Netzwerk besitzt, kann eine RTT-Messung durch Senden einer Quittung zu dem Sender starten und auf den Empfang eines Datenpakets, ausgelöst durch diese Quittung, warten. Allerdings sollte der Empfänger sicherstellen, dass verschiedene Erfordernisse erfüllt sind, bevor eine RTT-Messung gestartet wird. Nachfolgend werden verschiedene, beispielhafte Erfordernisse beschrieben.
Für den Zweck der folgenden Beschreibung besteht ein Datenpaket aus einem Header, der eine typische Länge von 40 Bytes besitzt, wobei dieser Header ein Sequenzzahl-Feld umfasst, das das erste Daten-Byte in diesem Segment anzeigt. Dieser Wert kann als ein Identifizierer für das Datenpaket dienen. Eine typische Größe für ein TCP-Paket, umfassend einen Header und Daten, ist 1500 Bytes. Allgemein wird für Fachleute auf dem betreffenden Fachgebiet verständlich werden, dass eine Quittung den awnd Wert und die Sequenzzahl des Datenpakets umfasst, die der Sender der Quittung erwartet, zu empfangen, wobei dies als die Quittungszahl bekannt ist.
Nachfolgend stellt 1A die allgemeinen Erfordernisse dar und 1B stellt ein Ausführungsbeispiel dar. Für die entsprechenden Erfordernisse sind entsprechende Zahlen, gefolgt durch die jeweilige Angabe A oder B, ausgewählt worden, um das Verständnis zu erleichtern.
Als ein erstes Erfordernis R1 nach dem Start (Schritt 100 in 1) muss der Empfänger sicherstellen, dass der Sender im Fluss gesteuert ist (mittels des angezeigten Fensters awnd, siehe Schritt 200A) und sich nicht länger in der TCP-Slow-Start-Phase befindet. Während einer TCP-Slow-Start-Phase treten Bursts von Datenpaketen auf und deshalb kann die RTT-Messung gestört werden. Eine einfache und konservative Art und Weise, dieses Erfordernis sicherzustellen, ist diejenige, zu warten, bis mehrere Datenpakete empfangen sind. Nachdem eine Menge von 2·awnd – 1 Paketen gesendet ist (siehe 200B in 1B), erreicht entweder das Fenster des Senders awnd oder der Sender hat bereits die Anhäufungs-Vermeidungs-Phase zuvor erreicht. Es ist anzumerken, dass hier und in der folgenden Beschreibung die Variable awnd in Einheiten von Segmenten vorliegt, wogegen in einem realen TCP die Variablen awnd und cwnd in Einheiten von Bytes vorliegen.
Falls, zum Beispiel, ein Wert für awnd = 10 Datensegmente nach Empfang von 19 Paketen betrachtet wird, kann angenommen werden, dass sich der Sender nicht länger in der Slow-Start-Phase befindet.
In 2 ist dieses Erfordernis in einer beispielhaften Art und Weise dargestellt. In diesem Fall awnd = 5 Segmente stellen die Linien von links nach rechts Datenpakete von dem Sender zu dem Empfänger dar, die Zahl in der Mitte ist die Sequenzzahl (dies ist nur ein Beispiel, da in der Realität SN in Bytes angegeben ist). Die Zahlen an der rechten Achse sind die Werte der SN_ack.
Die Figur stellt dar, dass ein Warten von 2·awnd – 1 = 2·5 – 1 = 9 Paketen (bis ein Paket mit SN = 10 ankommt) mit dem Punkt übereinstimmt, wo der Sender im Fluss gesteuert ist. Dies bedeutet, dass jedes ACK-Paket nur ein Datenpaket an dem Sender auslöst. Das erste Paket in dem Beispiel, für das dies gilt, ist Paket Nummer 10.
Ein zweites Erfordernis R2 ist dasjenige, dass der Empfänger in der Lage sein sollte, die Sequenzzahl des Datenpakets abzuschätzen, in Bezug auf die die momentane Quittung dabei ist, an dem Sender auszulösen. Mit anderen Worten, dass der Empfänger in der Lage ist, den Wert von SN_expect zu berechnen (Schritt 300A). Diese Prüfung folgt, wenn das angezeigte Fenster awnd nicht für eine bestimmte Anzahl von Paketen erhöht worden ist (Schritt 300B). Ein Nebeneffekt eines Erhöhens des Werts des angezeigten Fensters ist die Möglichkeit, Bursts von Paketen an dem Sender zu haben. Dies würde auch die RTT-Messung stören und fehlerhaft seinen Wert erhöhen.
In 3 ändert sich der awnd Wert von 5 auf 7 und entsprechend diesem Erfordernis kann keine RTT-Messung für die nächsten 7 Pakete gestartet werden. Die Zahlen an der rechten Achse stellen nun den Wert von awnd in einer Anzahl von Paketen dar. Der Grund ist derjenige, dass der Empfänger nicht in der Lage ist, den Wert von SN_expect zu bestimmen. Die Figur stellt auch das Burst von Paketen, übertragen durch den Sender, dar, was diese Messung aufgrund höherer Verarbeitungszeiten stören könnte. Diese Effekte würden nicht notwendigerweise für diese Anzahl von X = awnd Paketen dauern, allerdings ist dies eine Sicherheitsgrenze.
Eine weitere Frage 400A, die ein drittes Erfordernis R3 darstellt, wird durchgeführt, um zu prüfen, ob die ACK ein neues Datenpaket an dem TCP-Sender auslöst (Schritt 400A). Dies bedeutet, dass eine Frage durchgeführt wird, ob der awnd Wert erniedrigt worden ist (Schritt 400B). Falls dies der Fall ist, ist keine RTT-Messung für eine vorbestimmte Anzahl von nächsten Datenpaketen möglich. Falls eine andere Erniedrigung vorhanden ist, wird entschieden, für eine zusätzliche Anzahl von (awnd_old – awnd_new) Paketen zu warten (Schritt 450B).
In dem Beispiel, das in 4 dargestellt ist, stellen die Zahlen an der rechten Achse wiederum den Wert von awnd dar. Zu einem Zeitpunkt ändert sich dieser Wert von 5 auf 3. Dies bedeutet, dass für 5 – 3 = 2 Paketen keine RTT-Messung gestartet werden kann. Die Figur stellt deutlich den Grund dar, da kein neues TCP-Paket aufgrund der kleineren Fenstergröße ausgelöst wird, bis 2 neue ACKs an dem Sender empfangen werden. Es ist anzumerken, dass keine RTT-Messung mit der ACK gestartet werden kann, wenn die Erfordernisse nicht erfüllt sind. Die ankommenden Datenpakete könnten dennoch für die RTT-Messung verwendet werden, die zuvor gestartet wurde.
Nur wenn alle vorstehend erwähnten Erfordernisse R1-R3 erfüllt sind, startet der Empfänger eine RTT-Messung, wie dies im Schritt 500A, B angezeigt ist, mit der momentanen Quittung. Um eine RTT-Messung vorzunehmen, werden die Schritte, wie sie in 5 dargestellt sind, durchgeführt.
Im Schritt 510 wird eine Quittung des momentan empfangenen Datenpakets von dem Empfänger zu dem Sender geschickt. Weiterhin wird, wie als Schritt 520 dargestellt ist, der Zeitpunkt T_ack, zu dem die Quittung gesendet wurde, gespeichert. Im Schritt 530 wird eine Sequenzzahl SN_expect eines erwarteten Datenpakets bestimmt, das die Sequenzzahl des ersten Bytes des TCP-Datenpakets, ausgelöst durch die momentane Quittung, anzeigt. Die erwartete Sequenzzahl wird wie folgt berechnet: SN_expect = SN_ack + (awnd – 1)·MSSwobei SN_ack die Quittungszahl in der momentanen Quittung ist und MSS die maximale Segmentgröße in Bytes bezeichnet.
In dem Empfänger wird, im Schritt 540, die Sequenzzahl aller Datenpakete SN_data, die nach T_ack empfangen sind, entsprechend dem Zustand SN_data ≥ SN_expectverglichen.
Falls diese Bedingung nicht erfüllt ist, wartet der Empfänger auf das nächste, empfangene Datenpaket. Falls der Zustand wahr ist, wird der nächste Schritt 550 durchgeführt, wo der tatsächliche Zeitpunkt T_now gespeichert wird. In dem nächsten Schritt 560 kann eine Berechnung von RTT als RTT = T_now – T_ackdurchgeführt werden.
Allgemein können RTT-Messungen, beschrieben in dem Flussdiagramm der 5, so oft wiederholt werden, wie dies benötigt wird, so lange wie die Erfordernisse, dargestellt in 1, erfüllt sind.

Claims

Verfahren zum Durchführen von Messung der Round-Trip-Zeit (Round Trip Time – RTT) in einem Datenpaket-Empfänger, der ein Sendesteuerungsprotokoll zur Kommunikation mit einem Sender über ein Netzwerk verwendet, wobei das Verfahren die folgenden Schritte umfasst: Senden (510) einer Bestätigung für ein aktuell empfangenes Datenpaket zu dem Sender, Messen (520) eines ersten Zeitpunktes beim Senden der Bestätigung, Auslösen des Sendens weiterer Datenpakete in Reaktion auf das Empfangen von Empfangsbestätigungen bei dem Sender, Berechnen (530) einer Sequenznummer SN_expect des erwarteten Datenpaktes auf Basis der Sequenznummer SN_ack des aktuell bestätigten Datenpaketes, des Empfangsfensters awnd und der maximalen Segmentgröße MSS gemäß der folgenden Gleichung: SN_expect = SN_ack + (awnd – 1)·MSSVergleichen (540) der Sequenznummer der empfangenen Datenpakete mit der berechneten Sequenznummer des erwarteten Datenpakets; Messen (550) eines zweiten Zeitpunktes beim Empfangen eines Datenpaketes, dessen Sequenznummer der berechneten Sequenznummer des erwarteten Datenpaketes gleich ist oder größer ist als diese; und Berechnen (560) der RTT-Messung auf Basis des gemessenen ersten und zweiten Zeitpunktes.
Verfahren nach Anspruch 1, wobei die RTT-Messung nur durchgeführt wird, wenn sich der Sender nicht in einer Slow-Start-Phase befindet.
Verfahren nach Anspruch 1 oder 2, wobei die RTT-Messung nur durchgeführt wird, wenn eine Flusssteuerungs-Variable, die dem Sender von dem Empfänger gemeldet wird, über eine vorgegebene Anzahl empfangener Datenpakete konstant gewesen ist.
Verfahren nach Anspruch 1-3, wobei der Empfänger dem Sender einer oberen Grenzwert der Sende-Bitrate anzeigt.
Verfahren nach einem der Ansprüche 1-4, wobei die Sende-Bitrate durch eine Empfangsfenstergröße gesteuert wird, die als Flusssteuerungsbefehl dient.
Verfahren nach Anspruch 5, wobei die Sende-Bitrate von einem sich dynamisch ändernden Überlastfenster gesteuert wird.
Verfahren nach den Ansprüchen 5 und 6, wobei die Sende-Bitrate entsprechend dem Minimum des Überlastfensters und des Empfangsfensters gesteuert wird, wie es durch den Empfänger gemeldet wird.
Verfahren nach Anspruch 5, wobei, wenn das Empfangsfenster verkleinert worden ist, die RTT-Messung verhindert wird, bis eine zusätzliche Anzahl von. Datenpaketen empfangen wird.