ANALIZA SYMULACYJNA WYDAJNOŚCI PROTOKOŁU RTP REALIZUJĄCEGO USŁUGĘ MULTIKASTOWĄ TYPU SSM

Transkrypt

1 Robert Chodorek Katedra Telekomunikacji Akademia Górniczo-Hutnicza Al. Mickiewicza 30, Kraków Agnieszka Chodorek Zakład Telekomunikacji i Fotoniki Politechnika Świętokrzyska Al lecia Państwa Polskiego 7, Kielce 2003 Poznañskie Warsztaty Telekomunikacyjne Poznañ grudnia 2003 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 środowisku 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 transmisji 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 wszystkich 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 jako projekt badawczy nr 4 T11D W referacie przedstawiono analizę protokołu RTP przeprowadzoną w środowisku symulacyjnym ns-2. Rozdział 2 referatu prezentuje model symulacyjny protokoł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 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.

2 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. Symetria 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_ przedział czasu pomiędzy 3,75 ms generowanymi pakietami załączenie/wyłączenie random_ 0 randomizacji czasu pomiędzy kolejnymi generowanymi pakietami packetsize_ 210 rozmiar (w bajtach) pakietu RTP maxpkts_ 2 28 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 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 seqno_ 0 interval_ 0 random_ 0 Opis numer sekwencyjny raportu RTCP przedział czasu pomiędzy raportami RTCP 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 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 skryptu 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.

3 (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 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 ). nad1 100 Mb/s 1 µs R1 B 1 τ 1 R2 B 21, B 22,, B 2N τ 21, τ 22,, τ 2N odb1 odb2 odbn Rys. 2. Topologia wykorzystywana podczas symulacji. Przedstawiona w referacie analiza symulacyjna protokołu RTP obejmowała zagadnienia multimedialnych 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 B 1 i opóźnieniu τ 1 (wartości domyślne tych parametrów: B 1 = 10 Mb/s, τ 1 = 2,5 ms). Ruter R2 jest połączony z i-tym odbiornikiem łączem o przepustowości B 2i i opóźnieniu τ 2i (wartości domyślne: B 2i = 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: B). Rzeczywiste przebiegi ruchu MPEG-4 pochodzą z publicznie dostępnych 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 x max = 9370 B; odchylenie standardowe δ = 1231), vclips wideoklip (x śr = 5333 B; x max = B; δ = 1943), cam film pochodzący z kamery monitorującej parking (x śr = 4539 B; x max = 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 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ń multikastowych RTP została przeprowadzona w łączu nieobciążonym dodatkowym ruchem. Badania obejmowały szacowanie zmian parametrów jakościowych transmisji wideo w funkcji długości pakietu RTP, opóźnienia propagacyjnego oraz przepustowości łącza 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 B 1, B 2i, τ 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 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: , star: , vclips: , cam: ). Dla bardzo małych i dużych pakietów RTP opóźnienia rosną. W przypadku bardzo małych pakietów, jest to spowodowane głównie wzrostem udziału stałych nagłówków RTP/UDP/IP w całkowitym rozmiarze pakietu. opóźnienie [s] rozmiar pakietu [B] 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). wariancja opóźnienia [s] rozmiar pakietu [B] 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 x max. Wariancja opóźnienia jest wtedy liniowo zależna od wariancji ramek wideo 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 B 1 oraz B 2i, 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

5 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 τ. przepływność [b/s] czas RTT [s] Rys. 5. Przepływność protokołu RTP w funkcji czasu RTT; oznaczenia jak na Rys. 3. opóźnienie [s] czas RTT [s] Rys. 6. Średnie opóźnienie transmisyjne pakietu RTP w funkcji czasu RTT; oznaczenia jak na Rys. 3. wariancja opóźnienia [s] czas RTT [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ływność transmisji RTP praktycznie nie zależy od czasu RTT. Maksymalna zaobserwowana różnica przepływności, wynikająca z różnicy opóźnienia propagacyjnego τ 1 = 10 3 ms 1 ms = 999 ms, wyniosła (tj %) 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 multikastowych, niezależnie, czy należał on do systemu złożonego z N = 1 czy N = 5 odbiorników Badania jakości transmisji wideo przy różnych wartościach przepustowości łącza B 2i Badania transmisji wideo przy różnych wartościach przepustowości łącza B 2i prowadzone były dla 200- bajtowych pakietów RTP, w systemie o parametrach: B 1 = 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 B 2i 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),

6 przepływność [b/s] opóźnienie [s] Rys. 8. Przepływność protokołu RTP w funkcji względne straty pakietów Rys. 9. Względne straty pakietów RTP w funkcji 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 transmisyjnego 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 Rys. 10. Średnie opóźnienie transmisyjne RTP w funkcji wariancja opóźnienia [s] Rys. 11. Wariancja opóźnienia transmisyjnego w funkcji 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 [2] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A Transport Protocol for Real- Time Applications, RFC July [3] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A Transport Protocol for Real- Time Applications, RFC 1889, January [4] S. Bhattacharyya (red.), An Overview of Source- Specific Multicast (SSM), RFC 3569, July [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.