DE69535404T2 - Flussteuerung für echtzeit-datenströme - Google Patents
Flussteuerung für echtzeit-datenströme Download PDFInfo
- Publication number
- DE69535404T2 DE69535404T2 DE69535404T DE69535404T DE69535404T2 DE 69535404 T2 DE69535404 T2 DE 69535404T2 DE 69535404 T DE69535404 T DE 69535404T DE 69535404 T DE69535404 T DE 69535404T DE 69535404 T2 DE69535404 T2 DE 69535404T2
- Authority
- DE
- Germany
- Prior art keywords
- data
- data rate
- recommended
- rate
- packets
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
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 bis2D 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 Computer11 Echtzeitdaten, wie Videotelefondaten, über ein Netz17 austauschen, das einen oder mehrere Router, wie einen Router19 , 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 Tgoal 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 Tactual Impulsen (die eigentliche verstrichene Zeit seit der letzten Messung), wird die empfangene Datenrate Rmeasured (in Bytes/Sekunde) wie folgt berechnet:
Rmeasured = (N/Tactual)·(60 Impulse/Sekunde) - Die ErrorRate (auch in Bytes/Sekunde) wird berechnet zu:
ErrorRate = (L·Rmeasured)/P -
- 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 Rweighted über die letzten B Intervalle wie folgt berechnet:
for(i = 1..B – 1)
ri = ri + 1
rB = Rmeasured
Rweighted = (Σ(i=1..B) (Wi·ri))/100 - Die Art und Weise, in der Rweighted berechnet wird, wird in den
2A bis2D 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 in2B 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 in2C und2D 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 Rweighted berechnet worden ist, kann eine sich empfehlende vom entfernten Sender zu verwendende Datenrate Rsuggested 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 Rsuggested auf der Grundlage des vorherigen Wertes von Rsuggested wie folgt zu begrenzen:
Cap = Rsuggested·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 Rweighted angepasst wird, um zu Rsuggested zu kommen, wird in
3A und3B 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 Rweighted 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 Rsuggested 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 Rsuggested darstellt und ist die Proportionalitätskonstante zwischen Rsuggested und ErrorRate. Die Abnahme in der gewichteten Durchschnittsdatenrate unterliegt demselben festgeschriebenen Maximum wie in3A . - Schließlich werden nach Berechnen der Rsuggested 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. Rsuggested auf MaxRate und Füllen aller Werte des Vektors r mit dem ersten berechneten Rmeasured, bevor das erste Rweighted 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 Rsuggested 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:
Tgoal = (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
Rsuggested = 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 Rsuggested, 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 Rsuggested 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 (43)
- 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.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US230371 | 1994-04-20 | ||
US08/230,371 US5434860A (en) | 1994-04-20 | 1994-04-20 | Flow control for real-time data streams |
PCT/US1995/004746 WO1995029549A1 (en) | 1994-04-20 | 1995-04-18 | Flow control for real-time data streams |
Publications (2)
Publication Number | Publication Date |
---|---|
DE69535404D1 DE69535404D1 (de) | 2007-04-12 |
DE69535404T2 true DE69535404T2 (de) | 2007-11-08 |
Family
ID=22864969
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE69535404T Expired - Lifetime DE69535404T2 (de) | 1994-04-20 | 1995-04-18 | Flussteuerung für echtzeit-datenströme |
DE69536115T Expired - Lifetime DE69536115D1 (de) | 1994-04-20 | 1995-04-18 | Flusssteuerung für Echtzeit-Datenströme |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE69536115T Expired - Lifetime DE69536115D1 (de) | 1994-04-20 | 1995-04-18 | Flusssteuerung für Echtzeit-Datenströme |
Country Status (6)
Country | Link |
---|---|
US (1) | US5434860A (de) |
EP (3) | EP1780961B1 (de) |
AU (1) | AU2357495A (de) |
DE (2) | DE69535404T2 (de) |
HK (1) | HK1103189A1 (de) |
WO (1) | WO1995029549A1 (de) |
Families Citing this family (84)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5854898A (en) | 1995-02-24 | 1998-12-29 | Apple Computer, Inc. | System for automatically adding additional data stream to existing media connection between two end points upon exchange of notifying and confirmation messages therebetween |
US5742602A (en) * | 1995-07-12 | 1998-04-21 | Compaq Computer Corporation | Adaptive repeater system |
US5751969A (en) * | 1995-12-04 | 1998-05-12 | Motorola, Inc. | Apparatus and methods for predicting and managing congestion in a network |
US6130878A (en) | 1995-12-27 | 2000-10-10 | Compaq Computer Corporation | Method and apparatus for rate-based scheduling using a relative error approach |
US6061411A (en) * | 1995-12-22 | 2000-05-09 | Compaq Computer Corporation | Method and apparatus for synchronizing a serial bus clock to a serial bus function clock |
EP0798897A3 (de) | 1996-03-26 | 1999-07-14 | Digital Equipment Corporation | Verfahren und Anlage zur relativen Fehlerablaufplannung unter Verwendung diskreter Geschwindigkeiten und proportioneller Skalierung der Geschwindigkeit |
US5864678A (en) * | 1996-05-08 | 1999-01-26 | Apple Computer, Inc. | System for detecting and reporting data flow imbalance between computers using grab rate outflow rate arrival rate and play rate |
US5748901A (en) * | 1996-05-21 | 1998-05-05 | Ramot University Authority Ltd. | Flow control algorithm for high speed networks |
US6026075A (en) * | 1997-02-25 | 2000-02-15 | International Business Machines Corporation | Flow control mechanism |
US6131119A (en) * | 1997-04-01 | 2000-10-10 | Sony Corporation | Automatic configuration system for mapping node addresses within a bus structure to their physical location |
US6105064A (en) * | 1997-05-30 | 2000-08-15 | Novell, Inc. | System for placing packets on network for transmission from sending endnode to receiving endnode at times which are determined by window size and metering interval |
JP3873405B2 (ja) * | 1997-10-21 | 2007-01-24 | ソニー株式会社 | データ配信システム及びデータ配信装置 |
US7184426B2 (en) * | 2002-12-12 | 2007-02-27 | Qualcomm, Incorporated | Method and apparatus for burst pilot for a time division multiplex system |
US6574211B2 (en) * | 1997-11-03 | 2003-06-03 | Qualcomm Incorporated | Method and apparatus for high rate packet data transmission |
US9118387B2 (en) | 1997-11-03 | 2015-08-25 | Qualcomm Incorporated | Pilot reference transmission for a wireless communication system |
US5999963A (en) * | 1997-11-07 | 1999-12-07 | Lucent Technologies, Inc. | Move-to-rear list scheduling |
US6118761A (en) * | 1997-12-18 | 2000-09-12 | Advanced Micro Devices, Inc. | Apparatus and method for generating rate control frames in a workgroup switch based on traffic contribution from a network switch port |
JP3914317B2 (ja) * | 1997-12-26 | 2007-05-16 | インターナショナル・ビジネス・マシーンズ・コーポレーション | データ通信装置およびその方法 |
US6680944B1 (en) * | 1998-03-09 | 2004-01-20 | Sony Corporation | Apparatus for and method of predictive time stamping of isochronous data packets transmitted over an IEEE 1394-1995 serial bus network |
US6272546B1 (en) | 1998-03-12 | 2001-08-07 | Sony Corporation | Method of and apparatus for managing resource allocation and bandwidth overflow in a cooperative, distributed computing environment |
US6816934B2 (en) * | 2000-12-22 | 2004-11-09 | Hewlett-Packard Development Company, L.P. | Computer system with registered peripheral component interconnect device for processing extended commands and attributes according to a registered peripheral component interconnect protocol |
US6487663B1 (en) | 1998-10-19 | 2002-11-26 | Realnetworks, Inc. | System and method for regulating the transmission of media data |
US6934837B1 (en) | 1998-10-19 | 2005-08-23 | Realnetworks, Inc. | System and method for regulating the transmission of media data |
US7492393B2 (en) * | 1999-02-12 | 2009-02-17 | Sony Corporation | Method of and apparatus for generating a precise frame rate in digital video transmission from a computer system to a digital video device |
US20020013852A1 (en) | 2000-03-03 | 2002-01-31 | Craig Janik | System for providing content, management, and interactivity for thin client devices |
US7468934B1 (en) | 1999-07-12 | 2008-12-23 | Ez4Media, Inc. | Clock with link to the internet |
US6633574B1 (en) * | 1999-03-17 | 2003-10-14 | Loytec Electronics Gmbh | Dynamic wait acknowledge for network protocol |
US6421745B1 (en) | 1999-04-12 | 2002-07-16 | Sony Corporation | Asynchronous connections with scattering page tables for transmitting data from a producer device to a consumer device over an IEEE 1394 serial data bus |
US6538990B1 (en) | 1999-04-15 | 2003-03-25 | International Business Machines Corporation | Method and system for congestion flow control in a high speed network |
US6445711B1 (en) | 1999-04-23 | 2002-09-03 | Sony Corporation | Method of and apparatus for implementing and sending an asynchronous control mechanism packet used to control bridge devices within a network of IEEE STD 1394 serial buses |
US8064409B1 (en) | 1999-08-25 | 2011-11-22 | Qualcomm Incorporated | Method and apparatus using a multi-carrier forward link in a wireless communication system |
US6621804B1 (en) | 1999-10-07 | 2003-09-16 | Qualcomm Incorporated | Method and apparatus for predicting favored supplemental channel transmission slots using transmission power measurements of a fundamental channel |
EP1111841B1 (de) * | 1999-12-21 | 2011-06-22 | Alcatel Lucent | Verfahren zur Übermittlung des Netzwerkzustandes und Kommunikationsnetzwerk |
US6732209B1 (en) * | 2000-03-28 | 2004-05-04 | Juniper Networks, Inc. | Data rate division among a plurality of input queues |
US6850488B1 (en) * | 2000-04-14 | 2005-02-01 | Sun Microsystems, Inc. | Method and apparatus for facilitating efficient flow control for multicast transmissions |
US6501739B1 (en) * | 2000-05-25 | 2002-12-31 | Remoteability, Inc. | Participant-controlled conference calling system |
US7142934B2 (en) * | 2000-09-01 | 2006-11-28 | Universal Electronics Inc. | Audio converter device and method for using the same |
US20020065927A1 (en) * | 2000-09-05 | 2002-05-30 | Janik Craig M. | Webpad and method for using the same |
US20060031550A1 (en) * | 2000-09-05 | 2006-02-09 | Universal Electronics Inc. | Webpad adapted to communicate using wide area and local area communication channels |
US20020065902A1 (en) * | 2000-09-05 | 2002-05-30 | Janik Craig M. | Webpad and method for using the same |
US6766376B2 (en) | 2000-09-12 | 2004-07-20 | Sn Acquisition, L.L.C | Streaming media buffering system |
US7200357B2 (en) * | 2000-10-20 | 2007-04-03 | Universal Electronics Inc. | Automotive storage and playback device and method for using the same |
US6973098B1 (en) | 2000-10-25 | 2005-12-06 | Qualcomm, Incorporated | Method and apparatus for determining a data rate in a high rate packet data wireless communications system |
US7068683B1 (en) * | 2000-10-25 | 2006-06-27 | Qualcomm, Incorporated | Method and apparatus for high rate packet data and low delay data transmissions |
US6789190B1 (en) * | 2000-11-16 | 2004-09-07 | Computing Services Support Solutions, Inc. | Packet flooding defense system |
US6996064B2 (en) * | 2000-12-21 | 2006-02-07 | International Business Machines Corporation | System and method for determining network throughput speed and streaming utilization |
US7647418B2 (en) * | 2001-06-19 | 2010-01-12 | Savvis Communications Corporation | Real-time streaming media measurement system and method |
KR100408525B1 (ko) | 2001-10-31 | 2003-12-06 | 삼성전자주식회사 | 네트워크에 적응적인 실시간 멀티미디어 스트리밍 시스템및 방법 |
US7929447B2 (en) * | 2002-03-05 | 2011-04-19 | Sony Corporation | Method of flow control for data transported using isochronous packets over an IEEE 1394-2000 serial bus network |
US7154910B2 (en) * | 2002-03-05 | 2006-12-26 | Sony Corporation | Method for any speed dubbing using isochronous packets on isochronous channels or on asynchronous streams over an IEEE 1394-2000 serial bus network |
EP1387528A1 (de) * | 2002-07-31 | 2004-02-04 | Deutsche Thomson-Brandt Gmbh | Verfahren und Gerät um eine Kommunikation auf einem Netzwerk mit Busstruktur durchzuführen |
WO2004042507A2 (en) * | 2002-10-31 | 2004-05-21 | Arizan Corporation | Methods and apparatus for summarizing document content for mobile communication devices |
US20090118019A1 (en) | 2002-12-10 | 2009-05-07 | Onlive, Inc. | System for streaming databases serving real-time applications used through streaming interactive video |
US9314691B2 (en) | 2002-12-10 | 2016-04-19 | Sony Computer Entertainment America Llc | System and method for compressing video frames or portions thereof based on feedback information from a client device |
US9077991B2 (en) | 2002-12-10 | 2015-07-07 | Sony Computer Entertainment America Llc | System and method for utilizing forward error correction with video compression |
US9108107B2 (en) | 2002-12-10 | 2015-08-18 | Sony Computer Entertainment America Llc | Hosting and broadcasting virtual events using streaming interactive video |
US9138644B2 (en) | 2002-12-10 | 2015-09-22 | Sony Computer Entertainment America Llc | System and method for accelerated machine switching |
US8964830B2 (en) | 2002-12-10 | 2015-02-24 | Ol2, Inc. | System and method for multi-stream video compression using multiple encoding formats |
US20040148391A1 (en) * | 2003-01-11 | 2004-07-29 | Lake Shannon M | Cognitive network |
US9274576B2 (en) * | 2003-03-17 | 2016-03-01 | Callahan Cellular L.L.C. | System and method for activation of portable and mobile media player devices for wireless LAN services |
US7768234B2 (en) * | 2004-02-28 | 2010-08-03 | Janik Craig M | System and method for automatically synchronizing and acquiring content for battery powered devices |
JP2004280695A (ja) * | 2003-03-18 | 2004-10-07 | Sony Corp | データ共有システム,送信側端末装置,受信側端末装置,プログラム,送信側端末装置の処理方法 |
US7603491B2 (en) * | 2003-06-19 | 2009-10-13 | Intel Corporation | Bandwidth conserving protocol for command-response bus system |
KR100523357B1 (ko) * | 2003-07-09 | 2005-10-25 | 한국전자통신연구원 | 이더넷 기반 수동형 광네트워크의 보안서비스 제공을 위한키관리 장치 및 방법 |
US7652844B2 (en) * | 2003-12-24 | 2010-01-26 | Bruce Edwards | System and method for protecting removeable media playback devices |
US20070258595A1 (en) * | 2004-03-11 | 2007-11-08 | Universal Electronics Inc. | Syncronizing Device-Specific Encrypted Data to and from Mobile Devices Using Detachable Storage Media |
US8154995B2 (en) * | 2005-01-26 | 2012-04-10 | At&T Intellectual Property I, L.P. | System and method of managing digital data transmission |
US20060235883A1 (en) | 2005-04-18 | 2006-10-19 | Krebs Mark S | Multimedia system for mobile client platforms |
KR100739710B1 (ko) * | 2005-06-14 | 2007-07-13 | 삼성전자주식회사 | 패킷의 손실 타입을 판별하는 방법 및 장치 |
US9779644B2 (en) * | 2007-08-08 | 2017-10-03 | Landmark Screens, Llc | Method for computing drive currents for a plurality of LEDs in a pixel of a signboard to achieve a desired color at a desired luminous intensity |
US9342266B2 (en) * | 2007-08-08 | 2016-05-17 | Landmark Screens, Llc | Apparatus for dynamically circumventing faults in the light emitting diodes (LEDs) of a pixel in a graphical display |
US9262118B2 (en) * | 2007-08-08 | 2016-02-16 | Landmark Screens, Llc | Graphical display comprising a plurality of modules each controlling a group of pixels corresponding to a portion of the graphical display |
US9620038B2 (en) * | 2007-08-08 | 2017-04-11 | Landmark Screens, Llc | Method for displaying a single image for diagnostic purpose without interrupting an observer's perception of the display of a sequence of images |
US9536463B2 (en) * | 2007-08-08 | 2017-01-03 | Landmark Screens, Llc | Method for fault-healing in a light emitting diode (LED) based display |
US9659513B2 (en) | 2007-08-08 | 2017-05-23 | Landmark Screens, Llc | Method for compensating for a chromaticity shift due to ambient light in an electronic signboard |
US8099476B2 (en) | 2008-12-31 | 2012-01-17 | Apple Inc. | Updatable real-time or near real-time streaming |
US8811200B2 (en) | 2009-09-22 | 2014-08-19 | Qualcomm Incorporated | Physical layer metrics to support adaptive station-dependent channel state information feedback rate in multi-user communication systems |
US8805963B2 (en) | 2010-04-01 | 2014-08-12 | Apple Inc. | Real-time or near real-time streaming |
GB201105502D0 (en) | 2010-04-01 | 2011-05-18 | Apple Inc | Real time or near real time streaming |
CN102238179B (zh) | 2010-04-07 | 2014-12-10 | 苹果公司 | 实时或准实时流传输 |
US8856283B2 (en) | 2011-06-03 | 2014-10-07 | Apple Inc. | Playlists for real-time or near real-time streaming |
EP2836921A4 (de) | 2012-04-12 | 2017-05-24 | Tata Consultancy Services Limited | System und verfahren zur untersuchung und kontinuierlichen abfrage von datenströmen |
TWI636689B (zh) * | 2016-11-25 | 2018-09-21 | 財團法人工業技術研究院 | 影音串流傳輸率決定方法與伺服器 |
CN110071877B (zh) * | 2018-01-22 | 2021-01-29 | 华为技术有限公司 | 一种传输信息的方法和装置 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4691314A (en) * | 1985-10-30 | 1987-09-01 | Microcom, Inc. | Method and apparatus for transmitting data in adjustable-sized packets |
JP2865782B2 (ja) * | 1990-03-16 | 1999-03-08 | 富士通株式会社 | 非同期伝送用codec装置 |
US5313455A (en) * | 1990-04-23 | 1994-05-17 | Koninklijke Ptt Nederland N.V. | Transmission system with recording of untransmitted packets |
US5307351A (en) * | 1991-08-26 | 1994-04-26 | Universal Data Systems, Inc. | Data communication apparatus for adjusting frame length and method of operating same |
US5313454A (en) * | 1992-04-01 | 1994-05-17 | Stratacom, Inc. | Congestion control for cell networks |
-
1994
- 1994-04-20 US US08/230,371 patent/US5434860A/en not_active Expired - Lifetime
-
1995
- 1995-04-18 EP EP07100417A patent/EP1780961B1/de not_active Expired - Lifetime
- 1995-04-18 AU AU23574/95A patent/AU2357495A/en not_active Abandoned
- 1995-04-18 DE DE69535404T patent/DE69535404T2/de not_active Expired - Lifetime
- 1995-04-18 DE DE69536115T patent/DE69536115D1/de not_active Expired - Lifetime
- 1995-04-18 EP EP95917574A patent/EP0756792B1/de not_active Expired - Lifetime
- 1995-04-18 WO PCT/US1995/004746 patent/WO1995029549A1/en active IP Right Grant
- 1995-04-18 EP EP10165876A patent/EP2271032A3/de not_active Withdrawn
-
2007
- 2007-10-24 HK HK07111484.3A patent/HK1103189A1/xx not_active IP Right Cessation
Also Published As
Publication number | Publication date |
---|---|
EP2271032A2 (de) | 2011-01-05 |
EP0756792B1 (de) | 2007-02-28 |
US5434860A (en) | 1995-07-18 |
EP1780961B1 (de) | 2010-10-13 |
EP1780961A3 (de) | 2007-09-26 |
WO1995029549A1 (en) | 1995-11-02 |
DE69536115D1 (de) | 2010-11-25 |
AU2357495A (en) | 1995-11-16 |
HK1103189A1 (en) | 2007-12-14 |
EP1780961A2 (de) | 2007-05-02 |
EP2271032A3 (de) | 2012-07-25 |
DE69535404D1 (de) | 2007-04-12 |
EP0756792A1 (de) | 1997-02-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE69535404T2 (de) | Flussteuerung für echtzeit-datenströme | |
DE602004008267T2 (de) | Übertragung von überwachungspaketen zur steuerung von überlastung und verbindungsaufbau in paketbasierten netzen mit begrenzter bandbreite | |
DE60216887T2 (de) | Verfahren zur dynamischen Übertragung von Datenpaketen unter Verwendung von RTP und RTCP Protokollen | |
DE60119780T2 (de) | System und verfahren für eine übertragungsratensteuerung | |
DE19983404B4 (de) | Verfahren und Vorrichtung zur Verwendung bei der Einstellung eines TCP Gleitfensters | |
DE69922180T2 (de) | Verfahren und Vorrichtung zur Datenflusssteuerung | |
DE69130559T2 (de) | Dynamische regelung der codierrate minimiert verkehrsüberlast in einem paketnetzwerk | |
DE60217361T2 (de) | Verfahren und System zur Überlastkontrolle in einem Kommunikationsnetzwerk | |
DE3780799T2 (de) | Anordnung zur ueberlastregelung durch bandbreitenverwaltung fuer paketvermittlungssystem. | |
EP1428408B1 (de) | Verteilte übermittlung von informationen in einem verbindungslosen, paketorientierten kommunikationsnetz | |
DE69126640T2 (de) | Flusssteuerung für Hochgeschwindigkeitsnetzwerk | |
DE69328468T2 (de) | Fehlerrateüberwachungsgerät | |
DE3780800T2 (de) | Anordnung zur ueberlastregelung fuer paketvermittlungssystem. | |
DE69434763T2 (de) | Verfahren und Vorrichtung zur Überlastregelung in einem Kommunikationsnetzwerk | |
US9577935B2 (en) | Unified congestion control for real-time media support | |
DE69432206T2 (de) | Dynamische Bandbreitenabschätzung und Adaption für Datenpaketnachrichtennetze | |
EP3044918B1 (de) | Netzwerkbasierte adaptive ratenbegrenzung | |
DE69130853T2 (de) | Bandbreitenverwaltung und Überlastabwehr für den Zugang zu Breitband-ISDN-Netzen | |
Widmer et al. | A survey on TCP-friendly congestion control | |
DE69732398T2 (de) | System zur Verkehrssteuerung und Überlastregelung für Paketnetzwerke | |
DE60212104T2 (de) | Auf Empfänger basierte Umlaufzeitmessung in TCP | |
DE60032458T2 (de) | Selbstanpassender Zitterspufferspeicher | |
DE60211322T2 (de) | Empfängerinitiierte Inkrementierung der Übertragungsrate | |
CN102461093B (zh) | 管理业务负荷的方法 | |
DE112018005429T5 (de) | Engpassbandbreiten- und umlaufzeit-überlastungssteuerung mit zufall-früherkennung |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8364 | No opposition during term of opposition | ||
8327 | Change in the person/name/address of the patent owner |
Owner name: APPLE INC., CUPERTINO, CALIF., US |
|
8328 | Change in the person/name/address of the agent |
Representative=s name: DERZEIT KEIN VERTRETER BESTELLT |