On delimiting video rebuffering for stream

Jordi Mongay Batalla
Piotr Krawiec
Instytut Telekomunikacji, Politechnika Warszawska
ul. Nowowiejska 15/19, 00-665 Warszawa
{jordim, pkrawiec}@tele.pw.edu.pl
Łukasz Łopatowski
Poznańskie Centrum Superkomputerowo-Sieciowe
ul. Noskowskiego 10, 61-704 Poznań
[email protected]
REALIZACJA ZARZĄDZANYCH I NIEZARZĄDZANYCH USŁUG DOSTARCZANIA TREŚCI
W SIECIACH ŚWIADOMYCH TREŚCI
Streszczenie: Artykuł prezentuje zaawansowane funkcjonalności systemu zarządzania usługami dla Sieci Świadomych Treści, umożliwiające realizację zarządzanych i niezarządzanych usług dostarczania multimediów. Proponowany system korzysta z posiadanej wiedzy o użytkowniku,
treści oraz sieci, i aktywnie współpracuje z eksploatowaną
infrastrukturą Sieci Świadomych Treści. Współpraca ta
pozwala na wprowadzenie nowych mechanizmów umożliwiających dynamiczne przełączanie serwera treści i ścieżki
przekazu w przypadku wystąpienia zakłóceń transferu.
Nadrzędnym celem proponowanych rozwiązań jest poprawa funkcjonalności systemu dla pełnego cyklu życia usługi,
ze szczególnym uwzględnieniem procesu dostarczania treści
multimedialnych, maksymalizujących zadowolenie użytkownika z odbioru usługi.
1. WSTĘP
Jednym z głównych trendów w obszarze badań nad
Internetem Przyszłości (ang. Future Internet) jest ukierunkowanie na przekaz informacji, a w szczególności
ukierunkowanie na przekaz treści multimedialnych [1].
Zaproponowane zostały nowe koncepcje i architektury,
takie jak Information-Centric Networking (ICN) czy też
Content-Oriented/-Centric/-Aware Networking (oznaczone odpowiednio: CON/CCN/CAN) [2]-[9]. Jednakże
dotychczasowe badania dotyczące koncepcji CON/CCN
wskazują potencjalne problemy związane z ich wdrożeniem do rzeczywistych sieci, takie jak konieczność
zmiany podstawowych procesów w sieci, czy też problemy ze skalowalnością wynikające ze złożoności
funkcji wykonywanych przez węzły sieciowe (operacje
przekazu treści z zachowaniem stanu, przechowywanie
replik treści, obsługa olbrzymiego zbioru nazw treści,
sposób sterowania połączeniami zbliżony do występującego w sieciach z protokołem RSVP itp.).
Podejściem pośrednim jest koncepcja sieci świadomej przekazywanej treści CAN (ang. Content Aware
Network) przyjęta w [2] i [4], która ogranicza stopień
„świadomości” sieci jedynie do typu treści, likwidując
tym samym problemy ze skalowalnością charakteryzujące podejście CON/CCN. Architektura CAN jest w głównej mierze dedykowana do dostarczania usług multimedialnych i jej podstawowym celem jest zdefiniowanie
zorientowanej na przekaz treści, dynamicznej i elastycznej platformy zarządzania i sterowania, umożliwiającej
wielu podmiotom biznesowym (tj. dostawcom usług,
dostawcom treści, operatorom sieci, użytkownikom
końcowym) współdziałanie w celu efektywnej realizacji
usług multimedialnych w środowisku rozległych, wielodomenowych sieci IP.
Niniejszy artykuł prezentuje system zarządzania
usługami SM (ang. Service Management), jaki został
zdefiniowany dla ww. architektury CAN w projektach
ALICANTE [2],[3] i DISEDAN [4], oraz zaimplementowany w prototypach stworzonych w ramach tych projektów. W szczególności, przedstawione zostaną aspekty
techniczne dotyczące sposobu realizacji w systemie SM
zarządzanych i niezarządzanych usług dostarczania treści
multimedialnych.
System SM jest wykorzystywany przez dostawcę
usług do zarządzania cyklem życia usługi multimedialnej, obejmującym etapy kreacji, planowania, publikacji,
dostarczania i usuwania usługi, z których to faza dostarczania jest kluczowa dla uzyskania najwyższego poziomu postrzeganej przez użytkownika jakości odbioru
treści multimedialnej QoE (ang. Quality of Experience).
Z fazą dostarczania związana jest koncepcja usług zarządzanych i niezarządzanych, które odnoszą się do możliwości transferu poprzez sieć treści multimedialnej
z wykorzystaniem kontrolowanych (rezerwowanych)
zasobów (usługa zarządzana), bądź też przekazu danych
zgodnie z modelem typu best-effort, kiedy zasoby sieciowe nie są w żaden sposób kontrolowane przez dostawcę usług (usługa niezarządzana).
Struktura artykułu jest następująca. W rozdziale
drugim przedstawiono koncepcję zarządzanych i niezarządzanych usług w sieci CAN. Rozdziały 3 i 4 prezentują szczegółowo proponowane sposoby realizacji usług
zarządzanych i niezarządzanych, zaś rozdział 5 stanowi
podsumowanie artykułu.
2. USŁUGI ZARZĄDZANE I NIEZARZĄDZANE
W SIECIACH CAN
Cechą płaszczyzny zarządzania i sterowania M&C
(ang. Management and Control) sieci świadomych przekazywanej treści CAN jest udostępnienie informacji
o użytkowniku, treści oraz sieci różnorodnym podmiotom współdziałającym ze sobą tak, żeby każdy z nich
mógł uzyskać dodatkowe profity z realizowanego
wspólnie procesu dostarczania treści. Rysunek 1 ilustruje
interakcje pomiędzy poszczególnymi podmiotami skutkujące „świadomością” kontekstu użytkownika (ang.
User Context Awareness), treści (ang. Content Awareness) oraz sieci (ang. Network Awareness). Na przykład:
aplikacja użytkownika końcowego świadoma sieci
(tj. mająca dostęp do informacji o stanie sieci) może
optymalizować swoje decyzje związane z adaptacją
treści (np. obniżeniem rozdzielczości przesyłanego materiału wideo w celu zachowania płynności); z kolei dostawca usług może wykorzystać informacje o profilu
oraz kontekście użytkownika (jaki terminal? jaka sieć
dostępowa?) dla zwiększenia efektywności procesu
dostarczania treści i jego szybszej adaptacji do wymagań
użytkownika. Ponadto, informacje o użytkowniku mają
fundamentalne znaczenie dla procesu przygotowania
treści do transmisji (np. dołączenie treści reklamowych).
User Context
Awareness
Service Providers
Service Providers
Content Providers
Content Providers
Content
Awareness
CAN 1
Network
Awareness
CAN 2
CAN 3
Rys. 1. Interakcje pomiędzy środowiskiem użytkownika,
usług i sieci.
Z kolei sieć pozyskuje informacje o rodzaju przesyłanej
treści, dzięki czemu może zaoferować usługę zestawiania na żądanie połączenia koniec-koniec z różnym poziomem jakości obsługi QoS (ang. Quality of Service),
uzyskując zarazem możliwość optymalnej alokacji zasobów sieciowych. Świadomość sieci po stronie dostawcy
usług rozumiemy jako możliwość przekazania przez
dostawcę usług zgłoszenia do operatora sieci CAN dotyczącego zestawienia wirtualnych sieci CAN (ang. Virtual CAN – VCAN). Sieć VCAN realizowana jest
w oparciu o jedną lub wiele domen IP, zaś oferowane
przez nią parametry jakości transmisji mogą być dostosowane do wymagań konkretnych usług (IPTV, VoD
itp.), dla których dany VCAN jest zestawiany. Operator
sieci CAN może stosować różnorodne mechanizmy
różnicujące parametry przekazu pakietów na poziomie
sieciowym, zapewniając w ten sposób gwarancje QoS
dla danej sieci VCAN.
Dedykowana wirtualna sieć VCAN umożliwia realizację usługi zarządzanej przez proponowany system
SM. Jak już wspomniano, koncepcja takiej usługi odnosi
się do dostarczenia treści multimedialnej w sposób kontrolowany, z punktu widzenia parametrów jakości przekazu QoS, z wykorzystaniem dedykowanych zasobów
sieciowych [10]. Realizacja usługi zarządzanej wymaga
spełnienia dwóch założeń: 1) świadomość treści i alokacja zasobów na poziomie sieci, oraz 2) świadomość sieci
na poziomie aplikacji. Dzięki nim powstaje pętla sprzężenia zwrotnego pomiędzy warstwą sieci, warstwą aplikacji i warstwą usługową, umożliwiająca przeprowadzenie skutecznych procesów optymalizacyjnych. W związku z tym, przedstawiony w następnym rozdziale sposób
realizacji usług zarządzanych zakłada, dla scenariusza
wielodomenowego, współdziałanie operatorów siecio-
wych mające na celu dostarczenie wspólnej warstwy
pośredniczącej (VCAN) skupiającej w sobie świadomość sieci oraz świadomość treści. Warstwa ta odpowiedzialna jest za dostarczenie informacji wynikających
ze świadomości sieci do systemu zarządzania usługami
SM, jak również przekazanie informacji wynikających
ze świadomości treści do systemu zarządzania siecią NM
(ang. Network Manager).
Usługi niezarządzane wymagają dynamicznych reakcji systemu zarządzania usługami SM na występujące
zakłócenia poprawnego działania sieci i/lub źródeł treści
(tj. serwerów strumieniujących multimedia). Zakłócenia
te wynikają z braku gwarancji rezerwacji zasobów infrastruktury realizującej przekaz treści dla tego typu usług.
Proponowany system SM wprowadza możliwość zmiany
serwera treści oraz ścieżki wykorzystywanej do transmisji treści multimedialnej w sytuacji, kiedy pogorszeniu
ulegają warunki panujące w sieci. Jest to realizowane
poprzez implementację mechanizmu adaptacji źródła
i ścieżki CSPA (ang. Content Source and Path Adaptation). Moduł CSPA systemu SM odpowiedzialny jest za
gromadzenie i analizę informacji (w czasie rzeczywistym) o błędach uzyskiwanych od użytkownika (obniżenie wartości QoE), jak również otrzymanych od sieci
(obniżenie wartości QoS), następnie zaś podejmowanie
odpowiednich decyzji dotyczących adaptacji źródła
treści i/lub ścieżki przekazu w celu przywrócenia pożądanych poziomów jakości QoE i QoS. Moduł CSPA
został szczegółowo przedstawiony w rozdziale 4, włącznie z wynikami symulacyjnymi algorytmu zaproponowanego do lokalizacji błędów w sieci, dzięki czemu
możliwe jest przeprowadzenie prawidłowej adaptacji
źródła i ścieżki przekazu.
3. ROZWIĄZANIE DLA USŁUG
ZARZĄDZANYCH: VCAN
Podejście dla wirtualnej sieci CAN (VCAN) przyjęte w niniejszym artykule zakłada wykorzystanie nowej
koncepcji wprowadzającej świadomość treści na poziomie sieci oraz świadomość sieci na poziomie aplikacji,
co ma na celu optymalizację procesu transferu danych
w ramach zarządzanej usługi dostarczania treści multimedialnych [11]. Proces zestawienia sieci VCAN jest
przeprowadzany po uzyskaniu przez dostawcę usług
informacji odnośnie potencjalnej liczby i dyslokacji
użytkowników usługi, jak również o planowanym rozmieszczeniu, w sposób zagregowany, treści multimedialnych w sieci.
Sieć VCAN stanowi infrastrukturę nakładkową
(ang. overlay) umożliwiającą realizację połączeń typu
koniec-koniec, których parametry dopasowane są do
wymagań projektowych opracowanych przez danego
dostawcę usług. Pojedynczy VCAN może być zestawiony na infrastrukturze fizycznej obejmującej wiele odrębnych domen, z których każda zarządzana jest przez niezależnego operatora sieciowego NP (ang. Network Provider) i może oferować różnorodne poziomy gwarancji
QoS obsługi strumieni multimedialnych. Zarządzanie
zasobami VCAN bazuje na wertykalnych i horyzontalnych umowach SLA (ang. Service Level Agreement)
negocjowanych i zawieranych, na płaszczyźnie zarządzania i sterowania M&C, pomiędzy dostawcą usług,
operatorem sieci CAN i operatorami sieci fizycznych.
Na poziomie płaszczyzny danych, informacje dotyczące
treści oraz usług są przenoszone w pakietach strumienia
multimedialnego generowanego przez serwer treści
i odpowiednio obsługiwane przez inteligentne węzły
sieciowe warstwy VCAN, tzw. węzły MANE (ang. Media-Aware Network Element). Zatem świadomość treści
na poziomie sieci jest realizowana na dwa sposoby: na
poziomie płaszczyzny M&C oraz na poziomie płaszczyzny danych.
Rysunek 2 przedstawia elementy architektury
VCAN konieczne do realizacji usług, z zaznaczonymi
interakcjami zachodzącymi pomiędzy modułem zarządzania siecią wirtualną VCAN (VCAN Manager), warstwą sieciową i systemem zarządzania usługami SM.
Przyjmujemy, że istnieje jeden VCAN Manager dla każdej z domen sieciowych, co zapewnia jednorodność
procesów planowania, wymiarowania, negocjacji, zestawiania i eksploatacji sieci VCAN w każdej z fizycznych domen sieciowych. Ponadto, każda z domen fizycznych posiada tradycyjny moduł zarządzania zasobami IntraNRM (ang. Intra-domain Network Resource
Manager), który jako jedyny ma uprawnienia do przeprowadzenia odpowiedniej konfiguracji urządzeń sieciowych danej domeny dla zagwarantowania wymaganych parametrów QoS.
CAN RM
SLS
CSPA
1
Service Provider
Environment
Service
Manager
3
VCAN
Manager
VCAN
Environment
VCAN
Manager
SLS
2
4
Intra-Network
Resource Manager
Intra-Network
Network Resource Manager
Interconnection
AS1
5
MANE
Access
Network
Content
server
Agreements
AS2
Multi-domain VCAN
QoS enabled
MANE
MANE
MANE
Access
Network
Set-Top-Box
Home
Network
End User
Terminal
Rys. 2. Architektura systemu do realizacji sieci VCAN;
1,2,3,4,5 – interakcje procesów zarządzania i sterowania
(RM – Resource Manager, SLS – Service Level Specification, AS – Autonomous System).
Moduł VCAN Manager przypisany do danej domeny negocjuje przydział zasobów z modułem IntraNRM
tej domeny, jak również z innymi modułami VCAN Manager w sytuacji, kiedy zestawiany VCAN obejmuje
więcej niż jedną domenę sieciową. W takim przypadku
konieczne jest uprzednie zawarcie porozumienia NIA
(ang. Network Interconnection Agreement) pomiędzy
operatorami poszczególnych domen, umożliwiającego
ich kooperację na poziomie sieciowym dla zapewnienia
gwarancji QoS w relacji od końca do końca. Moduł
VCAN Manager mapuje sieć VCAN na fizyczne zasoby
dostępne u operatorów sieciowych, następnie zaś generuje żądanie zestawienia sieci VCAN i nadzoruje,
w kooperacji z operatorami zaangażowanych domen
sieciowych, jej działanie.
W systemie SM moduł zarządzania zasobami CAN,
nazwany CAN RM (ang. CAN Resource Manager), jest
odpowiedzialny za wykonywanie wszystkich następujących po sobie procesów niezbędnych dla obsługi VCAN:
planowanie sieci VCAN, jej wymiarowanie (przeprowadzane poprzez negocjacje z VCAN Manager) oraz nadzór nad jej działaniem.
Na rysunku 2 zaprezentowano wszystkie interakcje
płaszczyzny M&C (oznaczone: 1,2,3,4,5), jakie są konieczne dla zestawienia sieci VCAN. Zbiór interakcji
(1,2,3) odpowiada za dwuetapowe negocjacje parametrów VCAN prowadzane w oparciu o wcześniejsze negocjacje pomiędzy operatorami sieci (oznaczonymi jako
interakcja (4)). Po ich zakończeniu następuje interakcja
(5) związana z zestawieniem sieci VCAN. Moduł CAN
RM dostawcy usług wysyła do inicjującego modułu
VCAN Manager żądanie instalacji sieci VCAN wraz ze
specyfikacją wymagań obejmującą: (1) informacje dotyczące topologii i pojemności ścieżek, tj. macierz ścieżek
wirtualnych (przepustowość, identyfikator wejściowy,
identyfikator wyjściowy), (2) klasy usług sieci VCAN
(opóźnienie, zmienność opóźnienia, poziom strat pakietów), oraz (3) przedziały czasowe, w których sieć VCAN
powinna być aktywna. Identyfikatory wejściowe (którymi mogą być np. prefiksy IP) identyfikują domeny,
w których zlokalizowane są serwery treści, podczas gdy
identyfikatory wyjściowe odnoszą się do domen użytkowników. Inicjujący VCAN Manager, biorąc pod uwagę porozumienia SLA zawarte z innymi modułami
VCAN Manager oraz z modułem IntraNRM swojej domeny, sprawdza dostępność zasobów w fizycznych domenach sieciowych i zwraca odpowiedź pozytywną lub
negatywną. W przypadku odpowiedzi pozytywnej,
zwraca on również listę wszystkich zaakceptowanych
ścieżek wirtualnych wraz z zaakceptowanymi przedziałami czasowymi ich funkcjonowania, jak również listę
etykiet treści/usługi dla każdej ze ścieżek wirtualnych,
którymi będą oznaczone pakiety strumieni przesyłanych
za pomocą danej sieci VCAN. Dodatkowo, VCAN Manager może przekazać do modułu CAN RM informacje
o odległościach (wyrażonych w liczbie przeskoków)
pomiędzy poszczególnymi węzłami sieci VCAN, co
umożliwi modułowi adaptacji źródła treści podjęcie
zoptymalizowanych decyzji dotyczących wyboru źródła
treści oraz ewentualnej replikacji kopii treści na serwerach w fazie dostarczania usługi sieciowej.
Operację wstawienia odpowiednich etykiet treści/usług do pakietów danych realizuje serwer treści,
któremu informację o etykietach przekazuje moduł CAN
RM (należący do systemu zarządzania usługami SM).
Warto zwrócić uwagę, iż w proponowanym rozwiązaniu
świadomość treści na poziomie sieciowym może być
uzyskana nie tylko poprzez płaszczyznę M&C, ale również dzięki mechanizmom pełnej analizy pakietów DPI
(ang. Deep Packet Inspection) zaimplementowanym
w węzłach MANE. Dzięki tym mechanizmom możliwa
jest, na poziomie warstwy sieciowej, identyfikacja
i odpowiednia obsługa (celem zapewnienia gwarancji
QoS) pakietów przenoszących treści multimedialne,
które nie są opatrzone stosownymi etykietami. Zwiększa
to elastyczność proponowanego rozwiązania, gdyż po-
zwala na wykorzystanie standardowych serwerów nieposiadających mechanizmu wstawiania etykiet do generowanych pakietów.
Implementacja interfejsu zarządzania i sterowania
pomiędzy modułami CAN RM i VCAN Manager została
wykonana w oparciu o technologię Web Services z wykorzystaniem protokołu SOAP (ang. Simple Object Access Protocol).
Zaprezentowana architektura sieci VCAN jest skalowalna, otwarta oraz umożliwia dalszą ewolucję; jest to
zgodne z najnowszymi trendami, silnie wspieranymi
przez producentów sprzętu sieciowego, takimi jak Sieci
Programowalne SDN (ang. Software Defined Networks)
[12], które wprowadzają do sieci wyraźny podział pomiędzy płaszczyzną sterowania a płaszczyzną przekazu
danych i zakładają bardziej scentralizowany sposób
zarządzani siecią w porównaniu do obecnie stosowanych
metod. Podobnie do podejścia proponowanego dla SDN,
opracowane przez nas rozwiązanie przenosi proces decyzyjny oraz inteligencję działania z węzłów sieciowych
(przełączników/ruterów) do zewnętrznych jednostek,
zlokalizowanych na jednej lub wielu maszynach fizycznych (zależnie od decyzji podjętych w procesie wymiarowania sieci).
4. ROZWIĄZANIE DLA USŁUG
NIEZARZĄDZANYCH: CSPA
Głównym zadaniem modułu adaptacji źródła
i ścieżki CSPA, będącego częścią systemu zarządzania
usługami SM, jest reakcja na pogorszenie warunków
sieciowych i zwiększenie jakości usług oferowanych
przez dostawcę usług. Moduł CSPA otrzymuje w czasie
rzeczywistym zgłoszenia od użytkowników wskazujące,
iż treść multimedialna jest strumieniowana ze złą jakością. W proponowanym rozwiązaniu zaimplementowany
został jedynie interfejs pomiędzy dostawcą usług a użytkownikiem, umożliwiający monitorowanie wartości QoE
w oparciu o wartości MOS (ang. Mean Opinion Score)
wyznaczone na podstawie pomiarów przeprowadzonych
na poziomie aplikacji (np. opóźnienie odtwarzania),
jednakże nie powinno stanowić problemu opracowanie
podobnego interfejsu z operatorem sieci, w celu monitorowania parametrów QoS (opóźnienie, straty pakietów
itp.). Przyjmujemy, iż aplikacja użytkownika końcowego
posiada funkcjonalność konieczną do monitorowania
jakości odbieranego strumienia multimedialnego i generowania odpowiednich alertów przekazywanych do
modułu CSPA.
Proces decyzyjny zaimplementowany w module
CSPA odpowiedzialny jest za uruchomienie właściwych
działań adaptacyjnych. Za każdym razem kiedy proces
ten jest wywoływany (odstęp pomiędzy kolejnymi wywołaniami określony jest zmienną konfiguracyjną TO),
moduł CSPA wykonuje dwie operacje: (1) stara się zidentyfikować i zlokalizować przyczynę zgłaszanych
problemów (przeciążenie w sieci? zbyt duże obciążenie
serwera?) poprzez uruchomienie algorytmu lokalizacji
błędów FLA (ang. Fault Localization Algorithm), który
bierze pod uwagę topologię sieci oraz alerty otrzymane
podczas ostatniego okresu TO (każdy z alertów zawiera
następujące informacje: identyfikator treści aktualnie
pobieranej przez użytkownika, adres IP serwera strumieniującego daną treść, adres IP terminala użytkownika);
następnie zaś (2) CSPA uruchamia jedną z trzech przedstawionych poniżej akcji adaptacyjnych, uwzględniając
odebrane alerty oraz wykonywane uprzednio działania
adaptacyjne. Każda z rozważanych akcji adaptacyjnych
wiąże się z wysłaniem żądania do innych elementów
systemu, wraz z informacjami koniecznymi do przeprowadzenia wywoływanej operacji. Możliwe są następujące akcje adaptacyjne:
1. Moduł CSPA żąda przeprowadzenia operacji replikacji treści, obejmującej stworzenie dodatkowych
kopii popularnej treści i umieszczenie ich na wybranych serwerach treści. Akcja ta jest uruchamiana w przypadku, kiedy część z odebranych alertów
dotyczy tej samej treści i różnych serwerów treści,
i bierze pod uwagę również informacje o dystansie
sieciowym (wyrażonym liczbą przeskoków) wcześniej utworzonych kopii danej treści. Dodatkowe
kopie treści tworzone są dynamicznie, wywołując
w razie konieczności odpowiednią operację transkodowania, i wgrywane na wyselekcjonowane
serwery treści. Następnie przeprowadzana jest aktualizacja informacji o dostępnych treściach multimedialnych, dzięki czemu obsługa nadchodzących
żądań dostarczenia treści jest realizowana
z uwzględnieniem nowych kopii.
2. Dodatkowo moduł CSPA może uruchomić procedurę przełączania połączenia charakteryzującego
się słabą jakością, na nowy, wybrany serwer treści
i na nową ścieżkę. Następuje to w sytuacji, gdy
znaczna część z odebranych alertów odnosi się do
tego samego serwera treści. Moduł CSPA wysyła
wówczas żądanie do terminala użytkownika w celu
wywołania procedury przełączania, przekazując
w nim informacje o błędnie działających serwerach
treści. W tej sytuacji terminal użytkownika powinien posiadać mechanizm płynnego przełączania,
dzięki któremu zmiana serwera treści zostanie
przeprowadzona w sposób niezauważalny dla użytkownika. Przykład implementacji takiego mechanizmu, uwzględniający strumieniowanie treści za
pomocą protokołów RTP/RTSP oraz HTTP, został
zaprezentowany w artykule [13].
3. Ponadto, moduł CSPA może uaktualnić dane wejściowe do algorytmu selekcji serwerów treści o informacje dotyczące bieżących warunków sieciowych, dzięki czemu nadchodzące żądania strumieniowania treści nie będą obsługiwane przez serwery
które zostały zidentyfikowane jako będące w stanie
przeciążenia. Akcja ta jest wywoływana na skutek
odebrania kilku alertów dotyczących tego samego
serwera w sytuacji, gdy podczas ostatniego okresu
TO nastąpiła zmiana serwera treści.
Przedstawione akcje adaptacyjne mają wpływ na
poprawę obciążenia systemu w różnych skalach czasowych. Podsumowując, w przypadku usług niezarządzanych (tj. bez gwarancji QoS oferowanych przez sieć)
moduł CSPA ma możliwość: (1) niwelacji skutków
pojedynczych zakłóceń (poprzez przełączenie źródła
transmisji), (2) występujących lokalnie, bieżących przeciążeń (poprzez adaptację procesu wyboru serwera tre-
ści), oraz (3) potencjalnych przeciążeń dużej grupy serwerów (poprzez replikację treści).
4.1. Specyfikacja algorytmu FLA
Zaproponowany algorytm FLA, zaimplementowany w module CSPA, wykorzystuje podejście wyznaczania metryki wnioskowania [14] będącym jedną z technik
lokalizacji błędów bazujących na wnioskowaniu Bayesowskim. Algorytm FLA odpowiedzialny jest za wskazanie hipotezy dotyczącej błędu w sieci (tj. przeciążenie
łącza lub/i serwera treści), najlepiej wyjaśniającej występujące symptomy (tj. otrzymywane alerty o złej jakości połączeń strumieniujących treści multimedialne).
Proponowany algorytm FLA został oparty o rozwiązanie
zaprezentowane w [15], odpowiednio zmodyfikowane
w celu dopasowania do opracowywanego systemu.
W implementacji algorytmu wykorzystano tzw.
model propagacji błędów, zwany również mapą przyczynowo-skutkową. Reprezentuje on wpływ błędu jednego z elementów systemu (serwera lub łącza) na inny
element (w naszym przypadku terminal użytkownika),
a zatem przechowuje informacje o związkach przyczynowo-skutkowych pomiędzy zbiorem błędów F a zbiorem symptomów S. W celu stworzenia takiego modelu
propagacji błędów, konieczne jest wprowadzenie do
FLA informacji dotyczących: (1) topologii sieci (tj.
utworzonych sieci VCAN); (2) zbioru wszystkich możliwych błędów F które mogą spowodować symptomy S;
zbiór ten obejmują błędy łączy, błędy węzłów sieciowych oraz błędy serwerów; (3) wartości prawdopodobieństwa wystąpienia każdego z błędów serwerów
Pr(FS) oraz błędów łączy Pr(FL) (tj. wystąpienia przeciążeń). Informacje o wartościach prawdopodobieństw
błędów mogą być uzyskane na podstawie własności
infrastruktury fizycznej, na której zestawiony jest dany
VCAN (np. dostępne przepustowości łączy, parametry
serwerów), oraz informacji o błędach występujących
w przeszłości.
Selekcja zbioru błędów Fset, będących skutkiem zaobserwowanych symptomów SO, bazuje na wyznaczeniu
metryki wnioskowania B(Fset) zgodnie z równaniem (1),
które określa prawdopodobieństwo sytuacji, iż wszystkie
błędy należące do zbioru Fset wystąpiły, i jednocześnie
błędy te stanowią wyjaśnienie wszystkich symptomów
zbioru SO, jakie pojawiły się w ostatnim okresie obserwacji TO (a więc od chwili ostatniego uruchomienia
algorytmu FLA). Jako wynik, FLA zwraca najbardziej
prawdopodobną hipotezę, tj. zbiór błędów Fset dla którego metryka B(Fset) osiąga najwyższą wartość. Zbiór ten
zawiera listę błędów wskazujących elementy będące
przyczyną nieprawidłowego działania sieci.




