In den letzten Kapiteln beschäftigten wir uns mit der Frage, wie wir Multimediadaten, insbesondere RTP-Daten, über eine PPP-Verbindung übertragen können. Wir beschrieben verschiedene Probleme und zeigten zum Teil Lösungen auf.
Damit unsere Überlegungen nicht isoliert im Raum stehen, haben wir eine Testumgebung geschaffen, in der wir unsere Überlegungen probieren konnten.
Wir überlegten uns somit, was die günstigste Simulationsumgebung sein könnte. Es standen dabei mehrere Möglichkeiten zur Diskussion, von denen zwei in den nächsten Abschnitten genauer beschrieben sind.
Es ergeben sich jedoch einige gravierende Nachteile:
Alles im allen erschien es uns recht fraglich, ob man mit dieser Umgebung vernünftige Ergebnisse erzielen kann.
Die Abbildung [testImpl-1] gibt einen Überblick über die von uns implementieren Komponenten und deren Interaktionen. In den folgenden Abschnitten ist jedes der implementieren Module separat beschrieben. Der Source-Code der Testimplementierung ist im Anhang [srcTestImpl] enthalten.
Neben dieser Rolle stellte es auch das eigentliche Hauptmodul auf der entfernten Seite dar. Für die Seite des "Anrufers" war noch eine weitere Zusatzkomponente nötig, bei der es möglich ist, die Eingaben der Tastatur direkt zum Modem zu schicken. Nur so war es möglich, mit Hilfe des Modems zu wählen und das Programm auf der Seite in der TU zu starten. Auch hier galt, daß durch Eingabe von CTRL/B die Verbindung unterbrochen werden konnte. Es wurde jedoch nicht die physikalische Modemverbindung getrennt, sondern nur der in der Abbildung sichtbare Protokollstack sauber terminiert. Danach befand man sich wieder im "Terminal-Modus".
escaped. XON und XOFF wird bei Modemverbindungen oft eingeschaltet, da die unterliegenden Verbindungen diese oft von sich aus einstreuen. Durch das escapen dieser Werte ist man somit immer auf der sicheren Seite. Das CTRL/B wird nun bei uns escaped, da wir es (wie oben schon erwähnt) zum Abbruch der Verbindung benutzen[ Der Wert wurde nicht ganz zufällig gewählt. 0 wurde nicht verwendet, da dieser des öfteren in realen Daten vorkommt. Würde dieser escaped erden müssen, hätte das ein erhöhtes zu übertragendes Datenvolumen zur Folge. CRTL/A wurde von unserem Terminal Programm bereits benutzt, so daß sie die Verwendung von CTRL/B anbot.].
In unserer Implementierung wird das FCS-Feld mit einen 16 Bit CRC berechnet und übertragen. Für unsere Testimplementierung sollte das ausreichen. Verwendet wurde hierzu die in RFC 1662 angegebene CRC Tabelle aus Appendix C.2, sowie das dort beschriebene Verfahren zur Berechnung.
Das PPP-Modul entspricht eigentlich einer ganz normalen PPP-Implementierung jedoch mit der Einschränkung, daß kein LCP (Link Control Protocol)[ Dieses wird benutzt, um verschieden Optionen, die die PPP-Verbindung betreffen, ausgehandelt werden. ] vorhanden ist. Da sich unser Interesse nicht auf die Realisierung einer weiteren PPP-Implementierung richtet, gingen wir von festen, bereits ausgehandelten Voraussetzungen aus:
Wie jedes PPP-Modul wird anhand des Protokoll-Feldes das verwendete Protokoll erkannt. Andere Module, die ein spezielles Protokoll behandeln können, müssen sich für dieses beim PPP-Modul mit einer Callback-Routine registrieren.
Es fehlen:
Für die drei verschiedenen Pakettypen wurde auch drei verschiedene Werte für das PPP Protokoll-Feld genommen. Diese Werte sind von uns frei erfunden und wurden NICHT beim IANA registriert. Sie dienten nur für unsere Testzwecke.
Es existiert ein entscheidender Unterschied zwischen einem RTP-Mixer und einem Translator. Der Translator empfängt einen RTP-Strom und sendet ihn wieder neu aus. Jede Daten-Quelle bleibt für den Empfänger weiterhin erkennbar. Der Translator hat auch die Option, eine Formatwandlung durchzuführen. Hauptsächliches Einsatzgebiet sind Proxies für Firewalls, Multicast zu Unicast Konverter und Wandler für exotische oder nicht überall unterstützte Datenformate.
Der RTP-Mixer hingeben mischt mehre eingehende Datenquellen, und erscheint als eigener Sender. Er hat also den ganzen Aufwand, die Daten zu ordnen, Lücken zu erkennen, die Daten zu mischen, dabei eventuell das Format zu ändern etc. Er wird hauptsächlich dort eingesetzt, wo es um die Verringerung der Bandbreite geht, wenn es oft vorkommt, daß viele Quellen gleichzeitig aktiv sind.
Neben der Funktion als Proxy für die Multicast Daten zu fungieren, führt unser Translator die notwendige Formatwandlung der RTP Daten durch. In der Tabelle [formate] ist abgegeben, welche Ausgangsformate bei welchem Ziel- und Quellformat verwendet wird. Andere Formate als in der Tabelle aufgeführt werden derzeit nicht unterstützt.
| Ziel- / Quellformat | PCM µ-law | PCM A-law | GSM | LPC |
| GSM | GSM | GSM | GSM | LPC |
| LPC | LPC | LPC | LPC | LPC |
Die Beschreibung der Meßergebnisse ist in Abschnitt [messungen] enthalten.
Wenn das simulierte Netzwerkinterface ein Paket von einer unteren Schicht empfing, wurden die IP und UDP-Header wieder entfernt. Mit Hilfe der Zieladresse des IP-Headers und der Zielportnummer des UDP-Headers, wurden die Daten an exakt diese Adresse gesendet. Da diese Felder von dem Sendeteil der Implementierung auf der anderen Seite des Modems generiert wurden, bestimmte diese auch das Ziel. Insofern kommt dies Implementierung einem realen Netzwerkinterface recht nahe.
Es ist somit nötig, mit select oder poll[ select und poll sind zwei C-Funktionen unter UNIX, die es ermöglichen auf Daten und Ereignissen von mehren Filedescriptoren gleichzeitig zu warten.] zu arbeiten. Damit sich dies in der Implementierung der einzelnen Module nicht weiter berücksichtigt werden muß, implementierten wir ein weiteres Modul (Filehandler). Dieses besitzt eine Main-Loop, in der ein select ausgeführt wird. Routinen, die auf Daten eines Filedescriptors warten, müssen sich und den Filedescriptor beim Filehandler mit einer Callback-Routine registrieren. Wenn Daten für einen solchen Filedescriptor bereitstehen, ruft der Filehandler die entsprechende Callback-Routine auf.
Wie schon zu Beginn dieses Kapitels erwähnt, kann das Programm durch Eingabe eines bestimmten Zeichenwertes (CRTL/B) beendet werden. Realisiert wird dies durch eine globale Variable, mit Hilfe die Main-Loop des Filehandlers beendet werden kann.
Nachdem die oben beschriebene Testumgebung implementiert war, galt es diese zu Testen. Als erstes Testszenario versuchten wir die zu der Zeit zufälliger Weise aktive Übertragung der NASA STS-82 Space-Shuttle-Mission zu verfolgen. Wir verwendeten hierzu die in Abbildung [testImpl-2] dargestellte Umgebung.
Die RTP-Daten wurden im PCMU2 Format (40ms Frames mit PCM µ-law) gesendet. Dies entspricht 320 Bytes je Frame. Für die Komprimierung der Daten verwendeten wir GSM. Anhand von Tracinginformationen, die auf unserer Seite ausgegeben wurden waren deutliche Paketverluste zu erkennen, auch kam es vor, daß die Pakete in der falschen Reihenfolge ankamen. Unsere Implementierung verhielt sich jedoch stabil, so daß es möglich war der Übertragung zu folgen. Nach diesem ersten Test gingen wir davon aus, daß die Implementierung hinreichend arbeitet, um Messungen durchführen zu können.
Die erste Messung beschäftigte sich mit Fragestellung, wie hoch die tatsächliche benötigte ausgehende Bandbreite für unseren komprimierten RTP-Datenstrom ist. Wir sendeten hierzu von einem Windows 95 PC mit Hilfe von vat RTP-Daten (PCMU2, 40ms Frames) in das Netz. In unserer Implementierung protokollierten wir dann die Anzahl der pro Sekunde über das Netz empfangenen Bytes, und addierten den Overhead für einen einfachen IP und UDP Header (28 Bytes)[ Zur Erinnerung, in unserer Implementierung haben wir nur Zugriff auf die Nutzdaten, jedoch nicht auf den IP und UDP-Header.].
Ebenfalls wurden die Bytes gezählt, die durch die Modemverbindung jede Sekunde gesendet wurden. In Abbildung [testImpl-plot1] sind die beiden Messungen gegenübergestellt. Der eingehende Datenstrom beinhaltete 40 ms RTP Frames, mit PCM µ-law codierten Audiosamples. Für den komprimierten Datenstrom verwendeten wie die GSM Kodierung. Für die Messungen wurde ein Text vorgelesen und übertragen.
Es sind deutlich die kurzen Unterbrechungen zu erkennen, die aus den Sprechpausen resultieren. Ebenfalls gut zu erkennen ist, daß für die eingehenden Daten etwas mehr als 70 benötigt werden. Dieser gemessene Wert deckt sich auch sehr gut mit der theoretischen Betrachtung aus Abschnitt [needed-bandw] (wir ermittelten dort 72 ). Die benötigte Bandbreite zum Senden der komprimierten RTP Daten schwingt im gleichen Takt, wie die für den eingehenden Datenstrom. Im Mittel liegt sie bei ca. 15 . Zum Vergleich leiten wir uns den zu erwartenden Wert her:
| = | (GSM + IP/UDP/RTP-Header + PPP + HDLC) / 40 | |
| = | (66 + 2 + 2 + 4) / 40 | |
| = | 14,8 |
Der gemessene Wert liegt somit sehr nahe an dem zu erwartenden theoretischen Wert.
Die gleiche Messung führten wir nocheinmal durch, jedoch wurde nun die ausgehenden Daten nicht mit GSM, sondern mit LPC komprimiert. Die graphische Auswertung zeigt die Abbildung [testImpl-plot2].
Die nun benötigte Bandbreite beträgt nun nur noch ca. 7 . Setzt man anstelle der bei GSM benötigten 66 Bytes für 40 ms Audiodaten die für LPC nötigen 24 Bytes ein, so ergibt sich ein theoretischer Wert von 6,4 . Dieser Wert liegt ebenfalls dicht bei dem von uns gemessenen.
Um Messungen durchführen zu können, benötigten wir somit zwei Pakete, von denen wir wissen, daß sie direkt aufeinander folgen. Da wir jedoch nur die RTP-Daten übertrugen, und diese in einem größeren Abstand gesendet wurden, reichten diese nicht. Versuchsmessungen bestätigten dies Annahme auch. Aus diesem Grunde führten wir ein weiteres PPP-Protokoll-Paket ein. Dieses Paket wurde vor jedem eigentlichem PPP-Paket gesendet, so daß wir sicher waren, daß es die beiden Pakete auch wirklich in Folge gesendet wurden. Dieses Triggerpaket bestand nur aus der PPP-Protokollnummer ohne Daten.
Für die Bestimmung machten wir immer 100 Messungen. Gemessen wurde die Zeit die verging, vom Eintreffen des Triggerpaketes bis zum Eintreffen des nächsten PPP-Paketes. Die Messungen sind wie in Abschnitt [cum-freq] als kumulierte Häufigkeitsverteilung dargestellt (siehe Abbildung [testImpl-plot3]). Die Messungen wurden während eines realen Gespräches mit Dr. Henning Schulzrinne aufgenommen, und entsprechen somit einem real vorkommenden Datenaufkommen. Zur Erinnerung, der definierten, daß die Bandbreite, bei der das 0,5-Quartil liegt näherungsweise als die real zur Verfügung stehende Bandbreite angesehen werden kann.
Im Gegensatz zu unseren Testmessungen aus Kapitel [bandwidth] verlaufen die Kurven ein wenig linearer. Das war auch zu erwarten, da wie es bei den Testmessungen mit optimalen Verhältnissen zu tun hatten. Dennoch ist deutlich zu sehen, daß alle Meßreihen, mit zwei Ausnahmen, sehr dicht beieinander liegen. Das heißt, daß solche Messungen durchaus ein reproduzierbares Ergebnis liefern können. Die statistische Streuung der Meßergebnisse ist insofern als verhältnismäßig klein zu bezeichnen. Mit Ausnahme der beiden "Ausreißer" liegt die gemessene Bandbreite somit zwischen 17 und 20 kbit/s.
Um die Güte dieser Messungen bestimmen zu können, müssen wir zunächst jedoch die theoretisch zu erwartende Bandbreite mathematisch herleiten. Gemessen wurde die Bandbreite, die für PPP-Nutzdaten zur Verfügung steht. Es entfallen also die HDLC-Framing-Informationen (Flag und FCS), sowie das PPP-Protokoll-Feld. Übertragen wurden in der Regel 40 ms GSM Frames (66 Bytes), die zusammen mit dem komprimierten IP/UDP/RTP-Headern 68 Bytes ausmachten. Für die Framinginfomrationen fielen 2 Bytes für die HDLC Flags, 2 Bytes für das FCS Feld, und ein Byte für das komprimierte PPP-Protokoll-Feld (zusammen 5 Bytes) an.
Laut Aussage des Modems[ Bei dem von uns verwendeten US-Robotics Modem können die Parameter der letzten Verbindung mit dem Befehl ATI6 abgefragt werden.] betrug die Datenrate in der von uns gemessenen Richtung 24 . Wie bereits in Abschnitt [v42] errechnet wurde, kommen zu den zu übertragenden Daten ca. 1,6% Overhead durch bitstuffing hinzu. Die für Modemdaten zur Verfügung stehende Bandbreite Bmodembeträgt somit:
B | = | 24000 - 1,6% |
| = | 23616 |
Bei der von uns verwendeten ACCM waren 3 Werte zum Escapen maskiert. Es ergibt sich somit ein Overhead O für E gesetzte Bits in der ACCM von:
O | = | (E + E + E) / 256 |
| = | (3 + 1 + 1) / 256 = .01953 | |
| O(n) | = | .01953 * n |
Übertragen wurden immer Frames mit 68 + 5 Bytes, so daß sich die theoretische Bandbreite B ergibt zu:
B | = | 68 / (68 + 5 + O(68 + 5)) * 23616 |
| = | 21,6 |
Die Bandbreite, die unser vorgestelltes Meßverfahren ermittelte, lag mit ca. 18,5 um ca. 15% niedriger, als die theoretisch zu erwartende.
Durch die Integrierung von Timern an verschiedenen Stellen waren wir in der Lage, die verschiedenen Messungen durchzuführen. So konnten wir die resultierende benötigte Bandbreite für den ausgehenden Datenstrom in Relation zum eingehenden betrachten. Wie zu erwarten zeigte sich eine nahezu proportionale Verringerung der benötigten Bandbreite. Durch die Konvertierung der eingehenden IP/UDP/RTP-Daten, konnte die benötigte Bandbreite bei PCM µ-law auf ca. 21% verringert werden, wenn GSM, sowie IP/UDP/RTP-Header-Komprimierung eingesetzt wurden. Bei der Verwendung von LPC, verringerte sie sich sogar auf ca. 10%.
Mit Hilfe dieses Verfahrens ist es somit möglich, ausgesendete RTP-Datenströme aus dem INTERNET über eine Verbindung mit niedriger Bandbreite transparent zu übertragen. Eine Modemverbindung erwies sich dabei als durchaus brauchbar.
Weiterhin konnten wir durch Messungen zeigen, daß unser entwickeltes Verfahren zur Bestimmung der zur Verfügung stehenden Bandbreite sehr gute Ergebnisse liefert. Durch geeignetes Koppeln dieser beiden Komponenten müßte es somit auch möglich sein, das RTP-Datenformat entsprechend der gemessenen Bandbreite dynamisch anzupassen.