DE19983951B4

DE19983951B4 - Überlast-Steuerungsverfahren für ein paketvermitteltes Netzwerk

Info

Publication number: DE19983951B4
Application number: DE19983951T
Authority: DE
Inventors: Jian Ma; Peng Fei
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 1999-04-27
Filing date: 1999-04-27
Publication date: 2009-06-25
Anticipated expiration: 2019-04-28
Also published as: DE19983951T1; WO2000065782A1; CA2372023A1; GB2364615A; AU4034299A; GB0125202D0; GB2364615B

Abstract

Verfahren mit
Steuern von Überlast in einem paketvermittelten Netzwerk, welches Verkehrsquellen (A), Verkehrsziele (B) und Netzwerkknoten (AN, N1) aufweist, bei dem das Übertragungssteuerungsprotokoll (TCP) als ein Transportschichtprotokoll verwendet wird; und
Weiterleiten von Datenpaketen und entsprechenden Bestätigungen zwischen einer Verkehrsquelle und einem Verkehrsziel,
dadurch gekennzeichnet, dass das Steuern aufweist:
Hinzufügen, an einem Netzwerkknoten, einer Überlastbenachrichtigungsinformation zu einem Datenpaket, welches einem aufgrund eines Zwischenspeicherüberlaufs verlorenen Datenpaket folgt, um dadurch einen überlastungsbezogenen Datenverlust anzuzeigen, und dass
ein Vorgang einer erneuten Übertragung an einer Verkehrsquelle durchgeführt wird, nachdem eine vorbestimmte Anzahl von Duplikat-Bestätigungen mit Überlastbenachrichtigungsinformationen empfangen wurden.

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft ein Verfahren zur Steuerung einer Überlast in einem paketvermittelten Netzwerk, insbesondere einem Drahtlos- oder Mobilnetzwerk, bei dem das Transmission Control Protocol (TCP) bzw. das Übertragungssteuerungsprotokoll als ein Transportschichtprotokoll verwendet wird, sowie ein derartiges paketvermitteltes Telekommunikationsnetzwerk.
HINTERGRUND DER ERFINDUNG
Überlastungssteuerung oder Überlastabwehr ist einer der Schlüsselmechanismen, um die zunehmende Vielfalt von Diensten und Arten von Verkehr im Internet unterzubringen. Wie allgemein bekannt ist, ist TCP das populärste Transportschichtprotokoll zum Datentransfer. Es stellt verbindungsorientierten zuverlässigen Transfer von Daten zwischen zwei Verbindungshosts bereit, wobei ein Host einen an ein Netzwerk angeschlossenen Computer oder irgendein System bezeichnet, welches an ein Netzwerk angeschlossen werden kann, um einem an das gleiche Netzwerk angeschlossenen anderen Host Dienste anzubieten. TCP verwendet mehrere Techniken zum Maximieren der Leistungsfähigkeit der Verbindung durch Überwachung unterschiedlicher, die Verbindung betreffender Variablen. Beispielsweise enthält TCP einen internen Algorithmus zur Vermeidung von Überlastung.
Überlastabwehr betrifft das allgemeine Problem der Verkehrsverwaltung für paketvermittelte Netzwerke. Überlastung bezeichnet eine Situation, in der die Anzahl von Übertragungsanforderungen zu einer speziellen Zeit die Übertragungskapazität an einem (als „Flaschenhals-Ressource" bezeichneten) gewissen Netzwerkpunkt überschreitet. Überlastung führt herkömmlicher Weise zu Überlastzuständen. Als ein Ergebnis können beispielsweise die Zwischenspeicher überlaufen, so dass Pakete entweder durch das Netzwerk oder durch den Teilnehmer erneut übertragen werden. Im allgemeinen entsteht Überlastung, wenn der eingehende Verkehr bei einem bestimmten Verbindungsweg größer ist als die Kapazität des abgehenden Verbindungsweg. Die primäre Funktion der Überlaststeuerung bzw. Überlastabwehr besteht darin, einen guten Durchsatz und Verzögerungsleistungsfähigkeit sicherzustellen, während eine gerechte Zuordnung von Netzwerkressourcen zu den Benutzern gewahrt wird. Für den TCP Verkehr, dessen Verkehrsmuster oft stark bursthaftig sind bzw. eine schwankende Anzahl von Paketen pro Zeiteinheit aufweisen können, stellt die Verbindungssteuerung ein herausforderndes Problem dar. Es ist bekannt, dass Paketverluste zu einer merklichen Verschlechterung beim TCP Durchsatz führen. Daher sollte für den bestmöglichen Durchsatz eine minimale Anzahl von Paketverlusten auftreten.
Bislang wurden mehrere Schemata, einschließlich schnellen TCPs bzw. Fast-TCP vorgestellt, um die Funktion des Verhinderns einer Überlastung in der TCP-Flusssteuerung zu verbessern. Obwohl der Zweck dieser Mechanismen darin besteht, Paketverluste bzw. Verwerfen von Paketen im Fall von Warteschlangenüberläufen zu vermeiden, kann eine Netzwerküberlastung nicht vollständig vermieden werden, selbst mit äußerst perfekten Überlastungsverhinderungsmechanismen. Somit ist es weiterhin notwendig, diese Mechanismen mit existierenden TCP-Flusssteuerungsmechanismen zur Überlaststeuerung bzw. Überlastabwehr zu kombinieren, das heißt, Quellenfensterverringerung bzw. Source-Window-Reduction soll manchmal aufgerufen werden durch verlorene Pakete aufgrund eines Zwischenspeicherüberlaufs, um dadurch die zeitliche Überlastung abzuschwächen.
Anfänglich war beabsichtigt, dass das Internet Dienstenach-bestem-Bemühen bzw. sogenannte Best-Effort-Dienste unterstützt, und das TCP-Überlast-Steuerungsverfahren, welches tatsächlich implementiert war, wurde auf der Annahme entwickelt, dass das Netzwerk als „black-box" behandelt werden würde. Das heißt, dass die Endknoten keine Steuerung durchführen, indem sie sich direkt von dem Zustand von Routern und Übertragungsleitungen vergewissern, sondern vielmehr den Verkehr regulieren, indem sie indirekt aus Paketverlusten und Antwortzeitschwankungen Rückschlüsse auf die Netzwerklast ziehen. Bei verdrahteten Netzwerken darf dies keine schwerwiegenden Probleme hervorrufen, da Paketverluste im wesentlichen aufgrund von Überlastung auftreten. Beim Vorhandensein hoher Fehlerraten und intermittierender Verbindungscharakteristik wie bei drahtlosen Verbindungswegen, bedingt dieses Verlassen auf Paketverluste als Indikator für Überlastung jedoch eine beträchtliche Verschlechterung der TCP Leistungsfähigkeit, da das TCP auf Paketverluste so reagiert, wie es in der drahtgebundenen bzw. verdrahteten Umgebung reagieren würde. Das heißt, es lässt seine Fenstergröße zum erneuten Übertragen abfallen bzw. verringert diese vor dem erneuten Übertragen von Paketen, initiiert Überlastungssteuerungs-(bzw. Überlastungsabwehr-) oder -Verhinderungsmechanismen und setzt seinen Zeitgeber zur erneuten Übertragung zurück. Dies führt zu einer unnötigen Verringerung der Verbindungsbandbreitennutzung von Drahtlos- und Mobilnetzwerken, was einen geringen Durchsatz und sehr hohe interaktive Verzögerungen bedingt.
Kürzlich wurden mehrere Schemata vorgeschlagen, um die Effekte von Verlusten ohne Überlastungsbezug auf die TCP-Leistungsfähigkeit über Netzwerke abzuschwächen, die drahtlose oder ähnliche Verbindungen mit hohen Verlusten haben.
In dem Artikel „Implementation and Performance Evaluation of Indirect TCP" von Ajay V. Bakre et al., IEEE Transactions an Computers, Band 46, Nr. 3, März 1997, ist das indirekte TCP Protokoll als eines der ersten Protokolle beschrieben, um zwischen unterschiedlichen Verlusten zu unterscheiden, indem eine TCP Verbindung zwischen einem festen und einem mobilen Host in zwei getrennte Verbindungen an der Basisstation aufgeteilt wird, so dass ein optimierteres drahtloses verbindungsspezifisches Protokoll, welches im Hinblick auf bessere Leistungsfähigkeit abgestimmt ist, über eine Einstufen-Drahtlos-Verbindung bzw. One-Hop-Drahtlosverbindung verwendet werden kann. Jedoch gibt es bei diesem Ansatz einige Nachteile, wie beispielsweise der Verlust der Semantik, Anwendungsrückverbindung bzw. "Application Re-Linking" und Software-Verwaltungsdaten bzw. Software-Overhead.
Weiterhin wurde ein ELN-Protokoll (Explicit Loss Notification bzw. ausdrückliche Verlustbenachrichtigung) vorgeschlagen, bei dem eine Option zur ausdrücklichen Benachrichtigung über einen Verlust bei TCP Bestätigungen hinzugefügt ist, wenn ein Paket auf einem drahtlosen Verbindungsweg verloren wird. In diesem Fall müssen zukünftige kumulative Bestätigungen, die jedem verlorenen Paket entsprechen, immer markiert werden, um zu identifizieren, dass ein Verlust aufgetreten ist, der keinen Überlastbezug hat. Weiterhin könnte es schwierig sein, Pakete zu identifizieren, die aufgrund von Fehlern auf verlustbehafteten Verbindungswegen verloren wurden, und eine Verbindung eines verfälschten Pakets zu bestimmen, da der Header bzw. Kopfabschnitt selbst verfälscht sein könnte.
Zusätzlich ist ein weiteres Forschungsgebiet beschrieben in „A proposal to add Explicit Congestion Notification (ECN) to IP" von K. K. Ramakrishnan et al., Internet Draft-kksjf-ecn-02.txt, September 1998, bei dem Überlastungssteuerung von Paketverlusten entkoppelt ist. Aufgrund dessen werden Paketverluste keine Überlastungssteuerung aufrufen bzw. aktivieren, so dass Übertragungsfehler nicht zu einem verringerten Durchsatz führen. Insbesondere wird eine ausdrückliche Benachrichtigung bezüglich einer Überlastung bzw. Explicit Congestion Notification (ECN) zu einer TCP-Bestätigungsoption hinzugefügt, indem in dem Netzwerk einsetzende Überlastung erfasst wird. Auf den Empfang dieser ECN Nachricht hin, verringert der Sender sein Überlast-Fenster ("Congestion Window") jedes Mal, wenn ein Verlust auftritt.
Jedoch haben viele derzeitige Netzwerke mit Routern, deren Hauptfunktion darin besteht, Pakete zu routen, keine Vorkehrungen für die Erfassung einer einsetzenden Überlastung, bevor ein Warteschlangenüberlauf auftritt. Selbst wenn solche Vorkehrungen vorgesehen wären, könnte ungeachtet dessen die Paketmarkierungsrate nicht Schritt halten mit deren Durchlaufrate während Perioden, in denen die mittlere Warteschlangengröße einen oberen Schwellenwert überschreitet. Daher verlieren bzw. verwerfen Router Pakete eher als dass sie die ECN in dem Paket-Header setzen.
Trotz all dieser Schwierigkeiten ist es wahrscheinlich, dass ECN allmählich eingesetzt wird. Es ist somit eine wesentliche Anforderung für zukünftige TCP Netzwerke, dass sie für die Umstellung ausgelegt sind.
Weiterer Stand der Technik in dem einschlägigen Gebiet ist aus den folgenden Druckschriften bekannt, die jedoch alte nicht die genannte Anforderung für eine Umstellung von TCP-Netzwerken für den Einsatz von ECN erfüllen können.
In dem Artikel „A Comparison of Mechanisms for Improving TCP Performance over Wireless Links" von H. Balakrishnan et al., IEEE/ACM Transactions an Networking, Vol. 5, No. 6, Dezember 1997, Seiten 756 bis 769, geht es allgemein um eine Verluststeuerung in einem TCP Netzwerk. Er lehrt insbesondere die Hinzufügung von Verlustbenachrichtigungen, die auf einen Verlust hinweisen, der nicht mit einer Überlast in Bezug steht. Weiterhin lehrt er die Hinzufügung von ELN-Informationen zu TCP-Bestätigungen. Auch lehrt dieser Artikel, dass ein Paket auf der Drahtlosstrecke zwischen zwei Knoten verloren gegangen ist. Daher ist nicht ein Zwischenspeicherüberlauf die Ursache für einen Paketdatenverlust, wie es vorstehend problematisiert ist.
In dem Artikel „Improving TCP/IP Performance over Wireless Networks" von H. Balakrishnan et al., MOBICOM 95, Berkeley, USA, 1995, Seiten 2 bis 11, wird im Wesentlichen eine Zwischenspeicherung von Paketen an einer Basisstation und die Durchführung von lokalen Neuübertragungen gelehrt.
In dem Artikel „A Binary Feedback Scheme for Congestion Avoidance in Computer Networks with a Connectionless Network Layer" von K. K. Ramakrishnen und R. Jain, Proc. SIGCOMM, 88, Vol. 18, No. 4, August 1988, wird gelehrt, dass ein Überlasthinweisbit in einem fraglichen Paket in der Vorwärtsrichtung gesetzt wird. Weiterhin wird zwar eine Abhängigkeit von einer mittleren Warteschlangenlänge gelehrt, aber ohne auf den Verlust eines Datenpakets Bezug zu nehmen. Dieser Artikel enthält keinen Hinweis auf eine zweckmäßige Realisierung einer Neuübertragung in diesem Zusammenhang.
In dem US-Patent Nr. US 5,675,742 A ist beschrieben, dass für einen Feedbackprozess aufgrund eines Staus in einem Router ein Flag in einem Paket gesetzt und zum Zielsystem übertragen wird. Auch diese Druckschrift enthält aber keinen hilfreichen Hinweis auf eine zweckmäßige Realisierung einer Neuübertragung in diesem Zusammenhang.
ZUSAMMENFASSUNG DER ERFINDUNG
Es ist daher eine Aufgabe der vorliegenden Erfindung, ein Verfahren zur Steuerung der Überlastung in einem paketvermittelten Netzwerk und ein paketvermitteltes Telekommunikationsnetzwerk anzugeben, mittels dem bzw. mit dem eine unnötige Verringerung der Verbindungsweg-Bandbreitenverwendung verhindert werden kann.
Diese Aufgabe wird erfindungsgemäß gelöst durch ein Verfahren gemäß Patentanspruch 1, sowie durch ein paketvermitteltes Telekommunikationsnetzwerk gemäß Patentanspruch 13.
Vorteilhafte Weiterbildungen und Modifikationen sind in den jeweiligen abhängigen Patentansprüchen angegeben.
Demgemäß ist ein abgekürzter ECN Mechanismus bzw. Short-Cut ECN Mechanismus (Drahtlos-ECN bzw. Wireless-ECN) bereitgestellt, der vorzugsweise in Drahtlos- oder Mobilumgebungen verwendet werden kann. Wie ELN ist der Mechanismus angepasst, um der TCP Quelle den Grund für einen Paketverlust mitzuteilen. Insbesondere kann die Quelle informiert werden, dass ein Verlust aufgrund von Gründen aufgetreten ist, die mit Netzwerküberlastung in Bezug stehen, so dass eine Überlastungssteuerung von erneuten Übertragungen entkoppelt werden kann. Somit wird das Überlastungsfenster nur verringert, falls die Überlastungsbenachrichtigungsinformation empfangen wurde, ohne Paketverluste zu berücksichtigen. Durch schnelles Informieren der Quelle über das Auftreten eines Verlustes aufgrund von Gründen, die in Bezug zu einer Netzwerküberlastung stehen, kann Überlastungssteuerung und Verlust-Wiederherstellungsmechanismus ("loss recovery") getrennt werden. Dieser Mechanismus ist einfach zu implementieren und mit der existierenden TCP-Überlastungssteuerung bzw. Überlastabwehr kompatibel.
Wenn Drahtlos-ECN bzw. Wireless-ECN in der herkömmlichen ECN Umgebung verwendet wird, wird Wireless-ECN durch die TCP Quelle als eine neue Instanz der Überlastung interpretiert. Die Integration von Wireless-ECN in den bekannten ECN Mechanismus erlaubt es, dass die Überlastungssteuerung durch WECN oder ECN Nachrichten initiiert wird. Da eine WECN Nachricht zumindest nicht später als die Schwellenanzahl von nachfolgenden Paketen hinzugefügt werden sollte, kann sie Überlastungssteuerung noch früher als mit dem schnellen Mechanismus zur erneuten Übertragung aufrufen. Die Integration von WECN in den ECN Mechanismus vermeidet nicht nur unnötige überlastungsinduzierte Paketverluste, sondern verhindert ebenfalls die unnötige verzögerte Initiierung der Überlastungssteuerung, was oft auftritt aufgrund eines Verlustes eines ECN Pakets oder eines ineffizienten Effekts des ECN Mechanismus oder anderer Ausnahmen bei dem ECN Mechanismus.
Vorzugsweise folgt das folgende Datenpaket direkt dem verlorenen Datenpaket. Dies stellt sicher, dass die Überlastungsbenachrichtigungsinformation unvermeidbar hinzugefügt werden kann, selbst mit bzw. bei Mehrfachpaketverlusten, und es besteht kein Bedürfnis für einen Mechanismus in dem Router, um die mittlere Warteschlangengröße zu überwachen. Da die Überlastungsbenachrichtigungsinformation so schnell wie möglich nachdem der Paketverlust aufgrund von Überlastung aufgetreten ist hinzugefügt wird, ist sichergestellt, dass eine Netzwerküberlastung zeitlich abgeschwächt wird.
Weiterhin kann die Überlastungsbenachrichtigung in dem Header bzw. Kopfabschnitt des folgenden Datenpakets hinzugefügt sein. In diesem Fall kann beispielsweise Bit Nr. 5 in dem IPv4 TOS Oktett verwendet werden.
Vorzugsweise sollte es jedem der Netzwerkknoten möglich sein, die Überlastungsbenachrichtigunginformation hinzuzufügen, um dadurch einen überlastungsbezogenen Datenverlust anzuzeigen. Dadurch stellen mehrfache WECN Nachrichten eine Robustheit gegen die Möglichkeit des Verlustes eines WECN Pakets in den bidirektionalen Übertragungswegen bereit.
Das Hinzufügen der Überlastungsbenachrichtigunginformation ist zu jenen folgenden Datenpaketen erlaubt, die zu dem gleichen Überlastungsfenster in den aufeinanderfolgenden zurückliegenden Routern gehören. Zudem ist es jedem Netzwerkknoten erlaubt, die Überlastungsinformation lediglich einmal hinzuzufügen. Somit gehört jede Überlastungsbenachrichtigunginformation, die in einem Übertragungsfenster hinzugefügt wurde, zu einem anderen Netzwerkknoten.
Auf den Empfang eines Datenpakets mit einer hinzugefügten Überlastungsbenachrichtigunginformation hin setzt das Verkehrsziel vorzugsweise einen ÜberlastungsbenachrichtigungFlag bzw. eine Überlastungsbenachrichtigungkennung in dem Kopfabschnitt bzw. Header eines Bestätigungspakets. Der ÜberlastungsbenachrichtigungsFlag kann das Bit Nr. 8 in dem TCP Header des darauffolgenden Bestätigungspakets sein. Da das TCP die WECN Nachricht verwendet, um Überlastungssteuerung aufzurufen, wird ein Mechanismus zur erneuten Übertragung lediglich im Fall eines Paketverlustes ohne eine WECN Nachricht durchgeführt. Somit wird die TCP-Datenflussrate nicht beeinträchtigt. Dies ist äußerst nützlich in Drahtlos- oder Mobilnetzwerken, da das Netzwerk selbst die Funktion des Unterscheidens unterschiedlicher Ursachen von Paketverlusten hat. Durch Benachrichtigen der Quelle mit einem WECN Bestätigungspaket immer dann, wenn ein überlastungsbezogener Verlust aufgetreten ist, können Paketverluste aufgrund von Übertragungsfehlern das TCP Flusssteuerungsfenster (Überlastungsfenster) nicht verringern, was zu einer beträchtlichen Verbesserung der Leistungsfähigkeit führt. Das Überlastungsfenster ("Congestion Window") kann lediglich durch den ÜberlastungsbenachrichtigungsFlag verringert werden, der aufgrund eines Überlastungsverlustes gesetzt ist.
Vorzugsweise wird eine Überlastungsverarbeitung bei der Verkehrsquelle nur wiederholt, nachdem die ausstehenden Datenpakete, die vor dem ersten Empfang eines ÜberlastungsbenachrichtigungsFlags übertragen wurden, alle bestätigt wurden. Dadurch wird die Verringerung des Überlastungsfensters nicht wiederholt, falls das Paket verloren ging, bevor die Quelle ihr Fenster im Ansprechen auf den ÜberlastungsbenachrichtigungsFlag verringert hat.
Der WECN Mechanismus gemäß der vorliegenden Erfindung ermöglicht das vollständige Entkoppeln der Überlastungssteuerungsfunktion von Paketverlusten. Verglichen mit ECN kann die WECN Benachrichtigung unvermeidbar hinzugefügt werden, da die verlorenen Pakete dem Zwischenspeicher Zeit geben, einen gewissen Raum zum Halten und Übertragen neuer Daten zu räumen. Falls eine WECN verloren wird, beispielsweise in einem Zustand eines Verbindungswegs mit hohem Verlust, wo alle WECN Mitteilungen in einem Steuerungszyklus verloren werden, oder in einem Fall, bei dem nur eine WECN in einem Übertragungsfenster hinzugefügt wird und diese WECN aufgrund einer Störung verloren wird, wird dieser Verlust zu einem Versagen der Überlastungssteuerung für diesen Fluss und einer erhöhten Überlastung des Netzwerks führen, da die angenommene Ursache des Datenverlustes keine Überlastung war. Ungeachtet dessen werden andere WECNs für darauffolgend verlorene Pakete in dem nächsten Überlastungsfenster hinzugefügt. Somit ist der Mechanismus sehr sicher und robust, verglichen mit dem ECN Mechanismus, wo der Verlust einer ECN keine andere Hinzufügung eines ECN Pakets bedingen wird.
Gemäß der vorliegenden Erfindung brauchen keine Paketverluste berücksichtigt zu werden, um Überlastungsfensterverringerung aufzurufen. Da Mechanismen zur Überwachung der mittleren Warteschlangengröße in den Routern nicht erforderlich sind, kann der WECN Mechanismus auf eine einfache Weise implementiert werden und eröffnet den Weg zu einem weiteren Einsatz des ECN Mechanismus. Es ist zu beachten, dass der WECN Mechanismus kompatibel ist zu allen TCP Überlastungssteuerungsmechanismen, solange sie durch Paketverluste aufgerufen werden, und es ist leicht, diese in Drahtlos- und Mobilnetzwerke einzubringen. Mit dem inkrementellen bzw. schrittweisen Einsatz des ECN Mechanismus kann es die Integration von WECN in ECN erlauben, die Überlastungssteuerung durch WECN oder ECN Nachrichten und WECN Paketfunktionen nur zu initiieren, wenn innerhalb des entsprechenden Datenfensters ein Paketverlust aufgrund einer Überlastung früher ankommt als eine ECN. Mit dem Hinzufügen von WECN zu dem Mechanismus Fast-TCP könnte die Fensterreduktion bzw. Fensterverringerung durch WECN aufgerufen werden, wenn ein Zwischenspeicherüberlauf auftritt, da das TCP-Verhalten an den Endsystemen nicht verändert wird. Somit ist dies ein wirksamer Weg zur Verbesserung der TCP Leistungsfähigkeit in Drahtlos- und Mobilnetzwerken.
Da es erforderlich ist, WECN nicht später als nach einer Schwellenanzahl von Duplikatbestätigungen hinzuzufügen, kann zusätzlich eine verbesserte TCP Leistungsfähigkeit in verdrahteten Netzwerkumgebungen erwartet werden, da die Initiierung der Überlastungssteuerung durch die WECN Nachricht beschleunigt wird. Falls diese Nachricht zum Triggern der Übertragung oder erneuten Übertragung von Datenpaketen verwendet wird, kann es zudem die Geschwindigkeit des Eintritts in die TCP Wiederherstellungsphase bzw. TCP-Recovery-Phase aufgrund von Überlastung beschleunigen, so dass überlastungsbedingte verlorene Pakete schnell erneut übertragen werden.
KURZE BESCHREIBUNG DER ZEICHNUNG
Nachfolgend wird die vorliegende Erfindung ausführlicher auf der Grundlage eines bevorzugten Ausführungsbeispiels mit Bezug auf die beigefügte Zeichnung beschrieben. Es zeigen:
1 ein allgemeines Blockschaltbild einer Flusssteuerungsschleife in einem TCP-Über-ATM-Netzwerk, bei dem das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung implementiert ist;
2 ein allgemeines Blockschaltbild eines Zwischenknotens, der zwischen einer Verkehrsquelle und einem Verkehrsziel angeordnet ist, gemäß dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung;
3 ein allgemeines Blockschaltbild zweier aufeinanderfolgender Zwischenknoten gemäß dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung;
4 ein Diagramm von Übertragungen zwischen einer Verkehrsquelle und einem Verkehrsziel, im Fall dass eine Drahtlos-Überlastungs-Benachrichtigung (WECN) an der Verkehrsquelle ankommt, bevor eine herkömmliche Überlastungs-Benachrichtigung (ECN) innerhalb des gleichen Übertragungsfensters ankommt;
5 ein Diagramm von Übertragungen zwischen der Verkehrsquelle und dem Verkehrsziel, falls ein nicht überlastungsbedingter Paketverlust vor einer Überlastungsbenachrichtigung innerhalb des gleichen Übertragungsfensters erfasst wird;
6 ein Diagramm von Übertragungen zwischen der Verkehrsquelle und dem Verkehrsziel, im Fall, dass eine WECN an der Verkehrsquelle nach einer unwirksamen ECN Implementierung in dem vorangehenden Übertragungsfenster ankommt;
7 ein Diagramm von Übertragungen zwischen der Verkehrsquelle und dem Verkehrsziel, im Fall, dass eine WECN an der Verkehrsquelle nach einer normalen ECN innerhalb des gleichen Übertragungsfensters empfangen wird;
8 ein Diagramm von Übertragungen zwischen der Verkehrsquelle und dem Verkehrsziel, in dem Fall, dass eine WECN vor drei folgenden Paketen in dem gleichen Übertragungsfenster gesetzt wird;
9 ein Diagramm von Übertragungen zwischen der Verkehrsquelle und dem Verkehrsziel, im Fall einer WECN und eines nicht überlastungsbedingten Paketverlustes innerhalb des gleichen Übertragungsfensters; und
10 ein Diagramm von Übertragungen zwischen der Verkehrsquelle und dem Verkehrsziel, im Fall eines verzögerten Setzens der WECN und mehrfachen Überlastungsverlusten innerhalb des gleichen Übertragungsfensters.
BESCHREIBUNG DES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS
Nachfolgend wird das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung beschrieben auf der Grundlage eines TCP-Über-ATM-Netzwerks, wie in 1 gezeigt.
ATM (Asynchronous Transfer Mode) ist eine verbindungsorientierte Paketvermittlungstechnik, die von der internationalen Telekommunikationsstandardisierungsorganisation ITU-T als die Ziellösung des breitbandigen digitalen Netzwerks für integrierte Dienste bzw. Integrated Services Digital Network (B-ISDN) gewählt wurde. Die Probleme herkömmlicher Paketnetzwerke bzw. paketvermittelter Netzwerke wurden bei dem ATM Netzwerk durch Verwenden kurzer Pakete einer Standardlänge (53 Byte), die als Zellen bekannt sind, beseitigt. ATM Netzwerke werden schnell als Backbones für die zahlreichen Teile von TCP/IP Netzwerken wie beispielsweise dem Internet eingesetzt. Dies gilt auch für Drahtlos- oder Mobilnetzwerke.
Gemäß 1 ist eine Verbindung zwischen zwei Benutzerendgeräten A und B in dem TCP-Über-ATM-Netzwerk gezeigt, das heißt, die Benutzerendgeräte verwenden TCP als ein Transportschichtprotokoll. Zusätzlich sind zwei Zugangsknoten AN1 und AN2 der Benutzerendgeräte, ein Zwischenknoten N1 und Übertragungsleitungen TL1, TL2, die die Knoten verbinden, gezeigt.
Nachdem ein anfänglicher Quittungsaustausch bzw. Handshake abgeschlossen ist, beginnen die Benutzerendgeräte A und B mit dem Senden von Daten mittels TCP Segmenten. Der Ausdruck „Segment" betrifft die von TCP zu IP (Internet Protokoll) geleitete Informationseinheit. IP Kopfabschnitte bzw. IP Header werden an diese TCP Segmente angefügt, um IP Datagramme zu bilden, das heißt, TCP Segmente werden innerhalb von IP Datagrammen als die von IP verwendeten Informationseinheiten zu dem Empfänger transferiert. Jedes unverfälschte TCP Segment, das die Handshaking Segmente enthält, wird bestätigt. Zum Veranschaulichen der Funktion der Flusssteuerungsschleife sei angenommen, dass das Benutzerendgerät A ein TCP Segment zu dem Benutzerendgerät B sendet. Auf der Netzwerkschicht fügt das Benutzerendgerät A einen IP Header diesem TCP Segment hinzu, um ein IP Datagramm zu bilden. Dieses Datagramm wird in Standard-ATM-Zellen in dem Zugangsknoten AN1 umgewandelt, der am Rand des ATM Netzwerks ANW angeordnet ist. Die Zellen des Datagramms werden dann durch das ATM Netzwerk zu dem Zugangsknoten AN2 des Benutzerendgeräts B geroutet. Dieser Zugangsknoten rekonstruiert das ursprüngliche IP Datagramm aus den ankommenden Zellen und sendet das IP Datagramm zu dem Benutzerendgerät B. Das Benutzerendgerät B entfernt den IP Header, um das TCP Segment freizulegen. Wenn das Segment korrekt empfangen wird, sendet das Benutzerendgerät B ein bestätigendes TCP Segment ACK zu dem Benutzerendgerät A zurück.
TCP ist eines der wenigen Transportprotokolle, welches ursprünglich einen Überlaststeuerungsmechanismus hat. Das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung beruht auf diesem bekannten TCP Steuerungsmechanismus.
Deshalb wird dieser Mechanismus nachfolgend kurz beschrieben.
TCP-Überlaststeuerung beruht auf zwei Variablen: dem angebotenen Fenster des Empfängers (Wrcvr) und dem Überlastfenster (CNWD). Das von dem Empfänger angebotene Fenster wird bei dem Empfänger als ein Maß der Zwischenspeicherungskapazität des Empfängers geführt, und das Überlastfenster wird an dem Sender als ein Maß der Kapazität des Netzwerks geführt. Die TCP Quelle kann nie mehr Segmente senden, als das Minimum des angebotenen Fensters des Empfängers und des Überlastfensters.
Das TCP Überlast-Steuerungsverfahren weist zwei Phasen auf: langsamer Start und Überlastverhinderung. Eine als SSTHRES (Slow Start Threshold bzw. Langsamer-Start-Schwelle) bezeichnete Variable wird an der Quelle geführt, um zwischen den zwei Phasen zu unterscheiden. Die Quelle beginnt in der Phase des langsamen Starts zu senden, indem ein TCP Segment gesendet wird, das heißt, der Wert von CWND wird zu Beginn auf eins gesetzt. Wenn die Quelle eine Bestätigung empfängt, erhöht sie CWND um eins und sendet in Folge dessen zwei weitere Segmente. Auf diese Weise verdoppelt sich der Wert von CWND nach jeder Umlaufzeit während der Phase des langsamen Starts, da jedes Segment durch das Zielendgerät bestätigt wird. Die Phase des langsamen Starts endet und die Überlastverhinderungsphase beginnt, wenn CWND den Wert von SSTHRES erreicht.
Falls ein Datenpaket auf einer TCP Verbindung verloren wird, empfängt die Quelle keine Bestätigung und führt eine Verlust-Wiederherstellungsoperation durch.
Durch Duplizieren der Bestätigungen kann die TCP Quelle dazu gebracht werden, ihre Ausgangsrate zu verringern. Dies beruht auf den Algorithmen der schnellen erneuten Übertragung und schnellen Wiederherstellung, die die Quelle automatisch durchführt, nachdem eine gewisse Anzahl von Duplikatbestätigungen empfangen wurden. Diese Algorithmen sind in unterschiedlichen TCP Versionen weitverbreitet implementiert. Gemäß den Algorithmen führt die Quelle, nachdem sie eine vorbestimmte Schwellenanzahl von Bestätigungen (z. Bsp.: drei Bestätigungen) empfangen hat, eine erneute Übertragung dessen durch, was das fehlende Segment zu sein scheint, ohne auf den Ablauf eines Zeitgebers für die erneute Übertragung zu warten (Algorithmus der schnellen erneuten Übertragung bzw. Fast Retransmission Algorithmus). Danach, führt die Quelle Überlastverhinderung durch, anstatt eines langsamen Starts, um den Datenfluss nicht abrupt zu reduzieren (Algorithmus der schnellen Wiederherstellung bzw. Fast Recovery Algorithmus bzw. Algorithmus der schnellen Störungsbehebung).
2 zeigt ein allgemeines Diagramm eines an eine TCP Quelle A und ein TCP Ziel B, bei denen es sich jeweils um Arbeitsstationen bzw. Workstations oder dergleichen handeln kann, angeschlossenen Zwischenknotens. In dem Zwischenknoten ist eine Überlast als ein schwarzer Stern dargestellt, ein durchlaufendes Datenpaket als ein durchgezogenes Quadrat, und ein aufgrund der Überlast verlorenes Datenpaket als ein gepunktetes Quadrat.
Gemäß dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung ist in dem Zwischenknoten eine Drahtlos-ECN (WECN) Steuerungseinrichtung C bereitgestellt, die angepasst ist, um ein Datenpaket mit einer ausdrücklichen Drahtlos-Überlastbenachrichtigung (WECN bzw. Wireless Explicit Congestion Notification) unmittelbar nachdem ein Paketverlust aufgrund eines Zwischenspeicherüberlaufs aufgetreten ist, zu markieren, wobei der Zwischenspeicherüberlauf mittels einer (nicht dargestellten) Erfassungseinrichtung erfasst werden kann. Die Erfassungseinrichtung kann in der Steuerungseinrichtung C enthalten sein oder kann in dem Zwischenknoten eine separate Einrichtung sein.
Falls ein erstes verlorenes Paket aufgrund eines Zwischenspeicherüberlaufs in dem Zwischenknoten oder Router innerhalb eines Übertragungsfensters der TCP Quelle erfasst wird, wird eine WECN in dem Header bzw. Kopfabschnitt des unmittelbar folgenden durchlaufenden Pakets hinzugefügt. Die erforderliche Zeit für diesen Vorgang ist verfügbar aufgrund des verlorenen Datenpakets, was in zusätzlicher Zwischenspeicherzeit resultiert. Somit wird die WECK so schnell wie möglich nach einem Paketverlust hinzugefügt, so dass die Netzwerküberlast so bald wie möglich abgeschwächt werden kann.
Weiterhin zeigt ein Pfeil am Fuß bzw. unteren Ende von 2 die Übertragungsstrecke der WECN an, wobei das TCP Ziel B eine WECN Kennung bzw. einen WECN Flag in dem Header bzw. Kopfabschnitt eines Pakets im Ansprechen auf den Empfang eines WECN Datenpakets setzt, um dadurch die Überlast in dem Zwischenknoten mitzuteilen.
Jeder Knoten in dem Netzwerk sollte in der Lage sein, die WECN hinzuzufügen, um dadurch eine Überlast anzuzeigen, sobald ein Paketverlust auftritt. Um redundantes Hinzufügen von WECN zu verringern, ist es lediglich erforderlich, dass eine WECN Nachricht in einem Knoten gesetzt bzw. eingestellt wird, was ausreichend ist, um die Überlast mitzuteilen. Die WECN jedoch, bei der es sich um ein einzelnes WECN Bit handeln kann, kann in den folgenden Paketen, die zu dem gleichen Übertragungs- oder Überlastfenster gehören, durch unterschiedliche der aufeinanderfolgenden Router hinzugefügt werden, durch die die Datenpakete hindurchlaufen. Da es eine Umlaufzeit von der ersten hinzugefügten WECN zum Erreichen der Quelle A erfordert und der Zustand und die Zwischenspeicherbelegung in jedem Netzwerkknoten herkömmlicherweise stark variieren, wird im allgemeinen nicht nur eine WECN in einem Übertragungsfenster während einer Umlaufzeit gesetzt, da das erste verlorene Paket in jedem Zwischenknoten nicht zur gleichen Zeit auftreten muss. Somit gehört jede in einem Übertragungsfenster hinzugefügte WECN zu einem unterschiedlichen Übertragungs-Netzwerkknoten, dem es erlaubt ist, die WECN lediglich einmal hinzuzufügen.
3 zeigt ein allgemeines Diagramm eines Zwischenknotens 1 und eines Zwischenknotens 2, die aufeinanderfolgend in der Richtung der Vorwärtsstrecke verbunden sind. In dem vorliegenden Fall sind beide Zwischenknoten 1 und 2 überlastet bzw. verstopft. Ein WECN Datenpaket mit einer hinzugefügten WECN ist als ein schraffiertes Quadrat dargestellt.
Gemäß 3 fügt eine Steuerungseinrichtung C1, die in dem Zwischenknoten 1 angeordnet ist, eine WECN zu dem zweiten Datenpaket hinzu, da das erste Datenpaket aufgrund der Überlastung verloren ging. Weiterhin wird auch das dritte Datenpaket aufgrund der Überlast verloren. Da es dem Zwischenknoten 1 jedoch nur erlaubt ist, die WECN einmal hinzuzufügen, bleibt das erste Datenpaket ohne eine WECN Hinzufügung. Die Datenpaketsequenz wird dann über die Vorwärtsstrecke zu dem Zwischenknoten 2 übertragen, wo die fünften und sechsten Datenpakete aufgrund der Überlast verloren werden. Entsprechend wird eine WECN zu dem siebten Datenpaket durch eine Steuerungseinrichtung C2 des Zwischenknotens 2 hinzugefügt.
Das TCP Ziel B empfängt die Datenpaketsequenz, die die WECN Pakete Nummer 2 und 7 umfasst, und setzt die WECN Flags der entsprechenden Bestätigungspakete, um zu der TCP Quelle A zurück geleitet zu werden.
Auf der Vorwärtsstrecke dürfen aufeinanderfolgende Router ein WECN Bit in ankommenden Paketen nicht löschen bzw. überschreiben, um dadurch die WECN Regelbefolgung im Netzwerk beizubehalten. Da das TCP Ziel B einen WECN Flag in dem TCP Header eines Bestätigungspakets im Ansprechen auf jedes IP Paket mit einem hinzugefügten WECN Bit setzt, kann die TCP Quelle A innerhalb eines Überlastfensters eine Vielzahl von WECN Paketen empfangen, die von unterschiedlichen Zwischenknoten stammen. Da die Hauptfunktion der WECN darin besteht, lediglich einmal innerhalb eines Übertragungsfensters in dem Fall einer Netzwerküberlastung eine Überlastungssteuerung zu initiieren, das heißt, das Überlastfenster zu verringern, sorgen diese mehrfachen WECN Nachrichten auch für eine Stabilität gegen die Möglichkeit des Verlierens eines WECN Pakets auf der bidirektionalen Übertragungsstrecke.
Um den derzeit vorgeschlagenen ECN Mechanismus in dem IETF Entwurf bzw. IETF Draft zu erfüllen, sollten die einer Überlast ausgesetzten Informationen in den regulären Headern eines IP Pakets beibehalten werden, da die Verarbeitung der regulären Header in IP Paketen effizienter ist als die Verarbeitung der Header-Informationen in IP Optionen. Bei dem ECN Mechanismus sind Bit Nr. 6 und Bit Nr. 7 des IPv4 TOS Oktetts als das ECT Bit bzw. das CE Bit bestimmt. Zusätzlich dazu kann Bit Nr. 5 in dem IPv4 TOS Oktett als der WECN-Echo-Flag ausgewählt werden, der verwendet wird, um Überlastpaketverluste durch Zwischen-Router oder andere Netzwerkelemente anzuzeigen. Dadurch kann eine unterschiedliche Fensterverringerung durch die WECN Überlaststeuerung initiiert werden.
Wenn das TCP Ziel B ein CE Datenpaket empfängt, setzt es demzufolge den ECN-Echo-Flag in dem TCP Header des darauffolgenden ACK Pakets. Gemäß den unterschiedlichen CE Bit Einstellungen für die ECN und die WECN Pakete sind zwei unterschiedliche Flags des TCP Headers erforderlich. Da Bit Nr. 9 als der ECN-Echo-Flag des TCP Headers bestimmt ist, kann Bit Nr. 8 als der WECN-Echo-Flag verwendet werden. Falls irgendwelche der empfangenen Datenpakete CE Pakete mit gesetztem Bit 5 sind, hat somit das zurückgeführte ACK seinen WECN-Echo-Flag gesetzt. Falls irgendwelche der empfangenen Datenpakete CE Pakete mit gesetztem Bit 7 sind, dann hat das zurückgeführte ACK seinen ECN-Echo-Flag gesetzt. Da lediglich eine WECN in einem Zwischenknoten hinzugefügt werden darf, wird die Anzahl von WECN Paketen die Anzahl von gesamten Netzwerkknoten nicht überschreiten, die durch das Datenpaket zu durchlaufen sind. Dadurch kann die Last des Bereitstellens einer Zwischenphasen-Systemeinrichtung zwischen IP und TCP an der Zielseite gemildert werden.
Da es nicht auf Überlast zurückzuführenden Paketverlusten nicht erlaubt ist, Überlaststeuerung zu initiieren, gemäß dem vorstehend vorgeschlagenen WECN Mechanismus, hinsichtlich der Überlegung des Entkoppelns der Überlaststeuerung und Strategien zur erneuten Übertragung, erfassen somit Endknoten verlorene Datenpakete durch Empfangen einer WECN Nachricht, die durch die Zwischen-Netzwerkknoten gerade zu Zeiten des Zwischenspeicherüberlaufs gesetzt wurden, wobei die Überlastantwort der Endknoten auf ein empfangenes CE Paket zumindest so stark ist wie die Überlastantwort auf ein verlorenes Datenpaket, welches unabhängig ist von der Überlaststeuerung. Es besteht ebenfalls kein Bedürfnis für besondere Implementierungen von TCP in Bezug auf den durch die IETF vorgeschlagenen ECN Mechanismus, bei dem TCP eine weniger konservative Antwort erfordert, verglichen mit dem Fall eines verlorenen Paketes, insbesondere über kleine Zeitmaßstäbe, da ein Zwischenspeicherüberlauf noch nicht aufgetreten ist.
Das zusätzliche Erfordernis für die TCP Quelle A, um auf mehrfache WECN Bestätigungspakete zu reagieren, besteht darin, dass sie nicht die Reduktion des Überlastfensters wiederholen sollte, da das Paket wahrscheinlich verloren wurde, bevor die TCP Quelle A ihr Überlastfenster im Ansprechen auf ein früheres WECN Bestätigungspaket verringert hat. Somit sollte die TCP Quelle A auf ein WECN Bestätigungspaket höchstens einmal pro Umlaufzeit reagieren. Dies kann erreicht werden, indem die TCP Quelle A auf eine derartige Weise angepasst wird, dass sie auf ein darauffolgendes WECN Bestätigungspaket nur reagiert, nachdem die ausstehenden Datenpakete, die übertragen wurden, bevor die TCP Quelle A in eine Phase der Verlust-Wiederherstellung auf den Empfang des ersten WECN Bestätigungspakets hin eingetreten ist, alle bestätigt wurden. Ähnlich wie bei dem ECN Mechanismus könnte TCP geändert werden, um eine Verhandlungsphase während des Aufbaus bzw. Setups bereitzustellen, um zu bestimmen, ob beide Endknoten WECN-fähig sind.
Der WECN Mechanismus gemäß dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung führt zu einer Unabhängigkeit von TCP von dem Paketverlust als einem Indikator der Überlast. Da das TCP die WECN Nachricht verwendet, um Überlaststeuerung aufzurufen, wann immer ein Paketverlust auftritt, wird lediglich ein Mechanismus zur erneuten Übertragung als eine Antwort auf einen Paketverlust ohne eine WECN Nachricht gestartet, so dass die TCP Datenflussrate in einem solchen Fall nicht beeinträchtigt ist. Dies ist sehr nützlich in Drahtlos- oder Mobilnetzwerken, da das Netzwerk selbst die Funktion zur Unterscheidung unterschiedlicher Ursachen von Paketverlusten hat. Somit kann das TCP Überlastfenster lediglich verringert werden durch die WECN Nachricht, die aufgrund von Überlastverlusten gesetzt bzw. eingestellt wird.
Zudem kann die TCP Quelle A lediglich einmal während einer Umlaufzeit, und im allgemeinen auf die früheste der empfangenen WECN und ECN ACKs, reagieren. Falls zuerst eine ECN ACK empfangen wird, wird die herkömmliche Überlaststeuerung bei der TCP Quelle A aufgerufen. Wenn einige Paketverluste aufgrund von Überlast vor den ECN Nachrichten innerhalb einer Umlaufzeit ankommen bz. auftreten, werden jedoch die WECN Nachrichten, die unmittelbar auf den durch die Überlast bedingten ersten Paketverlust hin hinzugefügt wurden, rechtzeitig ankommen, um eine allgemeine Überlaststeuerung zu initiieren, beispielsweise mit halber Verkleinerung der Fenstergröße anstatt des Wartens auf die spätere Ankunft der ECN Pakete. Somit führt WECN zu einer Überlaststeuerung, die vollständig frei ist von nicht-überlastbedingten verlorenen Paketen, und hohe Leistungsfähigkeit ist sichergestellt, ohne gezwungen zu sein, auf Inseln unterschiedlicher Ursachen von Paketverlusten in Drahtlos- und Mobilnetzwerken zurückzugreifen.
Der WECN Mechanismus gemäß dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung führt nicht nur zu einer Entkopplung der Überlaststeuerung von der Verlust-Wiederherstellung, sondern leistet ebenfalls einen Beitrag zu der Verlust-Wiederherstellungsphase. Da es erforderlich ist, dass die WECN unmittelbar nach dem Auftreten des Paketverlustes gesetzt wird, ist es äußerst wahrscheinlich, dass das WECN Bestätigungspaket vor der Schwellenanzahl von Duplikatbestätigungspaketen ankommt. Falls diese WECN Nachricht verwendet wird, um die Übertragung oder erneute Übertragung irgendwelcher Datenpakete zu triggern, kann dies die Geschwindigkeit des Eintretens in die TCP-Wiederherstellungsphase erhöhen, um so verlorene Pakete mit Überlastbezug schnell erneut zu übertragen. Jedoch kann die ECN nicht immer unmittelbar nach einem verlorenen Paket hinzugefügt werden, falls es mehrere aufeinanderfolgende Paketverluste oder ungeordnete Pakete vor der Ankunft der ECN Nachricht gibt. Somit kann nicht beurteilt werden, welches verlorene Paket die Hinzufügung der ECN getriggert hat, oder ob sie verzögerungslos hinzugefügt wurde. Somit ist vorgeschlagen, ECN nur anzuwenden, um schnell in die Verlust-Wiederherstellungsphase einzutreten, bevor die Schwellen-Duplikatbestätigungspakete bzw. die Schwellenanzahl von Duplikatbestätigungspaketen ankommen. Anderenfalls sollte Datenübertragung während der Verlust-Wiederherstellung auf der Grundlage der herkömmlichen Algorithmen der schnellen erneuten Übertragung und schnellen Wiederherstellung durchgeführt werden.
4 zeigt ein Diagramm von Übertragungen zwischen der TCP Quelle A und dem TCP Ziel B, wobei die Übertragung einer ersten Nachricht X und einer zweiten Nachricht Y als eine Vielzahl von vorwärts- und rückwärts gerichteten bzw. hin- und her laufenden Pfeilen dargestellt ist, von denen jeder die Übertragung eines Datenpakets, respektive eines Bestätigungspakets (ACK) anzeigt. Gemäß dem Diagramm schreitet die Übertragung vom oberen Ende zum unteren Ende voran und entsprechende ACK Nachrichten sind durch die Rückwärtspfeile von dem Ziel B zu der Quelle A angegeben.
Somit ist ein Übertragungsfenster durch die Zeitperiode (vertikale Richtung) von dem Startpunkt eines Vorwärtspfeils zu dem Endpunkt des entsprechenden Rückwärtspfeils angegeben.
Während der Übertragung der Nachricht X wird das zweite Datenpaket aufgrund eines Überlastverlustes 1 verloren, der dem TCP Ziel B anhand des darauffolgenden dritten Datenpakets mitgeteilt wird. Somit wird ein Bestätigungspaket mit einem gesetzten bzw. eingestellten WECN-Echo-Flag zu der TCP Quelle A zurückgeführt, bevor irgendeine ECN Nachricht angekommen ist. Beruhend auf der empfangenen Bestätigung und duplizierten Bestätigung bzw. Duplikatbestätigung mit dem gesetzten WECN-Echo-Flag führt die TCP Quelle A eine Überlaststeuerung durch Verringern von SSTHRES auf die Hälfte des derzeitigen CWND Wertes durch. Dann wird CWND gleich dem neuen SSTHRES gesetzt.
In dem vorliegenden Fall wird eine ECN verzögert in dem fünften Datenpaket gesetzt, derart, dass ein ECN-Echo-Flag in dem entsprechenden ACK Paket gesetzt wird. An der TCP Quelle A wird die ACK mit ECN-Echo-Flag ignoriert, da die WECN-ACK bereits in dem gleichen Übertragungsfenster (d. h., Vorwärt- und Rückwärtspfeil bezogen auf die Übertragung der Nachricht Y) empfangen wurde. Ungeachtet dessen wird der herkömmliche Algorithmus für schnelle erneute Übertragung bei TCP bzw. der herkömmliche TCP-Fast-Retransmission-Algorithmus für das verlorene Paket 1 gestartet, da die Schwellenanzahl von Duplikat-ACKs, das heißt, 3 ACKs empfangen wurde.
Weiterhin tritt ein zusätzlicher Überlastverlust 2 bei dem sechsten Datenpaket auf, derart, dass eine WECN in dem siebten Datenpaket gesetzt wird, um eine ACK mit einem WECN-Echo-Flag zu initiieren. Jedoch wird die WECN Nachricht ebenfalls an der TCP Quelle A ignoriert, da die ACK mit WECN-Echo-Flag ebenfalls innerhalb des selben Übertragungsfensters empfangen wird. Wiederum wird der herkömmliche TCP-Fast-Retransmission-Algorithmus für das verlorene Paket 2 nach dem Empfang von 3 Duplikat-ACKs durchgeführt.
5 zeigt ein Diagramm ähnlich dem Diagramm gemäß 4, bei dem ein Nicht-Überlastverlust 1 während der Übertragung des ersten Datenpakets der Nachricht X auftritt. In dem vorliegenden Fall kommt die Schwellenanzahl von Duplikatbestätigungen an der TCP Quelle A vor dem Empfang der ECN Bestätigung an. Weiterhin tritt ein Überlastverlust 2 während der Übertragung des sechsten Datenpakets der Nachricht X auf.
Da im Ansprechen auf den Nicht-Überlastverlust 1 keine WECN hinzugefügt wird, wird der herkömmliche Fast-Retransmission-Algorithmus bzw. Algorithmus zur schnellen erneuten Übertragung durchgeführt, das heißt, das verlorene Datenpaket wird erneut übertragen, nachdem drei Duplikatbestätigungen empfangen wurden. Weiterhin wird die herkömmliche Überlaststeuerung, beispielsweise Reduktion von SSTHRES auf 0,625 CWND und Setzen eines neuen CWND gleich dem neuen SSTHRES im Ansprechen auf den Empfang der ECN Bestätigung durchgeführt. Bei dem vorliegenden Beispiel wird eine WECN im Ansprechen auf den Nicht-Überlastverlust 2 gesetzt. Jedoch wird die entsprechende WECN ACK ignoriert, da sie innerhalb des gleichen Übertragungsfensters empfangen wird. Ungeachtet dessen wird aufgrund des herkömmlichen Algorithmus zur erneuten Übertragung das verlorene Paket 2 auf den Empfang von drei Duplikat-Bestätigungen hin erneut übertragen.
6 zeigt ein anderes Übertragungsbeispiel, bei dem eine ECN in einem vorherigen Übertragungsfenster (Nachricht X) aufgrund einer erfassten Überlast gesetzt wird, und ungeachtet der im Ansprechen auf den Empfang der ECN ACK durchgeführten herkömmlichen Überlast ein darauffolgender Paketverlust in dem nachfolgenden Übertragungsfenster (Nachricht Y) auftritt.
Aufgrund des Überlastverlustes wird eine WECN in dem nachfolgenden Datenpaket gesetzt, und eine WECN Überlaststeuerung, das heißt, SSTHRES = 1/2 CWND und CWND = SSTHRES, gemäß dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung, wird im Ansprechen auf den Empfang der WECN ACK durchgeführt. Weiterhin wird die herkömmliche schnelle erneute Übertragung durchgeführt nach dem Empfang von drei Duplikat-Bestätigungen, um dadurch das verlorene Datenpaket erneut zu senden. Die darauffolgende ECN Nachricht wird ignoriert aufgrund ihres Empfangs innerhalb des gleichen Übertragungsfensters.
7 zeigt ein Übertragungsbeispiel, bei dem eine ECN Nachricht vor einem darauffolgenden Nicht-Überlast-Paketverlust 1 und einem Überlast-Paketverlust 2 innerhalb des gleichen Übertragungsfensters empfangen wird.
Gemäß 7 wird eine herkömmliche Überlaststeuerung im Ansprechen auf den Empfang der ECN ACK durchgeführt. Jedoch initiiert der Nicht-Überlastverlust 1 keine WECN Nachricht. Nach drei Duplikat-ACKs wird die herkömmliche erneute Übertragung des Nicht-Überlastverlustes 1 durchgeführt. Die im Ansprechen auf den Überlastverlust 2 darauffolgend gesetzte WECN ACK wird bei der TCP Quelle A ignoriert, da sie in dem gleichen Übertragungsfenster aufgetreten ist. Ungeachtet dessen wird wiederum die herkömmliche erneute Übertragung nach dem Empfang von drei Duplikat-Bestätigungen durchgeführt.
8 zeigt einen Fall, in dem das zweite und sechste Datenpaket einer Nachricht X aufgrund von Überlast verloren werden und das siebte Datenpaket ein ungeordnetes bzw. falsch eingeordnetes Paket ist. Somit werden WECN Nachrichten in dem dritten und achten Datenpaket gesetzt, da das siebte Datenpaket ein ungeordnetes ist. Die Überlaststeuerung gemäß dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung wird dann im Ansprechen auf den Empfang der ersten WECN ACK durchgeführt. Danach wird eine herkömmliche erneute Übertragung im Ansprechen auf den Empfang von drei Duplikat-ACKs durchgeführt. Jedoch wird die zweite WECN ACK, die von einer Duplikat-WECN-ACK begleitet ist, (aufgrund des ungeordneten Pakets) ignoriert, da sie innerhalb des gleichen Übertragungsfensters empfangen wird. Ungeachtet dessen wird wiederum die herkömmliche erneute Übertragung für das verlorene Paket 2 nach dem Empfang von drei Duplikat-ACKs durchgeführt. Da das ungeordnete Paket nicht identifiziert werden kann, ist dessen erneute Übertragung nicht möglich.
In 9 ist ein weiteres Übertragungsbeispiel gezeigt, bei dem ein Nicht-Überlastverlust 1 (erstes Datenpaket) und ein späterer Überlastverlust 2 (fünftes Datenpaket), gefolgt von einem Nicht-Überlastverlust 3 (sechstes Datenpaket) während der Übertragung einer Nachricht X auftreten.
Der erste Nicht-Überlastverlust 1 initiiert keinerlei Überlaststeuerungsprozedur und führt zu einer herkömmlichen erneuten Übertragung nach dem Empfang von drei Duplikat-ACKs. Aufgrund des unmittelbar folgenden Nicht-Überlastverlustes wird die in dem sechsten Datenpaket im Ansprechen auf den Überlastverlust 2 gesetzte WECN nicht an dem TCP-Ziel B empfangen. Da das sechste Datenpaket aufgrund des Nicht-Überlastverlustes 3 verloren wird, wird in dem siebten Datenpaket keine WECN gesetzt. Somit wird die WECN ACK im Ansprechen auf den Empfang des achten Datenpakets übertragen, um dadurch die Überlaststeuerungsprozedur gemäß dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung zu initiieren. Aufgrund des verlorenen sechsten und Nicht-WECN siebten Datenpakets wird die WECN ACK von zwei Duplikat-WECN ACKs begleitet. Danach werden die Verluste 2 und 3 gemäß dem herkömmlichen Algorithmus zur erneuten Übertragung erneut übertragen.
Schließlich zeigt 10 einen Fall, in dem drei Überlastverluste 1 bis 3 während der Übertragung der Nachricht X auftreten, wobei die entsprechenden WECN verzögert gesetzt werden.
Gemäß der herkömmlichen erneuten Übertragung wird jedes der drei verlorenen Datenpakete 1 bis 3 durch die TCP Quelle A im Ansprechen auf den Empfang der jeweiligen drei Duplikat-ACKs erneut übertragen (erneute Übertragung des verlorenen Pakets 3 ist nicht dargestellt). Bei dem vorliegenden Fall wird die Überlaststeuerungsprozedur gemäß dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung verzögert, bis das erste WECN ACK empfangen wurde. Jedoch wird die darauffolgende WECN ACK innerhalb des gleichen Übertragungsfensters ignoriert.
Das vorstehend beschriebene ECN-basierte Überlaststeuerungsverfahren kann in jedem beliebigen Paketnetzwerk verwendet werden. Gemäß der obigen Beschreibung kann die Überlaststeuerung durchgeführt werden, ohne die herkömmliche Überlaststeuerungsverarbeitung des TCP wesentlich zu ändern.
Obwohl die Erfindung hier in Verbindung mit dem bevorzugten Ausführungsbeispiel gemäß der beigefügten Zeichnung beschrieben wurde, ist es klar, dass die Erfindung nicht auf diese Beispiele beschränkt ist, da sie auf mehrere Arten innerhalb des Schutzbereichs der beigefügten Patentansprüche variieren kann. Wie vorstehend angegeben, ist eine Vorbedingung für ein Benutzerendgerät die, dass es empfangene (d. h. unverfälschte) Dateneinheiten korrekt bestätigt. Daher kann die Idee im Prinzip auf jedes andere Protokoll angewandt werden, welches Bestätigungen sendet. Wie bereits ausgeführt können die Benutzerendgeräte drahtlosen Zugang zu dem Netzwerk haben.
Zusammenfassend betrifft die Erfindung ein Verfahren zur Steuerung bzw. Verringerung der Überlast in einem paketvermittelten Netzwerk, insbesondere einem Mobil- oder Drahtlosnetzwerk, bei dem das Übertragungssteuerungsprotokoll bzw. Transmission Control Protocol (TCP) als das Transportschichtprotokoll verwendet wird. Eine Überlastbenachrichtigungsinformation wird einem Datenpaket hinzugefügt, welches einem aufgrund eines Zwischenspeicherüberlaufs verlorenen Datenpaket folgt. Dies ist ein wirksamer Weg, um die TCP Leistungsfähigkeit in Drahtlos- und Mobilnetzwerken zu verbessern, da Überlaststeuerung vollständig unabhängig von erneuten Übertragungen durchgeführt werden kann. Der vorgeschlagene Mechanismus stellt eine einfache Weise des Einführens von TCP-Überlastverhinderungssteuerungsstrategien in Drahtlos- und Mobilnetzwerken bereit. Zusätzlich sollte die Überlastbenachrichtigungsinformation zumindest nicht später als eine Schwellenanzahl von nachfolgenden Paketen hinzugefügt werden, um dadurch die Geschwindigkeit der Überlaststeuerungsinitiierung und Verlustwiederherstellung aufgrund von Überlast zu beschleunigen bzw. festzulegen.

Claims

Verfahren mit Steuern von Überlast in einem paketvermittelten Netzwerk, welches Verkehrsquellen (A), Verkehrsziele (B) und Netzwerkknoten (AN, N1) aufweist, bei dem das Übertragungssteuerungsprotokoll (TCP) als ein Transportschichtprotokoll verwendet wird; und Weiterleiten von Datenpaketen und entsprechenden Bestätigungen zwischen einer Verkehrsquelle und einem Verkehrsziel, dadurch gekennzeichnet, dass das Steuern aufweist: Hinzufügen, an einem Netzwerkknoten, einer Überlastbenachrichtigungsinformation zu einem Datenpaket, welches einem aufgrund eines Zwischenspeicherüberlaufs verlorenen Datenpaket folgt, um dadurch einen überlastungsbezogenen Datenverlust anzuzeigen, und dass ein Vorgang einer erneuten Übertragung an einer Verkehrsquelle durchgeführt wird, nachdem eine vorbestimmte Anzahl von Duplikat-Bestätigungen mit Überlastbenachrichtigungsinformationen empfangen wurden.
Verfahren nach Anspruch 1, wobei das folgende Datenpaket dem verlorenen Datenpaket direkt folgt.
Verfahren nach Anspruch 1 oder 2, wobei die Überlastbenachrichtigungsinformation in dem Header des folgenden Datenpakets hinzugefügt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Überlastbenachrichtigungsinformation durch jeden der Netzwerkknoten hinzugefügt werden kann, um dadurch einen überlastbezogenen Datenverlust anzuzeigen.
Verfahren nach einem der vorangehenden Ansprüche, wobei es erlaubt ist, die Überlastbenachrichtigungsinformation durch aufeinanderfolgende Netzwerkknoten in nachfolgenden Datenpaketen hinzuzufügen, die zu dem gleichen Überlastfenster gehören.
Verfahren nach einem der vorangehenden Ansprüche, wobei es jedem Netzwerkknoten erlaubt ist, die Überlastinformation lediglich einmal hinzuzufügen.
Verfahren nach einem der vorangehenden Ansprüche, wobei das Verkehrsziel einen Überlastbenachrichtigungs-Flag in dem Header eines Bestätigungspakets im Ansprechen auf ein empfangenes Datenpaket mit einer hinzugefügten Überlastbenachrichtigungsinformation setzt.
Verfahren nach einem der vorangehenden Ansprüche, wobei die hinzugefügte Überlastbenachrichtigungsinformation Bit Nr. 5 in dem Diensttyp-Oktett gemäß dem Internet-Protokoll Version 4 (IPv4 TOS Oktett) ist.
Verfahren nach Anspruch 7, wobei der Überlastbenachrichtigungs-Flag Bit Nr. 8 in dem Übertragungssteuerungsprotokoll-(TCP)Header des Bestätigungspakets ist.
Verfahren nach einem der vorangehenden Ansprüche, wobei eine Überlastverarbeitung bei der Verkehrsquelle nur wiederholt wird, nachdem die ausstehenden Datenpakete, die vor dem Empfang des ersten Überlastbenachrichtigungs-Flags übertragen wurden, alle bestätigt wurden.
Verfahren nach einem der vorangehenden Ansprüche, wobei ein Überlastfenster im Ansprechen auf den Empfang des Überlastbenachrichtigungs-Flags verringert wird.
Verfahren nach Anspruch 11, wobei das Überlastfenster nur verringert wird, wenn der Überlastbenachrichtigungs-Flag empfangen wurde vor der Ankunft einer vorbestimmten Anzahl von Duplikat-Bestätigungen, die in Bezug zu dem verlorenen Datenpaket stehen.
Paketvermitteltes Telekommunikationsnetzwerk, mit: Netzwerkknoten (AN1, AN2, N1), die durch Übertragungsleitungen (TL1, TL2) miteinander verbunden sind; und Benutzerendgeräten, die an die Netzwerkknoten angeschlossen sind, wobei die Benutzerendgeräte als Verkehrsquellen (A) arbeiten, die Datenpakete übertragen, und als Verkehrsziele (B) arbeiten, die Datenpakete empfangen, wobei das Übertragungssteuerungsprotokoll (TCP) in dem Netzwerk als ein Transportschichtprotokoll verwendet wird; dadurch gekennzeichnet, dass das Netzwerk weiter aufweist: Erfassungseinrichtungen zur Erfassung eines Verlustes eines Datenpakets aufgrund eines Zwischenspeicherüberlaufs in einem der Netzwerkknoten; und eine Steuerungseinrichtung (C), an dem Netzwerknoten, zum Hinzufügen einer Überlastbenachrichtigungsinformation zu einem Datenpaket, welches einem aufgrund des Zwischenspeicherüberlaufs verlorenen Datenpaket folgt, im Ansprechen auf ein Erfassungsergebnis der Erfassungseinrichtung, um dadurch einen überlastungsbezogenen Datenverlust anzuzeigen, und dass die als Verkehrsquellen (A) arbeitenden Benutzerendgeräte angepasst sind, um eine erneute Übertragung nur durchzuführen, nachdem eine vorbestimmte Anzahl von Duplikat-Bestätigungen mit Überlastbenachrichtigungsinformationen empfangen wurden.
Telekommunikationsnetzwerk nach Anspruch 13, wobei die Erfassungseinrichtungen (10) in zumindest einem der Netzwerkknoten bereitgestellt sind.
Telekommunikationsnetzwerk nach Anspruch 13 oder 14, wobei die Steuerungseinrichtung (C) angepasst ist, um die Überlastbenachrichtigungsinformation lediglich einmal in einem Übertragungsfenster hinzuzufügen.
Telekommunikationsnetzwerk gemäß einem der Ansprüche 13 bis 15, wobei die als Verkehrsziele (B) arbeitenden Benutzerendgeräte angepasst sind, um einen Überlastbenachrichtigungs-Flag in dem Header eines Bestätigungspakets im Ansprechen auf den Empfang eines Datenpakets mit der hinzugefügten Überlastbenachrichtigungsinformation zu setzen.
Telekommunikationsnetzwerk nach einem der Ansprüche 13 bis 16, wobei die als Verkehrsquellen (A) arbeitenden Benutzerendgeräte angepasst sind, um Überlaststeuerung im Ansprechen auf den Empfang des Überlastbenachrichtigungs-Flags durchzuführen.
Telekommunikationsnetzwerk nach Anspruch 17, wobei die Überlaststeuerung das Verringern eines Überlastfensters umfasst.
Telekommunikationsnetzwerk gemäß einem der Ansprüche 13 bis 18, wobei die als Verkehrsquellen (A) arbeitenden Benutzerendgeräte angepasst sind, um auf einen darauffolgenden Überlastbenachrichtigungs-Flag nur zu reagieren, nachdem ausstehende Datenpakete, die übertragen wurden, bevor in eine Verlustwiederherstellungsphase auf den Empfang des ersten Überlastbenachrichtigungs-Flags eingetreten wurde, alle bestätigt wurden.
Telekommunikationsnetzwerk nach einem der Ansprüche 13 bis 19, wobei das paketvermittelte Netzwerk ein Mobil- oder Drahtlosnetzwerk ist.