Robert Chodorek, Agnieszka Chodorek ANALIZA SYMULACYJNA WYDAJNOŚCI PROTOKOŁU RTP REALIZUJĄCEGO USŁUGĘ MULTIKASTOWĄ TYPU SSMAkademia Górniczo-Hutnicza/Katedra Telekomunikacji

Robert Chodorek Katedra Telekomunikacji Akademia Górniczo-Hutnicza Al. Mickiewicza 30, 30-059 Kraków

Agnieszka Chodorek

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 symulacyjna protokołu RTP przeprowadzona w środowis-ku symulatora zdarzeniowego ns-2. Przeanalizowano przypadek protokołu RTP realizującego transmisję multikastową typu SSM.

1. WSTĘP

Multikastowy protokół RTP (Real-time Transport Protocol) [2] jest, obok TCP i UDP, jednym z najczęściej stosowanych protokołów transportowych współczesnego Internetu. Jest on przeznaczony do trans-misji danych multimedialnych w czasie rzeczywistym. Jego zastosowania obejmują m.in. interaktywne usługi audio i (lub) wideo oraz dystrybucję danych audio i (lub) wideo. Protokół RTP posiada mechanizmy pozwalające na identyfikację rodzaju przesyłanych danych (audio, wideo) oraz identyfikację metody kodowania danych (PCM, ADPCM, MPEG-4 i inne). Obecnie wykorzystywana jest wersja 2 protokołu RTP, zdefiniowana w 1996 roku [3] i rozszerzona w lipcu 2003 [2] o nowe algorytmy sterowania transmisją multimedialną do dużych grup odbiorców.

Protokół RTP samodzielnie nie realizuje wszyst-kich funkcji warstwy transportowej. Do multipleksacji i detekcji błędów wykorzystuje protokół UDP, tworząc wraz z nim stos protokołowy RTP/UDP. Do sterowania transmisją realizowaną przez protokół RTP służy protokół RTCP (RTP Control Protocol). Protokół ten stanowi integralną część specyfikacji RTP i spełnia cztery podstawowe funkcje: (1) monitorowanie jakości transmisji danych, (2) identyfikacja źródła informacji, (3) skalowanie sesji multikastowej, (4) przenoszenie dodatkowych informacji kontrolnych sesji (funkcja opcjonalna). Każda transmisja RTP posiada skojarzoną z nią transmisję RTCP. W systemach konferencyjnych, w których przesyłanych jest niezależnie kilka rodzajów mediów (np. audio i wideo), każdy strumień składowy RTP posiada własny strumień RTCP, co pozwala na indywidualne sterowanie transmisją każdego strumienia.

Praca naukowa finansowana ze środków Komitetu Badań Naukowych w latach 2003-2005 jako projekt badawczy nr 4 T11D 015 24.

W referacie przedstawiono analizę protokołu RTP przeprowadzoną w środowisku symulacyjnym ns-2. Rozdział 2 referatu prezentuje model symulacyjny proto-kołu RTP. Rozdział 3 omawia eksperyment symulacyjny. Rozdział 4 prezentuje analizę jakości multikastowej transmisji wideo typu SSM realizowanej z wykorzystaniem protokołu RTP.

2. MODEL SYMULACYJNY PROTOKOŁU RTP

Rozdział prezentuje symulator ns-2 oraz modele symulacyjne protokołów RTP i RTCP.

2.1. Symulator ns-2

Dyskretny symulator zdarzeniowy sieci komputerowych ns-2 [1] został opracowany na Uniwersytecie w Berkeley w ramach programu VINT. Dostarcza on narzędzi do symulacji wielu protokołów, jak np. IP (IPv4, IPv6), TCP, UDP, RTP, HTTP, FTP. Pozwala na symulację mechanizmów zapewnienia gwarantowanej jakości usług sieciowych QoS i zapobiegania przeciążeniom. Symulator ns-2 wspiera wiele technologii sieciowych, takich jak sieci lokalne, rozległe, optyczne, bezprzewodowe, itd.

Ns-2 jest symulatorem obiektowym, napisanym w języku C++ oraz w języku skryptowym Otcl (Object Tool Command Language) stanowiącym interfejs programowy użytkownika. Modele symulacyjne zwykle są budowane z użyciem obu tych języków, przy czym modele mechanizmów przetwarzania protokołowego zazwyczaj są pisane w C++. Topologia sieci i parametry symulacji zazwyczaj są definiowane w języku Otcl, dlatego klasy C++ znajdują swoje ścisłe odzwierciedlenie w hierarchii obiektów Otcl.

