Institut für Kommunikationsnetze und Rechnersysteme - Universität ...

– 112 –
und HTTP-Version evtl. mehrere parallele TCP-Verbindungen aufgebaut. Außerdem können
die eingebetteten Objekte erst angefordert werden, nachdem die Grundseite zumindest teilweise
geladen worden ist. Schließlich sind die heutigen Browser in der Lage, bereits Teile
einer Seite oder auch eines darin eingebetteten Bildes darzustellen, bevor der Ladevorgang
abgeschlossen ist, sodass sich die Zeiten für Datentransfer und Darstellung überlappen. Dies
wirft auch Schwierigkeiten bei der genauen Definition der Reaktionszeit auf. Enthält die Seite
z. B. viele Bilder, ist auch die Zeit bis zur Darstellung des Textes ohne Bilder bereits eine
wichtige Größe.
Wie bei den einfachen Modellen für dynamischen TCP-Verkehr können auch hier neben absoluten
Metriken wieder von der Erwartungshaltung des Nutzers abhängige relative Maße zum
Einsatz kommen. In [64] werden verschiedene Erweiterungen für den in Abschnitt 4.3.2.2 präsentierten
Fun Factor vorgeschlagen. Die Definitionen enthalten als Bezugsgrößen neben der
minimalen Transferzeit auch vom Nutzer erwartete Werte für die Verzögerung beim Verbindungsaufbau.
4.3.3 Kenngrößen für Echtzeitverkehr
Ähnlich wie bei elastischem Verkehr geben auch bei Echtzeitanwendungen die grundlegenden
Maße der Paketebene noch kein klares Bild über die letztendlich vom Nutzer wahrgenommene
Dienstgüte. Allerdings ist deren Aussagekraft allgemein größer als bei Anwendungen, die
elastischen Verkehr produzieren. Dies gilt zumindest, solange man auf die Betrachtung adaptiver
Anwendungen, wie sie z. B. in [246] beschrieben werden und bei denen eine Anpassung
der Bandbreite an den Netzzustand erfolgt, verzichtet.
Multimedia-Applikationen erzeugen auf der Senderseite einen kontinuierlichen Datenstrom,
der im einfachsten Fall aus Paketen konstanter Länge besteht, die zu äquidistanten Zeitpunkten
t 0 , t 0
+ ∆t , t 0
+ 2∆t , … gesendet werden (Bild 4.8). Beim Empfänger wird zur Synchronisation
der Daten ein Ausspielpuffer (playout buffer) verwendet, um Verzögerungsschwankungen
im Netz auszugleichen und ein Ausspielen zu äquidistanten Zeitpunkten zu ermöglichen. 11
Dies bedeutet, dass das Paket mit der Sequenznummer i , das zum Zeitpunkt
t S () i = t 0
+ i ⋅ ∆t beim Sender erzeugt wurde, zu einem um einen konstanten Wert verschobenen
Zeitpunkt t P () i = t S () i + d P = t 0 + i ⋅ ∆t + d P ausgespielt, d. h. in ein Audio- oder
Videosignal umgewandelt wird. Die zeitliche Verschiebung d P wird dabei als Ausspielverzögerung
(playout delay) bezeichnet. Ist eine Ausspielverzögerung festgelegt, kann der Empfänger
den Ausspielzeitpunkt mit Hilfe der über RTP mitgelieferten Zeitstempel und einer über
NTP (network time protocol) synchronisierten Uhr bestimmen. Ein Ausspielen kann jedoch
nur erfolgen, wenn das Paket spätestens zum Zeitpunkt t P () i beim Empfänger eingetroffen ist
11 Dies gilt zumindest für Audioanwendungen. Bei Videoapplikationen ist teilweise die Reihenfolge innerhalb
eines Rahmens nicht maßgeblich. Doch auf Rahmenebene erfolgt auch hier i. d. R. eine Synchronisation.