B( Fset )    Pr(Fi X )   1   1  Pr(S j | Fi X ) 
 F X F
S S  F X F

i
set
 i set
 j O

(1)
4.2. Wyniki symulacyjne dla algorytmu FLA
W celu walidacji, czy proponowany algorytm jest
wystarczającym narzędziem do wykrywania przyczyn
raportowanych problemów dotyczących strumieniowania treści w rozważanym systemie dostarczania treści
multimedialnych, przeprowadzono szereg testów symu-
lacyjnych. Zbadane zostały parametry działania algorytmu FLA (szybkość oraz dokładność) przy założeniu
różnych rozmiarów sieci oraz zmiennej liczbie analizowanych alertów (symptomów). Przyjęty scenariusz testowy zakłada, iż błąd w sieci jest traktowany jako przeciążenie łącza lub serwera treści. Wartość określająca
pojemność została przypisana do każdego z łączy
(LkCap) oraz serwerów (SkCap). Prawdopodobieństwa
błędów łączy (PL) oraz serwerów (PS) są ściśle powiązane, zgodnie z równaniem (2).
Lk Cap  Pr(F L )  Sk Cap  Pr(F S )
(2)
Przyjęliśmy, że pojemność łączy LkCap = 32, zaś
serwerów SkCap = 30 równoczesnych połączeń. Wartości te zostały użyte w algorytmie FLA do wyznaczenia
za pomocą formuły (1) zbioru najbardziej prawdopodobnych błędów dla zgłoszonych alertów, przy założeniu że
wartość Pr(Sj/FiX) jest równa 1 jeśli błąd FiX powoduje
wystąpienie symptomu Sj; w przeciwnym wypadku
Pr(Sj/FiX) wynosi 0.
Struktura topologii sieci użytych do badań symulacyjnych zostały wygenerowane za pomocą narzędzia
Network Manipulator [16]. Podczas symulacji wyszukane zostały węzły brzegowe sieci, do których w sposób
losowy dołączono terminale użytkowników oraz serwery
treści. W kolejnym kroku wyznaczone zostały prawdopodobieństwa błędów dla każdego łącza oraz serwera
treści. Następnie generowano losowe połączenia pomiędzy terminalami a serwerami treści, monitorując na bieżąco obciążenie wszystkich łączy i serwerów do momentu, aż w systemie wystąpiła zdefiniowana wcześniej
liczba błędów Nf (co oznaczało, że Nf łączy i/lub serwerów weszło w stan przeciążenia, tj. liczba obsługiwanych
przez nie połączeń była większa niż przypisana pojemność LkCap lub SkCap). W przeprowadzonych testach
przyjęto że Nf = {1,2,3} błędy. Spośród zbioru terminali
użytkowników realizujących połączenia po przeciążonych łączach i/lub od przeciążonych serwerów, wylosowano Na terminali zgłaszających alert. W badaniach
przyjęto, iż Na = {2, 5, 10, 20} alertów. Mając zdefiniowany zbiór wygenerowanych błędów, odebranych alertów oraz topologię sieci, uruchomiono algorytm FLA
celem lokalizacji błędów skutkujących otrzymanymi
alertami. Zbiór błędów otrzymany w wyniku działania
algorytmu FLA został porównany ze zbiorem rzeczywistych błędów celem określenia liczby błędów zlokalizowanych poprawnie oraz błędnie. Dokładność algorytmu
FLA określa relację pomiędzy prawidłowo i błędnie
zlokalizowanymi błędami.
Przedstawiona powyżej procedura testowa została
wykonana dla sieci o topologii składającej się z określonej liczby węzłów Nn wynoszącej {100, 200, 300, 400}.
Dla każdej wartości Nn wygenerowanych zostało 10
różnych topologii sieci, zaś wyniki symulacyjne zgromadzono poprzez wykonanie trzech iteracji testów dla
każdej z topologii. Uzyskane wartości średnie wraz
z przedziałami ufności (na poziomie 0.95) zostały zaprezentowane na wykresach poniżej. Warto zwrócić uwagę,
iż każdy z przeprowadzonych testów obejmował 1000
niezależnych operacji algorytmu FLA.
Accuracy
Accuracy
0,8
0,6
0,4
0,2
0,8
0,6
0,4
0,2
0,0
2
5
10
20
No. of processed alerts (Na) [alerts]
0,0
2
5
10
20
No. of processed alerts (Na) [alerts]
C) Nf = 3 faults
Accuracy
1,0
Nn= 100 nodes
0,8
0,6
0,4
Nn= 200 nodes
0,2
Nn= 300 nodes
0,0
2
5
10
20
(o różnej liczbie Nn) wzrastają wraz ze zwiększaniem się
liczby jednoczesnych błędów Nf. Dla przykładu, różnica
w dokładności algorytmu dla dwóch przypadków: Nn =
400 i Nn = 300, wynosi jedynie 0,035 kiedy Nf = 1 błąd
(dla Na = 5 alertów), ale zwiększa się do 0,178 kiedy Nf
wynosi 3 błędy (również przy założeniu Na = 5 alertów).
Przyczyna jest czysto statystyczna: w przypadku jednego
błędu, liczba jego potencjalnych lokalizacji jest niewielka dla każdej z rozpatrywanych topologii. Z kolei dla
przypadku trzech występujących równolegle błędów,
liczba potencjalnych lokalizacji (dla zbioru trzech błędów) gwałtownie rośnie, szczególnie dla topologii składających się z dużej liczby węzłów.
Nn= 400 nodes
No. of processed alerts (Na) [alerts]
Rys. 3. Dokładność algorytmu FLA w zależności do
liczby przetwarzanych alertów.
Podsumowując, w wykonanych symulacjach
zmiennymi były następujące parametry: Nn, Nf i Na.
Należy oczekiwać, że większa topologia (tj. większa
wartość Nn) jak również większa liczba jednoczesnych
błędów w sieci (tj. większa wartość Nf) skutkują obniżeniem dokładności algorytmu FLA, zwiększając zarazem
jego złożoność (a więc wydłużając czas wykonania).
Z kolei wzrost liczby zgłoszonych alertów (tj. większa
wartość Na) prowadzi do zwiększenia dokładności, lecz
także złożoności algorytmu.
Rysunek 3 przedstawia dokładność algorytmu FLA
w funkcji parametrów Nn, Nf i Na. Wykres 3A wyznaczono dla przypadku wystąpienia jednego błędu w sieci
(proces generacji błędów został zatrzymany w chwili
pojawienia się pierwszego przeciążenia); wykres 3B
związany jest z wystąpieniem dwóch jednoczesnych
błędów, zaś wykres 3C – trzech. Wszystkie wykresy
zaprezentowane zostały w tej samej skali, zaś oś pozioma określa liczbę zgłoszonych alertów Na.
Jak możemy zaobserwować, uzyskane charakterystyki dokładności algorytmu FLA w większości przypadków są zgodne z oczekiwaniami. Pewnym zaskoczeniem może być znaczące obniżenie dokładności algorytmu zaprezentowane na wykresie 3C (tj. dla przypadku
najwyższej wartości Nf). Na tej podstawie możemy
stwierdzić, iż FLA działa prawidłowo kiedy liczba jednocześnie występujących błędów jest niewielka. Jednakże możemy przyjąć, iż taka wartość jest akceptowalna,
gdyż w normalnych warunkach działania sieci jednoczesne przeciążenie wielu różnych serwerów lub łączy występuje bardzo rzadko. We wszystkich badanych przypadkach już 10 odebranych alertów pozwalało uzyskać
wystarczającą dokładność algorytmu lokalizacji błędów.
Dlatego też czas TO określający odstęp pomiędzy kolejnymi wywołaniami FLA może być ustawiony na małą
wartość, co obniża prawdopodobieństwo równoczesnego
wystąpienia więcej niż dwóch błędów w jednym okresie
TO. W opracowanej implementacji przyjęto TO = 200 ms.
Wykresy przedstawione na rysunku 3 wskazują
również, iż początkowo liczba węzłów w sieci nie ma
zbyt dużego wpływu na uzyskane wyniki, jednakże różnice pomiędzy wynikami dla poszczególnych topologii
50
A) Variable No. of nodes
and Nf= 3 faults
B) Variable No. of processed alerts
and Nn= 100 nodes
50
Execution time [ms]
B) Nf = 2 faults
1,0
Execution time [ms]
A) Nf = 1 fault
1,0
40
30
20
10
0
100
200
300
400
No. of nodes (Nn) [nodes]
Na= 2 alerts
Na= 5 alerts
Na= 10 alerts
Na= 20 alerts
40
30
20
10
0
2
5
10
20
No. of processed alerts (Na) [alerts]
Nf= 1 fault
Nf= 2 faults
Nf= 3 faults
Rys. 4. Czas wykonania algorytmu FLA w zależności od
A) liczby węzłów w sieci, B) liczby przetwarzanych alertów.
Rysunek 4 prezentuje wartości czasu wykonania
algorytmu FLA dla różnej liczby Nn węzłów w sieci
(wykres 4A) oraz różnej liczby Na zgłoszonych alertów
(wykres 4B). Symulacje zostały przeprowadzone na
serwerze HP ProLiant DL360G6 z 64-bitowym systemem operacyjnym Linuks (jądro 2.6.34). Wykres 4A
wskazuje wykładniczy wzrost czasu wykonania algorytmu wraz ze wzrostem struktury sieci (zwiększeniem
liczby węzłów Nn). Ponadto, złożoność algorytmu FLA
jest wprost proporcjonalna do liczby przetwarzanych
alertów (co pokazuje wykres 4B), ponieważ FLA wykonuje jedną iterację więcej dla każdego kolejnego alertu.
Podobnie możemy zaobserwować liniowy wzrost czasu
wykonania FLA w wyniku zwiększania liczby jednoczesnych błędów Nf. Możemy zatem przyjąć, iż otrzymane
charakterystyki są zgodne z oczekiwaniami.
5. PODSUMOWANIE
Niniejszy artykuł prezentuje rozwiązanie przyjęte
dla realizacji systemu zarządzania usługami SM w projektach ALICANTE i DISEDAN, umożliwiające wdrożenie zarządzanych i niezarządzanych usług dostarczania
multimediów. Ponadto wskazuje on korzyści rozszerzenia procesu dostarczania treści o świadomość użytkownika, świadomość sieci i świadomość treści, umożliwiając w ten sposób zwiększenie poziomu zadowolenia
użytkownika z jakości odbioru treści multimedialnych.
Wdrożenie usług zarządzanych, bazujących na alokacji
wydzielonych zasobów dla różnych typów usług multimedialnych, jest możliwe dzięki znajomości typu transferowanej treści na poziomie sieciowym. Dodatkowo,
adaptację źródła treści oraz ścieżki przekazu uzyskano
poprzez wprowadzenie świadomości użytkownika, sieci
i treści do płaszczyzny zarządzania usługami. Adaptacja
źródła treści oraz ścieżki przekazu zwiększa efektywność procesu dostarczania treści w przypadku usług
niezarządzanych.
Ponadto, w artykule zademonstrowano, za pomocą
badań symulacyjnych, dokładność działania algorytmu
lokalizacji błędów FLA dla różnych scenariuszy, zakładających zmienną liczbę węzłów w sieci, występujących
błędów oraz zgłaszanych alertów. Algorytm FLA wykorzystywany jest m.in. do adaptacji schematu rozmieszczenia treści na serwerach, zależnie od aktualnego stanu
sieci oraz serwerów treści, i opiera się na zgłaszanych
przez użytkowników alertach sygnalizujących błędy
w procesie przekazu treści. W ten sposób zaprezentowana architektura może wykorzystywać dwie metody dla
zwiększenia parametrów jakości obsługi QoS: alokację
zasobów (odpowiednich do obsługi określonego typu
treści) dla danej sieci VCAN, przeprowadzaną na żądanie dostawcy usług (operacje wykonywane w średniej
i długiej skali czasowej), oraz przełączanie serwerów
treści (zbiór dynamicznych akcji wykonywanych
w krótkiej skali czasowej).
Podsumowując, nowe funkcjonalności systemu zarządzania usługami SM w środowisku sieci CAN mają
na celu zwiększenie jakości oferowanych usług poprzez
zapewnienie kooperacji pomiędzy różnymi podmiotami
zaangażowanymi w proces strumieniowania treści multimedialnych. Dalsze badania będą ukierunkowane na
opracowanie systemu nakładkowego (ang. overlay)
usprawniającego proces kooperacji pomiędzy podmiotami, rozszerzając tym samym zbiór możliwych funkcjonalności.
Prace badawcze, których wyniki przedstawiono
w niniejszym artykule, zostały wykonane w ramach
dwóch projektów: ALICANTE, dofinansowanego ze
środków 7. Programu Ramowego Unii Europejskiej
(numer kontraktu: 248652), oraz CHIST-ERA
DISEDAN (numer umowy: ERA-NET-CHIST-ERAII/01/2014)
SPIS LITERATURY
[1] J. Schönwälder et. al., “Future Internet = Content +
Services + Management”, IEEE Communications Magazine, vol. 47, no. 7, pp. 27-33, Jul. 2009
[2] FP7 ICT project, “MediA Ecosystem Deployment
Through Ubiquitous Content-Aware Network Environments”, ALICANTE, No248652, http://www.ictalicante.eu
[3] H. Koumaras et al., “Media Ecosystems: A Novel
Approach for Content-Awareness in Future Networks”,
FIA Book 2010
[4] Strona WWW projektu CHIST-ERA DISEDAN:
http://wp2.tele.pw.edu.pl/disedan/
[5] V. Jacobson et al., “Networking Named Content,”
CoNEXT ’09, New York, USA, pp. 1–12, 2009
[6] T. Koponen et al.: “A data-oriented (and beyond)
network architecture”, ACM SIGCOMM 2007
[7] K Katsaros, G. Xylomenos, G. Polyzos, “MultiCache: An overlay architecture for information-centric
networking”, Computer Networks, Elsevier, vol. 55, no.
4, pp. 938-947, March 2011
[8] A. Detti, N. Blefari-Melazzi, S. Salsano, M. Pomposini, “CONET: A Content Centric Inter-Networking
Architecture”, ACM Information-Centric Networking.
2011
[9] J. Choi, J. Han, E. Cho, T. Kwon, and Y. Choi,
“A Survey on Content-Oriented Networking for Efficient
Content Delivery”, IEEE Communications Magazine,
March 2011
[10] A. Bourdena, E. Pallis, G. Kormentzas, H. Skianis,
G. Mastorakis, “QoS provisioning and policy management in a broker-based CR network architecture”, in
Proc. IEEE Globecom 2012, Anaheim, California, USA,
03-07 December, 2012, pp. 1841-1846
[11] E. Borcoci et al, “Connectivity Services Management in Multi-domain Content-Aware Networks for
Multimedia Applications”, Proc. of. INTERNET 2011,
Luxembourg, June 2011
[12] S.H. Yeganeh, A. Tootoonchian, and Y. Ganjali,
“On Scalability of Software-Defined Networking” IEEE
Communications Magazine, pp.136-141, February 2013
[13] J. Mongay Batalla, L. Lopatowski et al., „Dynamic
Seamless Handover of Video Servers”. 12th International Conference on Telecommunications ConTEL 2013.
Zagreb (Croatia). June 2013
[14] M. Steinder and A. S. Sethi, “A survey of fault
localization techniques in computer networks,” Elsevier,
Science Computer Programming, vol. 53, pp. 165–194,
2004
[15] H. Dong et al., “Fast Fault Localization for Largescale IP-based Communication Systems Using Bayesian
Networks”. In Chinese Journal of Electronics Vol.18,
No. 4, pp. 735-740, October 2009
[16] Network Manipulator software, dostęp online:
http://www.labri.fr/perso/magoni/nem/, kwiecień 2014