Modele symulacyjne protokołów warstwy transportowej są reprezentowane w środowisku ns-2 przez obiekty potomne bazowej klasy Agent. Klasie tej odpowiada klasa Agent języka Otcl. Klasa Agent realizuje symulację procesów tworzenia, nadawania i odbioru pakietów.

2003

Poznañskie Warsztaty Telekomunikacyjne Poznañ 11-12 grudnia 2003

2.2. Model symulacyjny protokołu RTP

Model symulacyjny protokołu RTP jest w całości realizowany w oparciu o klasę Agent języka C++ i odpowiadającą jej klasę Agent języka Otcl. Model ten jest modelem symetrycznym; część nadawcza (nadajnik RTP) i odbiorcza (odbiornik RTP) są realizowane jako jeden wspólny obiekt potomny klasy Agent. Obiekt ten nosi nazwę RTPAgent, a jego odpowiednikiem w hierarchii obiektów Otcl jest klasa Agent/RTP. Symet-ria modelu symulacyjnego wynika z założeń protokołu RTP: żaden system końcowy nie jest uprzywilejowany, a każdy z nich może, w dowolnej chwili czasu, pełnić funkcję zarówno nadajnika, jak i odbiornika.

Tab. 1. Parametry modelu symulacyjnego protokołu RTP

Parametr Wartość

domyślna Opis

seqno_ 0 numer sekwencyjny pakietu RTP interval_ 3,75 ms przedział czasu pomiędzy

generowanymi pakietami random_ 0 załączenie/wyłączenie randomizacji czasu pomiędzy kolejnymi generowanymi pakietami packetSize_ 210 rozmiar (w bajtach)

pakietu RTP maxpkts_ 228 maksymalna liczba

generowanych pakietów Model symulacyjny protokołu RTP posiada szereg parametrów dziedziczonych po klasie Agent (adres IP źródła agent_addr_, numer portu źródłowego agent_port_, adres IP miejsca przeznaczenia datagramu dst_addr_, numer portu przeznaczenia dst_port_, itd.). Parametry te są wykorzystywane przez wewnętrzne procesy symulacji. Mogą być one konfigurowane z poziomu skryptu tcl.

Model symulacyjny protokołu posiada również parametry specyficzne dla klasy Agent/RTP. Lista tych parametrów wraz z opisem i wartością domyślną (początkową dla każdej symulacji) została zamieszczona w Tab. 1. Parametry specyficzne dla klasy Agent/RTP są konfigurowalne z poziomu skryptu tcl.

2.3. Model symulacyjny protokołu RTCP

Protokół RTCP dostarcza mechanizmów warstwy sesji, stąd też w skład modelu symulacyjnego wchodzą (obok obiektów potomnych klasy Agent) obiekty potomne bazowej klasy Session. Model symulacyjny protokołu RTCP jest realizowany dwutorowo:

• mechanizmy przetwarzania protokołowego są zawarte w klasie RTCPAgent (dziedziczącej po klasie Agent),

• mechanizmy zarządzania sesją RTP są zawarte w klasie RTPSession (dziedziczącej po klasie Session). Klasie RTCPAgent języka C++ odpowiada klasa Agent/RTCP języka Otcl, natomiast klasie RTPSession

języka C++ odpowiada klasa Session/RTP. Nazwy RTPSession i Session/RTP pochodzą od sesji RTP (nie zaś od warstwy sesji modelu OSI), która to sesja jest nadzorowana i sterowana przez protokół RTCP. Klasa Session/RTP nie zezwala na ustawienie żadnych parametrów specyficznych dla RTCP. Przegląd parametrów specyficznych dla klasy Agent/RTCP został zamieszczony w Tab. 2.

Tab. 2. Parametry modelu symulacyjnego protokołu RTCP

Parametr Wartość

domyślna Opis

seqno_ 0 numer sekwencyjny raportu RTCP interval_ 0 przedział czasu pomiędzy

raportami RTCP

random_ 0

załączenie/wyłączenie randomizacji przedziału

