Robert Chodorek
Katedra Telekomunikacji
Akademia Górniczo-Hutnicza
Poznañskie Warsztaty 2003
Al. Mickiewicza 30, 30-059 Kraków
Telekomunikacyjne
Agnieszka Chodorek
Poznañ 11-12 grudnia 2003
Zakład Telekomunikacji i Fotoniki
Politechnika Świętokrzyska
Al. 1000-lecia Państwa Polskiego 7, 25-314 Kielce
ANALIZA SYMULACYJNA WYDAJNOŚCI PROTOKOŁU RTP
REALIZUJĄCEGO USŁUGĘ MULTIKASTOWĄ TYPU SSM
Streszczenie: W referacie została zaprezentowana analiza W referacie przedstawiono analizę protokołu RTP
symulacyjna protokołu RTP przeprowadzona w środowis-przeprowadzoną w środowisku symulacyjnym ns-2.
ku symulatora zdarzeniowego ns-2. Przeanalizowano Rozdział 2 referatu prezentuje model symulacyjny proto-przypadek protokołu RTP realizującego transmisję kołu RTP. Rozdział 3 omawia eksperyment symulacyjny.
multikastową typu SSM.
Rozdział 4 prezentuje analizę jakości multikastowej transmisji wideo typu SSM realizowanej z
1. WSTĘP
wykorzystaniem protokołu RTP.
Multikastowy protokół RTP ( Real-time Transport
2. MODEL SYMULACYJNY PROTOKOŁU RTP
Protocol) [2] jest, obok TCP i UDP, jednym z
najczęściej stosowanych protokołów transportowych
Rozdział prezentuje symulator ns-2 oraz modele współczesnego Internetu. Jest on przeznaczony do trans-symulacyjne protokołów RTP i RTCP.
misji danych multimedialnych w czasie rzeczywistym.
Jego zastosowania obejmują m.in. interaktywne usługi 2.1. Symulator ns-2
audio i (lub) wideo oraz dystrybucję danych audio i (lub) wideo. Protokół RTP posiada mechanizmy pozwalające
Dyskretny symulator zdarzeniowy sieci
na identyfikację rodzaju przesyłanych danych (audio, komputerowych ns-2 [1] został opracowany na wideo) oraz identyfikację metody kodowania danych
Uniwersytecie w Berkeley w ramach programu VINT.
(PCM, ADPCM, MPEG-4 i inne). Obecnie Dostarcza on narzędzi do symulacji wielu protokołów, wykorzystywana jest wersja 2 protokołu RTP,
jak np. IP (IPv4, IPv6), TCP, UDP, RTP, HTTP, FTP.
zdefiniowana w 1996 roku [3] i rozszerzona w lipcu
Pozwala na symulację mechanizmów zapewnienia
2003 [2] o nowe algorytmy sterowania transmisją
gwarantowanej jakości usług sieciowych QoS i
multimedialną do dużych grup odbiorców.
zapobiegania przeciążeniom. Symulator ns-2 wspiera Protokół RTP samodzielnie nie realizuje wszyst-wiele technologii sieciowych, takich jak sieci lokalne, kich funkcji warstwy transportowej. Do multipleksacji i rozległe, optyczne, bezprzewodowe, itd.
detekcji błędów wykorzystuje protokół UDP, tworząc
Ns-2 jest symulatorem obiektowym, napisanym w wraz z nim stos protokołowy RTP/UDP. Do sterowania
języku C++ oraz w języku skryptowym Otcl ( Object transmisją realizowaną przez protokół RTP służy
Tool Command Language) stanowiącym interfejs protokół RTCP ( RTP Control Protocol). Protokół ten programowy użytkownika. Modele symulacyjne zwykle
stanowi integralną część specyfikacji RTP i spełnia są budowane z użyciem obu tych języków, przy czym
cztery podstawowe funkcje: (1) monitorowanie jakości modele mechanizmów przetwarzania protokołowego
transmisji danych, (2) identyfikacja źródła informacji, zazwyczaj są pisane w C++. Topologia sieci i parametry (3) skalowanie sesji multikastowej, (4) przenoszenie symulacji zazwyczaj są definiowane w języku Otcl,
dodatkowych informacji kontrolnych sesji (funkcja
dlatego klasy C++ znajdują swoje ścisłe
opcjonalna). Każda transmisja RTP posiada skojarzoną z odzwierciedlenie w hierarchii obiektów Otcl.
nią transmisję RTCP. W systemach konferencyjnych, w Modele symulacyjne protokołów warstwy
których przesyłanych jest niezależnie kilka rodzajów transportowej są reprezentowane w środowisku ns-2
mediów (np. audio i wideo), każdy strumień składowy przez obiekty potomne bazowej klasy Agent. Klasie tej RTP posiada własny strumień RTCP, co pozwala na
odpowiada klasa Agent języka Otcl. Klasa Agent indywidualne sterowanie transmisją każdego strumienia.
realizuje symulację procesów tworzenia, nadawania i odbioru pakietów.
Praca naukowa finansowana ze środków Komitetu
Badań Naukowych w latach 2003-2005 jako projekt
badawczy nr 4 T11D 015 24.
2.2. Model symulacyjny protokołu RTP
języka C++ odpowiada klasa Session/RTP. Nazwy
RTPSession i Session/RTP pochodzą od sesji RTP
Model symulacyjny protokołu RTP jest w całości
(nie zaś od warstwy sesji modelu OSI), która to sesja jest realizowany w oparciu o klasę Agent języka C++ i nadzorowana i sterowana przez protokół RTCP. Klasa
odpowiadającą jej klasę Agent języka Otcl. Model ten Session/RTP nie zezwala na ustawienie żadnych
jest modelem symetrycznym; część nadawcza (nadajnik parametrów specyficznych dla RTCP. Przegląd
RTP) i odbiorcza (odbiornik RTP) są realizowane jako parametrów specyficznych dla klasy Agent/RTCP
jeden wspólny obiekt potomny klasy Agent. Obiekt ten został zamieszczony w Tab. 2.
nosi nazwę RTPAgent, a jego odpowiednikiem w hierarchii obiektów Otcl jest klasa Agent/RTP. Symet-Tab. 2. Parametry modelu symulacyjnego
ria modelu symulacyjnego wynika z założeń protokołu protokołu RTCP
RTP: żaden system końcowy nie jest uprzywilejowany, a każdy z nich może, w dowolnej chwili czasu, pełnić
Wartość
Parametr
Opis
funkcję zarówno nadajnika, jak i odbiornika.
domyślna
numer sekwencyjny
seqno_
0
Tab. 1. Parametry modelu symulacyjnego protokołu RTP
raportu RTCP
przedział czasu pomiędzy
interval_
Wartość
0
Parametr
Opis
raportami RTCP
domyślna
załączenie/wyłączenie
numer sekwencyjny
seqno_
0
random_
0
randomizacji przedziału
pakietu RTP
czasu interval_
przedział czasu pomiędzy
interval_
3,75 ms
generowanymi pakietami
Model symulacyjny protokołu RTCP jest modelem
załączenie/wyłączenie
symetrycznym. Każdy agent protokołu RTCP może
randomizacji czasu
random_
0
generować zarówno raporty odbiornika, jak i nadajnika.
pomiędzy kolejnymi
Rodzaj wygenerowanego raportu zależy od funkcji, jaką generowanymi pakietami
w danej chwili pełni skojarzony z nią agent RTP.
rozmiar (w bajtach)
packetSize_
210
pakietu RTP
2.4. Symulacja transmisji RTP
maxpkts_
228
maksymalna liczba
generowanych pakietów
Symulacja transmisji RTP wymaga podłączenia do
węzła (reprezentującego warstwy 1-3 modelu OSI, wraz Model symulacyjny protokołu RTP posiada szereg
z protokołem IP) zarówno modelu protokołu RTP, jak i parametrów dziedziczonych po klasie Agent (adres IP
protokołu RTCP. Jawne podłączanie obu protokołów
źródła agent_addr_, numer portu źródłowego
pozwala, w razie potrzeby, na uproszczenie modelu
agent_port_, adres IP miejsca przeznaczenia
symulacyjnego transmisji. Analiza ogranicza się
datagramu dst_addr_, numer portu przeznaczenia
wówczas do zjawisk występujących w protokole RTP, z dst_port_, itd.). Parametry te są wykorzystywane
pominięciem elementów zarządzania sesją. Takie
przez wewnętrzne procesy symulacji. Mogą być one
podejście znajduje zastosowanie np. w przypadku badań konfigurowane z poziomu skryptu tcl.
wydajności protokołu na jednym kierunku transmisji.
Model symulacyjny protokołu posiada również
W przeciwieństwie do realnego RTP, model
parametry specyficzne dla klasy Agent/RTP. Lista tych symulacyjny protokołu realizuje multipleksację
parametrów wraz z opisem i wartością domyślną
przesyłanych strumieni zgodną z UDP. Nie ma zatem
(początkową dla każdej symulacji) została zamieszczona potrzeby stosowania dodatkowych modułów pomiędzy
w Tab. 1. Parametry specyficzne dla klasy Agent/RTP
RTP a węzłem, co znacznie przyspiesza symulację.
są konfigurowalne z poziomu skryptu tcl.
Rys. 1 przedstawia fragment przykładowego skryp-
tu symulacyjnego, powołującego dwie nowe instancje
2.3. Model symulacyjny protokołu RTCP
protokołu RTP ( rtp 1 i rtp 2), po czym dołącza je do (uprzednio utworzonych) węzłów n 1 i n 2. Metoda Protokół RTCP dostarcza mechanizmów warstwy
connect (Rys. 1a) konfiguruje adresację (dokładniej: sesji, stąd też w skład modelu symulacyjnego wchodzą numery węzłów docelowych i numery portów
(obok obiektów potomnych klasy Agent) obiekty przeznaczenia) systemów końcowych dla transmisji
potomne bazowej klasy Session. Model symulacyjny punkt-punkt. W przykładzie podanym na Rys. 1a,
protokołu RTCP jest realizowany dwutorowo:
obydwie stacje są nadajnikami i odbiornikami RTP.
• mechanizmy przetwarzania protokołowego są
Symulacja transmisji multikastowej (Rys. 1b)
zawarte w klasie RTCPAgent (dziedziczącej po wymaga powołania grupy multikastowej (tu: o adresie klasie Agent),
przypisanym do zmiennej grupa) oraz konfigurowania
• mechanizmy zarządzania sesją RTP są zawarte w
adresacji systemów nadawczych. Jest to realizowane
klasie RTPSession (dziedziczącej po klasie Session).
poprzez ustawienie parametrów dst_addr_ i
Klasie RTCPAgent języka C++ odpowiada klasa dst_port_ właściwego agenta RTP. W przykładzie
Agent/RTCP języka Otcl, natomiast klasie RTPSession danym na Rys. 1b, obydwie stacje są nadajnikami RTP.
szczególnie istotna w systemach radia internetowego i telewizji internetowej, gdzie w sposób naturalny
set rtp1 [new Agent/RTP]
zabezpiecza przed transmisją pochodzącą od
set rtp2 [new Agent/RTP]
nieautoryzowanych źródeł (tzw. „spamem”).
$ns attach-agent $n1 $rtp1
$ns attach-agent $n2 $rtp2
odb 1
$ns connect $rtp1 $rtp2
100 Mb/s
B
1
(b)
1 µs
τ1
odb 2
…
R1
R2
set grupa [Node allocaddr]
nad 1
B 21, B 22, …, B 2 N
set rtp1 [new Agent/RTP]
τ
21, τ22, …, τ2 N
set rtp2 [new Agent/RTP]
odbN
Rys. 2. Topologia wykorzystywana podczas symulacji.
$ns attach-agent $n0 $rtp1
$ns attach-agent $n1 $rtp2
Przedstawiona w referacie analiza symulacyjna
$rtp1 set dst_addr_ $grupa
protokołu RTP obejmowała zagadnienia multimedial-
$rtp1 set dst_port_ 0
nych połączeń multikastowych typu SSM. Analiza
$rtp2 set dst_addr_ $grupa
została przeprowadzona w oparciu o topologię
$rtp2 set dst_port_ 0
zamieszczoną na Rys. 2. Topologia ta wykorzystywana była do testowania połączenia multikastowego typu
SSM, w którym nad 1 rozsyła dane do odbiorników odb 1, (c)
odb 2, …, odbN. W skład analizowanego systemu $ns at 0.5 \
wchodzą (Rys. 2): węzeł nadawczy ( nad 1), dwa węzły
"$n0 join-group $rtp1 $grupa"
pośredniczące (rutery R 1, R 2) oraz N węzłów $ns at 0.5 \
odbiorczych ( odb 1, odb 2, …, odbN). Węzeł nadawczy
"$n1 join-group $rtp2 $grupa"
posiada teoretycznie nieskończony bufor (1000
pakietów) i połączony jest z ruterem R 1 łączem o przepustowości 100 Mb/s i opóźnieniu propagacyjnym 1
Rys. 1. Powołanie dwóch nowych instancji agentów RTP
µs. Pojemności buforów węzłów R 1 i R 2 są równe 150
i konfiguracja transmisji: a) punkt-punkt (typu unicast), pakietów. Ruter R 1 połączony jest z następnym w b) multikastowej, c) uzupełnienie harmonogramu
kolejności systemem R 2 łączem o przepustowości B 1 i eksperymentu o dołączenie systemów końcowych do
opóźnieniu τ1 (wartości domyślne tych parametrów:
grupy multikastowej.
B 1 = 10 Mb/s, τ1 = 2,5 ms). Ruter R 2 jest połączony z i-tym odbiornikiem łączem o przepustowości B 2 i i Aby odbierać dane rozsyłane na adres grupy
opóźnieniu τ2 i (wartości domyślne: B 2 i = 10 Mb/s, multikastowej, stacje muszą w sposób jawny dołączyć się τ2 i = 2,5 ms, i = 1, 2, … N).
do grupy. Rys. 1c przedstawia fragment skryptu języka Eksperyment zakładał realizację transmisji wideo
tcl, uzupełniającego harmonogram eksperymentu o MPEG-4 o częstotliwości generowania ramek 25 Hz.
dołączenie obydwu stacji do grupy multikastowej (po Każda transmisja trwała 5 minut (300 sekund), po czym czasie 0.5 s, licząc od chwili rozpoczęcia symulacji).
następował 500-minutowy okres oczekiwania na
Podłączanie protokołu RTCP realizowane jest w
opóźnione pakiety. Transmisja wideo wykorzystywała
sposób analogiczny. Należy przy tym pamiętać, iż
rzeczywiste przebiegi ruchu wideo MPEG-4 lub była
(niezgodnie ani z RFC 1889 [3], ani z RFC 3550 [2]) modelowana jako ruch o stałej prędkości bitowej (CBR) w symulatorze ns-2 obydwa protokoły powinny nadawać 2 Mb/s (rozmiar ramki wideo: 10 000 B). Rzeczywiste pakiety na adres dwóch różnych grup multikastowych.
przebiegi ruchu MPEG-4 pochodzą z publicznie dostęp-Wynika to z ograniczeń modelu węzła multikastowego
nych plików [5] o wysokiej jakości obrazu oryginalnego.
zaimplementowanego w symulatorze ns-2.
Do celów analizy zostały wybrane przebiegi: star – film
„ Gwiezdne wojny” (średni rozmiar ramki xśr = 1618 B; 3. EKSPERYMENT SYMULACYJNY
maksymalny rozmiar ramki x max = 9370 B; odchylenie
standardowe δ = 1231), vclips – wideoklip ( xśr = 5333 B; Wprowadzenie protokołów IGMPv3 i MLDv2
x max = 13568 B; δ = 1943), cam – film pochodzący z umożliwiło filtrację
źródeł za pomocą filtrów kamery monitorującej parking ( xśr = 4539 B; włączających i wykluczających. Udostępniło tym samym x max = 13535 B; δ = 2690). Wyrażenia podane w usługę SSM (ang. Source-Specific Multicast) transmisji nawiasach dotyczą próby 7500 ramek (pierwsze 5 minut multikastowej, zezwalająca na transmisję od dokładnie materiału filmowego). Charakterystyki statystyki
jednego źródła. Usługa ta, której podstawowe założenia opisowej opracowane dla całości materiału filmowego przedstawiono w RFC 3569 [4] z lipca 2003 roku, jest można znaleźć w [5].
4. ANALIZA SYMULACYJNA WYDAJNOŚCI
PROTOKOŁU RTP
0.025
Eksperyment symulacyjny miał na celu realizację
0.02
badań wpływu zmian parametrów protokołu RTP
(rozmiar pakietu RTP) oraz sieci (przepustowość, opóź-
nienie propagacyjne) na jakość transmisji ruchu wideo 0.015
źnienie [s]
(przepływność, opóźnienie, wariancja opóźnienia,
straty). Zrealizowano badania wydajności połączenia opó
multikastowego typu SSM realizowanego przez protokół
0.01
RTP.
Analiza symulacyjna wydajności połączeń multi-
0.005
kastowych RTP została przeprowadzona w łączu nieob-
4
0
2000
4000
6000
8000
1 .10
ciążonym dodatkowym ruchem. Badania obejmowały
rozmiar pakietu [B]
szacowanie zmian parametrów jakościowych transmisji Rys. 3.Średnie opóźnienie transmisyjne pakietu w funkcji wideo w funkcji długości pakietu RTP, opóźnienia pro-rozmiaru pakietu p, wyznaczone w odbiorniku odb 3
pagacyjnego oraz przepustowości łącza.
( i = 3) dla ruchu CBR (x) oraz materiałów filmowych: star (+), vclips ( ), cam (o).
4.1. Badania jakości transmisji wideo przy różnych długościach pakietu RTP p
5
2 .10
Badania jakości transmisji wideo przy różnych
długościach pakietu RTP p prowadzone były dla domyślnych wartości parametrów B 1, B 2 i, τ1 i τ2 i, źnienia [s]
i = 1, 2, …, N. System przeanalizowano dla przypadku 5
1 .10
N = 1 i N = 5 odbiorników multikastowych. Rozmiar pakietu p protokołu RTP zmieniany był w zakresie od 100 B do 10 000 B, przy czym największy nacisk riancja opóa
położono na wartości p z zakresu od 100 do 500 bajtów.
w
Badania wykazały, że w systemie nie występowały
straty pakietów, a uzyskane przebiegi miar jakości
4
transmisji w funkcji rozmiaru pakietu p pokrywały się 0
2000
4000
6000
8000
1 .10
rozmiar pakietu [B]
dla każdego z 5 odbiorników multikastowych. Nie
zaobserwowano również różnic pomiędzy wynikami
Rys. 4.Wariancja opóźnienia transmisyjnego pakietu w uzyskanymi dla N = 1
i
N = 5
odbiorników
funkcji rozmiaru pakietu p; oznaczenia – jak na Rys. 3.
multikastowych.
Dla analizowanych warunków pracy, system
Narzut wnoszony przez nagłówki niweluje tutaj
zachowywał się bardzo stabilnie w całym zakresie zmian korzyści wynikające z niewielkich wielkości pakietów, parametru p. Osiągana przepływność (liczona dla danych nie usuwa jednakże skutków ubocznych. Bardzo małym
przenoszonych przez protokół RTP, z pominięciem
rozmiarom pakietów towarzyszy zatem znaczny wzrost
narzutu wnoszonego przez nagłówki), wynikała tylko ze fluktuacji opóźnienia. Wraz ze wzrostem rozmiaru
średniej długości ramki wideo w badanym materiale
pakietu fluktuacje te początkowo maleją, aż do
filmowym i nie zależała w żadnym stopniu od rozmiaru osiągnięcia minimum (dla ruchu CBR rozmiar pakietu
pakietu RTP. Ze względu na dużą względną
jest równy wówczas rozmiarowi ramki wideo). Wraz z
przepustowość łączy (w stosunku do prędkości bitowej dalszym wzrostem p krzywa narasta, osiągając nasycenie ruchu wideo), ruch RTCP praktycznie nie wpływał na
w pobliżu x max. Wariancja opóźnienia jest wtedy liniowo przepływność RTP.
zależna od wariancji ramek wideo.
Rozmiar pakietów RTP ma wpływ zarówno na
średnie opóźnienie transmisyjne pakietu (Rys. 3), jak i na 4.2. Badania jakości transmisji wideo przy różnych wariancję opóźnienia (Rys. 4). Zjawisko to wynika z wartościach czasu RTT
niejednorodnego charakteru opóźnienia transmisyjnego, na które składają się czasy: propagacji, nadawania i Badania jakości transmisji wideo przy różnych
buforowania. Najmniejsze opóźnienia transmisyjne
wartościach czasu RTT prowadzone były dla domyślnej obserwowane były dla małych pakietów, rzędu 200 ( star) wartości parametru B 1 oraz B 2 i, i = 1, 2, …, N. Rozmiar do 300 bajtów ( cam), jednakże towarzyszyła im pakietu RTP wynosił 200 B. Do analiz przyjęto
stosunkowo duża wariancja opóźnienia (CBR: 7.27⋅10-6, nominalną wartość czasu RTT, równą podwojonemu
star: 1.15⋅10-6, vclips: 3.922⋅10-6, cam: 7.309⋅10-6). Dla całkowitemu czasowi propagacji τ w systemie. Wartość bardzo małych i dużych pakietów RTP opóźnienia rosną.
nominalna stanowi jednocześnie kres dolny
W przypadku bardzo małych pakietów, jest to spowodo-rzeczywistego czasu RTT pakietu znajdującego się w
wane głównie wzrostem udziału stałych nagłówków
systemie. System przeanalizowano dla przypadku N = 1 i RTP/UDP/IP w całkowitym rozmiarze pakietu.
N = 5 odbiorników multikastowych, dla których czas
τ =1 µs + τ
0.332%) dla każdego z badanych materiałów filmowych 1 + τ21 = … = 1 µs +τ1 + τ2N
zmieniany był w zakresie od 1 ms do 1 s, co dawało
i jest niezauważalna na wykresie.
zmiany czasu RTT równe 2⋅τ.
Jak można się było spodziewać, średnie opóźnienie
transmisyjne pakietów RTP jest silnie zależne od
wartości czasu RTT (Rys. 6). W przypadku mniejszych 6
wartości RTT, wyraźnie widoczny jest również wpływ
2 .10
czasów propagacji i buforowania, co skutkuje stałą
wartością wariancji opóźnienia w dużym zakresie zmian 6
1.5 .10
RTT (Rys. 7). W miarę wzrostu RTT wpływ tych czasów
[b/s]ść
maleje, dla dużych RTT nawet znacznie. Dzięki temu
on
6
wykres średnich opóźnień w funkcji RTT można
1 .10
wówczas (z dokładnością do kilku procent) przybliżyć zależnością liniową (o współczynniku kierunkowym
5
przepływ
5 .10
równym 2), a wariancja opóźnienia traci stały charakter i zaczyna narastać.
Również i w tym przypadku badania wykazały, że
3
1 .10
0.01
0.1
1
10
w systemie nie występowały straty pakietów. Uzyskane czas RTT [s]
przebiegi miar jakości transmisji w funkcji RTT
pokrywały się dla każdego z odbiorników multikasto-
Rys. 5. Przepływność protokołu RTP w funkcji czasu
wych, niezależnie, czy należał on do systemu złożonego RTT; oznaczenia – jak na Rys. 3.
z N = 1 czy N = 5 odbiorników.
10
4.3. Badania jakości transmisji wideo przy różnych wartościach przepustowości łącza B2 i
3
1 .10
0.01
0.1
1
10
Badania transmisji wideo przy różnych wartościach
przepustowości łącza B 2 i prowadzone były dla 2000.1
źnienie [s]
bajtowych pakietów RTP, w systemie o parametrach:
B
opó
1 = 100 Mb/s,
τ1 = 1 µs, τ2 i = 5 ms, i = 1, 2, …, N.
0.01
Podobnie, jak poprzednio, system przeanalizowano dla przypadku N = 1 i N = 5 odbiorników multikastowych, pracujących w symetrycznym drzewie dystrybucji, dla 3
1 .10
których przepustowości B 2 i były sobie równe i wynosiły B. Wartość B była zmieniana w zakresie od 100 kb/s do czas RTT [s]
2700 kb/s, z krokiem 100 kb/s, co umożliwiło stworzenie Rys. 6. Średnie opóźnienie transmisyjne pakietu RTP w
„wąskiego gardła”, które nie jest zdolne do przeniesienia funkcji czasu RTT; oznaczenia – jak na Rys. 3.
ramki wideo w czasie rzeczywistym.
W badanym systemie wzrost przepustowości łącza
4
3
1 .10
1 .10
0.01
0.1
1
10
pociąga za sobą proporcjonalny wzrost przepływności RTP (Rys. 8), co jest spowodowane zmniejszającymi się stratami pakietów (Rys. 9). Przepływność protokołu RTP
stabilizuje się na poziomie średniej prędkości bitowej źnienia [s]
źródła. Dalsze zwiększanie przepustowości łącza nie 5
1 .10
wpływa na przepływność protokołu RTP. Przepustowość graniczna łącza, przy której przepływność protokołu osiąga maksimum, znajduje się powyżej średniej
riancja opóaw
prędkości bitowej źródła i w dużej mierze zależy od parametrów statystycznych ruchu. Przykładowo, dla
6
ruchu CBR wynosi ona ok. 2.5 Mb/s, co wynika z
1 .10
prędkości bitowej źródła CBR (2 Mb/s), narzutu
czas RTT [s]
wnoszonego przez nagłówki RTP/UDP/IP (20%) oraz
ruchu RTCP (5%).
Rys. 7. Wariancja opóźnienia transmisyjnego pakietu Charakterystyka wartości względnej strat pakietów
RTP w funkcji czasu RTT; oznaczenia – jak na Rys. 3.
w funkcji przepustowości łącza (Rys. 9) jest krzywą nierosnącą, która dla dużych przepustowości stabilizuje Podobnie, jak poprzednio, dla analizowanych
się na poziomie zera. Opadająca część krzywej ma
warunków pracy system zachowuje się bardzo stabilnie charakter liniowy dla ruchu CBR oraz dla ruchu o
w całym zakresie zmian τ1 (Rys. 5). Osiągana przepływ-zmiennej prędkości bitowej (VBR) generowanego na
ność transmisji RTP praktycznie nie zależy od czasu bazie materiału filmowego o małej dynamice ( cam).
RTT. Maksymalna zaobserwowana różnica przepływ-
W przypadku ruchu VBR generowanego na bazie
ności, wynikająca z różnicy opóźnienia propagacyjnego
∆τ
materiału filmowego o dużej dynamice ( star, vclips), 1 = 103 ms – 1 ms = 999 ms,
wyniosła 0.00332 (tj.
10
2 .10
5
6
6
6
6
6
[b/s]
0
5 .10
1 .10 1.5 .10
2 .10 2.5 .10
3 .10
śćon
6
1 .10
0.1
źnienie [s]
opó
przepływ
0.01
3
1 .10
5
6
6
6
6
6
0
5 .10
1 .10
1.5 .10
2 .10
2.5 .10
3 .10
przepustowość [b/s]
przepustowość [b/s]
Rys. 8. Przepływność protokołu RTP w funkcji
Rys. 10. Średnie opóźnienie transmisyjne RTP w funkcji przepustowości łącza; oznaczenia – jak na Rys. 3.
przepustowości łącza; oznaczenia – jak na Rys. 3.
1
5
6
6
6
6
6
0.9
0
5 .10
1 .10 1.5 .10 2 .10 2.5 .10 3 .10
0.8
0.1
0.7
0.6
źnienia [s]
0.01
0.5
0.4
3
1 .10
lędne straty pakietów
0.3
g
ariancja opó
0.2
4
wz
w 1 .10
0.1
5
1 .10
5
6
6
6
6
6
0
5 .10
1 .10
1.5 .10
2 .10
2.5 .10
3 .10
przepustowość [b/s]
przepustowość [b/s]
Rys. 9. Względne straty pakietów RTP w funkcji
Rys. 11. Wariancja opóźnienia transmisyjnego w funkcji przepustowości łącza; oznaczenia – jak na Rys. 3.
przepustowości łącza; oznaczenia – jak na Rys. 3.
charakterystyka strat początkowo opada liniowo (do
małe pakiety są niekorzystne ze względu na wzrost
przepustowości bliskich średniej prędkości bitowej
wariancji opóźnienia. Na znaczny wzrost wariancji
źródła), a następnie wolniej, długo utrzymując się na opóźnienia wpływają również czasy RTT powyżej
poziomie kilku procent.
300 ms. Z tych samych powodów należy unikać pracy
Średnie opóźnienie transmisyjne w analizowanym
systemu na granicy przepustowości gwarantujących
systemie (Rys. 10), obserwowane dla małych wartości zerowe straty. Nawet, jeżeli w systemie nie występują przepustowości łącza, jest silnie zależne od czasu
straty pakietów lub straty te są niewielkie (rzędu
buforowania. Gwałtowana zmiana opóźnienia transmi-
pojedynczych %), dla niektórych materiałów filmowych syjnego obserwowana dla ruchu CBR i VBR o małej
mogą w tym obszarze pracy wystąpić duże fluktuacje
dynamice obrazu ruchomego ( cam) odpowiada punktowi opóźnienia transmisyjnego.
nieciągłości odcinkowo-liniowej charakterystyki strat.
Dla ruchu VBR o dużej dynamice obrazu ruchomego
SPIS LITERATURY
( star, vclips) zmiany te są znacznie łagodniejsze.
Spadkowi opóźnienia towarzyszy zwykle spadek
[1] K. Fall, K. Vradhan, „ The ns Manual”, URL
wariancji opóźnienia (Rys. 11), chociaż dla części
http://www.isi.edu/nsnam/ns/doc/ns_doc.pdf.
materiałów filmowych ( cam, vclips) jest obserwowany
[2] H. Schulzrinne, S. Casner, R. Frederick, V.
wzrost wariancji opóźnienia dla przepustowości łącza Jacobson, „RTP: A Transport Protocol for Real-bliskich średniej prędkości bitowej źródła.
Time Applications”, RFC 3550. July 2003.
[3] H. Schulzrinne, S. Casner, R. Frederick, V.
5. ZAKOŃCZENIE
Jacobson, „RTP: A Transport Protocol for Real-
Time Applications”, RFC 1889, January 1996.
Badania jakości wykazały, że multikastowa
[4] S. Bhattacharyya ( red.), „An Overview of Source-transmisja wideo typu SSM, realizowana z
Specific Multicast (SSM)”, RFC 3569, July 2003.
wykorzystaniem protokołu RTP, jest stabilna w szerokim
[5] F.H.P. Fitzek, M. Reisslein, „MPEG-4 and H.263
zakresie zmian rozmiarów pakietów i RTT. Ze względu Video Traces for Network Performance
na wymaganie niewielkiego opóźnienia, korzystniejsze Evaluation”, IEEE Network, Vol. 15, No. 6,
jest stosowanie mniejszych pakietów, chociaż bardzo November/December 2001.