-
Die
vorliegende Erfindung betrifft ein Verfahren zum Steuern einer Kommunikation
zwischen einem Sender und einem Empfänger, die gemäß einem
so genannten Übertragungssteuerprotokoll
oder TCP (Transmission Control Protocol) arbeiten.
-
Eine
Dateneinheit-orientierte Kommunikation ist altbekannt. In einer
Dateneinheit-orientierten Kommunikation wird eine Menge von Daten
in eine oder mehrere Dateneinheiten geteilt, wobei der Aufbau der
Dateneinheiten durch ein Kommunikationsprotokoll definiert ist,
welches der Sender und der Empfänger
bei der Kommunikation befolgen. Das Protokoll definiert auch, wie
eine spezifische Information zu codieren ist und wie der Sender
und/oder der Empfänger
auf eine spezifische Information reagieren können. Eine Dateneinheit-orientierte
Kommunikation ist auch als eine Paketaustauschkommunikation bekannt.
Es sei darauf hingewiesen, dass die Dateneinheiten, die bei einer
Verbindung mit spezifischen Protokollen verwendet werden, unterschiedliche
Namen wie etwa Pakete, Rahmen, Segmente, etc. aufweisen. Zum Zweck
der vorliegenden Beschreibung bezieht sich der Ausdruck "Dateneinheit" allgemein auf jedwede
Typen von Einheiten, die in einer Dateneinheitorientierten Kommunikation
verwendet werden.
-
Ein
Merkmal, das viele Kommunikationsprotokolle zur Erhöhung einer
Zuverlässigkeit
benutzen, besteht darin, empfangene Daten zu bestätigen. Spezifischer
sendet ein Sender oder ein Sende-Peer des gegebenen Protokolls Dateneinheiten
aus, und der Empfänger
oder Empfangs-Peer des gegebenen Protokolls bestätigt den korrekten Empfang
durch ein Zurückgeben
geeigneter Bestätigungs-Dateneinheiten.
Auf diese Weise wird der Sende-Peer informiert, dass die Dateneinheiten,
die gesendet wurden, auch korrekt empfangen wurden, und er kann
dementsprechend die Flusssteuerung der weiteren, zu übertragenden
Dateneinheiten steuern. Ein Beispiel eines Protokolls, das Bestätigungs-Dateneinheiten
verwendet, ist das sogenannte Übertragungssteuerungsprotokoll
(TCP, Transmission Control Protocol), das ein Teil der TCP/IP-Protokoll-Suite ist.
-
Das Übertragungssteuerungsprotokoll
und die TCP-IP-Protokoll-Suite
sind z.B. in "TCP/IP
Illustrated, Volume 1 – The
Protocols" von W.
Richard Stevens, Addison-Wesley, 1994 gut beschrieben.
-
Um
der Tatsache Rechnung zu tragen, dass Dateneinheiten oder Bestätigungs-Dateneinheiten verloren
gehen können,
ist ein Zeitablauf-Merkmal in vielen Protokollen bereitgestellt.
Ein derartiges Zeitablauf-Merkmal bedeutet, dass eine Zeitablauf-Periode
gesetzt wird, wenn Daten gesendet werden, und wenn die spezifischen
Daten nicht zu der Zeit bestätigt
worden sind, zu der die Zeitablauf-Periode abläuft, wird eine Zeitablauf-Antwortprozedur
gestartet. In dem TCP besteht die Zeitablauf-Antwort aus einem erneuten Übertragen
der Daten, die nicht bestätigt
wurden, und einem Rücksetzen
eines oder mehrerer Verlust-Steuerungsparameter.
-
Als
ein Beispiel verwendet TCP eine Fenster-basierte Flusssteuerung.
TCP ist ein Byte-orientiertes Protokoll, das eine gegebene Anzahl
von zu übertragenden
Bytes in sogenannte Segmente teilt, und eine Aufzeichnung der gesendeten
Daten wird hinsichtlich von Bytes gehalten, d.h. bis zu demjenigen
Byte, bis zu dem die Daten gesendet wurden, und eine Aufzeichnung
der empfangenen Daten wird auch hinsichtlich von Bytes gehalten,
d.h. bis zu demjenigen Byte, bis zu dem die Daten empfangen wurden.
Der einfachste Weg zum Steuern des Flusses von Segmenten in Verbindung
mit Bestätigungsnachrichten
wäre es,
ein Segment zu übertragen und
das nächste
Segment nicht zu übertragen,
bis das zuletzt gesendete Segment bestätigt wurde. Ein derartiges Verfahren
einer Flusssteuerung würde
jedoch nicht sehr effizient sein. wie bereits erwähnt, verwendet TCP
eine Fenster-basierte Flusssteuerung, die auch als eine Flusssteuerung
gemäß gleitenden
Fenstern bezeichnet wird. Dieses Konzept ist in dem oben erwähnten Buch
von W. Richard Stevens ebenfalls gut beschrieben.
-
2 veranschaulicht
das Konzept von gleitenden Fenstern. Wie ersehen werden kann, ist
bei dem Beispiel eine Menge von 8.192 Bytes zu übertragen, wobei diese Menge
in 8 Segmente geteilt ist. Das Senden der Segmente wird in Übereinstimmung mit
dem Sendefenster gesteuert, wobei das linke Ende des Sendefensters
durch die Daten in dem Segment definiert ist, die gesendet und bereits
bestätigt
worden sind. In dem Beispiel der 2 sind dies die
Daten bis zu 2.048 Bytes, d.h. die Segmente 1 und 2. Die Einstellung
der Länge
des Sendefensters und dadurch das rechte Endes des Fensters ist
eine Angelegenheit der Steuerungsprozedur, die hier im Detail nicht
erläutert
werden muss.
-
Das
Sendefenster definiert die Menge von Daten, die ihre entsprechende
Bestätigung
ausstehend aufweisen können.
In dem Beispiel der 2 sind die Daten bis zu 4 096
Bytes, d.h. Segmente 3 und 4 gesendet worden und noch nicht bestätigt worden,
und der Unterschied zwischen derartig gesendeten und nicht bestätigten Segmenten
von dem rechten Ende des Sendefensters definiert das verwendbare
Fenster, d.h. die Daten, die noch gesendet werden können, ohne
irgendwelche weiteren Bestätigungen
empfangen zu haben. Als Konsequenz können in dem Beispiel der 2 die
Segmente 5 und 6 noch gesendet werden, aber die Segmente 7 und 8 können nur
gesendet werden, wenn sich das Fenster nach rechts bewegt, was dann
passiert, wenn weitere Segmente bestätigt derart werden, dass sich
das linke Ende nach rechts bewegt und/oder wenn die Länge des
Sendefensters zunimmt.
-
Überdies
sei darauf hingewiesen, dass das TCP eine kumulative Bestätigung bereitstellt,
d.h. es existiert keine Eins-zu-Eins-Entsprechung zwischen Segmenten
und Bestätigungen
für Segmente,
weil eine Bestätigungsnachricht
eine Mehrzahl von Segmenten abdecken kann. Als ein Beispiel könnte der Empfangs-Peer
für die
Datenmenge, die in 2 gezeigt ist, eine Bestätigung von
Bytes bis zu 4.096 derart senden, dass diese Bestätigungsnachricht
beide Segmente 3 und 4 abdecken würde.
-
Das
Sendefenster, das von dem Sende-Peer verwendet wird, wird in typischer
weise durch das sogenannte angebotene oder angekündigte Fenster bestimmt werden,
welches eine Datenlänge
ist, die dem Sende-Peer von dem Empfangs-Peer bereitgestellt wird.
Auf diese Weise kann der Empfangs-Peer beeinflussen, wie viele Segmente
der Sende-Peer jeweils übertragen
wird, und typischer Weise wird das angekündigte Fenster auf der Grundlage
des Empfangspuffers des Empfangs-Peers
berechnet werden. Auch ist das angekündigte Fenster ein dynamischer
Parameter, der mit jeder Bestätigung
geändert werden
kann, die von dem Empfangs-Peer gesendet wird.
-
Über das
angekündigte
Fenster hinaus ist es auch üblich,
das sogenannte Besetzt-Fenster zu definieren, das in Verbindung
mit mehreren Besetzt-Steuerungsroutinen wie etwa einem langsamen Start,
einer Besetzt-Vermeidung, einer schnellen Neusendung und einer schnellen
Wiedergewinnung verwendet wird, siehe wiederum z.B. das oben erwähnte Buch
von W. Richard Stevens. Das Besetzt-Fenster ist eine Aufzeichnung,
die der Sende-Peer hält,
und ist dafür
vorgesehen, einen Besetzt-Zustand entlang der Verbindung zwischen
dem Sende-Peer und
dem Empfangs-Peer zu berücksichtigen.
Als ein typischer Steuerungsmechanismus wird das Sende-Fenster als
das kleinere von dem angekündigten
Fenster und dem Besetzt-Fenster
definiert werden.
-
Während das
angekündigte
Fenster eine Flusssteuerung ist, die von dem Empfangs-Peer auferlegt
ist, ist das Besetzt-Fenster
eine Flusssteuerung, die von dem Sende-Peer auferlegt ist, als ein Mechanismus
zum Berücksichtigen
des Besetzt-Zustands.
-
In
einem allgemeinen Sinn ist das Besetzt-Fenster ein Beispiel eines
adaptiven Flusssteuerungsparameters. In dem TCP besteht die oben
erwähnte
Zeitablauf-Antwort aus einem Rücksetzen des
Besetzt-Fensters in ein Segment und dann aus einem darauffolgenden
ausschließlichen Übertragen eines
Segments, nämlich
einem erneuten Übertragen
des Segments, das nicht bestätigt
wurde und dadurch den Zeitablauf herbeiführte. Der Sende-Peer wartet
dann auf die Bestätigung
des erneut übertragenen
Segments.
-
Ein
anderes Beispiel eines adaptiven Flusssteuerungsparameters ist die
Zeitablauf-Periode selbst, die z.B. in dem TCP als RTO (Retransmission Time
Out = Zeitablauf für
erneute Sendung) bezeichnet wird. Die RTO wird als Antwort auf einen
Zeitablauf verdoppelt.
-
Wie
bereits erwähnt,
ist das Zeitablauf-Merkmal ein Datenverlust-Erfassungsmechanismus.
Andere Datenverlust-Erfassungsmechanismen
existieren. Ein anderes Beispiel ist die erneute Sendung von Dateneinheiten
in dem TCP als Antwort auf den Empfang doppelter Bestätigungen.
Dieser Mechanismus wird kurz im folgenden erläutert werden.
-
Wie
bereits erwähnt
(siehe z.B. 2), wird eine zu übertragende
Datenmenge in eine Sequenz geteilt. Herkömmliche Implementierungen des
TCP sind derart angeordnet, dass dann, wenn der Empfangs-Peer eine
bestimmte Datenmenge bis zu einem gegebenen Byte empfangen und bestätigt hat (eine
bestimmte Anzahl aufeinanderfolgender Segmente), der die Daten erwartet,
die in der Sequenz als nächstes
kommen. Beispielsweise wird, wenn Segmente bis zu dem Segment 4
hin empfangen worden sind, dann das Segment 4 bestätigt und
der Empfangs-Peer erwartet, das Segment 5 zu empfangen. Wenn er
dann eine weitere Dateneinheit empfängt, die unterschiedlich von
dem Segment 5 ist (z.B. die Segmente 6, 7 und 8) setzt er die Bestätigung für das Segment
4 für jede
Dateneinheit fort, die er empfängt.
Folglich empfängt
der Sende-Peer doppelte Bestätigungen. Üblicherweise
ist das TCP auf eine derartige Weise implementiert, dass der Sende-Peer die Anzahl von
doppelten Bestätigungen zählen wird,
und wenn ein bestimmter Schwellenwert erreicht ist (z.B. 3), dann
wird die Dateneinheit, die in der Sequenz als nächstes auf die Dateneinheit
folgt, für
welche doppelte Bestätigungen
empfangen wurden, erneut übertragen.
-
Die
WO 98/37670 beschreibt ein Verfahren zum Verbessern eines Transportprotokoll-Betriebsverhaltens
in Netzen, welche verlustbehaftete Verbindungen aufweisen. Herkömmliche
Sender in einer Kommunikation identifizieren, das ein Paket aufgrund
eines Besetzt-Zustands verlorengegangen ist, entweder durch die
Ankunft doppelter Bestätigungen oder
durch die Abwesenheit einer Bestätigung
innerhalb eines Zeitablauf-Intervalls. In Reaktion auf einen Besetzt-Zustand werden geeignete
Steuerungsschemata in dem Sender wie etwa ein langsamer Start, eine
schnelle Wiedergewinnung und eine schnelle erneute Übertragung
ausgeführt.
Die WO 98/37670 zeigt ferner auf, dass dann, wenn übertragene
Pakete aus anderen Gründen
als einem Besetzt-Zustand nicht empfangen werden können, Besetzt-Zustand-Kombinationsmaßnahmen
schädlich
sein können.
-
Die
WO 98/37670 schlägt
eine Verwendung selektiver Bestätigungen
vor, die anzeigen, welche Pakete erfolgreich empfangen wurden, und
welche mit Nicht- Besetzt-Zustand-Bitfehlern empfangen wurden, während doppelte
Bestätigungen
unterdrückt
werden, um den Aufruf eines Besetzt-Mechanismus zu verhindern.
-
Der
Artikel "A comparison
of Mechanisms for Improving TCP Performance over Wireless Links" von H. Balakrishnan
et al, IEEE/ACM Transactions on Networking, Bd. 5, Nr. 6, 12/1997,
XP-000734405 beschreibt ein ähnliches
Schema wie die WO 98/37670. Zusätzlich
zu selektiven Bestätigungen
erwähnt
dieser Artikel auch eine explizite Verlustbenachrichtigung (ELN).
-
Es
ist die Aufgabe der vorliegenden Erfindung, die Kommunikation zwischen
einem TCP-Sender und einem TCP-Empfänger zu
verbessern.
-
Diese
Aufgabe wird durch das beanspruchte Verfahren gelöst.
-
In Übereinstimmung
mit der vorliegenden Erfindung wird ein Sender in einer Kommunikation
eine Antwortprozedur als Antwort auf ein Ereignis ausführen, das
einen Datenverlustmechanismus triggert, wobei die Antwortprozedur
zumindest zwei unterschiedliche Modi zum Anpassen der adaptiven
Parameter umfasst, die in einer Flusssteuerung verwendet werden.
Auf diese Weise sind das Verfahren und die Vorrichtung der vorliegenden
Erfindung in hohem Maße
in ihrer Verwaltung zum Triggern von Ereignissen flexibel und können insbesondere
auf eine derartige weise implementiert werden, dass die Antwortprozedur
in Abhängigkeit
verschiedener potentieller Ursachen des Trigger-Ereignisses derart
gewählt werden
können,
dass die korrekten Antwortmaßnahmen
auf eine gegebene Situation aufgerufen werden können, und dadurch Maßnahmen
vermieden werden können,
die die Situation tatsächlich
verschlimmern können,
die auftreten können,
nachdem ein Datenverlust-Erfassungsmechanismus
getriggert wurde.
-
Der
Datenverlust-Erfassungsmechanismus ist ein Mechanismus, der in der
Lage ist, einen Datenverlust zu erfassen.
-
Beispiele
sind ein Zeitablauf-Mechanismus oder ein doppelter Bestätigungs-Mechanismus.
-
Gemäß den gegenwärtig beschriebenen
Beispielen umfasst eine Antwortprozedur zumindest zwei unterschiedliche
Modi zum Anpassen der adaptiven Parameter, die in der Flusssteuerung
verwendet werden. Als ein Beispiel, das eine bevorzugte Ausführungsform
bildet, sind zwei Modi vorhanden, die jeweils unterschiedlichen
Ursachen eines Zeitablaufs oder einer vorbestimmten Anzahl von doppelten Bestätigungen
(z.B. die oben erwähnten
3) zugeordnet werden. Spezifischer ist ein erster Modus dem Verlust
einer Dateneinheit zugeordnet, und der zweite Modus ist einer übermäßigen Verzögerung entlang der
Verbindung zugeordnet. Aufgrund der Verwendung zweier unterschiedlicher
Modi ist es möglich, die
Parameter anzupassen, wie es für
die Ursache des Zeitablaufs oder doppelter Bestätigungen geeignet ist. Dementsprechend
wird die Flusssteuerungsprozedur einen oder mehrere Evaluations- und Beurteilungsschritte
enthalten, in welchen das Trigger-Ereignis qualifiziert wird, z.B. eine
Kategorisierung wird dahingehend durchgeführt, was das Ereignis herbeiführt. Dann
kann in Abhängigkeit
von dem Ergebnis dieser Charakterisierung eine geeignete Antwortprozedur
ermöglicht
werden. In dem Kontext des obigen Beispiels kann, wenn bestimmt
wird, dass der Zeitablauf oder die doppelten Bestätigungen
durch den Verlust einer Dateneinheit herbeigeführt sind, dann die bekannte
Antwortprozedur auf dem Verlust von Dateneinheiten durchlaufen werden,
wie es z.B. aus dem herkömmlichen
TCP bekannt ist, das annimmt, das jedweder Zeitablauf oder der Empfang
mehrerer doppelter Bestätigungen
durch den Verlust einer Dateneinheit herbeigeführt ist. Es ist jedoch ein
zweiter Modus vorhanden, und wenn bestimmt wird, dass der Zeitablauf
und doppelte Bestätigungen
durch eine übermäßige Verzögerung entlang
der Verbindung herbeigeführt
sind, wird dann eine Antwortprozedur auf eine übermäßige Verzögerung durchlaufen, die typischer
Weise unterschiedlich von der Antwortprozedur auf den Verlust einer
Dateneinheit sein wird.
-
Spezifischer,
wie auch detaillierter im folgenden erläutert werden wird, wird die
Beurteilung, dass Dateneinheiten verlorengegangen sind, durch ein Verringern
der Übertragungsrate
beantwortet werden, um dadurch einen weiteren Besetzt-Zustand zu vermeiden.
Andererseits wären,
wenn eine übermäßige Verzögerung entlang
der Verbindung vorhanden ist, dann die Maßnahmen, die als Antwort auf
einen angenommenen Verlust von Dateneinheiten unternommen werden,
nicht hilfreich, vielmehr können
sie tatsächlich
das Problem verschlimmern, das die übermäßige Verzögerung herbeiführt. Folglich
wird die Antwortprozedur auf eine übermäßige Verzögerung typischer Weise unterschiedlich
sein, und z.B. ein Aufrechterhalten der Übertragungsrate auf dem vorherigen
Pegel, aber andererseits ein Erhöhen
der Zeitablaufperiode umfassen, derart, dass weitere unnötige erneute Übertragungen
vermieden werden.
-
Natürlich können Systeme
derart implementiert werden, dass sie eine beliebige Anzahl von
Modi oder Antwortprozeduren auf verschiedene Fälle von Trigger-Ereignissen
bereitstellen. Die Anzahl der Modi und der spezifischen Maßnahmen,
die in jedem Modus unternommen werden, hängen natürlich von der spezifischen
Situation ab, d.h. dem gewählten Protokoll,
der gegebenen Kommunikationssituation, etc.
-
Ein
wichtiger Aspekt der oben beschriebenen Beispiele besteht darin,
dass, obwohl der Datenverlustmechanismus in der Lage ist, einen
Datenverlust zu erfassen, die Reaktion auf das Trigger-Ereignis
des Datenverlust-Erfassungsmechanismus
nicht annimmt, dass ein Datenverlust notwendigerweise aufgetreten
ist, vielmehr ist eine flexible Antwort möglich, die verschiedene Ursachen
des Trigger-Ereignisses
berücksichtigen
kann.
-
Aspekte
und Vorteile der vorliegenden Erfindung werden aus der folgenden
detaillierten Beschreibung besser verstanden werden, die Bezug nimmt
auf die Figuren.
-
In
den Figuren zeigen:
-
1 eine
Steuerungsprozedur;
-
2 ein
Erläutern
des Diagramms zum Beschreiben des Konzeptes einer Fenster-basierten Flusssteuerung;
-
3 einen
Graphen zum Erläutern
der Vorteile der beschriebenen Beispiele; und
-
4 ein
Erläutern
des Diagramms zum Veranschaulichen einer Situation, in welcher eine übermäßige Verzögerung in
einer Verbindung zwischen zwei Host-Computern herbeigeführt werden kann.
-
Obwohl
die folgende Beschreibung allgemein auf irgendein Kommunikationsprotokoll
gerichtet sein wird, das eine Datenbestätigung verwendet und auch ein
Zeitablauf-Merkmal bereitstellt, werden Beispiele häufig gegeben
werden, die das Übertragungssteuerungsprotokoll
TCP betreffen, das aus der TCP/IP-Protokoll-Suite bekannt ist. Die
vorliegende Erfindung betrifft ein auf einen TCP-Sender und einen
TCP-Empfänger angewendetes
Verfahren. Um jedwede unnötige
Wiederholung zu vermeiden, ist die Offenbarung in der Einleitung
dieser Anmeldung in die Erfindungsoffenbarung eingeschlossen.
-
1 zeigt
ein Teil-Flussdiagramm eines Beispiels eines Übertragungssteuerverfahrens.
Wie ersehen werden kann, zeigt ein Schritt S1 an, dass in eine Antwortprozedur
eingetreten wird. 1 zeigt nicht die Flusssteuerungsprozedur,
die zu diesem Punkt führt,
da sie nicht von Wichtigkeit ist.
-
Beispielsweise
kann sie die Fenster-basierte Flusssteuerungsprozedur sein, die
in Verbindung mit 2 erläutert ist und z.B. aus dem
TCP altbekannt ist. Es ist nur wichtig, dass ein Datenbestätigungs- und
ein Datenverlusterfassungs-Merkmal vorhanden ist und dass ein Sende-Peer
des Protokolls die Fähigkeit
eines Erfassens eines möglichen
oder potentiellen Datenverlusts aufweist und eine entsprechende
Antwortprozedur durchführen
kann. Wie bereits erwähnt,
kann das Datenverlust-Erfassungsmerkmal z.B. ein Zeitablauf-Merkmal
oder ein Erfassungsmerkmal für
eine doppelte Bestätigung
sein.
-
In
dem Beispiel der 1 werden, nachdem in die Antwortprozedur
eingetreten ist, selektive adaptive Parameter, die für die Flusssteuerung
verwendet werden, gespeichert und dann auf vorbestimmte Werte in
einem Schritt S2 zurückgesetzt.
Als ein Beispiel sind die Zeitablaufperiode und/oder das umgeschriebene
Besetzt-Fenster
adaptive Flusssteuerungsparameter. In dem herkömmlichen TCP wird das Besetzt-Fenster
typischer Weise auf einen Wert eines Segments zurückgesetzt
und gleichzeitig wird die RTO verdoppelt. Es sei darauf hingewiesen,
dass nicht sämtliche
adaptiven Parameter, die in der Flusssteuerungsprozedur verwendet
werden, tatsächlich
geändert
werden müssen,
vielmehr nur eine ausgewählte
Anzahl.
-
Es
sollte auch klar sein, dass das vorliegende Beispiel natürlich nicht
auf eine Fenster-basierte Flusssteuerung und die zugeordneten adaptiven
Parameter beschränkt
ist, sondern vielmehr ist das Beispiel auf jedes Flusssteuerungsprinzip
und die zugeordneten adaptiven Parameter anwendbar.
-
Zurückkehrend
auf 1 wird die Dateneinheit, die das Ereignis triggerte
(z.B. einen Zeitablauf herbeiführte)
erneut in einem Schritt S3 übertragen. Mit
anderen Worten wird, wenn bei dem Beispiel eines Zeitablaufs geblieben wird,
die Dateneinheit, für welche
eine Bestätigung
empfangen wurde, während der
Zeitablaufperiode erneut übertragen.
Dann wird zu einem späteren
Zeitpunkt in einem Schritt S4 bestimmt, ob eine Bestätigung,
die der erneut übertragenen
Dateneinheit zugeordnet ist, empfangen worden ist. Dies kann eine
kumulative Bestätigung
oder auch eine einzelne Bestätigung
sein. Es sei darauf hingewiesen, dass die gestrichelten Linien in 1 anzeigen,
dass andere Schritte dazwischengesetzt werden können, aber diese sind für die vorliegende Beschreibung
von keiner Bedeutung. Dann bestimmt gemäß dem Beispiel der 1 ein
Schritt S5, ob die Bestätigung,
die der Dateneinheit zugeordnet ist, die erneut übertragen wurde, tatsächlich die
ursprüngliche Übertragung
der Dateneinheit oder die erneute Übertragung bestätigt. Es
sei darauf hingewiesen, dass die "ursprüngliche Übertragung" bereits eine erneute Übertragung
sein kann, derart, dass die "erneute Übertragung" die erneute Übertragung
einer erneuten Übertragung
sein kann, etc. Es sind verschiedene Möglichkeiten eines Implementierens
des Schritts S5 vorhanden, wie weiter erläutert werden wird.
-
Wenn
der Schritt S5 bestimmt, dass die Bestätigungsnachricht tatsächlich die
erneute Übertragung
der Dateneinheit bestätigt,
dann geht die Prozedur zu einem Schritt S7, in welchem eine Dateneinheit-Verlustantwortprozedur
abläuft,
weil das negative Ergebnis des Entscheidungsschritts S5 anzeigt, dass
die ursprüngliche Übertragung
der Dateneinheit verloren ging. In dem Beispiel von TCP wird der Schritt
S7 aus herkömmlichen
Maßnahmen
gegenüber
einem Dateneinheitverlust bestehen.
-
Im
Gegensatz dazu geht, wenn der Entscheidungsschritt S5 bejahend beantwortet
wird, dann die Prozedur zu einem Schritt S6, in welchem eine Antwortprozedur
läuft,
die eine übermäßige Verzögerung beantwortet.
Mit anderen Worten müssen,
weil der Schritt S5 anzeigt, dass die ursprüngliche Übertragung der Dateneinheit
tatsächlich
nicht verloren ging, sondern nur übermäßig verzögert wurde, entsprechende Maßnahmen
unternommen werden. Beispielsweise kann dies, wenn das TCP als ein
Protokollbeispiel genommen wird, aus einem Zurücksetzen des Besetzt-Fensters
auf den Wert bestehen, der im Schritt S2 gespeichert ist, und andererseits
einem Anpassen der Zeitablauf-Periode an die Verzögerung.
Mit anderen Worten können
die Rundlaufzeit RTT (=Round Trip Time), die der ursprünglichen Übertragung
zugeordnet ist, und die Bestätigung
der ursprünglichen Übertragung
als eine Grundlage zum Anpassen der Zeitablauf-Periode verwendet
werden. Dadurch können
weiter unnötige
erneute Übertragungen
und Zeitabläufe
oder doppelte Bestätigungen aufgrund
einer übermäßigen Verzögerung vermieden werden.
-
Das
Besetzt-Fenster wird nicht einfach auf den vorherigen Wert zurückgesetzt,
sondern vielmehr auf den Wert gesetzt, den es angenommen hätte, wenn
die Antwortprozedur nicht stattgefunden hätte, d.h. der Datenverlust-Erfassungsmechanismus
nicht ausgelöst
worden wäre.
-
Wie
ersehen werden kann, zeigt das Beispiel der 1 einen
ersten Modus, der aus den Schritten S2, S3, S4, S5 und S7 besteht,
wie auch einem zweiten Modus, der aus den Schritten S2, S3, S4,
S5 und S6 besteht.
-
Nun
wird auf 3 Bezug genommen werden, die
ein Beispiel einer Flusssteuerungsprozedur zeigt, die in Verbindung
mit dem herkömmlichen
TCP ausgeführt
wird. Der Graph zeigt die Menge von Daten in transportierten Bytes über der
Zeit. Wie ersehen werden kann, werden die ersten beiden Segmente
zu einer Zeit t=4s gesendet. Dann werden aufgrund der Wechselwirkung
der empfangenen Bestätigungsdateneinheiten
und der Einstellung adaptiver Parameter, die nicht gezeigt sind,
Segmente gesendet.
-
Zum
Zwecke einer Erläuterung
sei darauf hingewiesen, dass die diamantförmigen Symbole sich auf Segmente
beziehen und die quadratischen Symbole auf Bestätigungsdaten-Einheiten. Die
Diamantsymbole zeigen das erste Byte des Segments an, wohingegen
die Quadrate das niedrigste nicht-bestätigte Byte anzeigen. Die Bestätigungsdateneinheiten,
die in einem bestimmten Segmentpegel angezeigt sind, bestätigen immer
die gesendeten Segmente bis zu dem Segmentpegel. Mit anderen Worten
bestätigt
die Bestätigung
bei einem Segmentpegel 6.400 Bytes (t=12s) die Segmente unterhalb 6.400
Byte, aber nicht einschließend
das Byte 6.400. Ganz im Gegensatz dazu, wie explizit in dem Graphen
angezeigt, ist das Segment bei 6.400 Byte (t=10s) eine Dateneinheit
oder ein Paket, das einen Zeitablauf herbeiführt. Als Folge wird eine erneute Übertragung
der Dateneinheit bei dem 6.400 Byte-Pegel durchgeführt.
-
Wenn
nun angenommen wird, dass der Zeitablauf, der in 3 gezeigt
ist, durch eine übermäßige Verzögerung herbeigeführt wurde,
nicht dadurch, dass das gezeigte erste Paket verloren geht, dann weist
die erneute Übertragung
die folgenden negativen Konsequenzen auf.
-
Einerseits
führt sie
zu einem verringerten Durchsatz-Betriebsverhalten,
da die gleichen Daten die Verbindung oder den Verbindungspfad zweifach durchlaufen
müssen,
was Bandbreiten verschwendet, die andernfalls für Nutzdaten hätten verwendet werden
können.
Diese negative Konsequenz wird in jedwedem Protokoll auftreten,
das auf einem Zeitablauf fälschlicherweise
durch ein erneutes Übertragen der
Dateneinheit antwortet.
-
Falls,
wie in 3 gezeigt, das TCP-Protokoll verwendet wird, dann
ist die Reaktion des Sende-Peers auf einen derartigen Zeitablauf,
der nicht von einem Dateneinheitverlust herbeigeführt wird, besonders
nachteilig: Der Sender wird sämtliche ausstehende
Pakete erneut übertragen
und darüber hinaus
eine Übertragungsrate
verringern. Dies ist explizit in 3 gezeigt.
-
Es
sei darauf hingewiesen, dass der oben beschriebene Zeitablauf, der
durch einen Dateneinheitverlust herbeigeführt wird, auch als ein unechter Zeitablauf
bezeichnet wird.
-
Wie
es auch in 3 gezeigt wird, interpretiert
in dem herkömmlichen
TCP der Sender sämtliche
Bestätigungen
falsch, die erneut übertragenen Dateneinheiten
zugeordnet sind, als Bestätigen
der erneuten Übertragung,
auch wenn diese Bestätigungen
(ACKs) tatsächlich
verzögerte
Bestätigungen
der ursprünglichen Übertragungen
sind.
-
Was 3 nicht
zeigt, ist, dass die doppelten Dateneinheiten, die von dem Sende-Peer
gesendet werden, zusätzlich
doppelte Bestätigungen
in dem Empfangs-Peer triggern werden, was noch zu einer weiteren
Verringerung in der Übertragungsrate
in dem herkömmlichen
TCP-Sender führt,
das Besetzt-Fenster wird nämlich
auf eine Hälfte
seines früheren
Werts gesetzt.
-
Das
Auftreten einer übermäßigen Verzögerung,
die über
das hinausgeht, was die TCP-Zeitablauf-Periode berücksichtigen
kann, kann insbesondere bei drahtlosen Netzen oder derartigen Protokollverbindungen
auftreten, von welchem zumindest ein Teil über eine drahtlose Verbindung
läuft.
Die Erfinder der vorliegenden Anmeldung erkannten, dass unechte
Zeitabläufe
oft genug in derartigen Netzen vorkommen können, so dass eine Erstverschlechterung
des Betriebsverhaltens resultiert. Beispiele hierfür werden
nun kurz erwähnt
werden.
-
4 zeigt
eine Situation, wo zwei Host-Computer als Peers des TCP wirken (angezeigt durch
die langen Pfeile von Host zu Host an der Unterseite und der Oberseite
der Figur). Die unteren Protokollschichten umfassen eine Funkverbindung über ein
drahtloses Zugriffsnetz auf das Internet. Die Verbindung zwischen
dem Internet und dem Host auf der rechten Seite ist nicht gezeigt.
Ein Beispiel eines Protokolls für
die Funkverbindung ist das sogenannte Funkverbindungs-Steuerungsprotokoll
RLC. Wie in 4 angezeigt, weisen sowohl das
Transportschichtprotokoll (z.B. TCP) als auch das Verbindungsschichtprotokoll
(z.B. RLC) eine ARQ (Automatische Anforderung für erneute Übertragung)-Funktion auf. Dies
bedeutet, dass diese Protokolle sowohl Zeitablaufals auch erneute Übertragungsfunktionen implementieren.
In der Situation der 4 wird aufgrund der ARQ, die
in der Verbindungsschicht verwendet wird, eine Wettlaufbedingung
zwischen der Verbindungsschicht und der Transportschicht erzeugt:
Während
die Verbindungsschicht Daten erneut überträgt, kann der Transport-Neuübertragungs-Zeitgeber
ablaufen, was zu einem unechten Zeitablauf führt. Die erneuten Übertragungen
in der Verbindungsschicht können
z.B. aufgrund von Übertragungsfehlern
oder einem Datenverlust wegen Kanalwechseln vorhanden sein.
-
Es
sei auch darauf hingewiesen, dass die Übertragungsverzögerung über das
drahtlose Netz oft ein beträchtlicher
Teil der End-zu-End-Verzögerung
zwischen dem Sende-Peer und dem Empfangs-Peer des Transportschichtprotokolls
ist. Wenn in diesem Fall die Bandbreite, die für die Transportschichtverbindung
verfügbar
ist, in dem drahtlosen Netz über
einer kurzen Zeitperiode beträchtlich
abfällt,
kann die resultierende Zunahme in der End-zu-End-Verzögerung zwischen
dem Transportschicht-Sender- und
Empfänger
zu unechten Zeitabläufen
führen.
Beispiele von Bandbreitenabfällen schließen mobile
Hosts ein, die einen Kanalwechsel in einer Zelle durchführen, die
eine geringere Bandbreite als die alte Zelle bereitstellt.
-
Wie
bereits zuvor angezeigt, kann das in Verbindung mit 3 beschriebene,
Problem vermieden werden. Spezifischer kann, wenn das Verfahren,
das in Verbindung mit 1 beschrieben ist, auf das Problem
in 3 angewandt wird, dann der Sende-Peer zwischen
Bestätigungsdateneinheiten
auf die ursprüngliche Übertragung
einer Dateneinheit und Bestätigungsdateneinheiten
auf die erneute Übertragung
einer Dateneinheit unterscheiden. Aus dieser Information kann der
Sender bestimmen, ob ein unechter Zeitablauf aufgetreten ist, oder
ob tatsächlich ein
Verlust einer Dateneinheit vorhanden war. Der Sender kann dann dementsprechend
reagieren.
-
Spezifischer
wird in dem Beispiel der 3 der Sender, der die Erfindung
verwendet, in der Lage sein, die Bestätigungsdateneinheit, die empfangen wird,
nachdem das gezeigte erste Paket erneut übertragen worden ist, identifizieren,
eine Bestätigung
für die
ursprüngliche Übertragung
(t=10s) und nicht für die
erneute Übertragung
(t=15s) zu sein. Aufgrund dessen wird der Sender eine geeignete
Antwortprozedur auf die übermäßige Verzögerung durchführen, nämlich nicht
die Dateneinheiten, die der ersten erneuten übertragenen Dateneinheit folgen,
erneut übertragen,
und auch nicht die Übertragungsrate
verringern, vielmehr wird der Sender die Zeitablaufperiode, die
in der Flusssteuerung eingesetzt wird, auf der Grundlage der gemessenen
Verzögerung
zwischen dem ursprünglichen Übertragen
der Dateneinheit und dem Empfang der entsprechenden Bestätigungsdateneinheit
für das
ursprüngliche Übertragen erhöhen. Auf
diese Weise können
unechte erneute Übertragungen
und Zeitabläufe
vermieden werden.
-
Wie
ersehen werden kann, sind die obigen Beispiele in der Lage, einen
Mechanismus bereitzustellen, der ein flexibleres Kommunikationssystem zulässt, wenn
ein Protokoll verwendet wird, das eine Bestätigung von Daten und eine Zeitablauffunktion oder
eine doppelte Bestätigungs-Erfassungsfunktion bereitstellt.
In dem gerade beschriebenen Beispiel ist die Erfindung in der Lage,
ein Trigger-Ereignis zu qualifizieren, d.h. zwischen zumindest zwei
unterschiedlichen Fällen
zu unterscheiden, und dann in der Lage, eine geeignete Antwortprozedur
aufzurufen. Es sei darauf hingewiesen, dass in den obigen Beispielen
die Modi zum Anpassen der adaptiven Parameter einem Dateneinheitverlust
einerseits und einer übermäßigen Verzögerung andererseits
zugeordnet waren. Vielmehr können
die Modi zum Anpassen der adaptiven Parameter jedwedem möglichen Grund
von Zeitablaufereignissen oder doppelten Bestätigungsereignissen zugeordnet
werden.
-
Bei
dem in 1 beschriebenen Beispiel wurde in dem Schritt
S5 bestimmt, ob die Bestätigungsdateneinheit,
die einer gegebenen Dateneinheit zugeordnet ist, die ursprüngliche Übertragung oder
die erneute Übertragung
der gegebenen Dateneinheit bestätigte.
Gemäß der ersten
Möglichkeit zum
Implementieren dieses Schritts hält
der Sender eine Aufzeichnung der Rundlaufzeit RTT, die der Verbindung
zwischen dem Sende- und dem Empfangs-Peer zugeordnet ist, und hält insbesondere eine
Aufzeichnung der kürzesten
RTT, die während der
Verbindung oder der Sitzungseinrichtung bis zu dem betrachteten
Zeitpunkt gefunden wird. Dann bestimmt, wenn eine Bestätigungsdateneinheit
für eine erneute übertragene
Dateneinheit innerhalb einer Zeitperiode empfangen wird, die kleiner
als ein vorbestimmter Teil der kürzesten
RTT ist, der Sender, dass diese Bestätigung zu der ursprünglichen Übertragung
und nicht zu der erneuten Übertragung
gehört.
Dieser Teil kann auf einen festen Wert eingestellt werden, oder
er kann selbst ein adaptiver Parameter sein. Natürlich ist es nicht notwendig,
dass der Vergleichswert, der mit dem Teil multipliziert wird, die kürzeste gemessene
RTT ist, vielmehr ist es auch möglich,
dass der Sender einen mittleren RTT-Wert hält. In diesem Sinne ist der
Vergleichswert, der mit dem Teil zu multiplizieren ist, allgemein
eine Funktion eines oder mehrerer RTT-Werte, die in dem Verlauf der
Verbindung gemessen werden (während
der Sitzung).
-
Zum
Implementieren des Schritts S5 addiert der Sender gemäß der vorliegenden
Erfindung eine Markierung zu Dateneinheiten, die er sendet, wobei die
Markierung auf eine derartige Weise definiert ist, dass sie es zulässt, zwischen
einer ursprünglichen Übertragung
und einer erneuten Übertragung
zu unterscheiden. Dann kann der Empfänger entsprechend Bestätigungsdateneinheiten
derart markieren, dass der Sender in der Lage ist, zu identifizieren,
ob sich eine Bestätigung
auf die ursprüngliche Übertragung
oder die erneute Übertragung
bezieht.
-
Gemäß der vorliegenden
Erfindung wird ein einzelnes Bit in den Dateneinheiten bezeichnet,
wobei ein Wert von 0 eine ursprüngliche Übertragung und
ein Wert von 1 eine erneute Übertragung
anzeigt, oder umgekehrt.