czasu interval_ Model symulacyjny protokołu RTCP jest modelem symetrycznym. Każdy agent protokołu RTCP może generować zarówno raporty odbiornika, jak i nadajnika. Rodzaj wygenerowanego raportu zależy od funkcji, jaką w danej chwili pełni skojarzony z nią agent RTP.

2.4. Symulacja transmisji RTP

Symulacja transmisji RTP wymaga podłączenia do węzła (reprezentującego warstwy 1-3 modelu OSI, wraz z protokołem IP) zarówno modelu protokołu RTP, jak i protokołu RTCP. Jawne podłączanie obu protokołów pozwala, w razie potrzeby, na uproszczenie modelu symulacyjnego transmisji. Analiza ogranicza się wówczas do zjawisk występujących w protokole RTP, z pominięciem elementów zarządzania sesją. Takie podejście znajduje zastosowanie np. w przypadku badań wydajności protokołu na jednym kierunku transmisji.

W przeciwieństwie do realnego RTP, model symulacyjny protokołu realizuje multipleksację przesyłanych strumieni zgodną z UDP. Nie ma zatem potrzeby stosowania dodatkowych modułów pomiędzy RTP a węzłem, co znacznie przyspiesza symulację.

Rys. 1 przedstawia fragment przykładowego skryp-tu symulacyjnego, powołującego dwie nowe instancje protokołu RTP (rtp1 i rtp2), po czym dołącza je do (uprzednio utworzonych) węzłów n1 i n2. Metoda connect (Rys. 1a) konfiguruje adresację (dokładniej: numery węzłów docelowych i numery portów przeznaczenia) systemów końcowych dla transmisji punkt-punkt. W przykładzie podanym na Rys. 1a, obydwie stacje są nadajnikami i odbiornikami RTP.

Symulacja transmisji multikastowej (Rys. 1b) wymaga powołania grupy multikastowej (tu: o adresie przypisanym do zmiennej grupa) oraz konfigurowania adresacji systemów nadawczych. Jest to realizowane poprzez ustawienie parametrów dst_addr_ i dst_port_ właściwego agenta RTP. W przykładzie danym na Rys. 1b, obydwie stacje są nadajnikami RTP.

(a)

set rtp1 [new Agent/RTP] set rtp2 [new Agent/RTP] $ns attach-agent $n1 $rtp1 $ns attach-agent $n2 $rtp2 $ns connect $rtp1 $rtp2

(b)

set grupa [Node allocaddr] set rtp1 [new Agent/RTP] set rtp2 [new Agent/RTP] $ns attach-agent $n0 $rtp1 $ns attach-agent $n1 $rtp2 $rtp1 set dst_addr_ $grupa $rtp1 set dst_port_ 0 $rtp2 set dst_addr_ $grupa $rtp2 set dst_port_ 0 (c) $ns at 0.5 \ "$n0 join-group $rtp1 $grupa" $ns at 0.5 \ "$n1 join-group $rtp2 $grupa"

Rys. 1. Powołanie dwóch nowych instancji agentów RTP i konfiguracja transmisji: a) punkt-punkt (typu unicast),

b) multikastowej, c) uzupełnienie harmonogramu eksperymentu o dołączenie systemów końcowych do

grupy multikastowej.

Aby odbierać dane rozsyłane na adres grupy multikastowej, stacje muszą w sposób jawny dołączyć się do grupy. Rys. 1c przedstawia fragment skryptu języka tcl, uzupełniającego harmonogram eksperymentu o dołączenie obydwu stacji do grupy multikastowej (po czasie 0.5 s, licząc od chwili rozpoczęcia symulacji).

Podłączanie protokołu RTCP realizowane jest w sposób analogiczny. Należy przy tym pamiętać, iż (niezgodnie ani z RFC 1889 [3], ani z RFC 3550 [2]) w symulatorze ns-2 obydwa protokoły powinny nadawać pakiety na adres dwóch różnych grup multikastowych. Wynika to z ograniczeń modelu węzła multikastowego zaimplementowanego w symulatorze ns-2.

3. EKSPERYMENT SYMULACYJNY

