DE69535404T2

DE69535404T2 - Flussteuerung für echtzeit-datenströme

Info

Publication number: DE69535404T2
Application number: DE69535404T
Authority: DE
Inventors: Guy Gregory Los Gatos RIDDLE
Original assignee: Apple Computer Inc
Current assignee: Apple Inc
Priority date: 1994-04-20
Filing date: 1995-04-18
Publication date: 2007-11-08
Anticipated expiration: 2015-04-19
Also published as: AU2357495A; EP0756792B1; DE69535404D1; EP2271032A2; DE69536115D1; WO1995029549A1; EP1780961A3; EP0756792A1; US5434860A; HK1103189A1; EP1780961B1; EP2271032A3; EP1780961A2

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf Flusssteuerung, d.h. Regulierung von Verkehr, der auf einem Teilbereich eines Kommunikationsnetzes erlaubt ist, um eine übermäßige Überlastung zu vermeiden.
Stand der Technik
Eines der Merkmale eines Echtzeitdatenstroms, wie ein Videotelefondatenstrom, ist, dass er isochron ist – dass die Fristeinhaltung wesentlich für die Vertragserfüllung ist. Falls ein Fehler in einem Video- oder Audiostrom auftritt, kann sich das System nicht die Zeit leisten, alles zu stoppen und die verlorenen Datenpakete neu zu senden. Dies wird ernsthaft den Echtzeitdatenstrom durcheinander bringen. Ein besseres Vorgehen ist es, "weiterzumachen" und das Video (oder Audio) mit dem nächsten intakten empfangenen Rahmen wieder aufzunehmen.
Eine ähnliche Situation existiert in Bezug auf Flusssteuerung. Bekannte Flusssteuerungsverfahren für Nicht-Echtzeitdatenströme umfassen eine "Stopp-und-Warte"-Flusssteuerung und eine "Gleitfenster"-Flusssteuerung. Bei einer "Stopp-und-Warte"-Flusssteuerung muss eine Antwort auf vorher gesendete Daten empfangen werden, bevor mehr Daten gesendet werden können. Eine Stopp-und-Warte-Flusssteuerung nimmt deshalb an, dass der Datenfluss unterbrochen werden kann und nach Belieben wiederaufgenommen werden kann – was bei Echtzeitdaten klarerweise nicht der Fall ist.
Bei einer Gleitfensterflusssteuerung werden Fluss-Kredite ausgetauscht und aufgebraucht. Zum Beispiel kann der Empfänger einen Empfangspuffer von 1000 Byte belegen und einen "Sende-Kredit"-Wert von 1000 der sendenden Seite senden. Falls der Sender dann 100 Bytes an den Empfänger sendet, verfolgt er dies durch Setzen einer "gesendet" Variable auf 100. An diesem Punkt könnte der Sender 1000 – 100 = 900 weitere Bytes senden. Da der Empfänger die Daten verarbeitet und Pufferplatz freigibt, könnte er den Sende-Kredit-Wert von 1000 + 100 = 1100 erhöhen und diesen Wert der sendenden Seite senden. Dem Sender wäre nun erlaubt, "Sende-Kredit" – "gesendet" Bytes an den Empfänger zu senden, nämlich 100 – 100 = 1000. Wie bei einer Stopp- und Warteflusssteuerung nimmt die Gleitfensterflusssteuerung an, dass der Datenfluss unterbrochen werden kann und nach Belieben wiederaufgenommen werden kann. Weder diese noch andere bekannte Verfahren der Flusssteuerung sind für Echtzeitdatenströme geeignet.
Eine Vielfalt anderer Ansätze zur Flusssteuerung wurden vorgeschlagen, von denen einige implementiert wurden. Eine solche Technik ist Paket-Entfernung – einfach Überschußpakete entfernen. Eine weitere Technik, die als isarithmetische Flusssteuerung bekannt ist, beschränkt die Gesamtzahl an Paketen in dem Netz durch Verwenden von Erlaubnissen, die innerhalb des Netzes zirkulieren. Immer, wenn ein Knoten ein Paket senden will, muss er erst eine Erlaubnis einfangen und sie zerstören. Die Erlaubnis wird wiedererzeugt, wenn der Zielknoten das Paket aus dem Netz entfernt. Bei einem weiteren Ansatz, der als der Choke Paket Ansatz bezeichnet werden kann, senden Knoten, die eine Überlast detektieren, "Choke Pakete" zurück an die Quelle einer beliebigen Nachricht, die in den überlasteten Bereich gesendet wurde. Die Quelle muss dann diesen Typ von Verkehr reduzieren oder beseitigen. Verschiedene Flusssteuerungstechniken werden in Grange, J.L., und Gien, M. Hrsg., Flow Control in Computer Networks, Amsterdam: North Holland Publishing, 1979 beschrieben.
Es wurde die Verwendung von Verlustlastkurven vorgeschlagen, um einen Paketlieferservice eines Hochgeschwindigkeitscomputernetzes zu charakterisieren. Für einen gegebenen Sender drückt die Verlustlastkurve die Wahrscheinlichkeit von Paketverlust als eine Funktion von angebotener Last zu irgendeinem gegebenen Zeitpunkt oder Lastbedingung im Netz aus. Unter Verwendung dieser Information wählt ein Sender seinen eigenen Kompromiss zwischen Durchsatz und Paketverlust. Ein Verlustlastalgorithmus wird entworfen, um eine Senderzusammenarbeit zu fördern, um Schutz vor Schnellsendern bereitzustellen, und um die angebotene Last die ganze Zeit über nahe an der Netzkapazität zu halten. Jedoch wählt der Sender seinen eigenen Paketdurchsatz. Solche Verlustlastkurven wurden in Williamson und Sheriton, "Lost Load Curves: Support for Rate Base Congestion Control in High Speed Datagram Networks", Computer Science Department, Stanford Universität, 1991, beschrieben. Ein Flusssteuerungsmechanismus zur Flusssteuerung von Echtzeitdatenströmen wurde in der Europäischen Patentanmeldung 0 446 956 A2 beschrieben. Eine Zellsenderate wird durch einen Zeitstempel bestimmt, der auf gesendeten Zellen angebracht wird, und fehlende Zellen können aus der Auslassung eines Zeitstempels vom Empfänger bestimmt werden. Das Fehlen eines Zeitstempels wird immer als eine fehlende Zelle bestimmt. In Echtzeitstromnetzen können Datenpakete in Unordnung empfangen werden. Der Empfang von ungeordneten Paketen sollte nicht die gleiche Auswirkung auf die neu berechneten Senderaten haben wie nicht empfangene Datenpakete. Das System und Verfahren der Europäischen Patentanmeldung würden auch nicht die Senderate der Datenpakete optimieren, sondern unnötigerweise eine solche Rate durch Ignorieren von Paketen außerhalb der Reihenfolge beschränken. Diese Beschränkung ist in Echtzeitvideo- und -audioströmen nachteilig.
Keiner der vorgenannten Flusssteuerungsmechanismen ist zur Flusssteuerung von Echtzeitdatenströmen optimiert.
KURZFASSUNG DER ERFINDUNG
Die vorliegende Erfindung stellt allgemein gesprochen eine Flusssteuerung von Echtzeitdatenströmen über Computernetze bereit. Ein Echtzeitdatenstrom wird zum Beispiel in Datenpaketen von einer Datenquelle gemäß eines vorbestimmten Protokolls über ein gemeinsames Netz gesendet. Datenpakete des Echtzeitdatenstroms werden an einem Datenziel empfangen, welches mit dem gemeinsamen Netz verbunden ist. Das Datenziel bestimmt eine sich empfehlende Datenrate für die Datenquelle, die teilweise auf einer Anzahl von Datenpaketen basiert, die während eines vorausgegangenen Intervalls verloren wurden, und sendet die sich empfehlende Datenrate an eine Datenquelle. Die sich empfehlende Datenrate wird an der Datenquelle empfangen, welche ihre Datenrate gemäß der sich empfehlenden Datenrate anpasst. Der Ratenanpassungsmechanismus ist entworfen, so dass ein Netzsegment nicht mit einer einzelnen isochronen Datenstromverbindung überlastet wird, und dass ein überproportionaler Anteil der Netzbandbreite nicht von der isochronen Datenstromverbindung verbraucht wird.
Insbesondere stellt die vorliegende Erfindung in einem ersten Aspekt ein Verfahren gemäß Anspruch 1 bereit. Die vorliegende Erfindung stellt weiterhin eine Vorrichtung gemäß Ansprüchen 24 und 40 bereit.
KURZE BESCHREIBUNG DER ZEICHNUNG
Die vorliegende Erfindung kann weiter aus der folgenden Beschreibung in Verbindung mit der beigefügten Zeichnung verstanden werden. In der Zeichnung:
ist 1 ein Systemdiagramm von Computern, die zum Austauschen von Echtzeitdatenströmen gekoppelt sind, auf die das vorliegende Verfahren der Flusssteuerung anwendbar ist;
sind 2A bis 2D Diagramme, die veranschaulichen, wie eine gewichtete Durchschnittsrate bestimmt wird;
ist 3 ein Graph, der veranschaulicht, wie die gewichtete Durchschnittsdatenrate während eines fehlerfreien Laufs nach oben angepasst wird, um zu einer sich empfehlenden Datenrate zu kommen;
ist 3B ein Graph, der veranschaulicht, wie die gewichtete Durchschnittsdatenrate während eines verlustbehafteten Laufs nach unten angepasst wird, um zu einer sich empfehlenden Datenrate zu kommen; und
ist 4 ein Graph, der den Arbeitsschritt des Berechnens eines Ratendurchschnitts veranschaulicht.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Unter Bezugnahme auf 1 ist das vorliegende Verfahren auf gemeinsame Computernetze anwendbar, in denen mehrere Computer 11 Echtzeitdaten, wie Videotelefondaten, über ein Netz 17 austauschen, das einen oder mehrere Router, wie einen Router 19, umfasst. Videotelefon- und anderer Echtzeitverkehr wird große Mengen von Daten erzeugen, die große Bandbreiten belegen. Um Videotelefonbenutzer davon abzuhalten, andere Netzbenutzer zu stören, wird ein automatisches Mittel zum Begrenzen der Daten bereitgestellt (Flusssteuerung), immer wenn eine reduzierte Netzleistung detektiert wird. In einem aus mehreren Netzsegmenten zusammengesetzten System, die durch streckenlimitierende Faktoren auf dem Netz verbunden sind, ist Durchsatz die Verarbeitungskapazität der Router selbst: wenn sie überlastet sind, beginnen sie, Pakete fallen zu lassen. Im folgenden Flusssteuerungsverfahren wird eine Zunahme an verlorenen Paketen einem Überlastzustand irgendwo entlang des Pfades, den die Videotelefonpakete zurücklegen, zugeschrieben. (Eine Zunahme an verlorenen Paketen könnte natürlich wegen einer qualitativ schlechten Übertragungsleitung entlang des Pfades sein – aber der Empfangsknoten hat keine Möglichkeit zu bestimmen, ob so ein Zustand existiert oder nicht.)
Der von dem vorliegenden Flusssteuerungsverfahren verfolgte Ansatz ist es, die Anzahl an von der entfernten Videotelefonanwendung empfangenen Pakete und die Anzahl an während der Übertragung verlorenen Pakete zu messen. Wie vollständiger in der US-Anmeldung mit der Seriennummer 08/129,992, eingereicht am 30. September 1993, beschrieben wird, trägt jedes Paket eine Sequenznummer, wodurch die Anzahl verlorener Pakete leicht bestimmt werden kann. Auf der Grundlage dieser Information berechnet der empfangende Knoten periodisch eine sich empfehlende Paketsenderate, die das Netz nicht überlasten wird. Diese Rate wird dann zum Sender zurückgesendet (auf einem sicheren Steuerkanal, der in der oben erwähnten Parallelanmeldung beschrieben wird), der sie verwendet, um Parameter unter seiner Kontrolle anzupassen, um seine erzeugte Bandbreite zu beschränken. Diese Parameter können die Rahmenrate und Kompressionsverhältnisse umfassen. Wenn es mehrere Ströme zwischen dem Sender und Empfänger gibt, berechnet der Empfänger eine Datenrate für jeden eingehenden Strom, aber addiert die Raten für die einzelnen Ströme und sendet dem Sender nur die Summe für den Anruf. Der Sender ist frei, die Bandbreite unter den verschiedenen Strömen des Aufrufs wieder zu allozieren, solange das Gesamtziel erreicht wird.
Messungen werden jedes Intervall von T_goal Impulsen (ein Impuls ist 1/60 Sekunde) gemacht. Für jeden Strom werden die Anzahl empfangener Pakete P, die Anzahl empfangener Bytes N (die Gesamtheit der Längen der empfangenen Pakete), und die Anzahl verlorener Pakete L (die durch Zählen fehlender Sequenznummern im Strom bestimmt werden) während dieses Intervalls alle aufgezeichnet.
Das Berechnen von L, der Anzahl verlorener Pakete, ist aufgrund der Möglichkeit kompliziert, dass Pakete ungeordnet ankommen. Der folgende Prozess L berücksichtigt diese Möglichkeit:
Für jeden Strom, halte eine Variable
E = nächste erwartete Sequenznummer.