Wprowadzenie protokołów IGMPv3 i MLDv2 umożliwiło filtrację źródeł za pomocą filtrów włączających i wykluczających. Udostępniło tym samym usługę SSM (ang. Source-Specific Multicast) transmisji multikastowej, zezwalająca na transmisję od dokładnie jednego źródła. Usługa ta, której podstawowe założenia przedstawiono w RFC 3569 [4] z lipca 2003 roku, jest

szczególnie istotna w systemach radia internetowego i telewizji internetowej, gdzie w sposób naturalny zabezpiecza przed transmisją pochodzącą od nieautoryzowanych źródeł (tzw. „spamem”).

B1 τ1 R1 _R2 odb1

Rys. 2. Topologia wykorzystywana podczas symulacji. Przedstawiona w referacie analiza symulacyjna protokołu RTP obejmowała zagadnienia multimedial-nych połączeń multikastowych typu SSM. Analiza została przeprowadzona w oparciu o topologię zamieszczoną na Rys. 2. Topologia ta wykorzystywana była do testowania połączenia multikastowego typu SSM, w którym nad1 rozsyła dane do odbiorników odb1, odb2, …, odbN. W skład analizowanego systemu wchodzą (Rys. 2): węzeł nadawczy (nad1), dwa węzły pośredniczące (rutery R1, R2) oraz N węzłów odbiorczych (odb1, odb2, …, odbN). Węzeł nadawczy posiada teoretycznie nieskończony bufor (1000 pakietów) i połączony jest z ruterem R1 łączem o przepustowości 100 Mb/s i opóźnieniu propagacyjnym 1 µs. Pojemności buforów węzłów R1 i R2 są równe 150 pakietów. Ruter R1 połączony jest z następnym w kolejności systemem R2 łączem o przepustowości B1 i

opóźnieniu τ1 (wartości domyślne tych parametrów:

B1 = 10 Mb/s, τ1 = 2,5 ms). Ruter R2 jest połączony z

i-tym odbiornikiem łączem o przepustowości B2i i

opóźnieniu τ2i (wartości domyślne: B2i = 10 Mb/s,

τ2i = 2,5 ms, i = 1, 2, …N).

Eksperyment zakładał realizację transmisji wideo MPEG-4 o częstotliwości generowania ramek 25 Hz. Każda transmisja trwała 5 minut (300 sekund), po czym następował 500-minutowy okres oczekiwania na opóźnione pakiety. Transmisja wideo wykorzystywała rzeczywiste przebiegi ruchu wideo MPEG-4 lub była modelowana jako ruch o stałej prędkości bitowej (CBR) 2 Mb/s (rozmiar ramki wideo: 10 000 B). Rzeczywiste przebiegi ruchu MPEG-4 pochodzą z publicznie dostęp-nych plików [5] o wysokiej jakości obrazu oryginalnego. Do celów analizy zostały wybrane przebiegi: star – film „Gwiezdne wojny” (średni rozmiar ramki xśr = 1618 B; maksymalny rozmiar ramki xmax = 9370 B; odchylenie

standardowe δ = 1231), vclips – wideoklip (xśr = 5333 B; xmax = 13568 B; δ = 1943), cam – film pochodzący z

kamery monitorującej parking (xśr = 4539 B; xmax = 13535 B; δ = 2690). Wyrażenia podane w

nawiasach dotyczą próby 7500 ramek (pierwsze 5 minut materiału filmowego). Charakterystyki statystyki opisowej opracowane dla całości materiału filmowego można znaleźć w [5].

4. ANALIZA SYMULACYJNA WYDAJNOŚCI PROTOKOŁU RTP

Eksperyment symulacyjny miał na celu realizację badań wpływu zmian parametrów protokołu RTP (rozmiar pakietu RTP) oraz sieci (przepustowość, opóź-nienie propagacyjne) na jakość transmisji ruchu wideo (przepływność, opóźnienie, wariancja opóźnienia, straty). Zrealizowano badania wydajności połączenia multikastowego typu SSM realizowanego przez protokół RTP.

Analiza symulacyjna wydajności połączeń multi-kastowych RTP została przeprowadzona w łączu nieob-ciążonym dodatkowym ruchem. Badania obejmowały szacowanie zmian parametrów jakościowych transmisji wideo w funkcji długości pakietu RTP, opóźnienia pro-pagacyjnego oraz przepustowości łącza.

4.1. Badania jakości transmisji wideo przy różnych długościach pakietu RTP p