1. Falls die Paketsequenznummer M == E, setze E = E + 1 P = P + 1 N = N + (Größe des Pakets)
2. Falls M > E, setze L = L + (M – E) P = P + 1 N = N + (Größe des Pakets) E = (M + 1)
3. Falls M < E, setze L = L – 1 P = P + 1 N = N + (Größe des Pakets)

Die vorstehenden Vergleiche können unter Verwendung von Modulo-Arithmetik vereinfacht werden. Falls zum Beispiel M in 1/4 des Sequenznummernraums größer als E unter Verwendung von Modulo-Arithmetik ist, dann wird M > E als wahr bewertet.
Falls die Messung zeigt, dass P während des Intervalls gleich Null ist, wird der Strom als untätig berichtet und keine der folgenden Berechnungen werden durchgeführt.
Am Ende jedes Intervalls von T_actual Impulsen (die eigentliche verstrichene Zeit seit der letzten Messung), wird die empfangene Datenrate R_measured (in Bytes/Sekunde) wie folgt berechnet:
R_measured = (N/T_actual)·(60 Impulse/Sekunde)
Die ErrorRate (auch in Bytes/Sekunde) wird berechnet zu:
ErrorRate = (L·R_measured)/P
Zusätzlich wird eine Variable ErrorFree gemäß der folgenden Prozedur berechnet:
Der Wert von ErrorFree gibt die Anzahl aufeinanderfolgender Intervalle an, die der Strom fehlerfrei war. Ein Spezialfall wird für den Fall bereitgestellt, wenn ein einzelner Fehler während des Intervalls bemerkt wird, um den Fluss nicht zu bestrafen, wo scheinbar verlorene Pakete sind, aber die Pakete stattdessen bloß außer der Reihenfolge sind.
Um zu vermeiden, dass Kurzzeitfluktuationen im Netzverkehr wilde Störungen in Datenflüssen verursachen, werden die berechneten empfangenen Datenraten über die letzten B Intervalle verfolgt (in einem Vektor r[1..B]), und ein Berechnen des Durchschnitts wird verwendet, um die Fluktuationen zu glätten. Anstatt allen Intervallen dasselbe Gewicht zu geben, wird das meiste Gewicht dem jüngsten Intervall gegeben (welches r[B] ist, wobei r[1] das älteste gehaltene ist). Die Gewichte (die in einer bevorzugten Ausführungsform insgesamt 100 ergeben müssen) werden in einem Vektor Weights [1..B] gehalten.
Als nächstes wird die gewichtete Datenrate R_weighted über die letzten B Intervalle wie folgt berechnet:
for(i = 1..B – 1)
r_i = r_i + 1
r_B = R_measured
R_weighted = (Σ_(i=1..B) (W_i·r_i))/100
Die Art und Weise, in der R_weighted berechnet wird, wird in den 2A bis 2D veranschaulicht. Die Datenraten über jedes einer Anzahl an Intervallen werden in "Buckets" ("Behältern") gespeichert, von denen jeder mit einem Gewicht verbunden ist. In einer bevorzugten Ausführungsform gibt es vier Buckets, mit denen jeweils die Gewichte 10, 20, 30 bzw. 40 verbunden sind. Die Buckets sind in einer Schlange angeordnet, so dass die Datenrate über das jüngste Intervall in dem Bucket gespeichert wird, der ein Gewicht von 40 hat, die Datenrate über das nächstjüngste Intervall wird in dem Bucket gespeichert, der ein Gewicht von 30 hat, etc.
Insbesondere unter Bezugnahme auf 2A werden, nachdem die Datenrate während eines ersten Intervalls gemessen wurde, alle Buckets auf diesen Wert initialisiert, zum Beispiel 752, was bedeutet, dass 752 Bytes während des Intervalls empfangen wurden. Man nehme an, dass 824 Bytes während des nächsten Intervalls empfangen werden. Am Ende des nächsten Intervalls ersetze der Wert 824 den Wert 752 im letzten Bucket, wie in 2B gezeigt ist. Man nehme nun an, dass 511 Bytes während des nächsten Intervalls empfangen werden, und dass 696 Bytes während des nächsten Intervalls nach diesem empfangen werden. Diese Werte werden in den Buckets am Ende der jeweiligen Intervalle gespeichert, wie in 2C und 2D veranschaulicht ist. Am Ende des vierten Intervalls ist der gewichtete Durchschnitt 671 Bytes, der durch eine gerade Linie dargestellt wird, die eine darunter liegende Fläche gleich der Fläche unter den Liniensegmenten hat, welche die "Niveaus" der jeweiligen Bucket darstellen.
Sobald R_weighted berechnet worden ist, kann eine sich empfehlende vom entfernten Sender zu verwendende Datenrate R_suggested berechnet werden. Um jedoch wilde Fluktuationen zu dämpfen, die auftreten können, wenn unter einigen Betriebssystemen gearbeitet wird, wird eine Variable Cap verwendet, um die maximale Änderung auf R_suggested auf der Grundlage des vorherigen Wertes von R_suggested wie folgt zu begrenzen:
Cap = R_suggested·25%.
Falls der Fluss einen guten Lauf fehlerfreier Intervalle erfährt, wird die sich empfehlende Datenrate als eine Belohnung um einen Wert erhöht, der für jedes aufeinanderfolgende fehlerfreie Intervall zunimmt, aber nicht um mehr als einen bestimmten Prozentsatz (ErrorFreeCap) einer maximalen erlaubten Rate MaxRate. Umgekehrt wird, wenn Fehler angetroffen werden, die sich empfehlende Datenrate um mehr, um einen Faktor ErrorRateFactor, als die gemessene ErrorRate wie folgt bestraft:
Die Art und Weise, in der R_weighted angepasst wird, um zu R_suggested zu kommen, wird in 3A und 3B veranschaulicht.
Insbesondere unter Bezugnahme auf 3A wird die gewichtete Durchschnittsdatenrate während eines fehlerfreien Laufs nach oben angepasst, um zu einer sich empfehlenden Datenrate zu kommen. In einer bevorzugten Ausführungsform wird für jedes aufeinanderfolgende fehlerfreie Intervall bis zum Maximum ErrorFreeCap die gewichtete Durchschnittsdatenrate R_weighted um ein Prozent der maximalen erlaubten Rate MaxRate vergrößert. Diese Zunahme unterliegt zusätzlich der Begrenzung Cap, die in einer bevorzugten Ausführungsform auf dem vorherigen Wert von R_suggested basiert und größer gleich oder kleiner gleich dem festgeschriebenen Maximum (cap) ist, das unter Verwendung von ErrorFreeCap berechnet wurde.
Unter Bezugnahme auf 3B wird die gewichtete Durchschnittsdatenrate während eines fehlerbehafteten Laufs nach unten angepasst, um zu einer sich empfehlenden Datenrate zu kommen. Die gewichtete Durchschnittsdatenrate wird um einen Betrag verkleinert, der linear mit ErrorRate zunimmt. Der konstante ErrorRateFactor ist die Steigung der Geraden, die R_suggested darstellt und ist die Proportionalitätskonstante zwischen R_suggested und ErrorRate. Die Abnahme in der gewichteten Durchschnittsdatenrate unterliegt demselben festgeschriebenen Maximum wie in 3A.
Schließlich werden nach Berechnen der R_suggested Werte für alle Ströme auf dem Anruf, sie zusammenaddiert und der Gesamtwert an den Sender über den sicheren Steuerkanal gesendet. Der Sender muss seine Datenerzeugungsrate dementsprechend anpassen.
In einer bevorzugten Ausführungsform werden Messintervalle nicht mit dem Fluss synchronisiert. Wenn man vom untätigen Zustand aus beginnt, sind die Daten vom ersten Messintervall deshalb zweifellos falsch, sofern die Messung nicht das komplette Intervall abdeckt. Die Daten aus dem ersten Messintervall werden deshalb entfernt. Die Berechnungen beginnen stattdessen unter Verwendung der zweiten Intervalldaten durch Initialisieren von ErrorFree auf Null. R_suggested auf MaxRate und Füllen aller Werte des Vektors r mit dem ersten berechneten R_measured, bevor das erste R_weighted berechnet wird.
Falls der Sender anfängt, sofort bei MaxRate zu senden, ist es gut möglich, besonders langsame Router mit so viel Verkehr zu überlasten, dass sogar der erste Wert von R_suggested nicht vom fernen Ende sicher zurückgegeben werden kann. Um diese Möglichkeit zu vermeiden, müssen Sender das Senden auf einem neu geprägten Strom bei einer geringeren Rate InitialRate beginnen. Während Erfahrung angesammelt wird, wird diese Rate nach oben oder unten angepasst.
In einer beispielhaften Ausführungsform wurden die folgenden Werte der vorstehenden globalen Konstanten verwendet:
T_goal = (5 Sekunden)·(60 Impulse/Sekunde) = 300 Impulse
B = 4 Buckets
Gewichte = {10,20,30,40}
MaxRate = ((6,000,000 bps)/2)/(8 Bits/Byte) = 375.000 Bytes/Sekunde
InitialRate = MaxRate·25%
ErrorFreeCap = 7
ErrorRateFactor = 10
Zusätzlich werden die folgenden Variablen pro aktivem Strom gehalten:
R[1..B] = Ratengeschichte
ErrorFree = Zählen fehlerfreier Intervalle
R_suggested = Datenrate, die der entfernte Sender verwenden sollte
Ein Merkmal des beschriebenen Flusssteuerungsverfahrens ist, dass, sobald es dem Sender gelungen ist, Bandbreite zu erhalten, er dazu neigen wird, diese Bandbreite zu halten, in Bevorzugung zu späteren Versuchen von anderen Sendern, Bandbreite zu erhalten. So wird, falls zum Beispiel ein Ende eines Anrufs zeitweise auf Wartestellung gesetzt wird, das andere Ende allmählich die freigemachte Bandbreite aufnehmen und versuchen, sie zu halten, was es für das andere Ende schwer macht, Bandbreite wiederzugewinnen, wenn es aus der Wartestellung genommen wird.
Eine Lösung für dieses Problem ist das Berechnen des Durchschnitts von Raten, das vom Sender durchgeführt werden kann, wenn er der detektiert, dass die Rate, mit der er senden darf, das gerade empfangene R_suggested, größer als die sich empfehlende Rate ist, mit welcher der Sender an die andere Seite sendet. Da die in beiden Richtungen fließenden Daten wahrscheinlich denselben Pfad durchlaufen, wird der Sender und der Empfänger beide durch Zusammenarbeiten begünstigt, um die Kanalbandbreite zu allozieren. Wenn der vorstehende Zustand detektiert wird, reduziert der Sender freiwillig seine Senderate auf halbes Niveau zwischen den beiden R_suggested Werten, um einer gleichmäßigeren Verteilung näher zu kommen.
Dieses Verfahren zur Ratendurchschnittsberechnung kompensiert auch mögliche Ungleichheiten in den Fähigkeiten der beiden beim Senden verwendeten Maschinen, von denen eine in der Lage sein kann, einen überproportionalen Betrag der Bandbreite zu belegen.
Die Art und Weise, auf die Ratendurschnittsberechnung eine gleichmäßigere Bandbreitenverteilung erzielt, wird in 4 veranschaulicht. Während die "dominante" Station freiwillig ihre Senderate reduziert, reduziert die entgegengesetzte Station die sich empfehlende Datenrate, die sie zur dominanten Station sendet. Zur gleichen Zeit kann die "unterwürfige" Station mehr Bandbreite belegen, als die dominante Station Bandbreite freigibt. Die sich empfehlende und tatsächliche Datenrate der beiden Stationen tendieren daher zu konvergieren.
Die oben beschriebene maximale Datenrate wird in einem Bemühen gesetzt, ein Ethernetsegment nicht mit einem einzelnen Videotelefon oder anderem Echtzeitdatenabruf zu überlasten.
Das Vorstehende beschrieb die Prinzipien, bevorzugten Ausführungsformen und Arbeitsmodi der vorliegenden Erfindung. Die Erfindung sollte jedoch nicht auf die diskutierten Ausführungsformen beschränkt werden. Die oben beschriebenen Ausführungsformen sollten deshalb als veranschaulichend anstatt als einschränkend betrachtet werden. Variationen in diesen Ausführungsformen können gemacht werden, ohne den Schutzbereich der vorliegenden Erfindung, wie er durch die folgenden Ansprüche definiert wird, zu verlassen. Zum Beispiel kann die Messungsintervalllänge angepasst werden. Ein Absenken der Messungsintervalllänge wird verursachen, dass der Flusssteuerungsprozess schneller auf Netzänderungen reagieren wird. Die Anzahl verwendeter Bucket kann erhöht oder erniedrigt werden, um eine längere oder kürzere Netzverkehr-Geschichte zu halten. Die verwendeten Gewichte können verändert werden, zum Beispiel um sie weniger exponentiell zu machen. Außerdem kann der Empfänger, anstelle die sich empfehlende Datenrate am Empfänger zu berechnen, einfach Rohmessungen an die Sender senden, aus denen der Sender dann die sich empfehlende Datenrate berechnen kann. Andere Variationen sind einem Durchschnittsfachmann ersichtlich.
Legende zu den Zeichnungen
1