Badania jakości transmisji wideo przy różnych długościach pakietu RTP p prowadzone były dla domyślnych wartości parametrów B1, B2i, τ1 i τ2i,

i = 1, 2, …, N. System przeanalizowano dla przypadku 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 położono na wartości p z zakresu od 100 do 500 bajtów.

Badania wykazały, że w systemie nie występowały straty pakietów, a uzyskane przebiegi miar jakości transmisji w funkcji rozmiaru pakietu p pokrywały się dla każdego z 5 odbiorników multikastowych. Nie zaobserwowano również różnic pomiędzy wynikami uzyskanymi dla N = 1 i N = 5 odbiorników multikastowych.

Dla analizowanych warunków pracy, system zachowywał się bardzo stabilnie w całym zakresie zmian parametru p. Osiągana przepływność (liczona dla danych przenoszonych przez protokół RTP, z pominięciem narzutu wnoszonego przez nagłówki), wynikała tylko ze średniej długości ramki wideo w badanym materiale filmowym i nie zależała w żadnym stopniu od rozmiaru pakietu RTP. Ze względu na dużą względną przepustowość łączy (w stosunku do prędkości bitowej ruchu wideo), ruch RTCP praktycznie nie wpływał na przepływność RTP.

Rozmiar pakietów RTP ma wpływ zarówno na średnie opóźnienie transmisyjne pakietu (Rys. 3), jak i na wariancję opóźnienia (Rys. 4). Zjawisko to wynika z niejednorodnego charakteru opóźnienia transmisyjnego, na które składają się czasy: propagacji, nadawania i buforowania. Najmniejsze opóźnienia transmisyjne obserwowane były dla małych pakietów, rzędu 200 (star) do 300 bajtów (cam), jednakże towarzyszyła im stosunkowo duża wariancja opóźnienia (CBR: 7.27⋅10-6, star: 1.15⋅10-6, vclips: 3.922⋅10-6, cam: 7.309⋅10-6). Dla bardzo małych i dużych pakietów RTP opóźnienia rosną. W przypadku bardzo małych pakietów, jest to spowodo-wane głównie wzrostem udziału stałych nagłówków RTP/UDP/IP w całkowitym rozmiarze pakietu.

0 2000 4000 6000 8000 1 .104 0.005 0.01 0.015 0.02 0.025 rozmiar pakietu [B] opó źnienie [s]

Rys. 3.Średnie opóźnienie transmisyjne pakietu w funkcji rozmiaru pakietu p, wyznaczone w odbiorniku odb3 (i = 3) dla ruchu CBR (x) oraz materiałów filmowych:

star (+), vclips ( ), cam (o).

0 2000 4000 6000 8000 1 .104 1 .10 5 2 .10 5 rozmiar pakietu [B] w a riancja opó źnienia [s]

Rys. 4.Wariancja opóźnienia transmisyjnego pakietu w funkcji rozmiaru pakietu p; oznaczenia – jak na Rys. 3.

Narzut wnoszony przez nagłówki niweluje tutaj korzyści wynikające z niewielkich wielkości pakietów, nie usuwa jednakże skutków ubocznych. Bardzo małym rozmiarom pakietów towarzyszy zatem znaczny wzrost fluktuacji opóźnienia. Wraz ze wzrostem rozmiaru pakietu fluktuacje te początkowo maleją, aż do osiągnięcia minimum (dla ruchu CBR rozmiar pakietu jest równy wówczas rozmiarowi ramki wideo). Wraz z dalszym wzrostem p krzywa narasta, osiągając nasycenie w pobliżu xmax. Wariancja opóźnienia jest wtedy liniowo

zależna od wariancji ramek wideo.

4.2. Badania jakości transmisji wideo przy różnych wartościach czasu RTT

Badania jakości transmisji wideo przy różnych wartościach czasu RTT prowadzone były dla domyślnej wartości parametru B1 oraz B2i, i = 1, 2, …, N. Rozmiar

pakietu RTP wynosił 200 B. Do analiz przyjęto nominalną wartość czasu RTT, równą podwojonemu całkowitemu czasowi propagacji τ w systemie. Wartość nominalna stanowi jednocześnie kres dolny rzeczywistego czasu RTT pakietu znajdującego się w systemie. System przeanalizowano dla przypadku N = 1 i N = 5 odbiorników multikastowych, dla których czas

propagacji τ =1 µs + τ1 + τ21 = … = 1 µs +τ1 + τ2N

zmieniany był w zakresie od 1 ms do 1 s, co dawało zmiany czasu RTT równe 2⋅τ.

1 .10 3 0.01 0.1 1 10 5 .105 1 .106 1.5 .106 2 .106 czas RTT [s] przepływ n o ść [b/s]

Rys. 5. Przepływność protokołu RTP w funkcji czasu RTT; oznaczenia – jak na Rys. 3.

1 .10 3 0.01 0.1 1 10 1 .10 3 0.01 0.1 10 czas RTT [s] opó źnienie [s]

Rys. 6. Średnie opóźnienie transmisyjne pakietu RTP w funkcji czasu RTT; oznaczenia – jak na Rys. 3.

1 .10 3 0.01 0.1 1 10 1 .10 6 1 .10 5 1 .10 4 czas RTT [s] w a riancja opó źnienia [s]

Rys. 7. Wariancja opóźnienia transmisyjnego pakietu RTP w funkcji czasu RTT; oznaczenia – jak na Rys. 3.

Podobnie, jak poprzednio, dla analizowanych warunków pracy system zachowuje się bardzo stabilnie w całym zakresie zmian τ1 (Rys. 5). Osiągana

przepływ-ność transmisji RTP praktycznie nie zależy od czasu RTT. Maksymalna zaobserwowana różnica przepływ-ności, wynikająca z różnicy opóźnienia propagacyjnego ∆τ1 = 103 ms – 1 ms = 999 ms, wyniosła 0.00332 (tj.

0.332%) dla każdego z badanych materiałów filmowych i jest niezauważalna na wykresie.

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 wartości RTT, wyraźnie widoczny jest również wpływ czasów propagacji i buforowania, co skutkuje stałą wartością wariancji opóźnienia w dużym zakresie zmian RTT (Rys. 7). W miarę wzrostu RTT wpływ tych czasów maleje, dla dużych RTT nawet znacznie. Dzięki temu wykres średnich opóźnień w funkcji RTT można wówczas (z dokładnością do kilku procent) przybliżyć zależnością liniową (o współczynniku kierunkowym równym 2), a wariancja opóźnienia traci stały charakter i zaczyna narastać.

Również i w tym przypadku badania wykazały, że w systemie nie występowały straty pakietów. Uzyskane przebiegi miar jakości transmisji w funkcji RTT pokrywały się dla każdego z odbiorników multikasto-wych, niezależnie, czy należał on do systemu złożonego z N = 1 czy N = 5 odbiorników.

4.3. Badania jakości transmisji wideo przy różnych wartościach przepustowości łącza B2i

Badania transmisji wideo przy różnych wartościach przepustowości łącza B2i prowadzone były dla

200-bajtowych pakietów RTP, w systemie o parametrach: B1 = 100 Mb/s, τ1 = 1 µs, τ2i = 5 ms, i = 1, 2, …, N.

Podobnie, jak poprzednio, system przeanalizowano dla przypadku N = 1 i N = 5 odbiorników multikastowych, pracujących w symetrycznym drzewie dystrybucji, dla których przepustowości B2i były sobie równe i wynosiły

B. Wartość B była zmieniana w zakresie od 100 kb/s do 2700 kb/s, z krokiem 100 kb/s, co umożliwiło stworzenie „wąskiego gardła”, które nie jest zdolne do przeniesienia ramki wideo w czasie rzeczywistym.

W badanym systemie wzrost przepustowości łącza 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 źródła. Dalsze zwiększanie przepustowości łącza nie 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 prędkości bitowej źródła i w dużej mierze zależy od parametrów statystycznych ruchu. Przykładowo, dla ruchu CBR wynosi ona ok. 2.5 Mb/s, co wynika z prędkości bitowej źródła CBR (2 Mb/s), narzutu wnoszonego przez nagłówki RTP/UDP/IP (20%) oraz ruchu RTCP (5%).

Charakterystyka wartości względnej strat pakietów w funkcji przepustowości łącza (Rys. 9) jest krzywą nierosnącą, która dla dużych przepustowości stabilizuje się na poziomie zera. Opadająca część krzywej ma charakter liniowy dla ruchu CBR oraz dla ruchu o zmiennej prędkości bitowej (VBR) generowanego na bazie materiału filmowego o małej dynamice (cam).