NETWORK ADAPTER – NETZADAPTER
NETWORK – NETZ

2A

BUCKET WEIGHTS – BUCKET-GEWICHTE

2B

BUCKET WEIGHTS – BUCKET-GEWICHTE

2C

BUCKET WEIGHTS – BUCKET-GEWICHTE

2D

BUCKET WEIGHTS – BUCKET-GEWICHTE

3A

BYTES/SECOND – BYTES/SEKUNDE
(INTERVALS) – INTERVALLE

3B

BYTES/SECOND – BYTES/SEKUNDE

4

REMOTE SUGGESTED – ENTFERNT SUGGESTED

Claims

Verfahren, umfassend: Empfangen von Datenpaketen an einem Datenziel (11), die von einer Datenquelle (11) in wenigstens einem Echtzeitdatenstrom über ein verteiltes Computernetz (17) gesendet wurden, wobei jedes der Datenpakete eine Sequenznummer enthält; Bestimmen einer sich empfehlenden Datenrate für die Datenquelle (11), teilweise auf der Grundlage der Anzahl verlorener Datenpakete, gesendet von der Datenquelle (11), aber nicht empfangen vom Datenziel (11), während eines vorausgegangenen Zeitintervalls, wobei die Anzahl verlorener Datenpakete auf der Grundlage von Sequenznummern im Strom bestimmt wird; und Senden von Information bezüglich der sich empfehlenden Datenrate vom Datenziel (11) zur Datenquelle (11); gekennzeichnet durch: Berücksichtigen der Möglichkeit, dass Pakete nicht in ihrer Reihenfolge empfangen werden, bei der Bestimmung der sich empfehlenden Datenrate.
Verfahren nach Anspruch 1, wobei die sich empfehlende Datenrate am Datenziel (11) bestimmt wird und vom Datenziel (11) zur Datenquelle gesendet wird.
Verfahren nach Anspruch 1 oder 2, welches die weiteren Schritte umfasst: Empfangen der sich empfehlenden Datenrate an der Datenquelle (11); und Anpassen einer Datenrate der Datenquelle (11) entsprechend der sich empfehlenden Datenrate.
Verfahren nach einem der vorangegangenen Ansprüche, wobei die sich empfehlende Datenrate über einen sicheren Steuerkanal gesendet wird.
Verfahren nach Anspruch 1, wobei die sich empfehlende Datenrate an der Datenquelle unter Verwendung der vom Datenziel (11) an die Datenquelle (11) gesendeten Information bestimmt wird.
Verfahren nach Anspruch 5, welches den weiteren Schritt umfasst: Anpassen einer Datenrate der Datenquelle (11) entsprechend der sich empfehlenden Datenrate.
Verfahren nach einem der vorangegangenen Ansprüche, wobei der Bestimmungsschritt folgendes umfasst: Messen einer Datenrate des Echtzeitdatenstroms während jeweils einzelner von mehreren im Wesentlichen gleichen vorausgegangenen Zeitintervallen.
Verfahren nach einem der vorausgegangenen Ansprüche, wobei der Bestimmungsschritt weiter umfasst: Bilden eines Durchschnitts der Datenrate des Echtzeitdatenstroms während mehrerer Intervalle.
Verfahren nach Anspruch 8, wobei der Durchschnitt ein gewichteter Durchschnitt der Datenrate des Echtzeitdatenstroms während mehrerer Intervalle ist.
Verfahren nach Anspruch 9, wobei der Durchschnitt ein gewichteter Durchschnitt der Datenrate des Echtzeitdatenstroms während jedes von einer vorbestimmten Anzahl aufeinanderfolgender vorausgegangener Intervalle ist.
Verfahren nach Anspruch 8, wobei die sich empfehlende Datenrate bestimmt wird durch das Anpassen der Durchschnittsdatenrate des Echtzeitdatenstroms während mehrerer Intervalle entsprechend der Anzahl verlorener Datenpakete, gesendet von der Datenquelle (11), aber nicht empfangen vom Datenziel (11), während eines vorausgegangenen Zeitintervalls.
Verfahren nach Anspruch 11, wobei die sich empfehlende Datenrate durch das Addieren eines Inkrements zur Durchschnittsdatenrate bestimmt wird, wenn die Anzahl verlorener Pakete während eines vorausgegangenen Zeitintervalls niedrig war.
Verfahren nach Anspruch 12, wobei zur Durchschnittsdatenrate ein Inkrement addiert wird, wenn die Anzahl verlorener Pakete während eines unmittelbar vorausgegangenen Zeitintervalls Null war.
Verfahren nach Anspruch 13, wobei mit der Zunahme der Anzahl verlorengegangener Intervalle, in denen die Anzahl verlorener Pakete Null war, ein größeres Inkrement zu der Durchschnittsrate addiert wird.
Verfahren nach Anspruch 14, wobei die vorausgegangenen Intervalle, in denen die Anzahl verlorener Pakete Null war, aufeinanderfolgende Intervalle sind.
Verfahren nach Anspruch 14, wobei die Größe des zur Durchschnittsdatenrate addierten Inkrements einer oberen Grenze unterliegt.
Verfahren nach Anspruch 11, wobei ein Inkrement von der Durchschnittsdatenrate subtrahiert wird, wenn die Anzahl verlorener Pakete während eines unmittelbar vorausgegangenen Zeitintervalls nicht Null war.
Verfahren nach Anspruch 17, wobei mit der Zunahme des Anteils verlorener Pakete zu empfangenen Paketen ein größeres Inkrement von der Durchschnittsdatenrate subtrahiert wird.
Verfahren nach Anspruch 18, wobei die Größe des Inkrements, welches von der Durchschnittsdatenrate subtrahiert wird, einer oberen Grenze unterliegt.
Verfahren nach Anspruch 11, wobei der Echtzeitdatenstrom nach dem Start mit einer anfänglich niedrigeren Datenrate als einer maximal erlaubten Datenrate gesendet wird.
Verfahren nach Anspruch 11, wobei beim Abschluss eines ersten Intervalls nach dem Start der Anteil verlorener Pakete zu empfangenen Paketen während des ersten Intervalls ignoriert wird, wenn die sich empfehlende Datenrate beim Abschluss des zweiten und der nachfolgenden Intervalle bestimmt wird.
Verfahren nach Anspruch 1, wobei die sich empfehlende Datenrate eine maximal erlaubte Rate ist.
Verfahren nach Anspruch 1, weiter umfassend: Addieren von sich empfehlenden Datenraten für jeden von mehreren Echtzeitdatenströmen, um eine aggregierte, sich empfehlende Datenrate zu erhalten; Senden von Information bezüglich der aggregierten, sich empfehlenden Datenrate vom Datenziel (11) zur Datenquelle (11); und Anpassen von Datenraten der mehreren Echtzeitdatenströme an der Datenquelle (11), so dass eine kombinierte Datenrate aus mehreren Echtzeitdatenströmen nicht die aggregierte, sich empfehlende Datenrate überschreitet.
Gerät zur Verwendung in einem verteilten Computernetz (17), das Echtzeitdatenströme übertragen kann, wobei das Gerät umfasst: Mittel zum Empfangen von Datenpaketen, die von der Datenquelle (11) in wenigstens einem Echtzeitdatenstrom über das verteilte Computernetz (17) gesendet wurden; wobei jedes der Datenpakete eine Sequenznummer enthält; Mittel zum Bestimmen von Information bezüglich einer sich empfehlenden Datenrate für die Datenquelle (11) auf der Grundlage der Anzahl verlorener Datenpakete, gesendet von der Datenquelle (11), aber nicht empfangen, während eines vorausgegangenen Zeitintervalls, wobei die Anzahl verlorener Datenpakete auf Grundlage der Sequenznummern im Strom bestimmt wird; und Mittel zum Senden der Information an die Datenquelle (11) bezüglich einer sich empfehlenden Datenrate; wobei das Gerät, dadurch gekennzeichnet ist, dass es weiter umfasst: Mittel zum Berücksichtigen der Möglichkeit, dass Pakete nicht in ihrer Reihenfolge empfangen werden, bei der Bestimmung der sich empfehlenden Datenrate.
Gerät nach Anspruch 24, wobei die sich empfehlende Datenrate am Gerät bestimmt wird und vom Gerät an die Datenquelle (11) gesendet wird.
Gerät nach Anspruch 24, wobei die Information der Datenquelle (11) erlaubt, bezüglich einer sich empfehlenden Datenrate eine sich empfehlende Datenrate für das Senden zu bestimmen.
Gerät nach Ansprüchen 24, 25 oder 26, wobei die Information bezüglich einer sich empfehlenden Datenrate über einen sicheren Steuerkanal gesendet wird.
Gerät nach Anspruch 24, weiter umfassend: Mittel zum Messen einer Datenrate des Echtzeitdatenstroms während jeweils einzelner von mehreren im Wesentlichen gleichen vorausgegangenen Zeitintervallen.
Gerät nach Anspruch 24, weiter umfassend: Mittel zum Bilden einer Durchschnittsdatenrate des Echtzeitdatenstroms während mehrerer Intervalle.
Gerät nach Anspruch 29, wobei der Durchschnitt ein gewichteter Durchschnitt der Datenrate des Echtzeitdatenstroms während mehrerer Intervalle ist.
Gerät nach Anspruch 30, wobei der Durchschnitt ein gewichteter Durchschnitt der Datenrate des Echtzeitdatenstroms während jedes von einer vorbestimmten Anzahl aufeinanderfolgender vorausgegangener Intervalle ist.
Gerät nach Anspruch 29, wobei die sich empfehlende Datenrate durch Anpassen der Durchschnittsdatenrate des Echtzeitdatenstroms während mehrerer Intervalle entsprechend der Anzahl verlorener Datenpakete, gesendet von der Datenquelle (11), aber nicht empfangen, während eines vorausgegangenen Zeitintervalls, bestimmt wird.
Gerät nach Anspruch 32, wobei die sich empfehlende Datenrate durch Addieren eines Inkrements zur Durchschnittsdatenrate bestimmt wird, wenn die Anzahl verlorener Pakete während eines vorausgegangenen Zeitintervalls niedrig war.
Gerät nach Anspruch 33, wobei die Größe des zur Durchschnittsdatenrate addierten Inkrements einer oberen Grenze unterliegt.
Gerät nach Anspruch 32, wobei ein Inkrement von der Durchschnittsdatenrate subtrahiert wird, wenn die Anzahl verlorener Pakete während eines unmittelbar vorausgegangenen Zeitintervalls nicht Null war.
Gerät nach Anspruch 35, wobei ein größeres Inkrement von der Durchschnittsdatenrate subtrahiert wird, wenn der Anteil verlorener Pakete zu empfangenen Paketen zunimmt.
Gerät nach Anspruch 36, wobei die Größe des zu subtrahierenden Inkrements von der Durchschnittsdatenrate einer unteren Grenze unterliegt.
Gerät nach Anspruch 24, wobei die sich empfehlende Datenrate eine maximal erlaubte Rate ist.
Gerät nach Anspruch 24, weiter umfassend: Mittel zum Addieren sich empfehlender Datenraten für jeden von mehreren Datenströmen, um eine aggregierte, sich empfehlende Datenrate zu erreichen; und Mittel zum Senden der aggregierten, sich empfehlenden Datenraten zur Datenquelle (11).
Gerät zur Verwendung in einem verteilten Computernetz (17), das Echtzeitdatenströme übertragen kann; wobei das Gerät folgendes umfasst: Mittel zum Senden von Datenpaketen zu einem Datenziel (11) in wenigstens einem Echtzeitdatenstrom über das verteilte Computernetz (17), wobei jedes Datenpaket eine Sequenznummer enthält; Mittel zum Empfangen von Information bezüglich einer sich empfehlenden Datenrate zum Senden vom Datenziel (11), wobei die Information teilweise auf der Anzahl verlorener Datenpakete, gesendet vom Gerät, aber nicht empfangen vom Datenziel (11), während eines vorausgegangenen Zeitintervalls basiert, wobei die Anzahl verlorener Datenpakete auf Grundlage von Sequenznummern im Strom am Datenziel (11) bestimmt wird; und Mittel zum Bestimmen einer sich empfehlenden Datenrate zum Senden, basierend auf der empfangenen Information bezüglich der sich empfehlenden Datenrate; wobei das Gerät dadurch gekennzeichnet ist, dass es umfasst Mittel zum Anpassen der Rate, in der Datenpakete entsprechend der sich empfehlenden Datenrate gesendet werden, in einer Weise, dass die Möglichkeit berücksichtigt wird, dass Pakete vom Datenziel (11) nicht in ihrer Reihenfolge empfangen werden.
Gerät nach Anspruch 40, wobei die Information bezüglich einer sich empfehlenden Datenrate eine sich empfehlende Datenrate ist, die vom Datenziel (11) bestimmt wird.
Gerät nach Anspruch 40, weiter umfassend: Mittel zum Anpassen einer gesendeten Datenrate entsprechend der sich empfehlenden Datenrate.
Gerät nach Ansprüchen 40, 41 oder 42, wobei die Information entsprechend der sich empfehlenden Datenrate über einen sicheren Steuerkanal empfangen wird.