W przypadku ruchu VBR generowanego na bazie materiału filmowego o dużej dynamice (star, vclips),

0 5 .105 1 .106 1.5 .106 2 .106 2.5 .106 3 .106 1 .106 2 .106 przepustowość [b/s] przepływ n o ść [b/s]

Rys. 8. Przepływność protokołu RTP w funkcji przepustowości łącza; oznaczenia – jak na Rys. 3.

0 5 .105 1 .106 1.5 .106 2 .106 2.5 .106 3 .106 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 przepustowość [b/s] wz g lę

dne straty pakietów

Rys. 9. Względne straty pakietów RTP w funkcji przepustowości łącza; oznaczenia – jak na Rys. 3. charakterystyka strat początkowo opada liniowo (do przepustowości bliskich średniej prędkości bitowej źródła), a następnie wolniej, długo utrzymując się na poziomie kilku procent.

Średnie opóźnienie transmisyjne w analizowanym systemie (Rys. 10), obserwowane dla małych wartości przepustowości łącza, jest silnie zależne od czasu buforowania. Gwałtowana zmiana opóźnienia transmi-syjnego obserwowana dla ruchu CBR i VBR o małej dynamice obrazu ruchomego (cam) odpowiada punktowi nieciągłości odcinkowo-liniowej charakterystyki strat. Dla ruchu VBR o dużej dynamice obrazu ruchomego (star, vclips) zmiany te są znacznie łagodniejsze. Spadkowi opóźnienia towarzyszy zwykle spadek wariancji opóźnienia (Rys. 11), chociaż dla części materiałów filmowych (cam, vclips) jest obserwowany wzrost wariancji opóźnienia dla przepustowości łącza bliskich średniej prędkości bitowej źródła.

5. ZAKOŃCZENIE

Badania jakości wykazały, że multikastowa transmisja wideo typu SSM, realizowana z wykorzystaniem protokołu RTP, jest stabilna w szerokim zakresie zmian rozmiarów pakietów i RTT. Ze względu na wymaganie niewielkiego opóźnienia, korzystniejsze jest stosowanie mniejszych pakietów, chociaż bardzo

0 5 .105 1 .106 1.5 .106 2 .1062.5 .106 3 .106 1 .10 3 0.01 0.1 10 przepustowość [b/s] opó źnienie [s]

Rys. 10. Średnie opóźnienie transmisyjne RTP w funkcji przepustowości łącza; oznaczenia – jak na Rys. 3.

0 5 .105 1 .1061.5 .1062 .1062.5 .1063 .106 1 .10 5 1 .10 4 1 .10 3 0.01 0.1 przepustowość [b/s] w ariancja opó źnienia [s]

Rys. 11. Wariancja opóźnienia transmisyjnego w funkcji przepustowości łącza; oznaczenia – jak na Rys. 3. małe pakiety są niekorzystne ze względu na wzrost wariancji opóźnienia. Na znaczny wzrost wariancji opóźnienia wpływają również czasy RTT powyżej 300 ms. Z tych samych powodów należy unikać pracy systemu na granicy przepustowości gwarantujących zerowe straty. Nawet, jeżeli w systemie nie występują straty pakietów lub straty te są niewielkie (rzędu pojedynczych %), dla niektórych materiałów filmowych mogą w tym obszarze pracy wystąpić duże fluktuacje opóźnienia transmisyjnego.

SPIS LITERATURY

[1] K. Fall, K. Vradhan, „The ns Manual”, URL http://www.isi.edu/nsnam/ns/doc/ns_doc.pdf. [2] H. Schulzrinne, S. Casner, R. Frederick, V.

Jacobson, „RTP: A Transport Protocol for Real-Time Applications”, RFC 3550. July 2003.

[3] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, „RTP: A Transport Protocol for Real-Time Applications”, RFC 1889, January 1996. [4] S. Bhattacharyya (red.), „An Overview of

Source-Specific Multicast (SSM)”, RFC 3569, July 2003. [5] F.H.P. Fitzek, M. Reisslein, „MPEG-4 and H.263

Video Traces for Network Performance Evaluation”, IEEE Network, Vol. 15, No. 6, November/December 2001.