Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie

Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie

Een Distributiedienst voor Spraaksignalen met Transcoderingsfunctionaliteit in de Multicastboom gebaseerd op Actieve Netwerken. An Active Networking based Service for the Distribution of Voice with Transcoding Capabilities in the Multicast Tree. Bart Duysburgh

Proefschrift tot het bekomen van de graad van Doctor in de Toegepaste Wetenschappen: Elektrotechniek Academiejaar 2003-2004

Promotoren:

Prof. Dr. Ir. P. Demeester Prof. Dr. Ir. B. Dhoedt Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie Sint-Pietersnieuwstraat 41, 9000 Gent Tel.: +32-9-264.99.70 Fax.: +32-9-264.99.60

Dankwoord

Dit doctoraatswerk vormt het sluitstuk van vijf jaar onderzoek binnen de vakgroep Informatietechnologie (INTEC), waarbij ik de kans kreeg mij te verdiepen in het onderzoeksgebied van computer- en communicatienetwerken. Tijdens deze periode droegen vele mensen bewust en onbewust hun steentje bij aan het welslagen van dit werk en ik wens ze hier dan ook oprecht te bedanken. Allereerst gaat mijn dank uit naar mijn promotoren, Prof. Piet Demeester en Prof. Bart Dhoedt, en de vakgroepvoorzitter Prof. Paul Lagasse, die me de gelegenheid gaven deel uit te maken van de INTEC netwerkgroep (IBCN). Voorts bedank ik mijn vele collega’s van de netwerkgroep voor de goede samenwerking, de fijne sfeer en op tijd en stond de ontspannende babbel en verpozing. In het bijzonder gaat mijn dank uit naar Stefaan Vanhastel, Filip De Turck en Thijs Lambrecht voor hun belangrijke bijdrage aan dit werk. Hierbij bedank ik ook Filip Vandermeulen, Bert De Vuyst, Bart Vansegbroeck, Peter Vandaele, Brecht Vermeulen, Steven Van den Berghe en Pieter Thysebaert voor de intense samenwerking evenals de vele memorabele uren die we spendeerden aan de opbouw en ontwikkeling van het ATLANTIS testlab en het opzetten van de practica. In deze opsomming van collega’s mogen om uiteenlopende redenen ook de volgende namen niet ontbreken: Chris Develder, Sophie Demaesschalck, Jan Cheyns, Bart De Vreese, Matthias Priem, Bruno Volckaert en Koert Vlaeminck. Verder bedank ik ook de INTEC medewerkers die zorgen voor de administratieve en technische ondersteuning en in het bijzonder Martine Buysse, Luc Haentjens, Eddy Hebbelinck, Marc Declercq en Erna. Ook gaat een sportieve groet uit naar alle sportievelingen van de Lachgas voetbal- en volleybalploeg en de badmintonspelers. Bedankt voor de vele uren sport- en spelplezier! Tot slot wil ik ook mijn familie en vrienden bedanken. In het bijzonder

ii

bedank ik mijn ouders voor de kansen die ik kreeg en hun blijvende steun en betrokkenheid. Ook mijn broers en mijn schoonouders wil ik in deze bedanking betrekken. Niet in het minst bedank ik tenslotte mijn liefste An, voor haar steun, vertrouwen en geduld en de vreugde die ze in mijn leven brengt. Sint-Niklaas, Oktober 2003 Bart Duysburgh

Inhoudsopgave

Dankwoord

i

1 Inleiding 1-1 1.1 Geavanceerde netwerkdiensten gebaseerd op Actieve Netwerken 1-1 1.2 Doelstellingen van dit doctoraatswerk . . . . . . . . . . . . . 1-3 1.3 Structuur van de doctoraatsthesis . . . . . . . . . . . . . . . . 1-6 1.4 Overzicht van de publicaties . . . . . . . . . . . . . . . . . . . 1-7 Referenties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10 2 Geavanceerde netwerkdiensten gebaseerd op Actieve Netwerken 2-1 2.1 Nieuwe netwerkconcepten: een logische evolutie . . . . . . . . 2-2 2.2 Actieve Netwerken . . . . . . . . . . . . . . . . . . . . . . . . 2-3 2.2.1 Concept en motivering . . . . . . . . . . . . . . . . . . 2-3 2.2.2 Architectuur voor Actieve Netwerken . . . . . . . . . . 2-5 2.2.3 Aspecten van ontwerp en implementatie . . . . . . . . 2-9 2.2.4 Beschikbare platformen voor Actieve Netwerken . . . 2-11 2.2.5 Zakenmodel voor Actieve Netwerken . . . . . . . . . . 2-11 2.2.6 Mogelijke toepassingen gebaseerd op Actieve Netwerken2-14 2.3 Een geavanceerde distributiedienst voor spraaksignalen met transcoderingsfunctionaliteit in de multicastboom . . . . . . . 2-15 Referenties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18 3 Prestatie-evaluatie van netwerkdiensten gebaseerd op routering in de applicatielaag 3-1 3.1 Een actieveknoopimplementatie op basis van het ANTS-platform 3-2 3.2 Algemene ALR-knooparchitectuur . . . . . . . . . . . . . . . 3-5 3.3 Pakketverwerking in een Linuxrouter . . . . . . . . . . . . . . 3-7 3.3.1 Pakketverwerking in Linuxkernel 2.2.18 . . . . . . . . 3-7 3.3.2 Model voor de verwerking van pakketten in Linux . . 3-10 3.3.3 Prestatie-evaluatie van pakketverwerking in Linux en validering van het model . . . . . . . . . . . . . . . . . 3-11 3.4 Evaluatie van een Javarelaisknoop . . . . . . . . . . . . . . . 3-14 3.5 Evaluatie van de ANTS actieve knoop . . . . . . . . . . . . . 3-16 3.6 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20

iv

Referenties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22 4 Kwaliteit van VoIP en getranscodeerde spraaksignalen 4.1 Prestatie-evaluatie van het best-effort Internet . . . . . . 4.1.1 Belangrijke parameters en aanpak . . . . . . . . . 4.1.2 Tijdsvertraging . . . . . . . . . . . . . . . . . . . . 4.1.3 Pakketverlies . . . . . . . . . . . . . . . . . . . . . 4.1.4 Jitter . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Kwaliteit van spraakcommunicatie over IP-netwerken . . . 4.2.1 Evaluatie van spraakkwaliteit . . . . . . . . . . . . 4.2.2 Invloed van digitalisering en codering . . . . . . . 4.2.3 Invloed van pakketverlies . . . . . . . . . . . . . . 4.2.4 Invloed van tijdsvertraging en jitter . . . . . . . . 4.3 Kwaliteit van getranscodeerde spraaksignalen . . . . . . . Referenties . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

4-1 4-2 4-2 4-5 4-7 4-8 4-8 4-9 4-11 4-13 4-15 4-19 4-23

5 Een distributiedienst voor spraaksignalen met transcoderingsfunctionaliteit in de multicastboom 5-1 5.1 Optimalisatie van de netwerkbelasting bij multicastbomen met transcoderingsfunctionaliteit . . . . . . . . . . . . . . . . 5-2 5.2 Procedures voor het opzetten van multicastbomen met transcoderingsfunctionaliteit . . . . . . . . . . . . . . . . . . . . . 5-5 5.2.1 Praktische aanpak in een Actief Netwerk . . . . . . . . 5-5 5.2.2 Opzetten van een multicastboom in een onbelast netwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9 5.2.3 Opzetten van een multicastboom in een belast netwerk5-10 5.2.4 Stabiliteit en samenhang van procedures voor het opzetten van multicastbomen . . . . . . . . . . . . . . . 5-16 5.2.5 Stabiliteit van de multicastboom bij wijzigingen in de multicastgroep . . . . . . . . . . . . . . . . . . . . . . 5-18 5.3 Prestatie-evaluatie van de geavanceerde multicastdienst . . . 5-21 5.3.1 Evaluatie van de netwerkbelasting . . . . . . . . . . . 5-21 5.3.2 Evaluatie van de dienstkwaliteit . . . . . . . . . . . . 5-25 Referenties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28 6 Besluit

6-1

Appendices A Performance Measurements on the Current Internet A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . A.2 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3 Measurements . . . . . . . . . . . . . . . . . . . . . . . A.3.1 Routes & Hopcount . . . . . . . . . . . . . . . A.3.2 Packet Loss . . . . . . . . . . . . . . . . . . . .

i

. . . . .

. . . . .

. . . . .

. . . . .

A-1 A-1 A-2 A-3 A-5 A-6

v

A.3.3 Delay . . . A.3.4 Jitter . . . A.4 Conclusions . . . . A.5 Acknowledgements Referenties . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

A-8 A-9 A-12 A-12 A-12

B Data Transcoding in Multicast Sessions in Active NetworksB-1 B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1 B.2 Transcoding in Multicast Sessions . . . . . . . . . . . . . . . . B-3 B.2.1 Transcoding in Active Networks . . . . . . . . . . . . B-3 B.2.2 Advantages . . . . . . . . . . . . . . . . . . . . . . . . B-5 B.2.3 Application . . . . . . . . . . . . . . . . . . . . . . . . B-6 B.3 Transcoding Tree Optimisation . . . . . . . . . . . . . . . . . B-7 B.3.1 Optimisation Problem . . . . . . . . . . . . . . . . . . B-7 B.3.2 Exact Solution and Heuristics . . . . . . . . . . . . . . B-9 B.3.2.1 Skinned Steiner Tree Heuristic . . . . . . . . B-9 B.3.2.2 Branch Attach Heuristic . . . . . . . . . . . B-11 B.4 Simulations and Results . . . . . . . . . . . . . . . . . . . . . B-11 B.5 Conclusions and Further Work . . . . . . . . . . . . . . . . . B-15 Referenties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-16 C On the influence of best-effort network conditions on the perceived speech quality of VoIP connections C-1 C.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1 C.2 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2 C.2.1 VoIP conferencing software . . . . . . . . . . . . . . . C-4 C.2.2 Impairment Node . . . . . . . . . . . . . . . . . . . . . C-5 C.2.3 Digital Speech Level Analyser . . . . . . . . . . . . . . C-5 C.3 Measurement Procedures . . . . . . . . . . . . . . . . . . . . C-6 C.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-7 C.4.1 Influence of sampling and encoding/decoding . . . . . C-7 C.4.2 Influence of packet loss . . . . . . . . . . . . . . . . . . C-10 C.4.3 Influence of delay jitter . . . . . . . . . . . . . . . . . C-11 C.4.4 Combined influence of packet loss and delay jitter . . C-12 C.5 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-13 C.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-13 Referenties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-15 D An active networking based service for media transcoding in multicast sessions D-1 D.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-2 D.2 Multicast service with transcoding capabilities . . . . . . . . D-5 D.3 Active networking framework . . . . . . . . . . . . . . . . . . D-6 D.4 Multicast tree set-up . . . . . . . . . . . . . . . . . . . . . . . D-8 D.4.1 Tree set-up direction . . . . . . . . . . . . . . . . . . . D-9

vi

D.4.1.1 Downstream set-up . . . . . . . . . D.4.1.2 Upstream set-up . . . . . . . . . . . D.4.2 Overcoming processing power scarcity . . . . D.4.2.1 Push upstream . . . . . . . . . . . . D.4.2.2 Push downstream . . . . . . . . . . D.4.2.3 Proxy . . . . . . . . . . . . . . . . . D.5 Performance evaluation and quality assessment . . . D.5.1 Transcoding performance . . . . . . . . . . . D.5.1.1 Measurements . . . . . . . . . . . . D.5.1.2 Discussion . . . . . . . . . . . . . . D.5.2 Tree set-up performance . . . . . . . . . . . . D.5.2.1 Simulations . . . . . . . . . . . . . . D.5.2.2 Results . . . . . . . . . . . . . . . . D.5.3 Perceived quality of transcoded voice streams D.5.3.1 Measurements . . . . . . . . . . . . D.5.3.2 Results . . . . . . . . . . . . . . . . D.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . D.7 Acknowledgement . . . . . . . . . . . . . . . . . . . . Referenties . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

D-9 D-10 D-12 D-14 D-14 D-15 D-16 D-16 D-17 D-18 D-18 D-19 D-19 D-21 D-22 D-23 D-25 D-26 D-26

E On E.1 E.2 E.3

the performance of Application Level Routing solutionsE-1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-2 General architecture of an Application Level Routing node . E-5 Packet handling in a PC based Linux router . . . . . . . . . . E-8 E.3.1 Packet processing in the Linux 2.2.18 kernel . . . . . . E-8 E.3.2 Mathematical model . . . . . . . . . . . . . . . . . . . E-10 E.3.3 Validation of the model . . . . . . . . . . . . . . . . . E-12 E.4 Performance of packet handling in a Java based relay node . E-15 E.5 Packet handling in an ANTS based Application Level Routing node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-17 E.6 Performance of an ANTS based multicast node . . . . . . . . E-24 E.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-25 Referenties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-26

F Design and analysis of a stable set-up protocol for transcoding multicast trees in active networks F-1 F.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . F-1 F.2 An advanced multicast service with transcoding capabilities . F-3 F.2.1 Basic tree set-up procedures . . . . . . . . . . . . . . . F-5 F.2.2 Set-up procedures in nodes with insufficient resources F-7 F.3 Stability and consistency of tree state during set-up proceduresF-11 F.4 Stability of the multicast tree with changing multicast groups F-14 F.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . F-18 F.6 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . F-20 Referenties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F-20

Lijst van figuren

2.1 2.2 2.3

3.1 3.2 3.3 3.4 3.5 3.6

3.7 3.8 3.9 3.10 3.11 3.12 3.13

3.14 3.15

Illustratie van het Store and Forward principe en het Store, Compute and Forward principe. . . . . . . . . . . . . . . . . . 2-4 De algemene architectuur van een actieve knoop. . . . . . . . 2-6 Illustratie van een geavanceerde dienst voor de distributie van spraaksignalen, beschikbaar in verschillende formaten, op een passief en een actief netwerk. . . . . . . . . . . . . . . . . . . 2-16 Algemene opbouw van de op ANTS gebaseerde actieve knoop. 3-3 Algemene architectuur van een ALR-knoop. . . . . . . . . . . 3-5 Vergelijking van het klassieke IP-doorvoerpad en het ALR-pad. 3-6 Overzicht van de kernelprocedures die betrekking hebben op de afhandeling van pakketten. . . . . . . . . . . . . . . . . . . 3-8 Verwerkingstijden van de verschillende kernelprocedures betrokken bij de afhandeling van pakketten. . . . . . . . . . . . 3-9 De bottom-half verwerking van een pakket wordt verlengd door de onmiddellijke top-half verwerking van aankomende pakketten die het huidige proces onderbreekt. . . . . . . . . . 3-10 Doorvoersnelheid van een 450MHz Debian Linuxrouter. . . . 3-12 Meting en schatting van de verwerkingstijd per pakket in een Linuxrouter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 Doorvoersnelheid van een Javarelaisknoop. . . . . . . . . . . . 3-14 Meting en schatting van de verwerkingstijd per pakket in een Javarelaisknoop. . . . . . . . . . . . . . . . . . . . . . . . . . 3-16 Doorvoersnelheid van een ANTS-knoop. . . . . . . . . . . . . 3-17 Doorvoersnelheid van een ANTS-knoop zonder Garbage Collector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18 Model voor de verwerking van pakketten in de ontvangstbuffer van een socket met onderbrekingen door de GarbageCollectordraad. . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19 Vergelijking van gemeten en berekende waarden van het pakketverlies in de ontvangstbuffer van de socket. . . . . . . . . . 3-20 Meting en schatting van de verwerkingstijd per pakket in een ANTS-knoop. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21

viii

4.1

Evolutie van de tweewegstijdsvertraging naar verschillende regio’s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Evolutie van het tweewegspakketverlies naar verschillende regio’s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Meetopstelling voor spraakkwaliteit over een IP-netwerk. . . 4.4 Invloed van pakketverlies op de spraakkwaliteit van gecodeerde signalen. . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Invloed van pakketverlies op de spraakkwaliteit van gecodeerde signalen. . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Invloed van een eenvoudige pakketverliesverhullingstechniek op de spraakkwaliteit. . . . . . . . . . . . . . . . . . . . . . 4.7 Illustratie van het veréénvoudigde model voor een dejitterbuffer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Berekend pakketverlies in dejitterbuffer onder invloed van jitter en voor verschillende dejittertijdsvertragingen. . . . . . 4.9 Invloed van jitter op pakketverlies in de dejitterbuffer. . . . 4.10 Invloed van jitter op de resulterende kwaliteit van een spraaksignaal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Invloed van opeenvolgende transcoderingen op de spraakkwaliteit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 5.2

5.3 5.4

5.5

5.6

5.7 5.8 5.9

. 4-6 . 4-7 . 4-10 . 4-13 . 4-14 . 4-15 . 4-16 . 4-18 . 4-18 . 4-19 . 4-21

Bandbreedtegebruik in de optimale multicastboom en in de serverknoop berekend voor de passieve en de actieve oplossing. 5-3 Aantal transcoderingen in de optimale multicastboom en in de serverknoop berekend voor de passieve en de actieve oplossing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 Voorbeeld van de toestandsinformatie in de knopen van een multicastboom met transcoderingen. . . . . . . . . . . . . . . 5-6 Illustratie van de praktische aanpak voor het opzetten van een multicastboom en het verzenden van een stroom op basis van het ANTS-platform. . . . . . . . . . . . . . . . . . . . . . 5-7 Illustratie van de procedures voor het opzetten van de multicastboom in de stroomopwaartse (5.5(a)) en de stroomafwaartse (5.5(b)) richting. . . . . . . . . . . . . . . . . . . . . 5-9 Verschillende strategieën voor het verplaatsen van een transcoderingsproces van een overbelaste knoop naar een naburige knoop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12 Illustratie van de toestandsinformatie in complexe multicastbomen met overbelaste knopen en verplaatste transcoderingen.5-13 Procedures voor het opzetten van toestandsinformatie tussen een overbelaste knoop en een transcoderende proxyknoop. . . 5-14 Illustratie van de invloed van de opzetprocedure op de bestaande stromen in het netwerk en de aanwezige toestandsinformatie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17

ix

5.10 Illustratie van de procedure bij het verdwijnen van een gebruiker en de overblijvende niet-optimale multicastboom. . 5.11 Bandbreedtegebruik in de multicastboom bij verschillende procedures, belasting en multicastgroepen. . . . . . . . . . . 5.12 Aantal transcoderingen in de multicastboom bij verschillende procedures, belasting en multicastgroepen. . . . . . . . . . . 5.13 Uitgaande bandbreedte in de serverknoop. . . . . . . . . . . 5.14 Aantal transcoderingen in de serverknoop. . . . . . . . . . . 5.15 Gemiddelde reactietijd voor het opzetten van een verbinding met de multicastboom voor de stroomopwaartse en stroomafwaartse procedure. . . . . . . . . . . . . . . . . . . . . . . 5.16 Distributie van het aantal opeenvolgende transcoderingen ondervonden door de stroom op weg van de serverknoop naar de gebruiker. . . . . . . . . . . . . . . . . . . . . . . . . . . A.1 Geographical location of target regions and routes to those regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 Reference Network. . . . . . . . . . . . . . . . . . . . . . . A.3 Average hopcount for different regions. . . . . . . . . . . . A.4 Average two-way packet loss for different regions over a 7-day period. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.5 Average two-way packet loss for different regions. . . . . . A.6 Average Round Trip Times for different regions over a 7-day period. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.7 Average Round Trip Times for different regions. . . . . . . A.8 RTTs for a 2-minute burst of packets, emulating an 8Kbit/s connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . A.9 Average Round Trip Times and StDev vs. time of day. . . B.1 B.2 B.3 B.4 B.5 B.6 B.7 B.8 B.9 B.10

Transcoding in an audio multicast session . . . . . Frame dropping in MPEG video stream . . . . . . Transcoding Tree optimising . . . . . . . . . . . . . Skinning the bandwidth . . . . . . . . . . . . . . . Tree cost (fixed number of destinations) . . . . . . Node cost (fixed number of destinations) . . . . . . Amount of flow leaving source . . . . . . . . . . . . Difference in tree cost between heuristics and exact Tree cost (fixed number of classes) . . . . . . . . . Node cost (fixed number of destinations) . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . solution . . . . . . . . . .

C.1 C.2 C.3 C.4

Measurement setup . . . . . . . . . . . . . . . . . . . . . . . MOS for all codecs of Table C.1 . . . . . . . . . . . . . . . . MOS vs. packet loss for all codecs . . . . . . . . . . . . . . MOS vs. packet loss for different packet sizes for G.711 µLaw (C.4(a)), G.726-7 4 bit (C.4(b)) and G.728 (C.4(c)) . .

. 5-20 . 5-22 . 5-23 . 5-24 . 5-25

. 5-26

. 5-27

. A-4 . A-4 . A-5 . A-7 . A-7 . A-9 . A-9 . A-10 . A-11 . . . . . . . . . .

B-2 B-4 B-8 B-10 B-12 B-13 B-13 B-14 B-14 B-15

. C-3 . C-7 . C-8 . C-9

x

C.5 C.5(a) MOS vs. jitter without dejittering buffer (G.711 µLaw); C.5(b) MOS vs. delay jitter for dejittered signal (G.711 µ-Law) from measurements and derived from the results of Fig. C.3(a) and C.5(c); C.5(c) Introduced jitter vs. resulting packet loss in dejittering buffer (G.711 µ-Law) . . . . . . . . C-13 C.6 Combined influence of delay jitter and packet loss on the perceived quality (G.729) . . . . . . . . . . . . . . . . . . . . C-14 D.1 D.2 D.3 D.4 D.5

Voice multicast service with transcoding in intermediate nodes.D-5 Active networking node. . . . . . . . . . . . . . . . . . . . . . D-7 Upstream tree set-up procedure. . . . . . . . . . . . . . . . . D-12 Strategies to overcome processing power scarcity in a node. . D-13 Upstream tree set-up procedure with transcodings pushed upstream to overcome processing power scarcity. . . . . . . . D-14 D.6 CPU time (in ms) needed to perform a transcoding of a 10 ms voice fragment, for a processor speed of 1000MHz. . . . . D-17 D.7 Use of bandwidth in multicast tree for different fractions of overloaded nodes and different strategies. . . . . . . . . . . . D-20 D.8 Number of transcodings in multicast tree for different fractions of overloaded nodes, for different strategy. . . . . . . . . D-21 D.9 Response time as a function of the number of group members for upstream and downstream tree set-up procedure. . . . . . D-22 D.10 Distribution of the number of successive transcodings between server and client. . . . . . . . . . . . . . . . . . . . . . . D-23 D.11 Measurement set-up for perceived quality of transcoded voice. D-23 D.12 MOS for transcoded voice streams. . . . . . . . . . . . . . . . D-24 D.13 Degradation of MOS due to successive transcodings. . . . . . D-25 E.1 An example overlay network: the client hosts which are interconnected by the overlay network run an overlay node runtime environment at the application level. The virtual nodes of the overlay network are connected by overlay tunnels and traffic traversing an overlay node is processed and forwarded by the runtime environment. The overlay traffic between nodes A and C is processed in the node runtime environment of overlay node B. . . . . . . . . . . . . . . . . . . . . . . . . E-2 E.2 General architecture of an Application Level Routing node: when a client host is part of an overlay network it runs an overlay node runtime environment for that overlay in the application level. Overlay traffic arrives through a tunnel, is processed by the protocol stack and is passed to the runtime environment via the corresponding socket of the tunnel. The traffic stream can either be terminated at a node or it can be forwarded to another destination. . . . . . . . . . . . . . . . . E-6

xi

E.3 Experimental Application Level Routing node set-up based on a Linux router extended with a Java based implementation of an Active Node runtime (ANTS). . . . . . . . . . . . . . . E-7 E.4 Overview of kernel procedures for packet handling: the arrival of a new packet on an interface triggers an IRQ and subsequently the execution of the netdev rx() procedure. A packet that has not reached its destination yet is forwarded by the net bh fw() procedure. Otherwise, it is passed to the application level by the net bh recv() procedure. A new UDP packet can be sent by means of the udp sendmsg() procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-9 E.5 Measured processing times for the Linux kernel packet handling procedures illustrated in Figure E.4. . . . . . . . . . . . . E-10 E.6 A packet’s basic bottom-half processing time τ0 is interrupted by arriving packets and their subsequent top-half handling, which takes a time τIRQ . Consequently, the total time needed for a packet’s bottom-half handling depends on the number of packets arriving during its processing. . . . . . . . . . . . E-11 E.7 Throughput measurement on a 450MHz Debian Linux router. E-13 E.8 Comparison of the results of two approaches to estimate the lin . Based on the measurements of Figure value of τ0lin + τIRQ E.7 and the model a first estimate is given by 1/Xmax . A second estimate is given by the sum of the measured values of netdev rx() and net bh fw(), shown in Figure E.5. . . . E-14 E.9 Throughput measurement for Java relay node. . . . . . . . . E-16 E.10 Estimation of the Java Relay packet processing time through two approaches. Fitting the model from Section 3.2 to the throughput measurement results of Figure E.9 gives a first estimate for the parameter τ0jav . Measuring the three components of the total processing time separately and summing the results gives a second estimate. . . . . . . . . . . . . . . . E-17 E.11 Throughput measurement for Java based ANTS node. . . . . E-18 E.12 Throughput measurement for Java based ANTS node without Garbage Collector. . . . . . . . . . . . . . . . . . . . . . E-19 E.13 Model for packet handling in a socket receive queue with a fraction p of the packet processing times interrupted by the Garbage Collector. . . . . . . . . . . . . . . . . . . . . . . . . E-20 E.14 State transition diagram for the socket receive queue packet handling model. . . . . . . . . . . . . . . . . . . . . . . . . . E-21 E.15 Packet loss generated in a UDP socket receive queue. A comparison is made between the packet loss values obtained from the throughput measurements in Figure E.11 and the values calculated with the model from Equations (9)-(16). . . . . . E-22

xii

E.16 Estimation of the ANTS node packet processing time through two approaches. Fitting the model from Section 3.2 to the throughput measurement results of Figure E.12 gives a first estimate for the parameter τ0ant . Measuring the three components of the total processing time separately and summing the results gives a second estimate. . . . . . . . . . . . . . . . E-24 E.17 Throughput of a Java/ANTS based ALR multicast node with 1, 2 and 3 receiving nodes for 128 bytes packets. . . . . . . . E-25 F.1 Example of the tree state information set up in the nodes for a simple tree with transcoding capabilities. . . . . . . . . . . F-4 F.2 Illustration of the difference between the tree set-up procedures in upstream (F.2(a)) and downstream (F.2(b)) direction.F-6 F.3 Strategies to overcome processing power scarcity in nodes where transcodings are needed. . . . . . . . . . . . . . . . . . F-8 F.4 Illustration of the tree state information in complex trees with pushed transcoding processes. . . . . . . . . . . . . . . . F-9 F.5 Set-up of traffic between an overloaded node and a transcoding proxy node. . . . . . . . . . . . . . . . . . . . . . . . . . F-10 F.6 Influence of the tree set-up procedure on the existing streams and their tree state. In Figure F.6(a), the existing stream with codec B from node 1 to node 4 is interrupted when in node 2 the entry for codec B is overwritten with codec A. In Figure F.6(b), this interruption is avoided by setting up state for codec A in parallel with the existing state for codec B. Afterwards, the state for codec B is cleaned up. . . . . . . F-12 F.7 Influence of the push procedures on the existing streams and their tree state. The Push Upstream procedure (Figure F.7(a)) has no significant influence, whereas the Push Downstream (Figure F.7(b)) and the Push to Proxy procedure (Figure F.7(c)) will interfere with the existing streams. Therefore, specific measures are required to preserve the existing streams. . . . . . . . . . . . . . . . . . . . . . . . . . . . F-14 F.8 The grid network used for the simulations and its division into different zones. . . . . . . . . . . . . . . . . . . . . . . . . F-16 F.9 Illustration of the remaining tree state exhibiting reduced performance after a user leaves the session. In Figure F.9(a) it is shown that this can be the case in a normal situation without overloaded nodes. In Figures F.9(b), it is shown that the Push Upstream procedure exhibits no reduced performance. However, the Push Downstream and Push to Proxy procedure can exhibit reduced performance as shown in Figures F.9(c), F.9(d) and F.9(e). . . . . . . . . . . . . . . . . . F-17 F.10 Influence of a changing user group on the use of network resources in the tree. . . . . . . . . . . . . . . . . . . . . . . . F-19

Lijst van tabellen

2.1 2.2

Overzicht van belangrijkste platformen voor Actieve Netwerken2-12 Overzicht van beschikbare codecs binnen de toepassing . . . . 2-15

3.1

Overzicht van de ANTS-programmeerinterface voor Actieve Netwerken. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4 Geschatte waarden uit gefit model voor relaisknoop. . . . . . 3-15 Geschatte waarden uit gefit model voor ANTS-knoop. . . . . 3-19

3.2 3.3 4.1

4.2 4.3 4.4 4.5 4.6 4.7

Overzicht van de beschikbare netwerkcapaciteit binnen BELNET en de capaciteit van BELNET naar de Belgische, de Europese en de Amerikaanse netwerken . . . . . . . . . . . Vergelijking van resultaten voor tweewegstijdsvertraging en tweewegspakketverlies tussen 1998 en 2001 . . . . . . . . . . Vergelijking van jitterresultaten 1998 en 2003 . . . . . . . . Overzicht van beschikbare codecs . . . . . . . . . . . . . . . Maximaal aanvaardbare waarden voor pakketverlies en jitter voor gecodeerde spraaksignalen. . . . . . . . . . . . . . . . . Spraakkwaliteit (MOS) van getranscodeerde signalen. . . . Verwerkingstijden van verschillende transcoderingen. . . . .

. 4-4 . 4-5 . 4-8 . 4-12 . 4-20 . 4-20 . 4-22

A.1 Minimum, maximum, average RTTs and standard deviation for simulated 8kb/s and 64kb/s connections. . . . . . . . . . . A-10 C.1 Overview of available codecs . . C.2 ACR or MOS scale . . . . . . . C.3 Difference in MOS for long and test signals . . . . . . . . . . .

. . . . . . . . . . . . . . . . . C-4 . . . . . . . . . . . . . . . . . C-6 short male and female voice . . . . . . . . . . . . . . . . . C-6

D.1 Voice codecs provided in multicast service . . . . . . . . . . . D-6 E.1 Fitted values from relay node model. . . . . . . . . . . . . . . E-16 E.2 Fitted values from ANTS node model. . . . . . . . . . . . . . E-23 F.1 Different types of capsules used in the multicast service. . . . F-12 F.2 Codecs provided in the multicast service . . . . . . . . . . . . F-15

xiv

Lijst van Afkortingen

Lijst van afkortingen A ACK ACR ADPCM ADSL ALAN ALR AMS-IX ANTS API ARPANET

Acknowledgement Absolute Category Rating Adaptive Differential Pulse Code Modulation Asymmetric Digital Subscriber Line Application Level Active Networks Application Level Routing Amsterdam Internet Exchange Active Network Transport System Application Programming Interface Advanced Research Projects Agency Network

B BNIX

Belgium National Internet Exchange

C CDN CPU

Content Distribution Network Central Processing Unit

D DARPA DSLA

E

Defense Advanced Research Projects Agency Digital Speech Level Analyser

xv

EE ETSI

Execution Environment European Telecommunications Standards Institute

F FGS

Fine Granularity Scalability

G GSM-FR

Global System for Mobile Communications Full Rate

I ICMP IETF ILP IP IRQ ISDN ISP ITU-T

Internet Control Message Protocol Internet Engineering Task Force Integer Linear Programming Internet Protocol Interrupt Request Integrated Services Digital Network Internet Service Provider International Telecommunication Union Telecommunications standardization sector

J JVM

Java Virtual Machine

M MOS MPEG

Mean Opinion Score Moving Picture Expert Group

xvi


N NACK NodeOS NS-2

Negative Acknowledgement Node Operating System Network Simulator, version 2

P PAMS PC PCM PESQ PLAN PSQM

Perceptual Analysis/Measurement System Personal Computer Pulse Code Modulation Perceptual Evaluation of Speech Quality Packet Language for Active Networks Perceptual Speech Quality Measurement

Q QoS

Quality of Service

R RAM RFC

Random Access Memory Request for Comment

T TCP TERENA TOS TTL

Transmission Control Protocol Trans European Research and Education Networking Association Type Of Service Time To Live

xvii

U UDP

User Datagram Protocol

V VoIP VNE

Voice over IP Virtual Network Engine

xviii


1

Inleiding

I

N dit eerste hoofdstuk wordt het algemeen kader van dit onderzoekswerk geschetst. De doelstellingen van dit doctoraatswerk worden besproken en de structuur van dit proefschrift wordt kort toegelicht. Verder wordt een overzicht gegeven van de publicaties die binnen dit onderzoek gerealiseerd werden.

1.1

Geavanceerde netwerkdiensten gebaseerd op Actieve Netwerken

Niettegenstaande het Internet in het begin van de jaren negentig nog in de kinderschoenen stond, zijn tegenwoordig veel van zijn toepassingen stevig ingeburgerd in ons dagelijks leven. Netwerktoepassingen zoals e-mail, surfen op het web, elektronisch bankieren en chatten hebben immers op korte tijd een vaste plaats verworven naast de traditionele informatie- en communicatiesystemen zoals post, krant, telefoon, radio en televisie. Dankzij de populariteit van deze nieuwe diensten heeft het Internet zich razendsnel een weg gebaand tot in de huiskamer van vele gezinnen en is het beschikken over een Internet verbinding een absolute must geworden. Vele gebruikers, zowel commercieel als particulier, hebben de afgelopen jaren de weg naar het Internet gevonden, aangetrokken door de nieuwe mogelijkheden geboden door ondermeer elektronische post, de haast eindeloze hoeveelheid informatie beschikbaar op het web of elektronische handel. Het is echter duidelijk dat

1-2

Hoofdstuk 1

het gamma van netwerkdiensten dat initieel de aantrekkingspool van het Internet vormde te beperkt is om de gestage groei van het Internet blijvend gaande te houden. In een tijd waarin gewenning en verveling steeds vlugger toeslaan, is het bijgevolg noodzakelijk om op regelmatige basis voor nieuwe en aantrekkelijke diensten te zorgen, die zowel vertrouwde als nieuwe gebruikers kunnen bekoren. Deze vaststelling is vooral van belang voor ISP’s (Eng.: Internet Service Providers) die met het oog op het maximaliseren van hun inkomsten steeds op zoek moeten gaan naar nieuwe diensten om hun klanten aan zich te binden. Wanneer men echter nieuwe toepassingen of diensten wil introduceren in het Internet, stoot men op een aantal problemen gerelateerd aan de volgende fundamentele kenmerken van het netwerk. Ten eerste zijn de principes en bouwstenen van het huidige Internet nagenoeg ongewijzigd gebleven sinds hun ontstaan. De basisprincipes dateren van de vroege jaren zeventig toen met het ARPANET [1] het allereerste computernetwerk ontwikkeld werd. In de geest van de toen brandend actuele Koude Oorlog was de belangrijkste doelstelling van dit netwerk het opzetten van een robuuste en veilige communicatie tussen twee computers. Bijgevolg bestaat de basisfunctionaliteit van de huidige computernetwerken nog steeds uit het transporteren van gegevens, opgesplitst in pakketten, tussen twee netwerkknopen die als zender en ontvanger fungeren. Ten tweede speelt het standaardisatieproces een belangrijke rol bij de ontwikkeling en de invoering van nieuwe toepassingen en diensten in het Internet. Met het oog op de samenwerking tussen apparatuur of software van verschillende producenten is het immers nodig een standaard op te stellen die de steun geniet van alle betrokken partijen uit de industrie. Dit kan een langdradig en langduring proces zijn met als gevolg dat de invoering van nieuwe diensten soms jaren vertraagd wordt. Deze twee fundamentele eigenschappen van de bestaande infrastructuur zorgen voor grote beperkingen bij de evolutie van het Internet. Enerzijds wordt de invoering van nieuwe toepassingen vertraagd door het aanslepende standaardisatieproces, waardoor de tijd tussen de ontwikkeling en de eigenlijke invoering voor de ISP onaanvaardbaar groot wordt. Anderzijds is de functionaliteit van computernetwerken te beperkt om geavanceerde en aantrekkelijke toepassingen te ondersteunen. Kortom, de bestaande infrastructuur wordt gekenmerkt door een duidelijk gebrek aan flexibiliteit en functionaliteit. Tot deze vaststelling kwam men midden de jaren negentig binnen de DARPA-onderzoeksgemeenschap [2] vanuit een aantal discussies over de toekomst van netwerkgebaseerde systemen. Hieruit vloeiden dadelijk een aantal initiatieven voort waarbij, ge¨ınspireerd door het succes van computergebaseerde systemen die door het gebruik van software een grote flexibili-

Inleiding

1-3

teit vertonen, het idee ontstond om netwerken programmeerbaar te maken. Hierbij werden twee grote stromingen gesuggereerd: open interfaces en mobiele code. In het concept van open interfaces wordt op netwerkapparatuur een gestandaardiseerde programmeerinterface voorzien die een flexibele en dynamische configuratie van het netwerk toelaat. Bij mobiele code voorziet men een infrastructuur waarbij kleine programma’s min of meer autonoom door het netwerk reizen en uitgevoerd kunnen worden in bepaalde knopen. Uitgaande van deze twee basisconcepten werden uiteindelijk drie concrete oplossingen ontwikkeld: Mobiele Software Agenten [3, 4], Programmeerbare Netwerken [5–7] en Actieve Netwerken [8–11]. Zoals de benaming duidelijk aangeeft, sluiten de eerste twee zeer nauw aan bij de respectievelijke basisideeën van mobiele code en open programmeerinterfaces. Het concept van Actieve Netwerken is echter een uiterste radicale en gedurfde uitwerking van deze concepten. In Actieve Netwerken kan elk pakket naast data ook een hoeveelheid uitvoerbare code met zich meedragen en kan deze code uitgevoerd worden in de netwerkknopen waardoor het pakket passeert. Het ontwerp van deze zogenaamde actieve pakketten laat toe om eenvoudig nieuwe functionaliteit aan het netwerk toe te voegen of het gedrag van het netwerk dynamisch te wijzigen.

1.2

Doelstellingen van dit doctoraatswerk

Uitgaande van de problematiek geschetst in de vorige paragraaf willen we binnen dit werk onderzoeken hoe geavanceerde toepassingen en diensten opgebouwd kunnen worden steunend op de nieuwe mogelijkheden geboden door Actieve Netwerken. Bijgevolg is de aanpak van dit werk specifiek toepassingsgedreven en wordt uitgebreid ingegaan op een bepaald type netwerkdienst. Enerzijds komen door de geschikte keuze van deze dienst verschillende aspecten van de geavanceerde functionaliteit en toegenomen flexibiliteit op basis van Actieve Netwerken aan bod. Anderzijds wordt door het belichten van de vele facetten van de gekozen dienst ook inzicht verkregen in de specifieke problemen en aspecten ervan. De keuze van deze dienst werd bepaald door de volgende overwegingen. Allereerst gaat de aandacht specifiek uit naar multimediatoepassingen aangezien we er van uitgaan dat in de toekomst de meest aantrekkelijke en geavanceerde netwerkdiensten op multimedia gebaseerd zullen zijn. Nu reeds is immers de verspreiding van audiovisuele media één van de belangrijkste toepassingen van het Internet. Denken we maar aan het uitzenden van de sessies van ondermeer de IETF- en Terena-conferenties [12, 13], het beschikbaar maken van klank- en beeldmateriaal door CNN [14], BBC [15] en recent ook door VRT [16] of het live uitzenden van optredens vanop het

1-4

Hoofdstuk 1

TW2003-festival [17]. Bij deze multimediatoepassingen wordt dezelfde mediastroom vaak door een groot aantal gebruikers tegelijkertijd ontvangen en het is dus voordelig gebruik te maken van multicasttechnieken om het verbruik van de netwerkcapaciteit te optimaliseren. Verder zijn multimediagegevens beschikbaar in een brede waaier van formaten, die ondermeer bepaald kunnen worden door de codering, de bitrate, de kwaliteit of de vereiste afspeelsoftware. Verder heeft men tegenwoordig de beschikking over een grote variatie aan mogelijke Internet verbindingen, waarbij naast de klassieke smalbandige toegang met analoge en digitale (ISDN) modems nu ook breedbandige oplossingen over het kabelnetwerk of via ADSL beschikbaar zijn. Tenslotte is flexibiliteit op steeds meer vlakken een belangrijke vereiste. In de context van netwerkdiensten kan flexibiliteit op twee verschillende manieren ge¨ınterpreteerd worden. Enerzijds kan het slaan op de soepelheid waarmee een nieuwe toepassing of dienst wordt ingevoerd in het netwerk. Anderzijds geeft het aan in welke mate een toepassing op zichzelf in staat is te reageren op veranderende omstandigheden en om te gaan met een breed aanbod aan gegevens of specifieke vereisten van gebruikers. De dienst die uitgaande van deze overwegingen werd gekozen en de rode draad door dit werk vormt, is een geavanceerde distributiedienst voor mediasignalen met transcoderingsmogelijkheden in de multicastboom. Deze dienst beantwoordt op de volgende manieren aan de vooropgestelde criteria. Door het gebruik van multicastcommunicatie kan een grote groep gebruikers de signalen tegelijk ontvangen, terwijl de belasting van het netwerk geoptimaliseerd wordt. Naar de gebruiker toe wordt voor extra flexibiliteit gezorgd door de individuele keuze te laten uit een brede waaier aan formaten. Bij deze keuze kan de gebruiker rekening houden met de door hem gewenste kwaliteit, de beperkingen van zijn Internetverbinding of de software die op zijn machine voor handen is. Wanneer men deze mogelijkheid in de huidige netwerken wil aanbieden, moet men voor elk formaat van de mediastroom een afzonderlijke multicastboom voorzien, hetgeen voor een aanzienlijke toename van de netwerkbelasting zorgt. Door de mogelijkheden van Actieve Netwerken kan men echter de distributie voorzien over één enkele multicastboom, waarbij initieel één formaat verzonden wordt en onderweg in bepaalde knopen van de boom een omzetting of transcodering gebeurt naar de gewenste formaten. Bovendien zorgen Actieve Netwerken voor een raamwerk waarbinnen het introduceren van nieuwe toepassingen gebaseerd is op het gebruik van uitvoerbare programma’s in de pakketten. Gebruik makend van deze techniek hoeft men niet in te grijpen in de knopen van het netwerk maar gebeurt het invoeren van nieuwe diensten veel vlotter door het introduceren van nieuwe pakketten met specifieke programma’s en functionaliteit.

Inleiding

1-5

In dit werk wordt een specifieke variant van deze dienst beschreven waarbij spraaksignalen met verschillende coderingen gedistribueerd worden naar meerdere gebruikers en eventueel in de netwerkknopen getranscodeerd worden. De volgende aspecten van deze dienst en van het onderliggende Actieve Netwerk worden in het vervolg behandeld. Voor de verschillende doelstellingen van de beschreven netwerkdienst wordt een ge¨ıntegreerde oplossing ontworpen, gebaseerd op flexibele routering, multicastcommunicatie en transcoderingen. Hierbij worden mechanismen voorzien om op dynamische wijze eventuele overbelasting in de netwerkknopen in rekening te brengen en alternatieve paden op te zetten. Voor deze geavanceerde functionaliteit wordt gesteund op de mogelijkheden van Actieve Netwerken. Binnen een theoretisch luik wordt de optimalisatie van de gebruikte multicastbomen met transcoderingsprocessen bekeken op basis van een ILPformulering. In een meer praktische benadering wordt het opzetten van deze bomen onderzocht op basis van simulaties, waarbij de prestaties van de dienst geëvalueerd worden. Aangezien binnen de beschouwde variant spraaksignalen getransporteerd worden, wordt de kwaliteit van deze spraaksignalen na transport over een IP-netwerk uitvoerig onderzocht. Een objectieve meetmethode wordt gebruikt waarbij de gemeten MOS-waarde (Eng.: Mean Opinion Score) weergeeft hoe een gemiddeld publiek de kwaliteit van het signaal ervaart. De invloed van diverse factoren zoals de netwerkkarakteristieken en de codering van het signaal worden onderzocht. Hierbij werd ook de efficiëntie van een aantal technieken zoals de verhulling van pakketverlies en het gebruik van een dejitterbuffer bekeken. Verder worden ook het concept van overlaynetwerken en het onderliggende mechanisme van routering in de applicatielaag onderzocht en wordt een prestatie-analyse uitgevoerd op basis van een theoretische analyse en van metingen op een experimentele opstelling. Overlaynetwerken worden immers steeds vaker gebruikt en vinden ook hun toepassing ter ondersteuning van multicastcommunicatie en Actieve Netwerken. Ze laten immers toe om verschillende netwerkknopen te verbinden met een virtueel netwerk onafhankelijk van de onderliggende infrastructuur. Hierbij kan in de virtuele knopen een alternatieve knoopfunctionaliteit verzorgd worden in een afzonderlijke uitvoeringsomgeving. Op die manier kan eenvoudig en op beperkte schaal nieuwe functionaliteit in een netwerk ingevoerd worden zonder in te grijpen in de bestaande infrastructuur.

1-6

1.3

Hoofdstuk 1

Structuur van de doctoraatsthesis

Binnen deze doctoraatsthesis wordt uitvoerig verwezen naar een aantal publicaties die als appendices zijn toegevoegd. Deze tekst heeft als doel een gedetailleerde synthese van het geleverde werk en de belangrijkste resultaten te geven. Voor meer gedetailleerde informatie wordt verwezen naar deze bijgevoegde publicaties. Na dit inleidende eerste hoofdstuk wordt in Hoofdstuk 2 dieper ingegaan op het ontstaan en de basisconcepten van Actieve Netwerken. De verschillende componenten zoals de actieve knoop en actieve pakketten worden besproken, evenals een aantal architecturale en implementatiegerichte aspecten. Hierbij wordt ook een zakenmodel voor het gebruik van Actieve Netwerken voorgesteld. Aansluitend wordt nog een uitgebreide introductie gegeven van de geavanceerde dienst die de rode draad vormt doorheen deze thesis. Hoofdstuk 3 spitst zich hoofdzakelijk toe op de werking en de implementatie-aspecten van het actieve netwerk waarop de geavanceerde multimediatoepassing steunt. Hierbij wordt de opbouw en werking van een specifieke actieve knoop geëvalueerd die binnen dit werk gebruikt werd. Aangezien deze implementatie uitgaat van een actief overlaynetwerk en overlaynetwerken in het algemeen steeds vaker gebruikt worden, wordt er ook ingegaan op de onderliggende concepten ervan. Meer bepaald wordt het concept van routering in de applicatielaag beschreven en wordt een prestatie-evaluatie uitgevoerd van toepassingen die op dit concept gebaseerd zijn. De inhoud van dit hoofdstuk is grotendeels gebaseerd op de publicatie van Appendix E. Aangezien een distributiedienst voor spraaksignalen het onderwerp vormt van dit werk, wordt binnen Hoofdstuk 4 de kwaliteit van spraak over IP en getranscodeerde spraaksignalen onderzocht. Bij het transporteren van spraaksignalen over een pakketgebaseerd netwerk voor toepassingen in ware tijd stuit men immers op een aantal problemen en beperkingen die in de eerste plaats een weerslag hebben op de kwaliteit van het ontvangen spraaksignaal. De verschillende karakteristieken van het netwerk, zoals pakketverlies, tijdsvertraging en variatie van de tijdsvertraging, worden bestudeerd en hun invloed op de kwaliteit van de getransporteerde spraak wordt bepaald. Verder wordt ook een prestatie-analyse gemaakt van transcoderingen van spraaksignalen. Zowel de resulterende kwaliteit als de verwerkingstijden van de transformatieprocedure worden beschouwd. Deze resultaten zijn eveneens beschreven in de publicaties van Appendix A, C en D. Vervolgens wordt in Hoofdstuk 5 de eigenlijke distributiedienst voor multimediastromen met transcoderingsfunctionaliteit in de multicastboom beschreven. Vanuit een theoretisch oogpunt wordt bekeken in hoeverre de gebruikte netwerkcapaciteit kan worden geoptimaliseerd ten opzichte van tra-

Inleiding

1-7

ditionele oplossingen. Verder worden verschillende procedures voorgesteld voor het praktisch opzetten van een multicastboom in een actief netwerk, rekening houdend met de aanvragen van de gebruikers. Hierbij is eventueel de installatie van transcoderingen nodig in bepaalde knopen, waarbij moet nagegaan worden of er voldoende rekencapaciteit aanwezig is. Een aantal oplossingen worden onderzocht voor het verplaatsen van een transcodering naar een andere knoop, wanneer onvoldoende capaciteit voor handen is. De dynamiek van deze procedures wordt bestudeerd, zowel tijdens het initiële opzetten van de boom als tijdens het verloop van een sessie wanneer gebruikers de groep verlaten of vervoegen. De prestaties van de verschillende procedures worden geëvalueerd op basis van simulaties. Deze verschillende aspecten vormen ook het onderwerp van de publicaties van Appendix B, D en F. Tenslotte worden de belangrijkste resultaten en besluiten beschreven in Hoofdstuk 6.

1.4

Overzicht van de publicaties

De onderzoeksresultaten kaderend binnen dit doctoraat werden gepubliceerd in internationale tijdschriften. Ze werden tevens gepresenteerd in een aantal internationale conferenties rond het thema van telecommunicatie en computercommunicatie. Onderstaande lijst geeft een overzicht van de publicaties die resulteerden uit het beschreven onderzoek. • Stefaan Vanhastel, Bart Duysburgh, Piet Demeester, ”Performance measurements on the current Internet”, 7th Workshop on Performance Modeling and Evaluation of ATM&IP Networks - IFIP Working Conference TC6 (Communication Systems), June 28-30, 1999, Antwerp, Belgium. • Stefaan Vanhastel, Steven Van den Berghe, Bart Duysburgh, Piet Demeester, ”A distributed platform for monitoring and shaping data flows”, 8th Int. Conf. on Telecommunication Systems, Modeling and Analysis, March 9-12, 2000, Nashville, TN, USA, pp. 675-681. • Stefaan Vanhastel, Bart Duysburgh, Filip De Turck, Peter Vandaele, Cristinel Petrisor, Dimitri Dewinne, Piet Demeester, ”A detailed study of the suitability of different access technologies for VoIP delivery”, 5th European Conference on Networks and Optical Communications (NOC’2000), Edited by D.W. Faulkner and A.L. Harmer, IOS Press, 2000, June 6-9, 2000, Stuttgart, Germany, pp. 42-49. • Bart Duysburgh, Thijs Lambrecht, Bart Dhoedt, Piet Demeester, ”Data transcoding in multicast sessions in active networks”, Lecture

1-8

Hoofdstuk 1

Notes in Computer Science (LNCS 1942), Proceedings of the Second International Working Conference on Active Networking, IWAN 2000, Springer-Verlag Berlin Heidelberg 2000, ISBN 3-540-41179-8, October 2000, Tokyo, Japan, pp. 130-144. • Filip De Turck, Stefaan Vanhastel, Peter Backx, Bart Duysburgh, Piet Demeester , ”Design of a generic architecture for service management and monitoring of service level agreements through distributed intelligent agents”, Proceedings of the IEEE Intelligent Network 2001 Workshop, IN2001, ISBN 0-7803-7047-3, May 6-9, 2001, Boston, MA, pp. 50-57. • Koen Cooreman, Thijs Lambrecht, Bart Duysburgh, Peter Backx, Piet Demeester, ”ARAN: An active routing protocol for wireless ad hoc networks”, Proceedings of the IEEE 2001 International Conference on Third Generation Wireless and Beyond, 3GWireless01, May 30 - June 2, 2001, San Francisco, USA, pp. 693-698. • Bart Duysburgh, Stefaan Vanhastel, Bart De Vreese, Cristinel Petrisor, Piet Demeester, ”On the influence of the best-effort network conditions on the perceived speech quality of VoIP connections”, 10th Int. Conf. on Computer Communications and Networks, ICCCN 2001, ISBN 0-7803-7128-3, 15-17 October, 2001, Scottsdale, AZ, USA, pp. 334-339. • Thijs Lambrecht, Peter Backx, Bart Duysburgh, Liesbeth Peters, Bart Dhoedt, Piet Demeester, ”Adaptive distributed caching on an active network”, Lecture Notes in Computer Science (LNCS 2207), Proceedings of the Third International Working Conference on Active Networking, IWAN 2001, Springer-Verlag Berlin Heidelberg 2001, ISBN 3-540-42678-7, September 30 - October 2, 2001, Philadelphia, PA, USA. • Bart Duysburgh, Thijs Lambrecht, Bart Dhoedt, Piet Demeester, ”Distributed tree setup strategies for active multicast services with transcoding capabilities”, Conference proceedings of Eurescom 2002 Powerful Networks for Profitable Services, ISBN 3-8007-2727-7, October 21-24, 2002, Heidelberg, Germany, pp. 281-289. • Bart Duysburgh, Thijs Lambrecht, Bart Dhoedt, Piet Demeester, ”On the quality and performance of active networking based media transcoding in multicast sessions”, 7th Int. Conf. on Telecommunications, ConTEL 2003, ISBN 953-184-052-0, 11-13 Juni, 2003, Zagreb, Croatia, pp. 455-462.

Inleiding

1-9

• Bart Duysburgh, Thijs Lambrecht, Filip De Turck, Bart Dhoedt, Piet Demeester, ”An active networking based service for media transcoding in multicast sessions”, Accepted for publication in IEEE Transactions on Systems, Man and Cybernetics, Part C, Special issue on Computational Intelligence in Telecommunications Networks and Internet Services. • Thijs Lambrecht, Bart Duysburgh, Tim Wauters, Filip De Turck, Bart Dhoedt, Piet Demeester, ”Optimizing Multimedia Transcoding Multicast Trees”, Submitted for publication in Elsevier Computer Networks Magazine. • Bart Duysburgh, Thijs Lambrecht, Filip De Turck, Bart Dhoedt, Piet Demeester, ”On the performance of Application Level Routing solutions”, Submitted for publication in Elsevier Computer Communications Magazine. • Bart Duysburgh, Thijs Lambrecht, Filip De Turck, Bart Dhoedt, Piet Demeester, ”Design and analysis of a stable set-up protocol for transcoding multicast trees in active networks”, Submitted for publication in Elsevier Journal of Network and Computer Applications. • Bart Duysburgh, Thijs Lambrecht, Peter Backx, Koen Cooreman, Bart Dhoedt, Piet Demeester, ”Active networks for advanced service deployment”, 1st FTW PHD Symposium, paper 9, December 2000, Gent, Belgium. • Peter Backx, Bart Duysburgh, Thijs Lambrecht, Liesbeth Peters, Tim Wauters, Bart Dhoedt, Piet Demeester, ”Enhanced applications through active networking”, 2nd FTW PHD Symposium, paper 99, December 2001, Gent, Belgium. • Bart Duysburgh, Thijs Lambrecht, Bart Dhoedt, Piet Demeester, ”An active networking based service for media transcoding in multicast sessions”, 3rd FTW PHD Symposium, paper 24, December 2002, Gent, Belgium. • Bart Duysburgh, Thijs Lambrecht, Bart Dhoedt, Piet Demeester, ”Network hosted transcoding services for optimised delivery of multimedia streams”, Submitted for presentation at the 4th FTW PHD Symposium, December 2003, Gent, Belgium.

1-10

Hoofdstuk 1

Referenties [1] V. Cerf, How the Internet came to be, Article published in ”The Online User’s Encyclopedia”, Bernard Aboba, Addison-Wesley, ISBN 0-201-62214-9, November 1993, http://www.netvalley.com/archives/mirrors/cerf-how-inet.txt. [2] DARPA: Defense Advanced http://www.darpa.mil.

Research

Projects

Agency,

[3] J. M. Bradshaw (Ed.), Software Agents, Published by the AAAI Press/The MIT Press, ISBN 0-262-52234-9, 1997. [4] V. A. Pham, A. Karmouch, Mobile Software Agents: an overview, IEEE Communications Magazine, July 1998, pp.26-37. [5] A. A. Lazar, Programming Telecommunication Networks, IEEE Network Magazine, September/October 1997, pp. 8-18. [6] J. Biswas, J.-F. Huard, A. A. Lazar, K. Lim, S. Mahjoub, L.-F. Pau, M. Suzuki, S. Torstensson, W. Wang, S. Weinstein, Application Programming Interfaces for Networks, White Paper, Working Group for IEEE P1520, 1999, http://www.ieee-pin.org/pinwp7.pdf. [7] J. Biswas, A. A. Lazar, J.-F. Huard, K. Lim, S. Mahjoub, L.-F. Pau, M. Suzuki, S. Torstensson, W. Wang, S. Weinstein, The IEEE P1520 Standards Initiative for Programming Network Interfaces, IEEE Communications Magazine, October 1998, pp. 64-70. [8] D. Tennenhouse. et al., A survey of active network research, IEEE Communications Magazine, January 1997, pp.80-86. [9] J. M. Smith, K. L. Calvert, S. L. Murphy, H. K. Orman , L. L. Peterson, Activating Networks: A Progress Report, IEEE Computer Magazine, April 1999, pp.32-41. [10] K. L. Calvert, S. Bhattacharjee, E. Zegura, J. Sterbenz, Directions in Active Networks, IEEE Communications Magazine, October 1998, pp.72-78. [11] K. Psounis, Active Networks: Applications, Security, Safety, and Architectures, IEEE Communications Surveys, http://www.comsoc.org/livepubs/surveys/, First Quarter 1999. [12] IETF: Internet Engineering Task Force, http://www.ietf.org.

Inleiding

1-11

[13] TERENA: Trans-European-Research and Education Networking Association, http://www.terena.nl. [14] CNN.com, http://www.cnn.com. [15] BBC news, http://news.bcc.co.uk. [16] VRTnieuws.net, http://www.vrtnieuws.net. [17] Rock Werchter live streaming, http://www.rockwerchter.be.

2 Geavanceerde netwerkdiensten gebaseerd op Actieve Netwerken

D

E grote toename van de populariteit van het Internet halfweg de jaren negentig zorgde ervoor dat een aantal essentiële problemen van de bestaande netwerkinfrastructuur aan het licht kwamen. Het gebrek aan functionaliteit en flexibiliteit in het netwerk bleek immers een obstakel bij het uitbreiden van de infrastructuur en het invoeren van nieuwe en geavanceerde diensten. Aangezien hierdoor de verdere evolutie van het Internet belemmerd wordt, startten een aantal inspanningen om aan dit fundamenteel probleem te verhelpen. Als oplossing werden een aantal nieuwe netwerkconcepten voorgesteld waarvan Actieve Netwerken het meest radicale is. Dit hoofdstuk beschrijft de basisconcepten van deze Actieve Netwerken. De structuur en de werking van een actieve knoop en van actieve pakketten worden besproken en mogelijke toepassingen worden voorgesteld. Tevens wordt ingegaan op een zakenmodel voor het gebruik van Actieve Netwerken. Tot slot wordt de geavanceerde netwerktoepassing ge¨ıntroduceerd die het verder onderwerp van dit werk uitmaakt.

2-2

2.1

Hoofdstuk 2

Nieuwe netwerkconcepten: een logische evolutie

Halfweg de jaren negentig won het Internet op kort tijd enorm aan populariteit. Een toenemend aantal gebruikers werd verbonden met het Internet en in de zakenwereld werd steeds meer gebruik gemaakt van de moderne communicatieinfrastructuur. Gestimuleerd door de liberalisering en de deregularisering van de communicatiemarkt en de hierdoor toenemende concurrentiestrijd tussen gevestigde en nieuwe spelers raakte de informatisering van de maatschappij in een stroomversnelling. Door deze evolutie ontstond er een steeds dringender vraag naar de ontwikkeling en invoering van nieuwe en geavanceerde toepassingen. Enerzijds had de zakenwereld nood aan nieuwe en aangepaste netwerkdiensten ter ondersteuning van hun steeds evoluerende bedrijfsprocessen. Anderzijds gingen ISP’s op zoek naar toepassingen om nieuwe klanten te lokken en nieuwe bronnen van inkomsten aan te boren op basis van de grote groep potentiële gebruikers op het Internet. Ondanks deze belangrijke drijfveren werd deze evolutie echter sterk gehinderd door een aantal fundamentele eigenschappen van de traditionele communicatienetwerken. Ten eerste verloopt de ontwikkeling en de invoering van nieuwe netwerkdiensten of protocollen zeer traag. Om redenen van interoperabiliteit moet er immers tussen de betrokken partijen in de industrie een standaard afgesproken worden. Ten gevolge van dit standaardisatieproces dat typisch binnen organisaties als IETF [1], ITU [2] of ETSI [3] geco¨ ordineerd wordt, moeten netwerkbeheerders lange tijd wachten vooraleer ze een commerciële implementatie kunnen installeren. Ten tweede is de installatie van nieuwe apparatuur en functionaliteit in het netwerk een tijdrovende taak, waarbij meestal in elke afzonderlijke component een tussenkomst van de beheerder vereist is. Ten derde is het niet voor de hand liggend om geavanceerde diensten te ondersteunen door het grote gebrek aan flexibiliteit in de huidige netwerkarchitecturen. De enige taak van het netwerk is immers het transporteren van pakketten tussen verschillende locaties, terwijl de eigenlijke functionaliteit van de toepassingen zich bevindt in de machines aan de rand van het netwerk. Geavanceerde toepassingen die steeds meer gebruik maken van bijkomende verwerking en functionaliteit in het netwerk zijn dan ook moeilijk te ondersteunen. Bijgevolg is er in toekomstige netwerken nood aan een flexibel raamwerk dat toelaat vlot nieuwe diensten in te voeren zonder hinder van het trage standaardisatieproces. Bovendien moet het configureren van netwerkapparatuur en het toevoegen van nieuwe functionaliteit eenvoudig ondersteund worden. Verder is het nodig meer functionaliteit in het netwerk te brengen


2-3

en af te stappen van het principe dat de intelligentie van de toepassing zich enkel in de machines aan de rand van het netwerk bevindt. In het huidige Internet worden reeds een aantal ad-hocoplossingen gebruikt met het oog op de verbetering van de bestaande netwerkdiensten. Belangrijke voorbeelden zijn firewalls, webproxy’s, webcaches en application gateways die gericht op bepaalde toepassingen zorgen voor extra functionaliteit in het netwerk. Firewalls zijn geavanceerde routers die lokale netwerken beschermen tegen indringers door het verkeer te filteren en ongewenste verbindingen af te breken op basis van regels die door de gebruiker gespecificeerd worden. Webproxy’s en webcaches maken het afhalen van webpagina’s sneller en efficiënter door de communicatie met webservers af te handelen in de proxy en vaak gevraagde pagina’s tijdelijk lokaal te bewaren in de cache. Een aanvraag voor een lokaal bewaarde pagina kan dan onmiddellijk beantwoord worden. In application gateways wordt specifieke toepassingsfunctionaliteit voorzien, zoals transcoderingsmogelijkheden voor audiovisuele media. Gedreven door de vastgestelde beperkingen van de bestaande netwerkinfrastructuur en ge¨ınspireerd door de reeds gebruikte ad-hocoplossingen werden in 1994 en 1995 vanuit de discussies binnen de DARPA-gemeenschap (Defense Advanced Research Project Agency) [4] drie nieuwe concepten gesuggereerd: Mobiele Software Agenten [5, 6], Programmeerbare Netwerken [7–9] en Actieve Netwerken [10–13]. De eerste oplossing steunt op het gebruik van mobiele code om meer flexibiliteit en functionaliteit in het netwerk te brengen. De tweede gaat uit van open, gestandardiseerde programmeerinterfaces op netwerkapparatuur om een dynamische configuratie en installatie van het netwerk te verkrijgen. De onderliggende concepten en mogelijkheden van Actieve Netwerken worden in de volgende paragrafen beschreven.

2.2 2.2.1

Actieve Netwerken Concept en motivering

Het concept van Actieve Netwerken komt voort uit de bovenvermelde discussies binnen DARPA rond de toekomst van netwerkgebaseerde systemen. Onder de noemer van Actieve Netwerken werden een aantal strategieën voorgesteld die het onderwerp werden van een door DARPA gesponsord onderzoeksprogramma. De doelstelling van het programma was de ontwikkeling van een flexibel en in ware tijd aanpasbaar netwerkplatform dat toelaat de snelle evolutie van netwerkgebaseerde systemen te volgen, eenvoudig nieuwe technologieën toe te voegen en te beantwoorden aan de vraag

2-4

Hoofdstuk 2

Passieve netwerkknoop

Actieve netwerkknoop

Verwerking actief passief

IN

Routering & Verzending (a)

UIT

IN

Routering & Verzending

UIT

(b)

Fig. 2.1: Illustratie van het Store and Forward principe en het Store, Compute and Forward principe.

naar steeds gesofisticeerder toepassingen. Om dit te bereiken steunen Actieve Netwerken enerzijds op de concepten van mobiele code en open programmeerinterfaces. Anderzijds gaan ze uit van de radicale veronderstelling dat elk pakket dat het netwerk doorkruist een programma kan bevatten en dat dit programma in elke knoop van het netwerk kan worden uitgevoerd. De pakketten die naast gegevens ook een programma met zich meedragen, worden actieve pakketten of capsules genoemd. Hierbij wordt het Store and Forward principe dat traditioneel aan de basis ligt van het huidige Internet vervangen door het Store, Compute and Forward principe. Dit houdt in dat bij aankomst van een actief pakket in een knoop de meegedragen code in een uitvoeringsomgeving verwerkt wordt. Na de uitvoering wordt het pakket verdergezonden naar zijn bestemming. Bijgevolg dient het netwerk niet meer exclusief voor het transport van pakketten maar wordt het mogelijk in de knopen bepaalde beslissingen te nemen of bijkomende verwerking uit te voeren. Deze knopen worden actieve knopen genoemd. Beide principes zijn voorgesteld in Figuur 2.1. Hoewel het concept van Actieve Netwerken duidelijk revolutionair is, is het desondanks het resultaat van een logische evolutie in het domein van de computernetwerken. Het Internet, gebaseerd op het Internet Protocol (IP) [14], kan reeds gezien worden als een eenvoudige vorm van Actieve Netwerken, waarbij het programma in een pakket bestaat uit het IP-adres en poortnummer van de bestemming in de pakkethoofding. Op basis van dit programma wordt het pakket in een knoop verdergezonden in de richting van zijn bestemming. Recent werd dit IP-routeringsproces uitgebreid met ondersteuning voor Quality of Service (QoS) [15], bijvoorbeeld door middel


2-5

van Differentiated Services [16]. In dit geval wordt bij het verzenden van een pakket in een knoop eveneens rekening gehouden met de informatie in het TOS-veld (Eng.: Type Of Service) van de IP-pakkethoofding en wordt de verwerking in de knoop aangepast aan het gespecificeerde QoS-niveau. In Actieve Netwerken trekt men deze trend door tot in het extreme. Pakketten dragen volledige programma’s met zich mee die hun gedrag in de knopen bepalen. De hoeksteen van het concept Actieve Netwerken is de actieve knoop, die zowel de klassieke routeringsfunctionaliteit als de bijkomende verwerkingsmogelijkheden voorziet. Daarom werd een algemene architectuur voor een actieve knoop ontwikkeld, waarbinnen de functionele componenten en hun specifieke interfaces worden gedefinieerd. Om de architectuur zo flexibel mogelijk te maken, is ze moedwillig zeer algemeen gehouden door enkel een verzameling van functionele blokken te specificeren. Daardoor blijven echter heel wat aspecten betreffende het ontwerp en de implementatie open voor discussie.

2.2.2

Architectuur voor Actieve Netwerken

De bedoeling van deze architectuur [17] is de definitie van een gemeenschappelijke basisfunctionaliteit voor elke actieve knoop. Hierbij wordt in algemene lijnen vastgelegd hoe toepassingen de mogelijkheden van een actief netwerk kunnen aanspreken, hoe pakketten in een actieve knoop verwerkt worden, welke hulpmiddelen in de knopen aanwezig zijn en hoe deze gebruikt kunnen worden. Daarvoor worden de basiscomponenten van de actieve knoop bepaald evenals de interfaces waarlangs ze aangesproken kunnen worden. De architectuur voorgesteld door de DARPA-gemeenschap is ge¨ıllustreerd in Figuur 2.2. De functionaliteit van de actieve knoop is verdeeld over twee grote blokken: een aantal uitvoeringsomgevingen (Eng.: Execution Environment, EE) en het knoopbesturingssysteem (Eng.: Node Operating System, NodeOS). Elk van deze blokken verzorgt een interface waarlangs zijn functionaliteit en diensten aangesproken kunnen worden. De NodeOS beheert de toegang tot de middelen en diensten van de knoop en biedt een interface naar de EE’s toe. Op basis van de middelen geboden via deze EE-NodeOS interface verzorgen de EE’s een omgeving met de specifieke functionaliteit van Actieve Netwerken. Binnen deze omgeving wordt meer bepaald een programmeerinterface of API (Eng.: Application Programming Interface) voor Actieve Netwerken voorzien. Op basis van deze interface kunnen toepassingen op de knoop of actieve pakketten afkomstig van deze toepassingen de actieve functionaliteit in de EE’s aanspreken. Langs deze weg krijgen ISP’s en ontwikkelaars van algemene netwerkdiensten of individuele gebruikers die een eigen specifieke toepassing op het

2-6

Hoofdstuk 2

netwerk uitvoeren toegang tot de actieve functionaliteit en men spreekt bijgevolg van de gebruiker-EE interface. Op basis van deze architectuur ligt de enige behoefte aan standaardisatie bij de minimale definitie van deze twee interfaces. Buiten deze minimale interfaces die in elke implementatie van een actieve knoop aanwezig moeten zijn, wordt verder niets vereist wat betreft de programmeertaal of de totale complexiteit van de API in de EE of de volledige interface van de NodeOS. Daardoor wordt de hoeveelheid afspraken en standaardisatie beperkt die nodig zijn om een actieve knoop te kunnen implementeren.

Toepassing

Toepassing Gebruiker-EE interface

Uitvoeringsomgeving

Uitvoeringsomgeving

Uitvoeringsomgeving EE-NodeOS interface

Knoopbesturingssysteem

kanalen

dradenvoorraden

geheugenvoorraden

Knoopmiddelen CPU netwerkinterfaces

geheugen

Fig. 2.2: De algemene architectuur van een actieve knoop.

Uitvoeringsomgeving De EE voorziet een omgeving waarbinnen actieve pakketten ontvangen worden en de programma’s die ze meedragen uitgevoerd kunnen worden. Deze programma’s kunnen gebruik maken van de middelen en diensten die de EE ter beschikking stelt via zijn API. Op basis daarvan kunnen de actieve pakketten geavanceerde toepassingsfunctionaliteit in de EE uitvoeren. De API kan ondermeer functionaliteit voorzien voor het manipuleren van pakketten, voor het beheer van gegevens op een knoop of voor het aanspreken van algemene lokale informatie. Zo kan men via de API bijvoorbeeld de inhoud van pakketten aanpassen, pakketten dupliceren of ze verderzenden. Ook kan men eventueel bepaalde gegevens opslaan op een knoop of deze gegevens raadplegen of wijzigen. Verder kan men algemene gegevens opvragen zoals de routeringstabel, de lokale tijd of het gebruik van de middelen in de knoop.


2-7

De API kan zeer eenvoudig gebaseerd zijn op een aantal parameters in de actieve pakketten die aangeven welke lokale functionaliteit wordt aangesproken en met welke argumenten. Anderzijds kan in de EE ook een volledige omgeving voorzien worden waarbinnen programma’s in een volwaardige en complexe programmeertaal worden ge¨ınterpreteerd en uitgevoerd. Op een netwerkknoop kunnen meerdere instanties van dezelfde EE voorzien worden zodat verschillende toepassingen die op dezelfde EE gebaseerd zijn naast elkaar uitgevoerd kunnen worden, zonder met elkaar te interfereren. Anderzijds voorziet de architectuur ook expliciet de mogelijkheid om simultaan verschillende API’s te ondersteunen door het gebruik van meerdere verschillende EE’s naast elkaar, die elk een verschillende API implementeren. Dit laat toe verschillende prototypes van Actieve Netwerken te ontwikkelen en te implementeren, elk met een specifieke aanpak en doelstelling. Bovendien wordt op die manier een evolutionair pad ingebouwd, waardoor nieuwe functionaliteit of diensten ingevoerd kunnen worden door eenvoudig een nieuwe API in een extra EE toe te voegen. Knoopbesturingssysteem Het knoopbesturingssysteem [18] voorziet de basisfunctionaliteit van de knoop die binnen de EE’s gebruikt wordt om een API voor Actieve Netwerken op te bouwen. De belangrijkste taak van het besturingssysteem is het controleren van de middelen van de actieve knoop en het afhandelen van de aanvragen voor het gebruik van ondermeer netwerkcapaciteit, verwerkingscapaciteit en geheugenruimte. Deze middelen worden binnen de architectuur geabstraheerd tot respectievelijk kanalen (Eng.: channels), dradenvoorraden (Eng.: thread pools) en geheugenvoorraden (Eng.: memory pools). Om de controle over het geheel van deze middelen te vereenvoudigen, worden deze drie abstracties samengebracht in een vierde abstractie: stromen (Eng.: flows). Deze stromen hangen nauwer samen met de manier waarop in werkelijkheid steeds een aantal beschikbare middelen gecombineerd worden wanneer ze door een toepassing gebruikt worden. De betekenis van deze abstracties wordt nu kort toegelicht. • Kanalen worden gebruikt om pakketten te verzenden, te ontvangen of verder te zenden. Kanalen zijn gekenmerkt door een richting die bepaalt of ze pakketten invoeren naar de EE, uitvoeren van de EE of doorvoeren door de EE. Bij het creëren van een kanaal wordt gespecificeerd welke specifieke pakketten erlangs getransporteerd worden en indien nodig wordt bandbreedte in het netwerk gereserveerd evenals geheugenruimte voor buffers in de knopen. • Draden en geheugen zijn nauw met elkaar verbonden aangezien ze steeds gecombineerd moeten worden om de verwerkingscapaciteit te

2-8

Hoofdstuk 2

realiseren. Draden komen overeen met lichtgewicht processen waarbinnen een bepaalde hoeveelheid van de beschikbare rekencapaciteit van de verwerkingseenheid kan gebruikt worden. De vereiste rekencapaciteit voor de verwerking van pakketten binnen een bepaalde stroom kan voorzien worden door een dradenvoorraad aan te maken. Bij het creëren van een dradenvoorraad wordt het maximum aantal draden, de snelheid waarmee processorcycli gebruikt worden, het totaal aantal beschikbare cycli en een schedulingmechanisme bepaald. Bij het aanmaken van een geheugenvoorraad wordt een aantal pagina’s in het geheugen gealloceerd die tijdens het uitvoeren van programma’s gebruikt kunnen worden. • Stromen zorgen voor een extra niveau van abstractie zodat ondermeer het bijhouden van een boekhouding van de verbruikte middelen en een systeem van toegangscontrole mogelijk worden. Voor een stroom wordt steeds een aggregaat van de verschillende systeemmiddelen gealloceerd. Dit bestaat typisch uit een invoeren uitvoerkanaal, een geheugenvoorraad en een dradenvoorraad. Actieve pakketten worden ontvangen langs het invoerkanaal, de pakketten worden verwerkt met gebruik van de geheugen- en dradenvoorraad en ze worden verzonden langs het uitvoerkanaal. Om de toegang tot de middelen van de knoop af te handelen en te controleren is in het knoopbesturingssysteem een beveiligingsmodule voorzien die de beveiligingspolitiek [19] moet opleggen. Elke aanvraag door een EE voor het gebruik van bepaalde middelen moet steeds vergezeld zijn van een identificatie van de gebruiker of de entiteit die oorspronkelijk de middelen heeft aangevraagd. Op basis van deze identificatie zal de beveiligingsmodule de authenticiteit van de aanvrager verifiëren en nagaan of deze toelating heeft om de gevraagde middelen te gebruiken. Hierbij kunnen ook beperkingen opgelegd worden met betrekking tot de hoeveelheden waartoe de aanvrager toegang heeft. Pakketten moeten bij aankomst in een knoop naar het geschikte kanaal gestuurd worden, zodat ze in de juiste uitvoeringsomgeving terechtkomen. Daarom voorziet de NodeOS een classificatiemodule die op basis van de bestaande kanalen en de bijhorende specificaties betreffende de te verwerken pakketten een beslissing neemt. Passieve pakketten worden langs een snel doorvoerkanaal verwerkt dat overeenkomt met de klassieke IP-doorvoerdienst. Actieve pakketten worden op basis van een bepaald patroon, meestal bestaande uit specifieke waarden van een aantal velden van de pakkethoofding, gezonden naar een specifiek kanaal.


2-9

Om een aanvaardbaar kwaliteits- en prestatieniveau te garanderen beschikt het besturingssysteem over verschillende schedulingmechanismen die de toegang tot de verwerkings- en netwerkmiddelen bepalen. Deze zorgen ervoor dat het verkeer van verschillende gebruikers van elkaar gescheiden wordt, zodat iedereen schijnbaar de beschikking heeft over een eigen virtuele uitvoeringsomgeving of virtuele verbinding.

2.2.3

Aspecten van ontwerp en implementatie

Kenmerken van de API voor Actieve Netwerken De programmeerinterface voor Actieve Netwerken die in de EE’s voorzien worden, kunnen heel verscheiden zijn naar gelang de EE. Deze verschillen kunnen specificeerd worden aan de hand van de volgende kenmerken. • Expressiviteit van de programmeertaal De mate van programmeerbaarheid van de API kan gaan van een eenvoudige lijst van parameters die zorgen voor de selectie van een bepaalde functionaliteit in de knoop tot een complexe programmeertaal die toelaat om het even welke procedure te beschrijven. Een eenvoudige taal beperkt het mogelijke gedrag van de knoop, zodat verificatie van het correcte gedrag haalbaar is en de mogelijkheden tot misbruik van de API beperkt worden. Het gebruik van een complexe programmeertaal maakt veel krachtiger programma’s mogelijk, maar men moet bepaalde beperkingen opleggen zodat de invloed van een pakket op het netwerk binnen de perken blijft. • Bewaren van toestandsinformatie Voor sommige toepassingen kan het nodig zijn een hoeveelheid toestandsinformatie bij te houden op verschillende knopen. Deze mogelijkheid kan al dan niet voorzien worden binnen de API. Hierbij is een zekere vorm van toegangscontrole vereist naargelang de informatie bereikbaar is voor alle pakketten of slechts voor een bepaald type. Een controlemechanisme zorgt daarbij voor authentisering en authorisatie bij het opvragen en wijzigen van de informatie. • Granulariteit van de controle Dit slaat op de reikwijdte van de acties uitgevoerd door de actieve pakketten. Enerzijds kan een aanpassing van het knoopgedrag door één pakket een invloed hebben op alle pakketten die de knoop passeren. Anderzijds kan een programma uitgevoerd door een pakket enkel het gedrag van dat ene pakket be¨ınvloeden. Tussen deze extremen kan bijvoorbeeld het knoopgedrag aangepast worden voor de verwerking van een stroom pakketten. In elk geval moet er in de API een beveiligingsmechanisme voorzien

2-10

Hoofdstuk 2

worden zodat aanpassingen van het knoopgedrag afkomstig zijn van geauthoriseerde gebruikers en enkel een effect hebben op de beoogde pakketten of stromen. Discrete of ge¨ıntegreerde aanpak • Discrete aanpak Hierbij wordt de verwerking van pakketten in een knoop strikt gescheiden van het proces waarbij programma’s en functionaliteit in het netwerk gebracht worden. De controle en configuratie van het netwerk gebeurt bijgevolg door een out-of-band mechanisme zoals in de klassieke infrastructuur. In dit geval worden de nodige programma’s in bepaalde knopen ge¨ınstalleerd vooraleer de eigenlijke data verzonden worden. In de knopen wordt dan op basis van een classificatiemechanisme het geschikte programma opgeroepen en uitgevoerd. De scheiding van de installatie en de uitvoering van extra programma’s zorgt ervoor dat de controle van het installatieproces van functionaliteit in het netwerk op basis van een strikte authentisering en authorisatie eenvoudiger en minder belastend voor het netwerk wordt. Deze aanpak is vooral geschikt voor het aanpassen van het knoopgedrag voor een langere duur of als een geavanceerde manier voor de configuratie van het netwerk. Bijgevolg is dit mechanisme vooral geschikt voor operatoren en ISP’s die op deze manier de communicatieinfrastructuur dynamisch kunnen uitbreiden en toepassingsgerichte functionaliteit kunnen toevoegen of aanpassen. Deze aanpak leunt dicht aan bij het concept van Programmeerbare Netwerken. • Ge¨ıntegreerde aanpak Dit is de meest radicale benadering van Actieve Netwerken, waarbij elk pakket naast de gegevens een programma bevat. Wanneer een pakket aankomt in een actieve knoop wordt het programma eruit ge¨ısoleerd en wordt het vervolgens uitgevoerd in een afzonderlijk omgeving. Hoewel dit de meest flexibele aanpak is, brengt deze ook de meeste veiligheidsrisico’s met zich mee. Door de programma’s in de pakketten kunnen gebruikers immers toestandsinformatie in de knopen vervalsen of de beschikbare middelen nodeloos verbruiken. De strenge eisen aan de beveiligingsmechanismen die hiervan het gevolg zijn en het feit dat de programma’s voor elk pakket afzonderlijk opgeroepen moeten worden, zorgen voor een grote druk op de prestaties van dit systeem. Algemeen gezien verdient een gemengde aanpak de voorkeur. Op die manier kunnen lichtgewicht programma’s in de pakketten meegevoerd wor-

Geavanceerde netwerkdiensten gebaseerd op Actieve Netwerken 2-11

den, terwijl grote en complexe programma’s vooraf ge¨ınstalleerd kunnen worden via het out-of-band mechanisme. Beveiliging Beveiligingsmaatregelen in een netwerk hebben tot doel de goede en betrouwbare werking van het netwerk te verzekeren, evenals de authenticiteit, de integriteit en de geheimhouding van de getransporteerde gegevens. In traditionele netwerken beperkt deze beveiliging zich tot de bescherming van de data en de eindknopen van het netwerk. In een actief netwerk is het echter mogelijk dat ook de toestand of het gedrag van de netwerkknopen of de EE’s aangetast worden of dat de middelen van netwerkknopen onnodig verbruikt worden. Bijgevolg moet ook voor beveiliging in het netwerk gezorgd worden. De belangrijkste component van de beveiliging is de authorisatie, die erin bestaat toelating te verlenen aan entiteiten voor het gebruik van bepaalde middelen of diensten in de knoop of EE. Hierbij worden ook beperkingen opgelegd van de te gebruiken middelen. Zowel het knoopbesturingssysteem als elke EE afzonderlijk kan een authorisatiepolitiek opleggen, waarbij de politiek van de EE’s deze van de NodeOS mag verstrengen maar niet mag omzeilen.

2.2.4

Beschikbare platformen voor Actieve Netwerken

In Tabel 2.1 worden de belangrijkste platformen voor Actieve Netwerken kort beschreven aan de hand van de hierboven besproken kenmerken: (1) programmeertaal, (2) toestandsinformatie, (3) controle, (4) ge¨ıntegreerde of discrete aanpak en (5) beveiliging.

2.2.5

Zakenmodel voor Actieve Netwerken

In een zakenmodel voor netwerkdiensten spelen de volgende partijen een rol. Een dienstaanbieder (Eng.: service provider) biedt netwerkdiensten aan en onderhandelt met de klanten of gebruikers over de vereiste eigenschappen van de dienst. Voor de functionaliteit van deze dienst kan gesteund worden op een combinatie van netwerkconnectiviteit, verwerkingsmiddelen, inhoud en specifieke toepassingsfunctionaliteit, die respectievelijk verstrekt worden door connectiviteitsaanbieders, rekenkrachtaanbieders, inhoudaanbieders en toepassingsaanbieders (Eng.: connectivity providers, computational resource providers, content providers, application service providers). Bovendien kan een klant ook een dienst aanvragen bij een dienstmakelaar (Eng.: service broker) die verschillende diensten van meerdere dienstaanbieders ter beschikking stelt. Hierbij dient opgemerkt dat één aanbieder verschillende rollen kan vervullen en dat dus bijvoorbeeld een dienstaanbieder tegelijk de rol van connectiviteitsaanbieder kan vervullen.

2-12

Hoofdstuk 2

TABEL 2.1: Overzicht van belangrijkste platformen voor Actieve Netwerken Platform ANTS [20]

Switchware [21]

NetScript [22]

Smart Packets [23]

Kenmerken API 1. Verwerkingsroutine per pakket in Java 2. Soft-state cache in elke knoop 3. Per protocolgroep 4. Zowel ge¨ıntegreerd d.m.v. capsules als discreet d.m.v. extensies 5. Integriteit van code d.m.v. fingerprinting; beperking controle tot protocol; beperking uitvoeringstijd en levensduur van capsules (TTL) 1. Gedrag van actieve pakketten beschreven door PLAN 2. Enkel toestand in extensies 3. Per namespace 4. Zowel ge¨ıntegreerd d.m.v. actieve pakketten als discreet d.m.v. actieve extensies 5. Sterke typering en beperkte functionaliteit in PLAN; beperking van gebruikte middelen 1. Netscript definieert stromen met specifieke verwerking door het verbinden van Virtual Network Engines (VNE) met Virtual Links 2. Enkel in VNE 3. Per datastroom (Dataflow) 4. Discreet d.m.v. VNE’s of boxes 5. Geen specifieke beveiliging 1. Hoog-niveautaal Sprocket en assemblertaal Spanner; voorziet enkel functionaliteit voor netwerkbeheer 2. Geen toestand 3. Toegangscontrolelijst 4. Ge¨ıntegreerd d.m.v. pakketten 5. Authorisatie van gebruikers d.m.v. publieke sleutel en integriteit van pakketten d.m.v. hash; beperkt gebruik van middelen en controle op correcte uitvoering

Binnen een zakenmodel waar de diensten door middel van een actief netwerk aangeboden worden, spelen deze partijen eveneens een rol. In dit geval verzorgt de dienstaanbieder diensten die gebruik maken van de onderliggende actieve netwerkinfrastructuur. Hierdoor kan een uitgebreider aanbod samengesteld worden van meer geavanceerde diensten die ondermeer gebruik maken van bijkomende verwerking in het netwerk. Bovendien kunnen nieuwe diensten vlot en flexibel ingevoerd worden, waardoor de dienstaanbieder vlug kan inspelen op nieuwe trends of wijzigende omstandigheden. Door het invoeren van nieuwe capsule- en extensiecode kunnen bestaande diensten eenvoudig uitgebreid worden of kunnen nieuwe diensten opgebouwd worden. Opnieuw kan de aanbieder gebruik maken van connectiviteit, verwerkingsmiddelen, inhoud en toepassingsfunctionaliteit aangeboden door verschillende partijen. In het geval van Actieve Netwerken zijn netwerkconnectiviteit en verwerkingsmiddelen echter sterk verweven aangezien naast de traditionele pakketverwerking ook bijkomende verwerking van de getransporteerde data in de netwerkknopen kan gebeuren. De middelen die bij deze netwerkgebonden verwerking betrokken zijn, worden dan ook samen aangeboden door een actievenetwerkenaanbieder, die beschikt over een infrastructuur voor Actieve Netwerken. Daarnaast kunnen echter


ook verwerkingsmiddelen verzorgd worden op specifiek daarvoor voorziene apparatuur door rekenkrachtaanbieders. Verder zijn binnen het aanbod van componenten voor toepassingsfunctionaliteit in dit geval ook capsules en extensies beschikbaar die door actievetoepassingenaanbieders worden verzorgd. Klanten kunnen enerzijds rechtstreeks onderhandelen met een dienstaanbieder over het gebruik van één van de aangeboden diensten of ze kunnen anderzijds een beroep doen op een dienstmakelaar.

In dit model maakt enkel de dienstaanbieder echt gebruik van de nieuwe mogelijkheden geboden door Actieve Netwerken door het ontwikkelen van nieuwe en geavanceerde diensten die vlot ingevoerd kunnen worden. De klanten varen hier wel bij door het ruimere aanbod en het snellere inspelen op nieuwe eisen en trends. Voor sommige klanten kan het echter nog voordeliger zijn wanneer ze zelf hun eigen specifieke diensten kunnen ontwikkelen en opzetten op basis van Actieve Netwerken. Dit houdt echter in dat gebruikers een actievenetwerkendienst van een aanbieder verkrijgen, die de nodige connectiviteit en actieve mogelijkheden verzorgt. Binnen het verkregen pakket van verwerkingsmiddelen in de actieve knopen en de connectiviteit heeft de klant dan zelf alles in handen om zijn eigen dienst op te bouwen. Hierbij kan hij ook gebruik maken van specifieke capsules en extensies afkomstig van toepassingsaanbieders. Deze benadering is echter moeilijk haalbaar aangezien zeer zware eisen gesteld worden aan de controleen beveiligingsmechanismen in het netwerk. Aangezien per klant de beschikking over verwerkingsmiddelen van het netwerk gegeven wordt, is immers een zeer fijne granulariteit van controle en beveiliging vereist, waardoor ze zwaar en inefficiënt wordt.

Wanneer gebruikers of klanten toch alle mogelijkheden van Actieve Netwerken ter beschikking willen hebben, ligt de oplossing voorlopig in Actieve Netwerken in de applicatielaag (Eng.: Application Level Active Networks) [24]. Hierbij worden een aantal eindgebruikers via een virtueel actief netwerk met elkaar verbonden, gebaseerd op overlaytechnologie. Binnen een omgeving uitgevoerd in de applicatielaag van elke gebruikersmachine wordt een virtuele actieve knoop voorzien en de virtuele knopen worden verbonden via tunnels. Hoewel het netwerk enkel bestaat uit eindgebruikermachines kan men toch een willekeurige virtuele topologie opzetten en heeft men de vrijheid om alle mogelijkheden van Actieve Netwerken te gebruiken. De overlaytechnologie en de verwerking in de applicatielaag zorgt echter voor een belangrijke bijkomende belasting, waardoor de prestaties van Actieve Netwerken in de applicatielaag vooralsnog beperkt zijn.

2-14

2.2.6

Hoofdstuk 2

Mogelijke toepassingen gebaseerd op Actieve Netwerken

Betrouwbare multicast maakt gebruik van ACK- en NACK-boodschappen zoals bij TCP [25] om de zender duidelijk te maken of een pakket al dan niet ontvangen werd. Aangezien deze boodschappen allen tegelijk langs de multicastboom naar dezelfde zender teruggezonden worden, kan er echter een ACK- of NACK-explosie ontstaan in de zender, die hierdoor overbelast wordt. Bij actieve betrouwbare multicast [26] worden meerdere van deze boodschappen onderweg in de boom geaggregeerd tot één enkele boodschap, zodat slechts een beperkt aantal ACK’s of NACK’s de zender bereiken. Bij online veilingen zenden deelnemers een bod naar de server die vervolgens bevestigt of het bod hoog genoeg was om aanvaard te worden. Hierbij moet elk bod in de server vergeleken worden met het voorlopig hoogste bod, zodat zeer veel boodschappen ontvangen en verwerkt moeten worden. In een actief netwerk [27] kan men ook in de tussenliggende knopen het lokaal voorlopig hoogste bod bijhouden en elk nieuw bod ermee vergelijken. Zo wordt de belasting verdeeld over het netwerk en wordt de reactietijd van de bevestiging of afkeuring van een bod versneld. Netwerkcongestie kan in traditionele netwerken enkel opgelost worden door de snelheid waarmee pakketten in de eindpunten van de verbinding verzonden worden te verminderen. Bovendien is het vaststellen van de congestie een traag proces. Bij actieve congestiecontrole in een actief netwerk [28] kan men echter in de netwerkknopen vrij snel overbelasting vaststellen en kan vervolgens in de onmiddellijke omgeving van de overbelaste knoop actie ondernomen worden. Actieve webcaching [29] maakt gebruik van kleine caches verspreid over alle knopen van het netwerk waarin de populairste pagina’s tijdelijk opgeslagen worden. Om de efficiëntie en reactiesnelheid van het cachingsysteem te optimaliseren, worden de pagina’s dynamisch verplaatst naar de caches waar ze het meest gevraagd worden. Aggregatie en distributie van gegevens over een netwerk kan eenvoudig ondersteund worden in een actief netwerk. In elke knoop kunnen replica’s van ontvangen boodschappen verzonden worden naar meerdere bestemmingen. Anderzijds kunnen boodschappen met een zelfde bestemming tijdelijk vertraagd worden zodat op regelmatige tijdstippen enkel een geaggregreerde boodschap verzonden kan worden. Deze functionaliteit komt onder andere van pas bij het verzamelen van informatie voor netwerkbeheer [23] en bij multicastcommuicatie [30].


2.3

Een geavanceerde distributiedienst voor spraaksignalen met transcoderingsfunctionaliteit in de multicastboom

De doelstelling van deze toepassing is de simultane distributie van spraaksignalen naar een groep van ge¨ınteresseerde luisteraars. Hierbij kan bijvoorbeeld gedacht worden aan het live uitzenden van een toespraak of van een presentatie op een conferentie. In tegenstelling tot de traditionele toepassingen waarbij slechts één versie van de mediastroom verspreid wordt, is het de bedoeling meerdere formaten ter beschikking te stellen, zodat gebruikers een optimale keuze kunnen maken. Gebruikers kunnen het formaat kiezen dat het best beantwoordt aan de mogelijkheden van hun netwerkverbinding of computer of aan de gewenste kwaliteit. Hiervoor wordt gebruik gemaakt van een multicastboom om het signaal tegelijk naar verschillende ontvangers te zenden. In de boom wordt initieel slechts één formaat verzonden en door middel van transcoderingen in de tussenliggende knopen worden de overige gevraagde formaten afgeleid uit het originele signaal. Op die manier moet niet voor elk formaat een afzonderlijke boom opgezet worden, maar worden de formaten dynamisch gecreëerd in de boom op basis van extra functionaliteit die steunt op Actieve Netwerken. De spraakcodecs die voor deze toepassing geselecteerd werden, zijn opgesomd in Tabel 2.2. Deze waaier biedt zowel breedbandige codecs met bijna uitstekende kwaliteit als zeer smalbandige codecs met aanvaardbare kwaliteit. Binnen de multicastboom zal steeds initieel de aangevraagde codec met de hoogste bitrate verzonden worden. De codecs met lagere bitrates worden door transcoderingen aangemaakt. In Figuur 2.3(a) wordt een sessie van deze toepassing ge¨ıllustreerd zoals ze in een traditioneel netwerk ge¨ımplementeerd zou worden. Hierbij wordt voor elk formaat een afzonderlijke boom opgezet. In Figuur 2.3(b) wordt dezelfde sessie voorgesteld in een actief netwerk, waarbij slechts één boom

TABEL 2.2: Overzicht van beschikbare codecs binnen de toepassing

Codec PCM 16bit G.711 µ-Law [31] G.726-7 ADPCM 4bit [32, 33] G.728 [34] G.729 [35]

Bitrate 128 kbit/s 64 kbit/s 32 kbit/s 16 kbit/s 8 kbit/s

2-16

Hoofdstuk 2

Actieve knoop met transcoderingsfunctionaliteit

G.726-7

PCM 16bit

PCM 16bit G.726-7

PCM 16bit G G.726-7

G

PCM 16bit

G.728

G.726-7 G.726-7

A

B

C

(a)

G.728

G.726-7

G.728

G.728

D

E

F

A

B

C

D

E

F

(b)

Fig. 2.3: Illustratie van een geavanceerde dienst voor de distributie van spraaksignalen, beschikbaar in verschillende formaten, op een passief en een actief netwerk.

met transcoderingen opgezet wordt. Hoewel in dit werk specifiek naar de distributie van spraaksignalen gekeken wordt, kan deze dienst ook gebruikt worden voor de verspreiding van videosignalen of meer algemene multimediastromen. De haalbaarheid van de transcodering van deze stromen in ware tijd vormt hierbij echter een kritische factor. Zo komt het transcoderen van een spraaksignaal immers neer op een complexe bewerking waarbij het signaal eerst gedecodeerd wordt naar het basis PCM16bit-signaal vooraleer het gecodeerd wordt naar de nieuwe codec. Bijgevolg zorgt deze procedure voor een niet te verwaarlozen belasting op de netwerkknopen en houdt ze dus een beperking van de prestatie in. Voor het transcoderen van videosignalen naar lagere bitrates of een lagere kwaliteit zijn meerdere mogelijkheden voor handen. Bij de eenvoudigste aanpak gaat men uit van het feit dat een typisch videosignaal, bijvoorbeeld gecodeerd met de MPEG-codec [36], bestaat uit verschillende frames die elk een deel van de beeldinformatie bevatten. Door het verwijderen van bepaalde frames uit de stroom verkrijgt men een signaal met lagere bandbreedte en een lagere kwaliteit. Verder bestaan er technieken van gelaagde codering [37], waarbij het gecodeerde signaal bestaat uit een basislaag met minimale kwaliteit en een aantal optimalisatielagen voor de kwaliteit. Het volledige signaal heeft een goede kwaliteit en door het verwijderen van één of meerdere van de extra lagen kan men een signaal met lagere


bitrate en kwaliteit bekomen. Op basis van deze technieken komt het transcoderen van een videosignaal neer op een filteroperatie die slechts voor een beperkte belasting op de netwerkknopen zal zorgen. De resulterende kwaliteit, vooral in het eerste geval, zal echter heel snel onaanvaardbaar zijn. Een betere kwaliteit kan verkregen worden door meer geavanceerde technieken. Hierbij wordt onder andere gebruik gemaakt van het samenvoegen van kwantisatiestappen, het veranderen van de resolutie, het uitbuiten van FGS (Eng.: Fine Granularity Scalability) [38] en het gebruik van spatiale filtering. Deze complexe technieken vereisen echter uitgebreide berekeningen op de te transcoderen beelden, waarbij ook een aanzienlijke hoeveelheid geheugenruimte gebruikt wordt. Bijgevolg kunnen er vraagtekens geplaatst worden bij de haalbaarheid van deze transcoderingstechnieken in ware tijd. Tot slot kan de beschreven dienst ook uitgebreid worden voor het gebruik van transmodering in plaats van transcodering. Hierbij wordt bijvoorbeeld een videosignaal op basis van informatie in de stroom omgezet naar een tekstuele beschrijving of samenvatting die op een niet-grafisch toestel (bijvoorbeeld een gsm) kan worden weergegeven.

2-18

Hoofdstuk 2

Referenties [1] IETF: Internet Engineering Task Force, http://www.ietf.org. [2] ITU: International Telecommunication Union, http://www.itu.int. [3] ETSI: European Telecommunications http://www.etsi.org. [4] DARPA: Defense Advanced http://www.darpa.mil.

Research

Standards

Project

Institute,

Agency,

[5] J. M. Bradshaw (Ed.), Software Agents, Published by the AAAI Press/The MIT Press, ISBN 0-262-52234-9, 1997. [6] V. A. Pham, A. Karmouch, Mobile Software Agents: an overview, IEEE Communications Magazine, July 1998, pp.26-37. [7] A. A. Lazar, Programming Telecommunication Networks, IEEE Network Magazine, September/October 1997, pp. 8-18. [8] J. Biswas, J.-F. Huard, A. A. Lazar, K. Lim, S. Mahjoub, L.-F. Pau, M. Suzuki, S. Torstensson, W. Wang, S. Weinstein, Application Programming Interfaces for Networks, White Paper, Working Group for IEEE P1520, 1999, http://www.ieee-pin.org/pinwp7.pdf. [9] J. Biswas, A. A. Lazar, J.-F. Huard, K. Lim, S. Mahjoub, L.-F. Pau, M. Suzuki, S. Torstensson, W. Wang, S. Weinstein, The IEEE P1520 Standards Initiative for Programming Network Interfaces, IEEE Communications Magazine, October 1998, pp. 64-70. [10] D. Tennenhouse. et al., A survey of active network research, IEEE Communications Magazine, January 1997, pp.80-86. [11] J. M. Smith, K. L. Calvert, S. L. Murphy, H. K. Orman , L. L. Peterson, Activating Networks: A Progress Report, IEEE Computer Magazine, April 1999, pp.32-41. [12] K. L. Calvert, S. Bhattacharjee, E. Zegura, J. Sterbenz, Directions in Active Networks, IEEE Communications Magazine, October 1998, pp.72-78. [13] K. Psounis, Active Networks: Applications, Security, Safety, and Architectures, IEEE Communications Surveys, http://www.comsoc.org/livepubs/surveys/, First Quarter 1999.


[14] J. Postel, Internet Protocol - DARPA Internet Program Protocol Specification, RFC 791, USC/Information Sciences Institute, September 1981. [15] X. Xiao, L. M. Ni, Internet QoS: A Big Picture, IEEE Network Magazine, March 1999, pp.8-18. [16] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, An Architecture for Differentiated Services, RFC 2475, December 1998. [17] Active Network Working Group, Architectural framework for active networks, July 1999, http://www.dcs.uky.edu/ calvert/arch-latest.ps. [18] Active Network NodeOS Working Group, NodeOS interface specification, January 2001, http://www.dcs.uky.edu/ calvert/nodeoslatest.ps. [19] Active Network Security Working Group, Security architecture for Active Networks, November 2001, http://www.dcs.uky.edu/ calvert/seclatest.ps [20] D. Wetherall, J. Guttag, D. Tennenhouse, ANTS: A toolkit for building and dynamically deploying network protocols, IEEE OpenArch98, April 1998. [21] D. S. Alexander, W. A. Arbaugh, M. W. Hicks, P. Kakkar, A. D. Keromytis, J. T. Moore, C. A. Gunter, S. M. Nettles, J. M. Smith, The SwitchWare Active Network Architecture, IEEE Network Magazine, May/June 1998, pp.29-36. [22] Y. Yemini, S. da Silva, Towards programmable networks, IFIP/IEEE International Workshop on Distributed Systems: Operations and Management, October 1996. [23] B. Schwartz, W. Zhou, A. W. Jackson, Smart Packets for Active Networks, BBN Technologies, January 1998. [24] M. Fry, A. Ghosh, Application level active networking, Journal on Computer Networks, pp.655-667, 1999. [25] J. Postel, Transmission Control Protocol - DARPA Internet Program Protocol Specification, RFC 793, USC/Information Sciences Institute, September 1981. [26] L. H. Lehman, S. J. Garland, D. L. Tennenhouse, Active Reliable Multicast, IEEE INFOCOM98, March-April 1998, pp.581-589.

2-20

Hoofdstuk 2

[27] B. Shihada, Active Network Approach to the Design Of Secure Online Auction Systems, Master thesis, Dalhousie University, March 2001. [28] S. Bhattacharjee, K. Calvert, E. Zegura, Congestion Control and Caching in CANES, ICC98, 1998. [29] S. Bhattacharjee, K. Calvert, E. Zegura, Self-organizing wide-area network caches, IEEE INFOCOM98, March-April 1998, pp.600-608. [30] A. Banchs, W. Effelsberg, C. F. Tschudin, V. Turau, Multicasting Multimedia Streams with Active Networks, IEEE LCN98, October 1998, pp.150-159. [31] ITU-T, G.711: Pulse Code Modulation (PCM) of Voice Frequencies, ITU-T, 1972. [32] ITU-T, G.726: 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM), ITU-T, 1990. [33] ITU-T, G.727: 5-, 4-, 3-, and 2-bits Sample Embedded Adaptive Differential Pulse Code Modulation, ITU-T, 1990. [34] ITU-T, G.728: Coding of Speech at 16kbit/s Using Low-Delay Code Excited Linear Prediction, ITU-T, 1992. [35] ITU-T, G.729: Coding of Speech at 8kbit/s Using Conjugate Structure Algebraic-Code-Excited Linear-Prediction (CS-ACELP), ITU-T, 1996. [36] MPEG, Moving Picture Experts Group, http://www.cselt.it/mpgeg. [37] S. McCanne, M. Vetterli, V. Jacobson, Low-Complexity Video Coding for Receiver-Driven Layered Multicast, IEEE Journal of Selected Areas in Communications, 1997, pp.982-1001. [38] W. Li, Overview of fine granularity scalability in MPEG4 video standard, IEEE Transactions on Circuits and Systems for Video Technology, Mar. 2001, pp.301-317.

3

Prestatie-evaluatie van netwerkdiensten gebaseerd op routering in de applicatielaag

O

VERLAYNETWERKEN worden steeds meer gebruikt ter ondersteuning van nieuwe toepassingen in computernetwerken. Een overlaynetwerk wordt opgezet tussen een aantal computers, waarbij een virtueleknoopomgeving uitgevoerd wordt in de applicatielaag van elke computer en een virtueel netwerk voor de verbinding van de knopen zorgt. De populariteit van deze overlaytechnologie ligt in het feit dat snel en flexibel nieuwe functionaliteit ge¨ınstalleerd kan worden in een extra laag bovenop de bestaande infrastructuur, zonder dat aanpassingen in het onderliggende netwerk nodig zijn. Overlaynetwerken vinden ondermeer een toepassing bij het realiseren van multicastcommunicatie in de applicatielaag (Eng.: Application Layer Multicast) [1–3], CDN’s (Eng.: Content Distribution Networks) [4–6] en Peer-to-Peer-toepassingen [7–9]. Aangezien de knoopfunctionaliteit van een overlaynetwerk zich bevindt in de applicatielaag, wordt alle verkeer langs de applicatielaag gerouteerd. Deze niet-conventionele verwerking van de pakketten, die neerkomt op het ALR-concept (Eng.: Application Level Routing), zorgt voor een belangrijke druk op de prestaties van de knopen. Bijgevolg gaat de extra flexibiliteit verkregen door het overlayconcept deels ten koste van een verminderde prestatie in de virtuele knopen. Overlaynetwerken zijn in het kader van dit werk van belang om twee re-

3-2

Hoofdstuk 3

denen. Enerzijds is de actieveknoopimplementatie die in dit werk gebruikt werd bij experimenten en metingen gebaseerd op een actief overlaynetwerk. Anderzijds biedt het concept van overlaynetwerken een handige mogelijkheid om een aantal gebruikers met een actief netwerk te verbinden zonder belangrijke beperkingen vanuit het netwerk. In dit hoofdstuk wordt het ALR-concept uit de doeken gedaan en wordt een prestatie-evaluatie van een ALR-knoop voorgesteld. Deze prestatie-evaluatie wordt beschreven in de publicatie van Appendix E, waarnaar verwezen wordt voor meer gedetailleerde informatie. Eerst wordt echter een beschrijving van de actieveknoopimplementatie gegeven die gebaseerd is op overlaytechnologie en die binnen dit werk gebruikt werd voor een aantal experimenten en analyses.

3.1

Een actieveknoopimplementatie op basis van het ANTS-platform

De actieve knoop die binnen dit werk voor experimenten gebruikt werd, bestaat uit een PC-gebaseerde Linuxrouter waarop versie 1.3 van het ANTSplatform (Eng.: Active Network Transport System) [10] uitgevoerd wordt in de applicatielaag. Het ANTS-platform is geschreven in Java en maakt handig gebruik van een aantal typische kenmerken van de Javatechnologie. Allereerst wordt bij het uitvoeren van een Javaprogramma steeds een virtuele machine of JVM (Eng.: Java Virtual Machine) aangemaakt, waarbinnen de uitvoering gebeurt. Op die manier wordt bij het uitvoeren van het ANTS-platform steeds automatisch een afgeschermde omgeving gecreëerd die in de context van Actieve Netwerken als een uitvoeringsomgeving beschouwd kan worden. Verder maakt Java gebruik van een platformonafhankelijke bytecode waarnaar alle programma’s gecompileerd worden. In de JVM, die wel afhankelijk is van het onderliggende platform, wordt deze bytecode ge¨ınterpreteerd en uitgevoerd. Deze manier van uitvoeren laat eenvoudig toe dat programma’s mobiel worden en dat ze dynamisch in een JVM geladen en uitgevoerd worden. De algemene opbouw van de actieve knoop is ge¨ıllustreerd in Figuur 3.1. Linux wordt als knoopbesturingssysteem gebruikt en voorziet de controle over de middelen van de PC-router. De EE-NodeOS interface wordt in feite verzorgd door de JVM. De Javatechnologie voorziet immers de mogelijkheden om pakketten over het netwerk te sturen via sockets, variabelen en gegevens op te slaan en te manipuleren in het geheugen en bepaalde functionaliteit op de knoop uit te voeren. Verschillende instanties van het ANTS-platform kunnen in parallel uitgevoerd worden, elk in een afzonderlijke JVM, zodat meerdere toepassingen naast elkaar ondersteund kunnen worden. Door het uitvoeren van het ANTS-platform op de knoop wordt

Prestatie-evaluatie van netwerkdiensten gebaseerd op routering in de applicatielaag 3-3

soft-statecache extensie

Actieve-knoop-EE (ANTS)

capsuleverwerking sockets

JAVA Gebruikersniveau Kernelniveau

UDP IN

UDP

IP

IP

OUT

Linuxrouter

Fig. 3.1: Algemene opbouw van de op ANTS gebaseerde actieve knoop.

een uitvoeringsomgeving gecreëerd waarbinnen actieve pakketten of capsules ontvangen, verwerkt en verzonden kunnen worden. De capsules worden verpakt in UPD/IP-pakketten en verzonden over sockets die de verschillende virtuele knopen verbinden. Deze sockets die allemaal luisteren naar één specifieke poort vormen een virtueel netwerk tussen de knopen. Bij aankomst in een knoop worden de capsules op basis van het poortnummer geclassificeerd en naar de ANTS-uitvoeringsomgeving gezonden. In de ANTS-EE wordt de bytecode van de capsule uitgepakt en uitgevoerd. In de bytecode wordt door elke capsule een eigen verwerkingsroutine meegedragen, die het gedrag van de capsule in de knoop bepaalt. Op basis hiervan kunnen geavanceerde toepassingen ontwikkeld worden door capsules met een bepaalde verwerkingsroutine te creëren zodanig dat het gewenste gedrag verkregen wordt. Om een bepaald gedrag te bekomen, kan men in de routine gebruik maken van de minimale API voor Actieve Netwerken die in de ANTS-EE voorzien is. Een overzicht van de API is gegeven in Tabel 3.1. Hierbij zijn de functies van de API opgesplitst in drie groepen: een eerste groep die het opvragen van informatie over de knoopomgeving toelaat, een tweede groep die het gebruik van een soft-statecache voorziet en een derde groep die zorgt voor functionaliteit om capsules te manipuleren. Afgezien van de mogelijkheid om capsules te verzenden of af te leveren aan een toepassing zijn er binnen ANTS ook methodes om capsules te kopiëren, te wijzigen of te verwijderen. Zo kan onder andere in elke knoop de inhoud van een capsule gewijzigd worden. Verder kan toestandsinformatie voor de toepassingen opgeslagen worden in een soft-statecache, zodat die later voor andere capsules beschikbaar is. Deze informatie, die slechts voor een bepaalde duur in de cache wordt bijgehouden, kan door andere capsules ook gewijzigd of verwijderd

3-4

Hoofdstuk 3

TABEL 3.1: Overzicht van de ANTS-programmeerinterface voor Actieve Netwerken. Klasse Node

Cache

Node

Functie int getAddress() ChannelObject getChannel() Extension findExtension(ext) long time() Object put(key, val, age) Object get(key) Object remove(key) void routeForNode(cap, node) void deliverToApp(cap, app) void log(msg)

Beschrijving Geef knoopadres Geef ontvangend kanaal Vind extensie Geef lokale tijd Bewaar object in cache Haal object uit cache Verwijder object uit cache Zend capsule naar knoop Geef capsule aan toepassing Schrijf controleboodschap

worden. Een systeem van extensies laat toe dat de knoop uitgebreid wordt met bepaalde complexe functionaliteit die te omvangrijk is om door de capsules zelf te worden meegedragen. Deze uitbreidingen kunnen dynamisch worden uitgevoerd en hebben een meer langdurig effect op het knoopgedrag dan de bytecode in de capsules. Verder kan men beschikken over de basisfunctionaliteit van de Javaprogrammeertaal. Op basis van de beschikbare controlelogica, de verschillende datatypes, het gebruik van complexe datastructuren en de mogelijke bewerkingen op de datatypes kan men complexe functionaliteit voorzien in de bytecode van de capsules. Naast de API beschrijven we kort de veiligheidsvoorzieningen binnen ANTS. De integriteit van de capsules en de meegedragen code wordt gecontroleerd door middel van een fingerprint die afgeleid wordt van de code en steeds meegezonden wordt. De impact van de capsules op hun omgeving wordt beperkt door het gebruik van protocolgroepen. Enkel capsules van eenzelfde protocolgroep kunnen elkaar en elkaars gegevens be¨ınvloeden. De belasting van de knopen wordt beperkt door de uitvoeringstijd van de capsules te beperken. Verder wordt de netwerkbelasting gecontroleerd door slechts een beperkte levensduur te geven aan de capsules door middel van een Time-To-Liveveld. De keuze voor het gebruik van deze prototype-implementatie van een actieve knoop werd bepaald door het feit dat het ANTS-systeem gebaseerd is op twee actuele en geschikte technologieën. Enerzijds wordt gebruik gemaakt van Java, een veel gebruikte technologie ter ondersteuning van netwerkgebaseerde toepassingen. Verder is ANTS ook gebaseerd op overlaytechnologie die steeds vaker gebruikt wordt om op een flexibele manier en zonder beperkingen van de onderliggende infrastructuur nieuwe toepassingen in een netwerk in te voeren. Bovendien biedt deze technologie een grote vrijheid aangezien men min of meer de volledige controle over het virtuele


netwerk heeft. Een belangrijk nadeel van dit prototype is echter dat deze beide technologieën een belangrijke invloed kunnen hebben op de prestatie. Dit is dan ook het onderwerp van de verdere paragrafen.

3.2

Algemene ALR-knooparchitectuur

Het belangrijkste element in overlaynetwerken is de ALR-knoop waarop de functionaliteit van de virtuele knoop in een afzonderlijke omgeving uitgevoerd wordt. Deze knoop kan zowel gebaseerd zijn op een gebruikersmachine als op een gewone router. Een algemene architectuur voor een ALR-knoop wordt voorgesteld in Figuur 3.2.

Virtuele-Knoopomgeving (Toepassingsproces)

socket

socket

Gebruikersniveau Kernelniveau

TCP

IN

UDP

TCP

UDP

IP

IP

Protocolstapel

Protocolstapel

OUT

Fig. 3.2: Algemene architectuur van een ALR-knoop.

Aangezien de specifieke knoopfunctionaliteit voor het overlaynetwerk uitgevoerd wordt in de applicatielaag, moeten pakketten die over het overlaynetwerk verzonden worden in de virtuele knopen naar de applicatielaag gebracht worden. Bijgevolg moeten aankomende pakketten via de kernel doorgegeven worden naar het gebruikersniveau en bij het verderzenden moeten pakketten opnieuw naar de kernel gekopieerd worden. Dit alternatieve pad dat door de pakketten in de ALR-knoop gevolgd wordt, lijkt in niets op het traditionele pad voor snelle IP-doorvoer in een klassieke router. In tegenstelling tot de efficiënte verwerking van pakketten in de IP-laag, waarbij in de routeringstabel de uitgaande interface wordt opgezocht en het pakket verzonden wordt, moeten in de ALR-knoop alle pakketten via de protocolstapel naar de applicatielaag gestuurd worden. Het is bijgevolg duidelijk dat dit niet-conventionele pad een belangrijke beperking zal vormen voor de prestaties van de ALR-knoop en het overlaynetwerk. Dit pad

3-6

Hoofdstuk 3

IP-doorvoerpad Applicatielaag

Applicatielaag

UDP

UDP

IP Ethernet

IP Eth

IP Eth

Ethernet

ALR-pad Applicatielaag

Applicatielaag

Applicatielaag

UDP

UDP

UDP

IP

IP

IP

UDP IP

Ethernet

Eth

Eth

Ethernet

Fig. 3.3: Vergelijking van het klassieke IP-doorvoerpad en het ALR-pad.

wordt ge¨ıllustreerd in Figuur 3.3 en vergeleken met het traditionele IPdoorvoerpad. In wat volgt beschrijven we een prestatie-analyse van een ALR-knoop, hoofdzakelijk gebaseerd op de hierboven beschreven ANTS-implementatie. In deze analyse worden de volgende parameters onderzocht. De belangrijkste parameter voor de prestatie is de doorvoersnelheid (Eng.: throughput) van de knoop, die aangeeft hoeveel pakketten per seconde verdergezonden kunnen worden in functie van de aankomstsnelheid. Nauw daarmee verwant is de parameter pakketverlies, die hoog kan oplopen wanneer de knoop zwaar belast wordt. Bij een te hoge belasting kunnen niet alle aankomende pakketten verwerkt worden en gaan er bijgevolg pakketten verloren. Een derde parameter is de verwerkingstijd van een pakket in de knoop. Deze totale tijd tussen de aankomst en het vertrek van een pakket in de knoop kan opgesplitst worden in meerdere componenten overeenkomend met de deelprocessen van de pakketverwerking. Bij de analyse wordt een tweeledige aanpak gebruikt. Enerzijds worden op een experimentele opstelling de doorvoersnelheid, het pakketverlies en de verschillende componenten van de verwerkingstijden van de pakketten gemeten in functie van de pakketlengte en de aankomstsnelheid van de pakketten. Dit laat reeds de evaluatie van de prestaties van de knoop toe. Om meer inzicht in de vastgestelde prestaties te krijgen wordt anderzijds een model opgesteld op basis van een analyse van de pakketverwerking in de ALR-knoop. Dit model laat toe de doorvoersnelheid te berekenen in functie van de aankomstsnelheid en de gemeten verwerkingstijden van de pakketten. Het model wordt gevalideerd door de gemeten waarden voor de verwerkingstijden te vergelijken met de waarden geschat op basis van het


model en de metingen van de doorvoersnelheid. Aangezien de beschouwde experimentele implementatie van een actieve knoop bestaat uit drie belangrijke componenten – de Linuxrouter, de JVMen de ANTS-software – wordt de analyse in drie verschillende stappen aangepakt. Eerst wordt de prestatie van de pakketverwerking in een Linuxrouter bekeken. Vervolgens wordt een op Java gebaseerde relaisknoop beschouwd als een eenvoudige toepassing van ALR. Tenslotte wordt de prestatie van de beschouwde ANTS-knoopimplementatie onderzocht. Dit werk wordt beschreven in de publicatie van Appendix E.

3.3

Pakketverwerking in een Linuxrouter

De implementatie van de experimentele actieve knoop die binnen dit werk gebruikt wordt, steunt op een PC-gebaseerde Linuxrouter. Meer bepaald wordt voor de verschillende knopen in de opstellingen gebruik gemaakt van PC’s met een AMD-K6 450MHz-processor, 192MB RAM-geheugen en 5 Fast-Ethernet netwerkinterfacekaarten. Op deze machines wordt Debian Linux als besturingssysteem gebruikt met kernelversie 2.2.18. In volgende paragraaf wordt op basis van de kernelcode [12, 13] de verwerking van pakketten in deze knoop beschreven.

3.3.1

Pakketverwerking in Linuxkernel 2.2.18

De behandeling van pakketten in een netwerkknoop kan in drie verschillende procedures opgedeeld worden: verzenden, ontvangen en doorvoeren. Deze laatste procedure komt overeen met de functionaliteit van het snel doorvoerpad in IP, waarbij een pakket op basis van de routeringstabel verdergezonden wordt naar zijn bestemming. Het verzenden van een pakket is de eenvoudigste procedure. Wanneer een toepassing een boodschap naar een socket stuurt, voert deze socket een aantal controles uit, splitst het geheel op in kleinere delen zodat ze in pakketten passen en geeft de individuele pakketten door aan de protocolstapel. Daar wordt aan een pakket de verschillende pakkethoofdingen toegevoegd en het pakket wordt dan in de verzendbuffer van de geschikte netwerkinterface geplaatst. Uiteindelijk zal de netwerkinterface het pakket verzenden over de verbinding. Het ontvangen en doorvoeren van pakketten zijn ingewikkelder procedures. Bij aankomst van een pakket leest de interface het pakket in, slaat het op in een buffer en genereert een IRQ (Eng.: Interrupt Request) om het besturingssysteem op de hoogte te brengen van de aankomst. Aangezet door deze IRQ zal het besturingssysteem de huidige processen onderbreken en begint het de behandeling van het nieuwe pakket. Aangezien hierdoor effectief een proces onderbroken wordt,

3-8

Hoofdstuk 3

Toepassingsproces (virtuele-knoopomgeving)

Gebruikersniveau Kernelniveau

socket

net_bh_recv()

UDP IP IN

socket

udp_sendmsg()

UDP net_bh_fw()

IP OUT

netdev_rx()

Fig. 3.4: Overzicht van de kernelprocedures die betrekking hebben op de afhandeling van pakketten.

moet de afhandeling van het pakket zo kort mogelijk zijn. Daarom wordt het afhandelen van de IRQ opgesplitst in twee procedures: een bovenste helft (Eng.: top-half) en een onderste helft (Eng.: bottom-half). Wanneer een onderbreking uitgevoerd wordt, worden de meest kritische bewerkingen eerst uitgevoerd in het top-half gedeelte. Hierbij wordt de pakkethoofding gekopieerd naar het kernelgeheugen, een referentie naar het pakket wordt in de pakketbuffer van de kernel (Eng.: backlog queue) opgeslagen en een vlag wordt aangezet om de bottom-half procedure uit te voeren. Na deze operaties wordt de controle over het systeem teruggegeven aan het onderbroken proces en afhankelijk van het controlesysteem voor de processor (Eng.: scheduler) wordt de bottom-half procedure later uitgevoerd. Bij deze procedure wordt het pakket ofwel door de protocolstapel verwerkt en afgeleverd aan de geschikte toepassing, ofwel wordt het verdergezonden naar de volgende knoop op weg naar de bestemming. De verschillende kernelprocedures die betrokken zijn bij de afhandeling van pakketten zijn voorgesteld in Figuur 3.4. De procedure netdev rx() is een deel van de driversoftware van de netwerkinterface en wordt uitgevoerd bij de afhandeling van een IRQ ten gevolge van een nieuw aangekomen pakket. Deze procedure verzorgt de top-half afhandeling van een pas aangekomen pakket. De bottom-half afhandeling ligt vervat in de procedure net bh(), die enerzijds zorgt voor het afleveren van het pakket aan een lokale toepassing of anderzijds het pakket verderzendt naar de bestemming. Om deze twee functies te onderscheiden verwijzen we respectievelijk naar de procedures net bh recv() en net bh fw(). Wanneer een nieuw UDPpakket door een toepassing over een socket gezonden wordt, wordt de proce-

Prestatie-evaluatie van netwerkdiensten gebaseerd op routering in de applicatielaag 3-9 Verwerkingstijden in de Linuxkernel 50 netdev_rx() net_bh_fw() net_bh_recv() udp_sendmsg()

45

40

Verwerkingstijd [µs]

35

30

25

20

15

10

5

0

0

500

1000

1500

Pakketlengte [bytes]

Fig. 3.5: Verwerkingstijden van de verschillende kernelprocedures betrokken bij de afhandeling van pakketten.

dure udp send msg() uitgevoerd. Binnen deze procedure worden de nodige pakkethoofdingen toegevoegd en wordt het pakket naar zijn bestemming verzonden. De verwerkingstijden voor deze procedures werden gemeten op de experimentele opstelling en zijn voorgesteld in Figuur 3.5 in functie van de gebruikte pakketlengte. Deze resultaten werden uitgemiddeld over tien metingen waarbij telkens de verwerkingstijd voor elk van de 50.000 pakketten in de stroom gemeten werd. Hieruit blijkt dat de top-half afhandeling van een pakket (netdev rx()) onafhankelijk is van de pakketlengte. De gebruikte driversoftware past immers een zero-copy benadering toe waarbij enkel de pakkethoofding en een referentie naar het pakket in het kernelgeheugen geschreven wordt. Het eigenlijke pakket blijft volledig opgeslagen in een buffer op de netwerkinterface. Pas bij de uitvoering van de bottom-half procedure wordt het pakket effectief gekopieerd. Wanneer het pakket verdergezonden moet worden (net bh fw()), wordt het volledig naar een verzendbuffer op de geschikte netwerkinterface gekopieerd. Wanneer het pakket bestemd is voor een lokale toepassing (net bh recv()), wordt het gekopieerd naar het gebruikersniveau van het geheugen. In beide gevallen is dus één kopie nodig. Wanneer een UDP-pakket verzonden wordt (udp sendmsg()), zijn twee kopies nodig: een eerste van het gebruikersniveau naar het kernelniveau van het geheugen, vervolgens een tweede naar de verzendbuffer op de geschikte netwerkinterface. De verwerkingstijden van deze drie procedures zijn bij-

3-10

Hoofdstuk 3

gevolg afhankelijk van de pakketlengte. Verder wordt aan het deel van de verwerkingstijd dat afhankelijk is van de pakketlengte ondermeer ook bijgedragen door de berekeningen van checksums op de pakketten. Uit de metingen blijkt dat de afhankelijkheid van de pakketlengte nagenoeg gelijk is voor de drie procedures. Verder blijkt dat de procedure voor het verzenden van een nieuw UDP-pakket duidelijk meer tijd vergt. Dit is immers de enige procedure waar een volledige nieuw pakket, inclusief pakkethoofdingen en checksums, samengesteld wordt.

3.3.2

Model voor de verwerking van pakketten in Linux

Uitgaande van de bovenstaande beschrijving kan de verwerkingstijd van een aankomend pakket opgesplitst worden in twee delen: een tijd τIRQ is nodig voor de top-half afhandeling van de IRQ en een tijd τ0 voor de uitvoering van de bottom-half procedure. Aangezien echter elke nieuwe aankomst van een pakket het huidige proces zal onderbreken, geldt dit ook voor de uitvoering van de bottom-half procedure. Daardoor zal de totale verwerkingstijd van de bottom-half procedure groter zijn dan τ0 . Wanneer nieuwe pakketten aankomen tijdens de minimale verwerkingstijd τ0 , worden IRQ’s gegenereerd bij elke aankomst en wordt het huidige proces onderbroken voor de onmiddellijke uitvoering van de top-half procedure. In de veronderstelling dat gemiddeld k0 pakketten aankomen in een interval τ0 en dat de top-half procedure een gemiddelde verwerkingstijd τIRQ heeft, zal de bottom-half verwerking van een pakket dus gemiddeld een tijd k0 .τIRQ langer duren. Wanneer bovendien in deze bijkomende tijd opnieuw pakketten aankomen, wordt de verwerking nog verder verlengd. Dit mechanisme is ge¨ıllustreerd in Figuur 3.6. τ τ0

τ1 = k0 .τIRQ

k0 pakketaankomsten

k1

τ2 = k1 .τIRQ τ3 = k2 .τIRQ

k2

Fig. 3.6: De bottom-half verwerking van een pakket wordt verlengd door de onmiddellijke top-half verwerking van aankomende pakketten die het huidige proces onderbreekt.

Uiteindelijk zal de totale bottom-half verwerking van een pakket een tijd τ in beslag nemen, die afhankelijk is van het aantal nieuwe pakketten


dat aankomt tijdens de verwerking. Zoals beschreven in de publicatie van Appendix E kan een uitdrukking afgeleid worden voor de verwerkingstijd τ in functie van de aankomstsnelheid van nieuwe pakketten λ, de minimale verwerkingstijd τ0 en de verwerkingstijd voor de top-half afhandeling τIRQ . Deze uitdrukking ziet er als volgt uit, waarbij µ = τ −1 de gemiddelde verwerkingssnelheid per pakket is. τ=

τ0 1 = 1 − λ.τIRQ µ

(3.1)

De afhandeling van pakketten kan dus als volgt gemodelleerd worden. De aankomst van een pakket in de netwerkinterface veroorzaakt een IRQ en de onmiddellijke top-half afhandeling. Hierbij wordt het pakket in de pakketbuffer van de kernel geplaatst in afwachting van de verdere verwerking. Pas wanneer het systeem daarvoor tijd heeft, wordt de bottom-half procedure uitgevoerd waarbij het pakket ofwel verdergezonden wordt, ofwel afgeleverd wordt aan een toepassing. Deze verwerking neemt gemiddeld een tijd τ in beslag. Zoals in de publicatie van Appendix E beschreven is, kan dit proces bijgevolg aanzien worden als een buffersysteem. Met N de lengte van de eindige pakketbuffer van de kernel kan dan de gemiddelde doorvoersnelheid X bepaald worden in functie van N , λ en µ op basis van de volgende uitdrukking. X=

λ[1 − (λ/µ)N ] 1 − (λ/µ)N +1

(3.2)

Op basis van de beide uitdrukkingen (3.1) en (3.2) kan dan de doorvoersnelheid X berekend worden in functie van de aankomstsnelheid λ en de verwerkingstijden τ0 en τIRQ .

3.3.3

Prestatie-evaluatie van pakketverwerking in Linux en validering van het model

Om de prestatie van de pakketverwerking in een Linuxrouter te evalueren werden op de beschreven opstelling metingen uitgevoerd van de doorvoersnelheid in functie van de aankomstsnelheid van de pakketten, voor verschillende pakketlengtes. In Figuur 3.7 wordt voor toenemende aankomstsnelheid van de pakketten de gemiddelde doorvoersnelheid voorgesteld. Het is duidelijk dat alle aankomende pakketten zonder verlies verdergezonden worden tot een drempel bereikt wordt die afhankelijk is van de pakketlengte. Vanaf deze drempel worden de onderbrekingen gegenereerd door aankomende pakketten zo talrijk dat het systeem steeds minder tijd krijgt om de bottom-half verwerking van de pakketten uit te voeren. Bijgevolg moeten pakketten steeds langer in de buffer wachten, zodat deze

3-12

Hoofdstuk 3

Doorvoersnelheid van Linuxknoop

4

5.5

x 10

64 bytes→

5

Uitvoersnelheid [pktn/s]

4.5 128 bytes→

4

192 bytes→ 256 bytes→

3.5 330 bytes→ 3

2.5

2

2

2.5

3

3.5

4

4.5

5

Aankomstsnelheid [pktn/s]

5.5

6

6.5 4

x 10

Fig. 3.7: Doorvoersnelheid van een 450MHz Debian Linuxrouter.

uiteindelijk volloopt. Op dit ogenblik gaan aankomende pakketten verloren omdat er geen plaats meer is in de buffer. Bij nog grotere aankomstsnelheden zal het systeem nagenoeg alle tijd gebruiken voor het afhandelen van de top-half verwerking, zodat haast geen pakketten volledig verwerkt worden. Deze situatie wordt receive livelock [14] genoemd, aangezien het systeem voortdurend aankomende pakketten verwerkt en dus actief is, maar in werkelijkheid worden er geen pakketten meer verdergezonden. Dit probleem wordt in de meest recente kernelversies (2.4.x) opgelost door het gebruik van polling. Deze oplossing werd voorgesteld in het kader van het Click routerproject [15]. Hierbij worden geen onderbrekingen meer gegenereerd door aankomende pakketten, maar de kernel zal regelmatig de netwerkinterfaces bevragen of er nieuwe pakketten te verwerken zijn. Aangekomen pakketten worden dan in één procedure volledig afgehandeld, waarbij de verwerking niet meer onderbroken kan worden. Naast de doorvoersnelheid werd ook de verwerkingstijd van pakketten in de Linuxrouter geëvalueerd. Uitgaande van het model kunnen twee compolin . Deze nenten van de totale verwerkingstijd beschouwd worden: τ0lin en τIRQ komen respectievelijk overeen met de verwerkingstijden van de procedures net bh fw() en netdev rx(), die reeds in de vorige paragraaf voorgesteld lin werden in Figuur 3.5. De totale verwerkingstijd τ0lin + τIRQ wordt in Figuur 3.8 voorgesteld als de som van de verwerkingstijden van deze twee procedures en in functie van de pakketlengte.

Prestatie-evaluatie van netwerkdiensten gebaseerd op routering in de applicatielaag 3-13 Schatting van de verwerkingstijd τlin+τlin 0

IRQ

35 net_bh_fw() netdev_rx() 1/Xmax 30


25

20

15

10

5

0 64

128

192

256

320

384

448

512


Fig. 3.8: Meting en schatting van de verwerkingstijd per pakket in een Linuxrouter.

Op basis van het model kan de totale verwerkingstijd ook geschat worden uit de metingen van de doorvoersnelheid. De doorvoersnelheid waarbij de hierboven vermelde drempel bereikt wordt, noemen we de maximale verliesloze doorvoersnelheid Xmax . Bij deze waarde gaan nog net geen pakketten verloren in het systeem. De processor zal dan 100% belast zijn met het verwerken van pakketten en bijgevolg geldt λ.τ = 1. Aangezien op dit punt λ = Xmax , geldt ook de volgende uitdrukking. 1 Xmax

lin = τ0lin + τIRQ

(3.3)

Met deze uitdrukking kan een schatting van de totale verwerkingstijd berekend worden die ook in Figuur 3.8 voorgesteld is. lin kleiner is dan de Het blijkt dat de gemeten waarde voor τ0lin + τIRQ −1 geschatte waarde op basis van Xmax . Dit verschil is eenvoudig als volgt te verklaren. Tijdens de metingen op de Linuxknoop waren parallel met de procedures voor de pakketverwerking nog een aantal andere kernelprocedures actief die instaan voor de algemene werking van het systeem. Bijgevolg is de processor dus een deel van de tijd belast met deze bijkomende procedures en geldt eigenlijk dat λ.τ < 1.

3-14

Hoofdstuk 3

Doorvoersnelheid van Javarelaisknoop 12000 metingen model

128 bytes→

10000


512 bytes→

1024 bytes→ 8000 1408 bytes→

6000

4000

2000

0

0

0.2

0.4

0.6

0.8

1

1.2


1.4

1.6

1.8

2 4

x 10

Fig. 3.9: Doorvoersnelheid van een Javarelaisknoop.

3.4

Evaluatie van een Javarelaisknoop

Een relaisknoop is zowat de eenvoudigste toepassing van een ALR-knoop, waarbij in de knoopomgeving pakketten ontvangen worden van een vorige knoop en onmiddellijk doorgezonden worden naar een volgende. Hoewel een relaisknoop nagenoeg geen enkel praktisch nut heeft, kan de analyse van zijn werking en prestatie nuttig zijn aangezien alle basisfunctionaliteit aanwezig is waarop meer complexe ALR-knopen steunen. We bestuderen de prestatie van een relaisknoop die in Java ge¨ımplementeerd is en pakketten ontvangt en verzendt over UDP/IP-sockets. Hiervoor beschouwen we opnieuw de doorvoersnelheid van de knoop op basis van volgende opstelling. De relaisknoop is opgesteld tussen twee knopen die respectievelijk UDP/IP-pakketten met een bepaalde lengte verzenden en ontvangen. De gemeten doorvoersnelheden voor verschillende pakketlengtes zijn voorgesteld in Figuur 3.9 in functie van de aankomstsnelheid van de pakketten . We stellen opnieuw vast dat de doorvoersnelheid een drempelwaarde bereikt, waarna pakketverlies optreedt. Dit is opnieuw het gevolg van de onderbrekingen gegenereerd door aankomende pakketten, waardoor de eigenlijke verwerkingstijd van een pakket verlengd wordt. De totale verwerjav . kingstijd kan dus ook gesplitst worden in twee componenten: τ0jav en τIRQ jav τ0 is de tijd nodig om een pakket in de relaisknoop te verwerken, waarbij het pakket uit de kernel gekopieerd wordt, afgehandeld wordt door de


protocolstapel, doorgegeven wordt naar de relaisknoopomgeving in de apjav stelt plicatielaag en tenslotte verdergestuurd wordt door de knoop. τIRQ de tijd voor dat de bovenstaande verwerking van een pakket onderbroken wordt door andere processen met hogere prioriteit. Aangezien een groot deel van deze verwerking in de applicatielaag plaats vindt, zal deze niet alleen onderbroken worden door IRQ’s van aankomende pakketten maar ook door andere kernelprocedures en zelfs processen uit de applicatielaag die met een voldoende hoge prioriteit het gebruik van de processor aanvragen. jav Bijgevolg kunnen voor τIRQ aanzienlijk grotere waarden verwacht worden lin . Dit wordt ondermeer aangetoond in de volgende dan de waarden van τIRQ analyse. De analyse van de verwerkingstijden van een pakket in de relaisknoop kan op twee manieren benaderd worden. Enerzijds kan het model bestaande uit de formules (3.1) en (3.2) gefit worden aan de metingen van Figuur 3.9 jav te verkrijgen. Deze om een schatting voor de parameters τ0jav en τIRQ waarden worden voorgesteld in Tabel 3.2. TABEL 3.2: Geschatte waarden uit gefit model voor relaisknoop.

Pakketlengte τ0jav jav τIRQ

128 bytes 59,6 µs 29,4 µs

512 bytes 65,3 µs 34,4 µs

1024 bytes 81,6 µs 37,0 µs

1408 bytes 87,0 µs 40,0 µs

Anderzijds kan de waarde van τ0jav eveneens geschat worden door de verwerkingstijden in de relaisknoop effectief te meten. De verwerkingstijd τ0jav kan opgesplitst worden in drie componenten die elk afzonderlijk gemeten kunnen worden. Een eerste deel is de tijd nodig om een pakket uit de pakketbuffer van de kernel te lezen, het af te handelen door de protocolstapel en het af te leveren aan een toepassing. Dit komt overeen met de net bh recv() procedure. Een tweede deel bestaat uit de verwerkingstijd in de relaisknoopomgeving. Deze werd gemeten door tijdsstempels af te drukken bij de ontvangst en het verzenden van een pakket in de relaisknoopomgeving. Een derde deel is de tijd nodig om een nieuw UDP-pakket af te handelen in de protocolstapel en het te verzenden over het netwerk. Dit laatste correspondeert met de udp sndmesg() procedure. De waarde jav daarentegen kan niet op een eenvoudige manier gemeten worden van τIRQ aangezien een hele reeks processen tegelijk bijdragen tot de onderbrekingen van de pakketverwerking. In Figuur 3.10 worden de waarden voor τ0jav voorgesteld die geschat werden op basis van het model en de metingen van de doorvoersnelheid. Deze worden vergeleken met de som van de waarden van de drie gemeten com-

3-16

Hoofdstuk 3

Schatting van de verwerkingstijd τjav op de Javarelaisknoop 0

100

90

zenden UDP [udp_sendmsg()] Java relais verwerkingstijd ontvangen UDP [net_bh_recv()]

80


↓

τjav 0 70

60

50

40

30

20

10

0 128

256

384

512

640

768

896

1024

1152

1280

1408


Fig. 3.10: Meting en schatting van de verwerkingstijd per pakket in een Javarelaisknoop.

ponenten van de verwerking. Deze twee benaderingen geven vergelijkbare resultaten, hetgeen wijst op de deugdelijkheid van het model. Uit deze resultaten blijkt duidelijk dat het verwerken van de pakketten in de applicatielaag voor een belangrijke beperking van de doorvoersnelheid zorgt. Ten opzichte van de standaard pakketverwerking in een Linuxknoop wordt de doorvoersnelheid verminderd met een factor drie tot vier (voor pakketten van 128 bytes van 43.000 pktn/s naar 11.000 pktn/s). Hierbij spelen vooral de bijkomende verwerkingstijden om een pakket van en naar de verwerkingsomgeving in de applicatielaag te zenden een rol. De eigenlijke verwerking in de Javarelaisknoop is tot een minimum beperkt en heeft bijgevolg slechts een kleine invloed.

3.5

Evaluatie van de ANTS actieve knoop

In deze sectie onderzoeken we de prestatie van de actieveknoopimplementatie op basis van ANTS. Deze complexe toepassing van een ALR-knoop verschilt in wezen weinig van de Javarelaisknoop, afgezien van de veel uitgebreidere pakketverwerking in het ANTS-platform. De pakketten dragen immers hun eigen verwerkingsmethode met zich mee die in de ANTS-omgeving uitgevoerd wordt en aldus hun gedrag in de knoop bepaalt. Bij de hier voorgestelde metingen van de doorvoersnelheid van de ANTS-

Prestatie-evaluatie van netwerkdiensten gebaseerd op routering in de applicatielaag 3-17 Doorvoersnelheid van ANTS−knoop 4000 doorvoersnelheid 3500

3000



2500

1024 bytes→ 1408 bytes→ 2000

1500

1000

500

0

0

1000

2000

3000

4000

5000

6000


Fig. 3.11: Doorvoersnelheid van een ANTS-knoop.

knoop bepaalt deze verwerkingsmethode van de pakketten enkel dat ze onmiddellijk verdergezonden moeten worden naar de bestemming. De resultaten van deze metingen worden voorgesteld in Figuur 3.11. Aangezien de ANTS-knoop een grote gelijkenis heeft met de eenvoudige relaisknoop verwachten we opnieuw een continu stijgende doorvoersnelheid zonder pakketverlies totdat een drempelwaarde bereikt wordt. We stellen echter vast dat pakketverlies reeds voor lage aankomstsnelheden optreedt in het stijgende gedeelte van de grafiek. Bovendien lijkt het pakketverlies onafhankelijk van de pakketlengte te zijn. Hieruit kan besloten worden dat een niet gering gedeelte van de processortijd ingenomen wordt door andere processen dan de procedures voor de pakketverwerking. De tijd beschikbaar voor het verwerken van pakketten wordt hierdoor beperkt en deze reductie neemt toe met stijgende aankomstsnelheden. Het is dus duidelijk dat het bijkomende proces enigszins verband houdt met de verwerking van de pakketten. Uit de ANTS-code blijkt dat dit bijkomend proces niets meer is dan de Garbage-Collectordraad van de JVM die op een regelmatige basis expliciet aangeroepen wordt vanuit de ANTS-software. Dit werd geverifieerd door de metingen van de doorvoersnelheid te herhalen met een aangepaste ANTS-knoop waarin de Garbage-Collectordraad niet meer aangeroepen wordt. De resultaten hiervan worden voorgesteld in Figuur 3.12 en we kunnen nu wel het verwachte verloop vaststellen. De activiteit van de Garbage Collector tijdens de pakketverwerking biedt echter niet de volledige verklaring voor het pakketverlies bij lage aankomst-

3-18

Hoofdstuk 3

Doorvoersnelheid van ANTS−knoop zonder Garbage Collector 4000 metingen model 128 bytes→

3500

512 bytes→


3000


2500

2000

1500

1000

500

0

0

1000

2000

3000

4000

5000

6000


Fig. 3.12: Doorvoersnelheid van een ANTS-knoop zonder Garbage Collector.

snelheden van de pakketten. Een reductie van de beschikbare processortijd voor de verwerking van de pakketten zal immers enkel leiden tot een vermindering van de maximale verliesloze doorvoersnelheid Xmax en kan op zich geen pakketverlies veroorzaken. Bijgevolg is er dus nog een tweede mechanisme verantwoordelijk voor het afwijkende gedrag. Dit mechanisme kan geanalyseerd worden op basis van de volgende vaststellingen. Ten eerste blijkt uit de Linuxkernelcode dat een pakket bij aankomst in een knoop niet onmiddellijk doorgegeven wordt aan de ANTS-uitvoeringsomgeving. In plaats daarvan wordt het pakket na de verwerking door de protocolstapel gekopieerd naar de ontvangstbuffer van de luisterende socket. De pakketten uit de ontvangstbuffer worden dan sequentieel verwerkt door de ANTSomgeving. Ten tweede wordt de pakketverwerking in ANTS onderbroken door de uitvoering van de Garbage-Collectordraad. De onderbroken pakketten ondervinden bijgevolg een extra verwerkingstijd. Ten derde is deze bijkomende verwerkingstijd veel groter dan de normale verwerkingstijd van een pakket. Bijgevolg is het duidelijk dat door het af en toe optreden van deze lange verwerkingstijden en voor voldoende hoge aankomstsnelheden van de pakketten de ontvangstbuffer van de socket vol zal lopen en aankomende pakketten verloren zullen gaan. In de publicatie van Appendix E wordt aangetoond dat dit mechanisme inderdaad verantwoordelijk is voor het pakketverlies bij relatief lage aankomstsnelheden. Daarvoor wordt het buffermodel uit Figuur 3.13 gebruikt. De eindige buffer voor N pakketten stelt de ontvangstbuffer van de

Prestatie-evaluatie van netwerkdiensten gebaseerd op routering in de applicatielaag 3-19 verwerkingssnelheid µ1

1−p

aankomstsnelheid

λ µ2 N

p

Fig. 3.13: Model voor de verwerking van pakketten in de ontvangstbuffer van een socket met onderbrekingen door de Garbage-Collectordraad.

socket voor en pakketten komen aan met een gemiddelde snelheid λ. Bij een fractie p van de pakketten in de buffer zal de verwerking onderbroken worden door de uitvoering van de Garbage-Collectordraad. De resulterende verwerkingstijd zal hierdoor veel groter worden dan de normale verwerkingstijd in de ANTS-omgeving. Bijgevolg zal de verwerkingssnelheid µ2 van deze onderbroken pakketten veel kleiner zijn dan de normale snelheid µ1 waarmee de overige fractie 1 − p afgehandeld wordt. Op basis van dit model en de analyse in Appendix E, die de geschikte waarden voor de parameters N , p, µ1 en µ2 in functie van λ en de pakketlengte oplevert, kan het pakketverlies berekend worden die in de ontvangstbuffer van de socket te verwachten is in functie van de pakketlengte en de aankomstsnelheid van de pakketten. Deze berekende waarden worden in Figuur 3.14 vergeleken met de gemeten pakketverliezen tijdens de metingen van de doorvoersnelheid. De beide waarden blijken goed overeen te komen en dit model is dus een goede benadering van de werkelijke situatie. De analyse van de verwerkingstijden in de knoop kan zoals bij de relaisknoop opnieuw op twee manieren benaderd worden. Door het model van formules (3.1) en (3.2) te fitten aan de resultaten van Figuur 3.11 krijgen ant die voorgesteld zijn in Tabel 3.3. we geschatte waarden voor τ0ant en τIRQ TABEL 3.3: Geschatte waarden uit gefit model voor ANTS-knoop.

Pakketlengte τ0ant ant τIRQ

128 bytes 232,0 µs 47,0 µs

512 bytes 253,0 µs 51,0 µs

1024 bytes 279,0 µs 59,0 µs

1408 bytes 288,0 µs 71,0 µs

Zoals bij de relaisknoop kan de waarde van τ0ant ook opgemeten worden in drie delen. Twee van de drie componenten van de totale verwerkingstijd, respectievelijk de tijd voor het ontvangen en het verzenden van een pakket, zijn identiek aan de corresponderende componenten bij de relaisknoop. De

3-20

Hoofdstuk 3

Pakketverlies in de ontvangstbuffer van de UDP−socket 22

20

18

Pakketverlies [%]

16

14

12

10

8

6 afgeleid uit doorvoermetingen model [128 bytes] model [512 bytes] model [1024 bytes] model [1408 bytes]

4

2 500

1000

1500

2000

2500

3000

3500


Fig. 3.14: Vergelijking van gemeten en berekende waarden van het pakketverlies in de ontvangstbuffer van de socket.

derde component komt overeen met de specifieke verwerking van een pakket in de ANTS-omgeving en werd in functie van de pakketlengte gemeten. Hierbij werd gebruik gemaakt van tijdsstempels die afgedrukt werden wanneer een pakket de ANTS-omgeving binnenkwam en verliet. De som van deze drie componenten wordt in Figuur 3.15 vergeleken met de geschatte waarden voor τ0ant op basis van het model en de doorvoermetingen. Opnieuw vinden we vergelijkbare resultaten met de beide benaderingen. Uit deze resultaten blijkt dat de verwerking van de pakketten door de ANTS-omgeving in de applicatielaag voor een zware belasting op de knoop zorgt. Naast de belasting van het doorgeven van pakketten van en naar de applicatielaag is in dit geval vooral de verwerkingstijd in de ANTS-omgeving de bepalende factor voor de doorvoersnelheid. In vergelijking met de Javarelaisknoop van vorige paragraaf werden in de ANTS-knoop doorvoersnelheden gemeten die een factor drie kleiner zijn (voor pakketten van 128 bytes van 11.000 pktn/s naar 3.600 pktn/s). Verder werd ook de invloed van Garbage Collection op de prestaties ge¨ıllustreerd.

3.6

Besluit

De analyse en metingen van dit hoofdstuk geven een goed idee van de prestaties van een virtuele netwerkknoop gebaseerd op het ALR-concept. Het blijkt dat met grote pakketten (1024 tot 1408 bytes) een doorvoersnel-

Prestatie-evaluatie van netwerkdiensten gebaseerd op routering in de applicatielaag 3-21 Schatting van de verwerkingstijd τant op de ANTS−knoop 0

350 zenden UDP [udp_sendmsg()] ANTS verwerkingstijd ontvangen UDP [net_bh_recv()] 300

ant

↓

τ0 Verwerkingstijd [µs]

250

200

150

100

50

0 128

256

384

512

640

768

896

1024

1152

1280

1408


Fig. 3.15: Meting en schatting van de verwerkingstijd per pakket in een ANTSknoop.

heid van 70Mb/s tot 80Mb/s haalbaar is voor de Javarelaisknoop. Voor de ANTS-knoop zijn snelheden van 25Mb/s tot 30Mb/s haalbaar. Dit zijn niet onaardige resultaten wanneer we de beperkingen van de hardware (450MHzprocessor) in acht nemen, evenals de intrinsieke traagheid van de Javatechnologie. Bovendien zorgt ook de pakketverwerking die gebaseerd is op IRQ’s voor extra belasting. Bijgevolg kan door het gebruik van snellere hardware, een efficiëntere en snellere programmeertaal en het polling mechanisme in de pakketverwerking de prestatie van de knoop nog sterk verbeterd worden. Overigens volstaan de prestaties van de ANTS-knoop ondanks deze ruime marge voor progressie reeds om een aantal parallelle mediastromen te ondersteunen.

3-22

Hoofdstuk 3

Referenties [1] D. Pendarakis, S. Shi, D. Verma, M. Waldvogel, ALMI: An Application Level Multicast Infrastructure, Proceedings of the 3rd USNIX Symposium on Internet Technologies and Systems (USITS01), March 2001, pp.49-60. [2] S. Banerjee, B. Bhattacharjee, C. Kommareddy, Scalable Application Layer Multicast, Proceedings of ACM SIGCOMM 2002, August 2002. [3] Y.-H. Chu, S. G. Rao, H. Zhang, A case for end system multicast, Proceedings of ACM SIGMETRICS 2000, June 2000. pp.1-12. [4] Akamai, http://www.akamai.com. [5] Exodus, http://www.exodus.com. [6] Speedera, http://www.speedera.com. [7] Gnutella, http://www.gnutella.com. [8] Freenet, http://freenet.sourceforge.net. [9] KaZaA, http://www.kazaa.com. [10] D. Wetherall, J. Guttag, D. Tennenhouse, ANTS: A toolkit for building and dynamically deploying network protocols, IEEE OpenArch98, April 1998. [11] D. Wetherall, Service Introduction in Active networks, PhD thesis, MIT, February 1999. [12] A. G. Gleditsch, P. K. Gjermshus, Linux Cross-Referencing Project, http://lxr.linux.no/. [13] G. Herrin, Linux IP Networking: A Guide to the Implementation and Modification of the Linux Protocol Stack, http://www.cs.unh.edu/cnrg/gherrin/. [14] J. C. Mogul, K. K. Ramakrishnan, Eliminating Receive Livelock in an Interrupt-Driven Kernel, ACM Transactions on Computer Systems, August 1997, pp.217-252. [15] E. Kohler, R. Morris, B. Chen, J. Jannotti, M.F. Kaashoek, The Click Modular Router Project, http://www.pdos.lcs.mit.edu/click/.

4

Kwaliteit van VoIP en getranscodeerde spraaksignalen

W

ANNEER spraaksignalen over een pakketgebaseerd netwerk getransporteerd worden, zijn ze onderhevig aan totaal andere omstandigheden dan in het traditionele telefoonnetwerk. Bij traditionele telefonie wordt voor elk gesprek een afzonderlijk circuit opgezet zodat de enige belemmering bestaat uit een constante tijdsvertraging en eventuele echo. Bij Voice over IP daarentegen worden de spraaksignalen samen met ander dataverkeer gemultiplexeerd op eenzelfde verbinding in een pakketgebaseerde netwerk en bijgevolg wordt de spraakcommunicatie be¨ınvloed door het gedrag van het overige verkeer. Hierdoor ontstaan specifieke belemmeringen van de netwerkkwaliteit zoals variabele tijdsvertraging (Eng.: jitter) en pakketverlies, die beide een nefaste invloed hebben op de kwaliteit van de spraaksignalen. Hoewel in de toekomst QoS-technieken een aanvaardbare netwerkkwaliteit kunnen garanderen voor bepaalde communicatiestromen, moet men zich in de huidig ontplooide netwerken behelpen met de best-effort dienst. Verder wordt de kwaliteit van de spraaksignalen ook be¨ınvloed door het digitaliseren en coderen van het bemonsterde signaal en het groeperen van de monsters in pakketten. Omdat binnen dit werk een distributiedienst voor spraaksignalen ontworpen en onderzocht wordt, gaan we in dit hoofdstuk dieper in op de verschillende aspecten van spraakkwaliteit bij transport over een pakketgebaseerd netwerk. Dit kwaliteitsonderzoek wordt niet enkel op de ontwik-

4-2

Hoofdstuk 4

kelde toepassing toegespitst, maar wordt ruimer bekeken in het kader van Voice over IP over het huidige best-effort Internet. Daarbij worden eerst de prestaties van het Internet geëvalueerd, zodat de kenmerken van het netwerk bekend zijn. Vervolgens wordt de invloed van digitalisering en codering op de kwaliteit van spraaksignalen onderzocht. Verder wordt de waargenomen kwaliteit van spraaksignalen gemeten wanneer ze getransporteerd worden over een netwerk dat onderhevig is aan pakketverlies, tijdsvertraging en jitter. Tenslotte wordt ook de invloed van één of meerdere transcoderingen op de kwaliteit van een spraaksignaal onderzocht. De evaluatie van de Internetkwaliteit wordt beschreven in de publicatie van Appendix A. De kwaliteitsmetingen van spraaksignalen zijn beschreven in de publicatie van Appendix C en de invloed van transcoderingen op de spraakkwaliteit wordt beschreven in de publicatie van Appendix D. De resultaten van dit hoofdstuk zullen in Hoofdstuk 5 gebruikt worden om de kwaliteit van de onderzochte dienst te evalueren.

4.1

Prestatie-evaluatie van het best-effort Internet

Om een idee te krijgen van de typische omstandigheden waaraan getransporteerde spraaksignalen in het huidige best-effort Internet onderhevig zijn, werd in het najaar van 1998 een uitgebreide reeks metingen opgezet ter evaluatie van de prestaties van het Internet. Begin 2001 werden deze metingen opnieuw opgezet in een permanente opstelling zodat we vandaag een overzicht hebben van de evolutie van de Internet kwaliteit over de afgelopen tweeëneenhalf jaar.

4.1.1

Belangrijke parameters en aanpak

De prestaties van een computernetwerk worden meestal beschreven aan de hand van de volgende parameters. Pakketten zijn bij het transport over een netwerk onderhevig aan de vertraging ten gevolge van het transport over grote afstanden en van de verwerking van de pakketten in elke router. De totale tijdsvertraging heeft een belangrijke invloed op de reactiesnelheid van toepassingen die steunen op een vraag- en antwoordmechanisme, zoals het aanvragen en afbeelden van webpagina’s. De tijdsvertraging heeft ook een invloed op de interactiviteit van een conversatie. Wanneer men te lang op een vraag of reactie van de andere partij moet wachten, is er geen sprake meer van een vlot gesprek. Voor de distributie van multimediastromen is een constante tijdsvertraging op zich geen probleem. Onder invloed van ander getransporteerd verkeer kan echter een variatie van de vertraging of jitter


4-3

optreden, die voor grote hinder kan zorgen. De getransporteerde stromen worden immers niet meer vloeiend ontvangen en het resultaat is een haast onherkenbaar signaal dat met horten en stoten wordt weergegeven. Verder kunnen pakketten ook verloren gaan in overbelaste routers wanneer de totale hoeveelheid verkeer op het netwerk te groot wordt. Dit pakketverlies is nefast voor de kwaliteit van bijna elke toepassing aangezien belangrijke gegevens verloren kunnen gaan. Het meten van deze drie parameters gebeurt op basis van actieve metingen in het Internet, waarbij voor de metingen specifiek testverkeer verstuurd wordt. Op basis van dit testverkeer dat bestaat uit de ICMP echo request en echo reply pakketten, wordt de invloed van het netwerk geëvalueerd. Wanneer men een echo request pakket stuurt naar een machine in het Internet, zal deze antwoorden met een echo reply pakket. Bij ontvangst van het antwoord kan men dan de totale tijdsvertraging van het pakket over het specifieke pad heen en terug naar de beoogde machine meten. Wanneer men meerdere echo request pakketten verstuurt, kan men eveneens het optreden van pakketverlies observeren aan de hand van het aantal niet beantwoorde pakketten. Verder kan men uit een reeks echo request pakketten die binnen een beperkte tijd na elkaar verstuurd worden ook de variatie van de tijdsvertraging opmeten. Het is belangrijk op te merken dat bij deze aanpak alle gemeten waarden gelden voor het heen en terug of tweewegspad. Rekening houdend met het mogelijk asymmetrische gedrag van het netwerk moet men bijgevolg de nodige zorg aan de dag leggen bij het afleiden van benaderende waarden voor het enkele pad. Daarentegen heeft deze meettechniek het voordeel dat de metingen vanuit één meetmachine kunnen gebeuren. Voor de metingen werden een 300-tal machines uit het Internet gekozen, verspreid over de continenten en gegroepeerd volgens een aantal landen of regio’s. Wegens hun economisch en politiek belang ligt het zwaartepunt van de metingen vooral bij Europa en de Verenigde Staten. Elke 15 minuten worden 20 ICMP echo request pakketten verstuurd naar elk van deze machines. Dit laat toe de tijdsvertraging en het pakketverlies vrijwel continu op te volgen. Metingen van de variaties in de tijdsvertraging worden slechts sporadisch uitgevoerd aangezien deze veel meer belastend zijn voor het netwerk. Om een goed beeld van de variatie binnen het bestek van een realistisch telefoongesprek te krijgen is het immers nodig gedurende een aantal opeenvolgende minuten een tiental pakketten per seconde te verzenden die het VoIP-gesprek nabootsen. Aangezien de resultaten van de metingen deels be¨ınvloed worden door het beschikbare toegangsnetwerk van het meetstation naar het Internet is het belangrijk de evolutie van dit toegangsnetwerk over de voorbije jaren

4-4

Hoofdstuk 4

TABEL 4.1: Overzicht van de beschikbare netwerkcapaciteit binnen BELNET en de capaciteit van BELNET naar de Belgische, de Europese en de Amerikaanse netwerken

Jaar 1998 2001 2002 2003

BELNET 4Mbit/s 189Mbit/s 189Mbit/s 2,5Gbit/s

Nationaal 2Mbit/s 1Gbit/s 1Gbit/s 1Gbit/s

Europees 31Mbit/s 79Mbit/s 1,087Gbit/s 2,965Gbit/s

Amerika 12,2Mbit/s 245Mbit/s 1,087Gbit/s 1,622Gbit/s

in acht te nemen. Het meetstation is via een lokaal netwerk verbonden met het universitair netwerk RUGNET. Vanuit het universitair netwerkknooppunt is er een verbinding naar het BELNET netwerk dat de academische centra binnen België verbindt. In het BELNET knooppunt in Brussel worden verbindingen voorzien naar de Belgische commerciële netwerken (via BNIX), naar de Europese commerciële en onderzoeksnetwerken (beide via AMS-IX) en naar de grote Amerikaanse netwerken die voor de verbinding met het globale Internet zorgen. Samengevat ziet de evolutie er als volgt uit. In 1998 bestond het lokale netwerk uit 10Mbit/s Ethernet en werd voor de verbindingen binnen RUGNET Fast Ethernet gebruikt. De verbinding naar BELNET bedroeg 4Mbit/s en vanaf BELNET was er een 2Mbit/s verbinding naar BNIX, 31Mbit/s naar de Europese netwerken en 4Mbit/s en 8,2Mbit/s naar de V.S.. In 2001 konden we een belangrijke verbetering van alle verbindingen vaststellen. Het lokale netwerk was uitgebreid naar Fast Ethernet en RUGNET naar Gigabit Ethernet. Bovendien was de verbinding naar BELNET verhoogd naar 34Mbit/s + 155Mbit/s. Verder bedroeg nu de capaciteit naar BNIX 1Gbit/s en naar de Europese netwerken had men 34Mbit/s via AMS-IX en 45Mbit/s via TEN-155. De Amerikaanse netwerken waren verbonden met 155Mbit/s en 90Mbit/s. In 2002 en 2003 werden vooral de verbindingen naar Europese netwerken en naar de Amerikaanse netwerken verder uitgebreid. Verder werden in 2003 de verbindingen binnen BELNET uitgebreid tot 2,5Gbit/s. Een overzicht van de beschikbare netwerkcapaciteit binnen BELNET en de capaciteit van BELNET naar de Belgische, de Europese en de Amerikaanse netwerken zijn te zien in Tabel 4.1. In de volgende paragrafen bespreken we de belangrijkste resultaten van de metingen die tijdens het najaar van 1998 uitgevoerd werden en die uitvoerig beschreven werden in de publicatie van Appendix A. We vullen deze beschrijving aan met een aantal bijkomende resultaten afkomstig uit recentere experimenten.


4-5

TABEL 4.2: Vergelijking van resultaten voor tweewegstijdsvertraging en tweewegspakketverlies tussen 1998 en 2001

West-Europa Oost-Europa Noord-Amerika Zuid-Amerika Oceanië Afrika Azië Midden-Oosten

4.1.2

Tijdsvertraging 1998 2001 195ms 81ms 640ms 384ms 417ms 181ms 883ms 423ms 739ms 509ms 808ms 365ms 841ms 444ms 1271ms 584ms

Pakketverlies 1998 2001 9,50% 1,16% 13,93% 6,32% 15,27% 3,00% 16,98% 5,32% 12,64% 2,50% 14,41% 3,18% 26,60% 8,17% 23,36% 5,15%

Tijdsvertraging

De tijdsvertraging in het netwerk is voor de meeste toepassingen vooral van belang in verband met de antwoordsnelheid wanneer men bijvoorbeeld informatie opvraagt, een website raadpleegt of een bestand downloadt. Bij toepassingen gericht op conversaties tussen een aantal deelnemers, zoals VoIP of videoconferentie, is de tijdsvertraging echter vooral van belang voor de interactiviteit van het gesprek. Het wordt algemeen aangenomen dat een tweewegstijdsvertraging van minder dan 300ms onopgemerkt blijft, terwijl bij waarden groter dan 800ms de kwaliteit en interactiviteit van de conversatie onaanvaardbaar wordt [1]. Grotere vertragingen leiden immers tot een stroef gesprek waarbij men lang moet wachten op reacties van de andere partij. In deze tweewegstijdsvertraging moet naast de netwerkvertraging ook de pakketizatievertraging en de dejittertijdsvertraging in rekening gebracht worden. Uit Tabel 4.1 is het duidelijk dat er een enorme vooruitgang is geboekt wat betreft de beschikbare netwerkcapaciteit in het toegangsnetwerk. Deze verbetering wordt ook gereflecteerd in de gemeten tijdsvertraging van januari 2001, zoals voorgesteld in Tabel 4.2. In 1998 voldeden slechts de verbindingen binnen West-Europa aan de grens van 300ms en vertoonden verder slechts de verbindingen naar Oost-Europa en Noord-Amerika nog een voldoende marge ten opzichte van de 800ms-grens. De situatie in 2001 is drastisch verbeterd, waarbij alle regio’s voldoen aan de 800ms-grens en de vertragingen van verbindingen binnen West-Europa en naar Noord-Amerika minder dan 300ms bedragen. Ten opzichte van 1998 is immers de tweewegstijdsvertraging ruwweg gehalveerd. Deze aanzienlijke verbetering is nagenoeg geheel te danken aan de uitbreiding van het toegangsnetwerk tussen

4-6

Hoofdstuk 4

eind 1998 en begin 2001, waarbij de oorspronkelijk zeer beperkte voorzieningen drastisch uitgebreid werden. Evolutie van tijdsvertraging per regio 900

Gemiddelde tweewegstijdsvertraging [ms]

800

700

West−Europa Oost−Europa Noord−Amerika Zuid−Amerika Oceanie Afrika Azie Midden−Oosten

600

500

400

300

200

100

0 Jan01

Apr01

Jul01

Okt01

Jan02

Apr02

Jul02

Okt02

Jan03

Apr03

Jul03

Tijd

Fig. 4.1: Evolutie van de tweewegstijdsvertraging naar verschillende regio’s.

De verdere evolutie van de tijdsvertraging in de voorbije tweeëneenhalf jaar wordt in Figuur 4.1 voorgesteld aan de hand van de maandelijkse gemiddelde tweewegstijdsvertraging per regio. Algemeen is te zien dat over de jaren de vertragingen in het netwerk dalen. Er is echter wel de sprong van de waarden voor Afrika en Azië in januari 2002 die het gevolg is van de uitbreiding van de lijst met machines waarnaar testverkeer gezonden wordt. Hierdoor zijn de waarden meer representatief geworden maar blijkt tevens dat de waarden van 2001 voor deze regio’s duidelijke onderschattingen zijn. Het is duidelijk dat verbindingen naar West-Europa en Noord-Amerika het snelst zijn met respectievelijke tweewegsvertragingen van ongeveer 50ms en 150ms. De verbindingen met Oost-Europa, Zuid-Amerika en Oceanië zijn zo geëvolueerd dat we sinds 2002 kunnen rekenen op tweewegsvertragingen van respectievelijk ongeveer 250ms, 300ms en 350ms. De evolutie voor de overige regio’s is eveneens gunstig, maar de vertragingen bedragen nog steeds

4-7


minimaal 450ms tot 550ms. Deze geleidelijke maar voortdurende verbetering sinds 2001 is niet meer specifiek het gevolg van de verdere uitbreiding van het universitaire toegangsnetwerk, maar is veeleer het gevolg van de algemene uitbreiding in de ruggengraatnetwerken van het wereldwijde Internet. Evolutie van pakketverlies per regio 12 West−Europa Oost−Europa Noord−Amerika Zuid−Amerika Oceanie Afrika Azie Midden−Oosten

Gemiddeld tweewegspakketverlies [%]

10

8

6

4

2

0 Jan01

Apr01

Jul01

Okt01

Jan02

Apr02

Jul02

Okt02

Jan03

Apr03

Jul03

Tijd

Fig. 4.2: Evolutie van het tweewegspakketverlies naar verschillende regio’s.

4.1.3

Pakketverlies

Wanneer we de evolutie van de hoeveelheid pakketverlies tussen 1998 en 2001 bekijken in Tabel 4.2, is de verbetering nog drastischer dan bij de tijdsvertraging. Het tweewegspakketverlies is gereduceerd met een factor 2 tot 8. Dit betekent een belangrijke verbetering ten opzichte van 1998, waar pakketverlies lag tussen 10% en 25%. Uit de verdere evolutie voorgesteld in 4.2, leiden we af dat tweewegspakketverlies voor West-Europa, NoordAmerika en Oceanië tussen 1% en 2% schommelt. Voor Oost-Europa, ZuidAmerika, Azië en het Midden-Oosten ligt dit tussen 2% en 4% en voor Afrika rond 6%.

4-8

4.1.4

Hoofdstuk 4

Jitter

Om een idee te krijgen van de jitter die door een mediastroom in het netwerk ondervonden wordt, bootsen we het verkeer van een typische VoIPverbinding na door middel van een specifiek gevormde stroom van ICMPpakketten. Een gesprek gecodeerd met een 8kbit/s codec en verzonden over UDP/IP kan geëmuleerd worden door om de 100 milliseconden een ICMP echo request pakket te verzenden met een totale lengte van 128 bytes (100 byte spraaksignaal plus IP- en UDP-hoofding van respectievelijk 20 en 8 bytes). Wanneer we deze stroom verzenden gedurende een tweetal minuten kan de standaardafwijking berekend worden op de ongeveer 1200 gemeten tijdsvertragingen. Dit geeft dan een idee van de optredende variatie op de tweewegstijdsvertraging. We merken hierbij op dat de keuze voor pakketten van 100ms aan de grote kant is aangezien men meestal pakketten van 10ms to 30ms gebruikt. Deze keuze is echter noodzakelijk aangezien met kleinere pakketten de metingen voor te veel belasting zorgen. De jittermetingen van 1998 werden in juni 2003 overgedaan voor dezelfde bestemmingen en de resultaten van beide experimenten zijn voorgesteld in Tabel 4.3. De variaties op de tweewegstijdsvertraging zijn duidelijk positief geëvolueerd en de omstandigheden zijn bijgevolg heel wat gunstiger voor het ondersteunen van mediastromen en conferentietoepassingen in ware tijd. Dit zal ook blijken wanneer verder in dit hoofdstuk de invloed van jitter op de kwaliteit onderzocht wordt. TABEL 4.3: Vergelijking van jitterresultaten 1998 en 2003

Amsterdam New York Zurich Tokyo Moscow

4.2

Tijdsvertraging 1998 2003 57,0ms 7,2ms 496,5ms 82,4ms 128,0ms 25,8ms 756,3ms 286,0ms 815,8ms 64,4ms

Standaardafwijking 1998 2003 20,7ms 4,0ms 64,4ms 4,5ms 17,6ms 0,5ms 87,4ms 0,4ms 88,3ms 2,3ms

Kwaliteit van spraakcommunicatie over IPnetwerken

In de computernetwerken van vandaag speelt de geleverde dienstkwaliteit of QoS een steeds grotere rol. Hierbij is niet alleen de kwaliteit van de netwerkdienst van belang maar ook die van de ondersteunde toepassingen.


4-9

Daarom willen we in het geval van VoIP de kwaliteit van een gesprek over een IP-netwerk opmeten en vergelijken met de uitstekende kwaliteit die we van het traditionele telefonienetwerk gewoon zijn. In het bijzonder willen we hierbij de kwaliteit meten zoals die door een gemiddeld gebruiker wordt ervaren en willen we de invloed van verschillende netwerkomstandigheden op deze spraakkwaliteit evalueren. Op basis van deze evaluatie kan dan het netwerk aangepast en gedimensioneerd worden om de geleverde dienst te optimaliseren.

4.2.1

Evaluatie van spraakkwaliteit

Aangezien de waargenomen spraakkwaliteit een subjectieve parameter is, worden traditioneel gecontroleerde kwaliteitstesten uitgevoerd met een uitgebreid testpubliek. Hierbij drukt een gemiddeld publiek zijn opinie over de kwaliteit van een aantal signalen uit op basis van de ACR-schaal (Eng.: Absolute Category Rating). Deze schaal gaat van 1 tot 5, waarbij 5 staat voor een uitstekende kwaliteit en 1 voor een slechte kwaliteit. Het uitmiddelen van alle opinies geeft dan een indicatie van de gemiddelde opinie over de kwaliteit of de Mean Opinion Score (MOS), eveneens uitgedrukt op de ACR-schaal [2]. Het resultaat van deze gestandaardiseerde methode is echter subjectief en sterk afhankelijk van het gebruikte publiek en is bovendien zeer tijdrovend. Daarom werden een aantal objectieve methodes ontwikkeld voor het meten van de spraakkwaliteit. Britisch Telecom ontwikkelde het Perceptual Analysis/Measurement System of PAMS-algoritme [3–5], terwijl KPN Research het Perceptual Speech Quality Measurement of PSQMalgoritme en later het PSQM+-algoritme voorstelde [6, 7]. Op basis van deze twee systemen werd uiteindelijk met een gezamenlijke inspanning het Perceptual Evaluation of Speech Quality (PESQ) algoritme ontwikkeld [8, 9]. Elk van deze algoritmen gaat uit van de objectieve registratie en vergelijking van een referentiesignaal en een gedegradeerd signaal. Op basis van de gemeten verschillen en rekening houdend met de kenmerken van het menselijk gehoor wordt dan een schatting gemaakt van de waargenomen kwaliteit, die uitgedrukt wordt als een MOS-waarde. Binnen dit onderzoek werd voor de MOS-metingen gebruik gemaakt van het PAMS-algoritme, waarvoor de nodige apparatuur op het ogenblik van de metingen ter beschikking was. Voor de evaluatie van de spraakkwaliteit werd gebruik gemaakt van de opstelling die in Figuur 4.3 wordt voorgesteld. Deze is gebaseerd op een aantal Linux-PC’s die verbonden zijn met een Fast Ethernet netwerk en waartussen VoIP-verbindingen kunnen opgezet worden. De omstandigheden van dit netwerk worden artificieel gecontroleerd, waarbij specifieke waarden voor de tijdsvertraging, de jitter en het pakketverlies ingesteld kunnen worden. Op die manier kunnen experimenten en metingen uitgevoerd worden on-

4-10

Hoofdstuk 4

MOS waarde

referentie signaal

DSLA

gedegradeerd signaal

Linux PC

Linux PC Linux PC router

geluidskaart

VoIP software

100BaseT ethernet

Internet emulator

zenderknoop

geluidskaart

100BaseT ethernet

VoIP software ontvangerknoop

netwerk interface kaart

instelbaar pakketverlies tijdsvertraging jitter

Fig. 4.3: Meetopstelling voor spraakkwaliteit over een IP-netwerk.

der verschillende en goed gecontroleerde omstandigheden. De belangrijkste componenten van de opstelling worden hieronder besproken. VoIP software Een eigen VoIP-implementatie wordt op twee eindgebruiker PC’s uitgevoerd. Hiervoor zijn beide PCs, die respectievelijk als zender en ontvanger fungeren, voorzien van een netwerkverbinding en een geluidskaart. In de zenderknoop wordt door de VoIP-software een spraaksignaal van de geluidskaart geregistreerd en het signaal wordt bemonsterd aan een frekwentie van 8kHz. De resulterende monsters worden gecodeerd volgens één van de beschikbare codecs en het gecodeerde signaal wordt verpakt in UPD/IP-pakketten en verzonden naar de ontvanger. Daar wordt het signaal gedecodeerd en afgespeeld via de geluidskaart. De beschikbare codecs, waarvoor open ANSI-C-implementaties gebruikt werden, zijn voorgesteld in Tabel 4.4. In de VoIP-software worden ook een aantal gangbare technieken gebruikt zoals detectie van spraakactiviteit en onderdrukking van perioden van stilte, nummering van pakketten om reconstructie van de originele volgorde toe te laten en een dejitterbuffer ter compensatie van de variaties in de tijdsvertraging. Internet-emulator Een Linux-PC die verbonden is tussen de twee eindgebruikerPCs fungeert als een Internet-emulator, die specifieke netwerkomstandigheden kan nabootsen. Op basis van de NistNet-software [10] kunnen specifieke


4-11

waarden voor de tijdsvertraging, de jitter en het pakketverlies ingesteld worden. DSLA De Digital Speech Level Analyser (DSLA) laat toe om de kwaliteit van getransporteerde spraaksignalen te bepalen op basis van het PAMSalgoritme. Hierbij wordt een referentie spraaksignaal door de DSLA gegenereerd en verzonden door het testnetwerk. Na transport door het netwerk wordt het resulterende signaal door de DSLA geregistreerd en opgeslagen. Het PAMS-algoritme voert dan een vergelijking van het originele en het ontvangen signaal uit en bepaalt de MOS-waarde voor het signaal. Hierbij wordt gebruik gemaakt van een psycho-acoustisch model om de werking van het menselijk gehoor in acht te nemen en wordt ook de invloed van verschillende fouten verrekend. Als referentie werd eerst de kwaliteit van het lokale klassieke telefoonnetwerk opgemeten, hetgeen resulteerde in een MOS van 4,3. Dit komt overeen met de uit de literatuur gekende MOS-waarden voor traditionele telefonie [5]. De MOS-waarden waarvoor het corresponderende signaal nog een aanvaardbare kwaliteit heeft, liggen tussen 3 en 5. Bij MOS-waarden kleiner dan 3 is de waargenomen kwaliteit van het signaal onaanvaardbaar. We merken hier ook op dat de MOS-waarden die hier voorgesteld worden in een aantal gevallen licht afwijken ten opzichte van de reeds gepubliceerde waarden in Appendix C. De nieuwe waarden zijn immers afkomstig van recentere experimenten, waarbij echter noodgedwongen een recentere versie van het PAMS-algoritme gebruikt werd1 . De vroegere conclusies gelden echter nog steeds voor de nieuwe waarden.

4.2.2

Invloed van digitalisering en codering

Om een analoog spraaksignaal om te zetten naar een digitaal signaal wordt het bemonsterd aan een frekwentie van 8kHz en de waarden van de monsters worden gedigitaliseerd tot een 16bit-woord. Zo verkrijgt men een 128kbit/s PCM-signaal (Eng.: Pulse Code Modulation). Uit de MOS-waarden in Tabel 4.4 kunnen we afleiden dat de bemonsteringsfrekwentie reeds voor een degradatie van de kwaliteit zorgt, wanneer we het 8kHz-signaal met een 44.1kHz-signaal vergelijken. Hoewel de hoeveelheid informatie in het 8kHz-signaal meer dan 5 keer kleiner is, is de vermindering van de kwaliteit beperkt. De oorzaak hiervoor ligt in het feit dat een spraaksignaal een beperkte bandbreedte heeft en eveneens heel wat redundante informatie bevat. Na de digitalisatie naar een PCM-signaal kan het signaal verder gecodeerd 1 Het DSLA-apparaat onderging sinds de eerste experimenten een gedwongen firmware en software upgrade, waardoor PAMSv2 vervangen werd door PAMSv3, hetgeen uitgebreid is met ”Transfer Function Equalisation”.

4-12

Hoofdstuk 4

TABEL 4.4: Overzicht van beschikbare codecs

Codec PCM 16bit 44,1kHz PCM 16bit 8kHz G.711 µ-Law G.726-7 ADPCM 5bit G.726-7 ADPCM 4bit G.726-7 ADPCM 3bit G.728 GSM-FR G.729 G.723.1

Bitrate 705,6 kbit/s 128 kbit/s 64 kbit/s 40 kbit/s 32 kbit/s 24 kbit/s 16 kbit/s 13 kbit/s 8 kbit/s 5,3 kbit/s

MOS 4,2 4,04 3,80 3,87 3,83 3,39 3,62 3,28 3,30 3,13

ref

[11] [12, 13] [12, 13] [12, 13] [14] [15] [16] [17]

worden tot een lagere bitrate. Aangezien dit neerkomt op het verder verwijderen van een gedeelte van de informatie die in het signaal vervat ligt, zorgt dit voor een bijkomende degradatie van de kwaliteit. Naargelang de compressiegraad en de aard van de codec kan deze kwaliteitsvermindering sterk verschillen. Het is duidelijk dat de codecs met een beperkte bandbreedtereductie (tot 32kbit/s) slechts een kleine degradatie van de kwaliteit tot gevolg hebben. Bij de codecs met een sterkere compressie is de kwaliteitsvermindering aanzienlijk groter. Hierdoor wordt eveneens de gevoeligheid van het gecodeerde signaal verhoogd ten opzichte van bijkomende defecten. Met MOS-waarden tussen 3,1 en 3,4 is de ruimte voor extra degradatie van het signaal immers beperkt. Bovendien stelt elke bit een in verhouding grotere hoeveelheid informatie voor dan bij lagere compressie, zodat bij een fout in verhouding meer schade aangebracht wordt aan het signaal. Na het coderen wordt het digitaal signaal verpakt in UDP/IP-pakketten van een vaste lengte en verstuurd naar de bestemming. In elk pakket wordt een op zichzelf staand fragment van het spraaksignaal verzonden, met een typische lengte tussen 10ms en 100ms. De keuze voor deze korte pakketten wordt bepaald door volgende overwegingen. De pakketlengte bepaalt de extra tijdsvertraging die opgelopen wordt v´ oór het verzenden door het wachten tot een pakket gevuld is. Ze bepaalt eveneens de hoeveelheid informatie die per pakket verloren gaat bij pakketverlies. Verder moet de verhouding tussen de netwerkbelasting van respectievelijk de pakkethoofdingen en de verzonden gegevens geoptimaliseerd worden. In de publicatie van Appendix C werd op basis van metingen getoond dat VoIP-stromen met grotere pakketlengtes gevoeliger zijn voor pakketverlies. In de hier beschreven experimenten werd een pakketlengte van 10ms gebruikt, behalve

4-13


voor GSM-FR en G.723.1, waarbij wegens de eigenschappen van de codecs een minimale pakketlengte van respectievelijk 20ms en 30ms vereist is.

4.2.3

Invloed van pakketverlies

Uit de prestatie-evaluatie van het best-effort Internet is het duidelijk dat men steeds rekening moet houden met een bepaalde hoeveelheid pakketverlies in het netwerk. Op verbindingen binnen West-Europa en naar NoordAmerika en Oceanië is pakketverlies beperkt tot 1% of 2%, terwijl waarden tussen 2% en 8% te verwachten zijn voor de overige regio’s. Spraakkwaliteit in functie van pakketverlies 4 G.711 µ−law G.726−7 5bit G.726−7 4bit G.726−7 3bit 3.5

MOS

3

2.5

2

1.5

1

0

0.05

0.1

0.15

0.2

0.25

0.3

Fractie pakketverlies

Fig. 4.4: Invloed van pakketverlies op de spraakkwaliteit van gecodeerde signalen.

In een reeks experimenten werd de invloed van pakketverlies op de spraakkwaliteit bepaald aan de hand van de resulterende MOS-waarden voor bepaalde hoeveelheden pakketverlies in het netwerk. Uit de resultaten in Figuur 4.4 en 4.5 is te zien dat 1% tot 3% pakketverlies reeds een duidelijke degradatie van de kwaliteit tot gevolg heeft. De kwaliteit blijft echter bij deze waarden nog aanvaardbaar voor bijna alle codecs. Enkel voor GSMFR en G.723.1 worden de MOS-waarden kleiner dan 3. Daarentegen bij 5% pakketverlies wordt de kwaliteit voor de meeste codecs onaanvaardbaar. Enkel G.711 µ-law blijft een aanvaardbare kwaliteit behouden tot waarden van 10% pakketverlies. Bij deze experimenten wordt in het ontvangergedeelte van de VoIP-software op het afspeeltijdstip van een verloren pakket gewoon stilte afgespeeld. Voor kleine pakketverliezen geeft dit haast geen merkbare kwaliteitsverandering aangezien door de kleine pakketten slechts

4-14

Hoofdstuk 4

Spraakkwaliteit in functie van pakketverlies 4 G.728 GSM−FR G.729 G.723.1 3.5

MOS

3

2.5

2

1.5

1

0

0.05

0.1

0.15

0.2

0.25

0.3


Fig. 4.5: Invloed van pakketverlies op de spraakkwaliteit van gecodeerde signalen.

een klein deel van het signaal verloren gaat. Bovendien bevat een spraaksignaal heel wat redundante informatie en heeft het menselijk gehoor een uitmiddelende werking, waardoor een klein ontbrekend stukje niet opvalt. Wanneer bij grotere pakketverliezen meer en ook opeenvolgende pakketten verloren gaan, wordt de kwaliteit snel onaanvaardbaar. Voor beperkte pakketverliezen kan de invloed van dit verlies op een spraaksignaal gecompenseerd of verhuld worden (Eng.: packetloss concealment). Eenvoudige technieken hierbij zijn het opnieuw afspelen van het laatste correct ontvangen pakket of het afspelen van een ruissignaal. Meer geavanceerde technieken [18] zijn ondermeer gebaseerd op de analyse van de ontvangen fragmenten voor en na de verloren pakketten en het voorspellen of schatten van de verloren fragmenten. Hierbij wordt dan een synthetisch signaal met gelijkaardige kenmerken gecreëerd en afgespeeld. Op die manier kan een aanzienlijke fractie pakketverlies verhuld worden voor de luisteraar. De invloed op de kwaliteit van de eenvoudigste techniek waarbij men het laatste pakket opnieuw afspeelt, werd in een beperkt experiment geëvalueerd met de G.711 µ-law codec. De resultaten van de kwaliteitsmetingen met en zonder pakketverliesverhulling worden voorgesteld in Figuur 4.6. Het is duidelijk dat zelfs deze eenvoudige techniek voor een aanzienlijke verbetering van de kwaliteit kan zorgen en dat bij pakketverlies tot 20% nog een aanvaardbare kwaliteit gehaald wordt.

4-15


Invloed van pakketverliesverhulling op spraakkwaliteit 4 G.711 µ−law zonder verhulling G.711 µ−law met verhulling

3.8

3.6

3.4

MOS

3.2

3

2.8

2.6

2.4

2.2

2

0

0.05

0.1

0.15

0.2

0.25

0.3


Fig. 4.6: Invloed van een eenvoudige pakketverliesverhullingstechniek op de spraakkwaliteit.

4.2.4

Invloed van tijdsvertraging en jitter

Zoals in een vorige paragraaf reeds werd vermeld, ligt de invloed van een constante tijdsvertraging bij VoIP vooral in de vermindering van de interactiviteit van een conversatie. Jitter daarentegen heeft een heel nefaste invloed op de verstaanbaarheid van een spraaksignaal. Aangezien bij jitter de tijdsvertraging van verschillende pakketten varieert, zal bijgevolg ook de tijd tussen opeenvolgende pakketten variabel zijn. Aangezien een spraaksignaal aan een constante snelheid verzonden wordt en ook aan dezelfde snelheid afgespeeld moet worden, zorgt jitter voor een belangrijk probleem. Onder invloed van jitter kunnen sommige pakketten uit de stroom immers te laat aankomen, zodat bij het afspelen korte stiltes optreden tussen opeenvolgende pakketten en het oorspronkelijk vloeiende signaal dus vervormd wordt. Zoals in de publicatie van Appendix C ge¨ıllustreerd werd, zijn standaardafwijkingen van 0,1ms tot 1ms reeds voldoende om een onaanvaardbare kwaliteit te krijgen. Om de optredende variaties te compenseren kan men aan de ontvangerzijde een dejitterbuffer gebruiken, waarbij een gedeelte van het signaal gebufferd wordt vooraleer het afspelen begint. Door deze bijkomende tijdsvertraging (dejittertijdsvertraging) wordt het geplande afspeeltijdstip van de pakketten uitgesteld en worden de eisen aan de mogelijke vertragingen versoepeld. Op die manier kan mits een bijkomende vertraging een gelijk-

4-16

Hoofdstuk 4

matige stroom afgespeeld worden. Pakketten die ondanks het extra uitstel nog te laat aankomen, worden als verloren beschouwd en in de dejitterbuffer wordt jitter dus vertaald naar pakketverlies. i∆ + β

di

deadline pakket i

d0 t

a0 a 1 a2

u0

ai

ui

Fig. 4.7: Illustratie van het ver´ eénvoudigde model voor een dejitterbuffer.

Men kan zich nu de vraag stellen hoe groot de dejittertijdsvertraging moet zijn om een bepaalde hoeveelheid jitter te kunnen overwinnen. Daarvoor beschouwen we het volgende model dat ge¨ıllustreerd wordt in Figuur 4.7. Dit model stelt een sterk vereenvoudigde situatie voor waarbij verondersteld wordt dat de aankomsten van pakketten statistisch onafhankelijk zijn en waarbij de vertragingen ervaren door de pakketten in het netwerk normaal verdeeld zijn. Elk pakket bevat een fragment met lengte ∆ en de pakketten worden bijgevolg gelijkmatig verzonden met een interval ∆ tussen opeenvolgende pakketten. De vertrektijd ai van het ide pakket wordt dan voorgesteld door: ai = a0 + i.∆ We onderstellen dat dit ide pakket, verzonden op tijdstip ai , in het netwerk een normaal verdeelde vertraging di ondervindt met gemiddelde µ en standaardafwijking σ en vervolgens aankomt op het tijdstip ui . Voor het ide pakket gelden dan de volgende uitdrukkingen: ui = ai + di P rob[di ≤ x] =

x−µ 1 1 + erf ( √ ) 2 2 σ 2

met

2 erf (z) = √ π

z

2

e−t dt

0

De werking van de dejitterbuffer bestaat erin aan de ontvangerzijde initieel een interval β van het signaal te bufferen en dus het begin van het afspelen met een tijd β uit te stellen. Het eerste pakket zal dus niet onmiddellijk bij aankomst op tijdstip u0 afgespeeld worden, maar wel op tijdstip u0 + β. De geplande afspeeltijdstippen van de volgende pakketten worden eveneens uitgesteld en het afspeeltijdstip van pakket i wordt dus u0 +i.∆+β. Wanneer de pakketten v´ o´ or dit tijdstip aankomen, zijn ze op tijd om afgespeeld te


4-17

worden. Komt een pakket later aan dan wordt het niet meer afgespeeld en wordt het als verloren beschouwd. Op die manier mogen de pakketten een bijkomende vertraging β oplopen in het netwerk. Een pakket zal dus te laat zijn om afgespeeld te worden en bijdragen tot het pakketverlies indien geldt: ui > u0 + i.∆ + β Uit het voorgaande kunnen we dan afleiden dat: P rob[ui − u0 > x]

= P rob[ai + di − a0 − d0 > x] = P rob[a0 + i.∆ + di − a0 − d0 > x] = P rob[di − d0 > x − i.∆] (x − i.∆) − 0 1 1 − erf ( √ √ ) = 2 2 ( 2σ) 2

Hierbij houden we rekening met het feit dat het verschil van twee identiek normaal verdeelde variabelen (di en d0 ) opnieuw √ normaal verdeeld is met gemiddelde waarde 0 en standaardafwijking 2σ. Verder kan nu de kans dat een pakket verloren gaat als volgt bepaald worden: P rob[ui − u0 > i.∆ + β]

= =

i.∆ + β − i.∆ 1 1 − erf ( ) 2 2 2σ β 1 1 − erf ( ) 2 2 2σ

Op basis van deze laatste uitdrukking kan de te verwachten fractie verloren pakketten in de dejitterbuffer berekend worden voor een bepaalde dejittertijdsvertraging en als functie van de jitter in het netwerk. Deze berekende waarden worden in Figuur 4.8 voorgesteld voor dejittertijdsvertragingen tussen 16ms en 64ms. Aan de hand van deze waarden is het mogelijk om de dejitterbuffer te configureren zodat de bestaande jitter in het netwerk gecompenseerd wordt en tegelijk de ge¨ıntroduceerde tijdsvertraging geminimaliseerd wordt. Dit model werd geverifieerd aan de hand van een specifiek experiment waarbij de hoeveelheid verloren pakketten in de dejitterbuffer werden gemeten. Daarvoor werd een spraaksignaal gecodeerd met de G.711 µ-law codec en verzonden in pakketten met een lengte van 8ms. In het netwerk werd in verschillende stappen een tijdsvertraging van 100ms ge¨ıntroduceerd met een standaardafwijking gaande van 0ms tot 40ms en de metingen werden uitgevoerd met een dejittertijdsvertraging van 16ms, 24ms en 32ms. Bij de experimenten werden het aantal verloren pakketten in de buffer gemeten evenals

4-18

Hoofdstuk 4

Pakketverlies in dejitterbuffer volgens model 0.4 β=16ms β=24ms β=32ms β=40ms β=48ms β=56ms β=64ms

0.35


0.3

0.25

0.2

0.15

0.1

0.05

0

0

5

10

15

20

25

30

35

40

Standaardafwijking van de tijdsvertraging [ms]

Fig. 4.8: Berekend pakketverlies in dejitterbuffer onder invloed van jitter en voor verschillende dejittertijdsvertragingen. Gemeten pakketverlies in dejitterbuffer 0.25 meting (β=16ms) meting (β=24ms) meting (β=32ms) model

β=16ms


0.2

0.15 β=24ms

0.1

β=32ms 0.05

0

0

5

10

15


Fig. 4.9: Invloed van jitter op pakketverlies in de dejitterbuffer.

de kwaliteit van het spraaksignaal. De gemeten hoeveelheid pakketverlies is voorgesteld in Figuur 4.9 en wordt er vergeleken met de verwachte waarden uit het model. Het is duidelijk dat de gemeten waarden vrij goed voldoen aan de verwachtingen. Verder worden ook de gemeten MOS-waarden als

4-19


Invloed van dejitterbuffer op spraakkwaliteit 4

3.8

3.6

3.4

MOS

3.2

3

2.8

2.6

2.4 β=16ms β=24ms β=32ms

2.2

2

0

5

10

15


Fig. 4.10: Invloed van jitter op de resulterende kwaliteit van een spraaksignaal.

functie van de jitter en voor verschillende dejittertijdsvertragingen voorgesteld in Figuur 4.10. Hieruit blijkt de degradatie van de kwaliteit overeen te komen met het optredende pakketverlies in de dejitterbuffer. Tot slot wordt in Tabel 4.5 een overzicht gegeven van de maximale pakketverliezen die bij de verschillende codecs nog een aanvaardbare kwaliteit geven en waarbij dus de MOS-waarde groter is dan drie. Eveneens wordt voor elke codec ook de maximale hoeveelheid jitter, uitgedrukt onder de vorm van de maximale standaardafwijking van de tijdsvertraging, die voor verschillende dejittertijdsvertragingen β nog aanvaardbaar is. Deze laatste waarden kunnen voor een gegeven maximaal aanvaardbaar pakketverlies afgeleid worden uit de curven van Figuur 4.8. Deze waarden zijn enkel geldig voor de situatie waarbij slechts één van deze invloeden optreedt.

4.3

Kwaliteit van getranscodeerde spraaksignalen

Transformaties van mediastromen tussen verschillende codecs of transcoderingen zijn van groot belang bij de geavanceerde toepassing die de rode draad vormt door dit werk. Daarom wordt in deze paragraaf aandacht besteedt aan de resulterende kwaliteit van een spraaksignaal na één of meerdere transcoderingen. Verder wordt ook een korte analyse gemaakt van de processorbelasting door de verschillende transcoderingsprocessen. De resul-

4-20

Hoofdstuk 4

TABEL 4.5: Maximaal aanvaardbare waarden voor pakketverlies en jitter voor gecodeerde spraaksignalen.

Codec

G.711 µ-Law G.726-7 5bit G.726-7 4bit G.726-7 3bit G.728 GSM-FR G.729 G.723.1

Pakketverlies 10% 4% 5% 3% 4% 1% 4% 1%

16ms 9ms 6,5ms 7ms 6ms 6,5ms 4,5ms 6,5ms 4,5ms

Jitter β 24ms 13ms 10ms 10,5ms 9ms 10ms 7ms 10ms 7ms

32ms 17,5ms 13ms 13,5ms 12ms 13ms 9,5ms 13ms 9,5ms

taten hiervan worden in Hoofdstuk 5 in rekening gebracht bij de evaluatie van de prestaties van de beschouwde distributiedienst. De codecs die in deze paragraaf beschouwd worden, zijn deze die specifiek voor de multicasttoepassing geselecteerd werden. We bekijken dus slechts een deelverzameling van de hierboven behandelde codecs. Om de invloed van transcoderingen op de kwaliteit te kunnen meten, werd in de opstelling van Figuur 4.3 de Internet-emulator vervangen door een aantal opeenvolgende transcoderingsknopen. Deze knopen decoderen de ontvangen pakketten naar een PCM-16bit-signaal en coderen vervolgens het signaal naar een andere codec. Deze transcoderingen gebeuren steeds naar een codec met een lagere bitrate. TABEL 4.6: Spraakkwaliteit (MOS) van getranscodeerde signalen.

Codec2 Codec1 PCM-16bit G.711 µ-Law G.726-7 4bit G.728

PCM16bit 4,04

G.711 µ-law 3,80

G.726-7 4bit 3,83 3,68

G.728

G.729

3,62 3,53 3,55

3,30 3,28 3,26 3,05

In Tabel 4.6 wordt de kwaliteit van een spraaksignaal na één en twee transcoderingen getoond. Een eerste omzetting bestaat steeds uit de codering van het PCM-16bit-signaal naar een van de codecs. Een tweede transcodering kan dan uitgevoerd worden naar een andere codec met lagere

4-21


bitrate. Hoewel het duidelijk is dat de reductie van de bitrate door de transcodering ten koste gaat van de kwaliteit, blijft de resulterende kwaliteit nog aanvaardbaar met MOS-waarden groter dan 3. Wanneer echter meerdere opeenvolgende transcoderingen uitgevoerd worden op hetzelfde signaal is de kans reëel dat het signaal door de geaccumuleerde kwaliteitsdegradatie onaanvaardbaar wordt. In Figuur 4.11 wordt de kwaliteitsvermindering bij opeenvolgende transcoderingen voorgesteld. De mogelijke scenario’s met drie of vier opeenvolgende transcoderingen worden getoond. We stellen vast dat wanneer de voorlaatste en de laatste codec respectievelijk G.728 en G.729 zijn, de gemeten MOS-waarden terugvallen tot ongeveer 3. In dat geval is de kwaliteit dus nog net aanvaardbaar. Het is ook duidelijk dat de kwaliteit van een signaal dat in meerdere stappen naar de finale codec getranscodeerd wordt steeds lager is dan wanneer het signaal in één keer getranscodeerd wordt. Verder blijkt uit de steeds steiler wordende helling van de curves dat de bijkomende degradatie van de kwaliteit toeneemt met elke transcoderingsstap. Evolutie van spraakkwaliteit bij opeenvolgende transcoderingen 4.5

PCM 16bit 4

G.711 µ−law G.726−7 4bit

MOS

G.726−7 4bit G.728 3.5

G.728 G.729

G.729

3

G.729

2.5

1

2

3

4

Aantal transcoderingen

Fig. 4.11: Invloed van opeenvolgende transcoderingen op de spraakkwaliteit.

Tot slot worden in Tabel 4.7 de verwerkingstijden voor de verschillende transcoderingen weergegeven. Deze waarden zijn vooral van belang bij de prestatie-evaluatie van de multicasttoepassing in Hoofdstuk 5 en ze werden gemeten op een onbelaste Linux-PC met een 1GHz-processor. De voorgestelde waarden zijn de verwerkingstijden voor de transcodering van een spraakfragment met een lengte van 10ms. Om een transcodering van een

4-22

Hoofdstuk 4

TABEL 4.7: Verwerkingstijden van verschillende transcoderingen.

Codec2 Codec1 PCM-16bit G.711 µ-Law G.726-7 4bit G.728

G.711 µ-law 0,01ms

G.726-7 4bit 0,14ms 0,15ms

G.728

G.729

0,66ms 0,66ms 0,79ms

3,64ms 3,65ms 3,77ms 4,07ms

signaal uit te kunnen voeren in ware tijd moet de verwerkingstijd van een fragment kleiner zijn dan de lengte van dat fragment. Het is duidelijk dat aan deze voorwaarde voldaan is voor alle transcoderingen. Een transcodering bestaat steeds uit het decoderen van het signaal naar PCM-16bit en het coderen naar de nieuwe codec. Aangezien het coderen een veel complexere procedure is dan het decoderen wordt de verwerkingstijd van een transcodering vooral bepaald door de complexiteit van de resulterende codec. Dit is ook duidelijk af te leiden uit de resultaten. Verder hebben de G.711 µ-law en G.726-7 4bit codecs een lage complexiteit aangezien ze gebaseerd zijn op PCM. De hybride codecs G.728 en G.729 zijn duidelijk complexer, waarbij G.728 duidelijk sneller is dan G.729.

4-23


Referenties [1] ITU-T, G.114: One-way Transmission Time, ITU-T, 1996. [2] ITU-T, P.800: Methods for subjective determination of transmission quality, ITU-T, 1996. [3] M.P. Hollier, M.O. Hawksford, D.R. Guard, Characterisation of Communications Systems Using a Speech-Like Test Stimulus, Journal of the Audio Engineering Society, Vol.41, No.12, 1993. [4] M.P. Hollier, M.O. Hawksford, D.R. Guard, Objective Perceptual Analysis: Comparing the audible performance of data reduction schemes, Presented to the 96th AES Convention in Amsterdam, Preprint No.3879, 1994. [5] ITU-T, P.56: Telephone transmission quality objective measuring apparatus, ITU-T, 1993. [6] J. G. Beerends, J. A. Stemerdink, Perceptual Speech Quality Measure Based on a Psychoacoustic Sound Representation, Journal of the Audio Engineering Society, Vol. 42, March 1994. [7] ITU-T, P.861, Objective Quality Measurement of Telephone-Band (300-3400Hz) Speech Codecs, ITU-T, 1996. [8] ITU-T Study Group 12, Performance of the Integrated KPN/BT Objective Speech Quality Assessment Model, Delayed Contribution D.136, May 2000. [9] ITU-T, P.862, Perceptual Evaluation of Speech Quality (PESQ), an Objective Method for End-to-End Speech Quality Assessment of Narrowband Telephone Networks and Speech Codecs, ITU-T, 2001. [10] NIST, National Institute of Standards http://www.antd.nist.gov/itg/nistnet/.

and

Technology,

[11] ITU-T, G.711: Pulse Code Modulation (PCM) of Voice Frequencies, IUT-T, 1972. [12] ITU-T, G.726: 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM), ITU-T, 1990. [13] ITU-T, G.727: 5-, 4-, 3-, and 2-bits Sample Embedded Adaptive Differential Pulse Code Modulation, ITU-T, 1990.

4-24

Hoofdstuk 4

[14] ITU-T, G.728: Coding of Speech at 16kbit/s Using Low-Delay Code Excited Linear Prediction, ITU-T, 1992. [15] ETSI, ETS 300 580-1: Digital Cellular Telecommunications system (Phase 2); Full Rate Speech; Part 1: Processing Functions (GSM 06.01), ETSI, 1997. [16] ITU-T, G.729: Coding of Speech at 8kbit/s Using Conjugate Structure Algebraic-Code-Excited Linear-Prediction (CS-ACELP), ITU-T, 1996. [17] ITU-T, G.723.1: Dual Rate Speech Coder for Multimedia Communications transmitting at 5.3 and 6.4 kbit/s, ITU-T, 1996. [18] C. Perkins, O. Hodson, V. Hardman, A survey of packet-loss recovery techniques for streaming audio, IEEE Network Magazine, SeptemberOctober 1998.

5

Een distributiedienst voor spraaksignalen met transcoderingsfunctionaliteit in de multicastboom

D

IT hoofdstuk vormt het sluitstuk van deze thesis en is volledig gewijd aan de geavanceerde netwerkdienst die reeds in Hoofdstuk 1 en 2 kort werd voorgesteld. De verschillende aspecten van deze distributiedienst die in de loop van dit werk onderzocht werden, komen hier aan bod en geven in de eerste plaats een beeld van het gebruik van Actieve Netwerken ter ondersteuning van geavanceerde netwerkdiensten. Door de analyse van deze dienst wordt immers duidelijk hoe de extra functionaliteit in de actieve netwerkknopen aangewend kan worden. Bovendien wordt ge¨ıllustreerd hoe op een flexibele manier nieuwe diensten in een actief netwerk ingevoerd worden en hoe deze diensten op zichzelf meer flexibiliteit kunnen vertonen. Verder worden de specifieke eisen en problemen van een dergelijke dienst duidelijk en worden ook de haalbaarheid en de prestaties van de dienst onderzocht. Eerst wordt een korte theoretische beschouwing gemaakt waarbij de mogelijke optimalisering van de gebruikte netwerkmiddelen in de actieve oplossing ten opzichte van de passieve oplossing in een traditioneel netwerk geëvalueerd wordt. Vervolgens wordt praktisch bekeken hoe op basis van

5-2

Hoofdstuk 5

een actief netwerk de multicastboom en de transcoderingsfunctionaliteit opgezet kan worden, rekening houdend met de aanvragen van de gebruikers en de belasting van de netwerkknopen. Daarna worden een aantal procedures voorgesteld die gebruikt worden in een belast netwerk om transcoderingsprocessen van een overbelaste knoop naar een alternatieve knoop te verplaatsen. De werking van de verschillende procedures werd gesimuleerd voor verschillende configuraties en op basis van de resultaten worden de prestaties van de distributiedienst geëvalueerd. Hierbij wordt eveneens de stabiliteit en de samenhang van de opgezette multicastbomen geanalyseerd. Tot slot wordt ook een evaluatie gemaakt van de dienstkwaliteit zoals ze door de gebruikers ervaren wordt. Hierbij wordt in verband met de spraakkwaliteit gebruik gemaakt van een aantal resultaten uit Hoofdstuk 4. De resultaten die in dit hoofdstuk beschreven worden, zijn eveneens beschreven in de publicaties van Appendix B, D en F. Voor meer gedetailleerde informatie wordt dan ook naar deze appendices verwezen.

5.1

Optimalisatie van de netwerkbelasting bij multicastbomen met transcoderingsfunctionaliteit

In de voorgestelde dienst worden spraaksignalen simultaan naar een aantal gebruikers gezonden, waarbij de gebruikers elk afzonderlijk een bepaald formaat van de beschikbare stroom kunnen kiezen. In een traditioneel netwerk kan dit slechts ondersteund worden door voor elk van de gevraagde formaten van de stroom een afzonderlijke multicastboom op te zetten. In tegenstelling tot deze passieve oplossing wordt in een actief netwerk slechts één enkele boom opgezet. Hierbij wordt initieel één formaat van de stroom verstuurd en waar nodig worden in de tussenliggende knopen van de boom de overige gevraagde formaten afgeleid uit het originele formaat door middel van transcoderingen. Dit werd reeds ge¨ıllustreerd in Figuur 2.3. Om de netwerkbelasting te kunnen evalueren en optimaliseren moet eerst duidelijk zijn waaruit deze belasting bestaat. In het geval van de passieve oplossing in een traditioneel netwerk bestaat de netwerkbelasting uit de gebruikte bandbreedte op de netwerkverbindingen door de verschillende bomen en de verwerkingskracht gebruikt door de transcoderingen in de server. In het actieve geval moet bovendien de gebruikte verwerkingskracht in de netwerkknopen meegerekend worden, aangezien hier ook transcoderingen in het netwerk uitgevoerd worden. Bijgevolg is de optimalisatie van de netwerkbelasting in het eerste, passieve geval tamelijk evident. Het komt er immers op aan voor elk formaat


5-3

de minimale Steinerboom [1] op te zetten. Op die manier zal voor elk formaat de ingenomen bandbreedte minimaal zijn en dus ook de totaal gebruikte bandbreedte van de volledige oplossing. In het actieve geval wordt de netwerkbelasting echter niet alleen bepaald door de vorm van de boom maar ook door de plaatsing van de transcoderingen langs de boom, waardoor de optimalisatie van de belasting een stuk complexer wordt. Om een optimale oplossing voor dit optimalisatieprobleem te vinden, werd een ILPformulering voor het probleem opgesteld. Op basis van deze formulering en de gespecialiseerde CPLEX-bibliotheek [2] kan dan een optimale oplossing voor het probleem berekend worden. De kostfunctie in de formulering werd zo gekozen dat op een eenvoudige manier een verschillend gewicht kan worden gegeven aan de bijdragen in de netwerkbelasting van zowel de bandbreedte als de transcoderingen. In deze bespreking zal echter enkel gekeken worden naar de optimalisatie van de gebruikte bandbreedte waarbij de kost van de transcoderingen niet in rekening gebracht wordt. Bandbreedtegebruik voor multicastboom en server 1100 Multicastboom (actief) Multicastboom (passief) Server (actief) Server (passief)

1000

Bandbreedtegebruik [kbps]

900

800

700

600

500

400

300

200

100

5

6

7

8

9

10

11

12

13

14

15

Aantal gebruikers in groep

Fig. 5.1: Bandbreedtegebruik in de optimale multicastboom en in de serverknoop berekend voor de passieve en de actieve oplossing.

Gewapend met deze beide oplossingsmethoden werden een aantal berekenigen van optimale multicastbomen uitgevoerd. Hierbij werd uitgegaan van een vermaasd netwerk met 19 knopen en 37 linken. Voor elke berekening werd één knoop geselecteerd die als server fungeert, evenals een groep van gebruikers. Elk van deze gebruikers vraagt willekeurig één van de vijf beschikbare formaten die opgesomd werden in Tabel 2.2. De optimale multicastboom werd berekend voor zowel de passieve als de actieve oplossing,

5-4

Hoofdstuk 5

Aantal transcoderingen in multicastboom en server 8 Multicastboom (actief) Multicastboom (passief) Server (actief) Server (passief)

7


6

5

4

3

2

1

0

5

6

7

8

9

10

11

12

13

14

15


Fig. 5.2: Aantal transcoderingen in de optimale multicastboom en in de serverknoop berekend voor de passieve en de actieve oplossing.

waarbij telkens het gebruik van de bandbreedte geoptimaliseerd werd. De berekeningen werden uitgevoerd voor verschillende waarden van het aantal gebruikers in de groep. In Figuren 5.1 en 5.2 worden de respectieve resultaten voor het bandbreedtegebruik en het aantal transcoderingen voorgesteld voor de actieve en de passieve oplossing. Zowel de belasting van de volledige boom als van de afzonderlijke serverknoop worden hierbij weergegeven. Voor de actieve oplossing stellen we een vermindering van de gebruikte bandbreedte in de boom vast tussen 14% en 21% ten opzichte van de passieve oplossing. Voor wat betreft het aantal transcoderingen neemt de netwerkbelasting echter toe, aangezien deze verspreid worden over het netwerk. Verder wordt een drastische verbetering van de belasting van de serverknoop vastgesteld, aangezien minder stromen verstuurd of getranscodeerd moeten worden. De vermindering van de uitgaande bandbreedte in de server bedraagt tussen 24% en 31%, terwijl het aantal transcoderingen in de server gereduceerd is met 76%. Dit werk werd verricht in samenwerking met collega Thijs Lambrecht en werd beschreven in [3]. De theoretische uitwerking van dit en aanverwante problemen zal deel uitmaken van zijn doctoraatsthesis. Meer gedetailleerde resultaten zijn ook beschreven in de publicatie van Appendix B.


5.2

5-5

Procedures voor het opzetten van multicastbomen met transcoderingsfunctionaliteit

Eén van de belangrijkste aspecten van de onderzochte dienst is het opzetten van de multicastboom waarlangs de spraaksignalen getransporteerd worden en waarbinnen de nodige transcoderingen voorzien worden. Bij deze procedures wordt de nodige toestandsinformatie voor de multicastboom in het netwerk opgezet, terwijl de door de gebruikers gevraagde formaten in rekening gebracht worden evenals de belasting van de verschillende netwerkknopen. In de volgende paragrafen wordt eerst dieper ingegaan op de verschillende mechanismen die geboden worden door het in Hoofdstuk 2 en 3 beschouwde ANTS-platform voor Actieve Netwerken. Meer bepaald wordt in paragraaf 5.2.1 praktisch bekeken hoe de beoogde distributiedienst op dit platform opgebouwd en ondersteund kan worden. Vervolgens wordt in paragraaf 5.2.2 de algemene procedure beschreven voor het opzetten van een multicastboom met transcoderingsfunctionaliteit, waarbij wordt ondersteld dat de netwerkknopen nagenoeg onbelast zijn. Wanneer echter bepaalde netwerkknopen onvoldoende verwerkingskracht ter beschikking hebben, kan er op deze knopen geen transcoderingsproces ge¨ınstalleerd worden. Daarom zijn bijkomende procedures nodig die zorgen voor het verplaatsen van deze transcodering naar een onbelaste knoop. Deze worden besproken in paragraaf 5.2.3. Tenslotte wordt ook de stabiliteit en de samenhang van de verschillende procedures geëvalueerd in paragrafen 5.2.4 en 5.2.5. In de volgende beschrijvingen wordt gebruik gemaakt van een distributiedienst met vijf beschikbare formaten of codecs, waarnaar verwezen wordt met A, B, C, D en E. Hierbij heeft codec A de hoogste bandbreedte en codec E de laagste.

5.2.1

Praktische aanpak in een Actief Netwerk

Op basis van het ANTS-platform voor Actieve Netwerken dat reeds in Hoofdstuk 2 en 3 werd besproken, kan het opzetten van een multicastboom met transcoderingsfunctionaliteit als volgt aangepakt worden. Om toe te laten dat een stroom zichzelf langs een multicastboom kan transporteren, is in de knopen van het netwerk toestandsinformatie nodig die er typisch uitziet als in Figuur 5.3. In elke knoop van de boom wordt een deel van de toestandsinformatie voor de betreffende sessie of stroom bijgehouden. Deze informatie bevat een lijst met wijzers die aangeven langs welke verbindingen de stroom verstuurd moet worden. Bovendien wordt bij elke wijzer ook het gevraagde formaat vermeld dat langs deze verbinding verwacht wordt.

5-6

Hoofdstuk 5

server to c 2 A 1 3B A to 4 5 6

c A A C

2

B

transcodering A>C

3

to c 3 B

gebruiker A

4

to c 4 A

gebruiker

A

5

C to c 5 A

gebruiker

6

to c 6 C

gebruiker

Fig. 5.3: Voorbeeld van de toestandsinformatie in de knopen van een multicastboom met transcoderingen.

Op basis van deze eenvoudige toestandsinformatie kunnen actieve pakketten de multicastboom volgen en de stroom afleveren aan de verschillende gebruikers. Zo wordt in knoop 2 uitgaande van de toestandsinformatie de stroom met codec A verdergezonden in de richting van knoop 4 en knoop 5. In de richting van knoop 6 wordt echter codec C gevraagd, waardoor de stroom eerst getranscodeerd wordt en pas daarna verdergezonden. Tenslotte is ook in de eindknopen van de multicastboom toestandsinformatie nodig die de pakketten verderzendt naar de ontvangende toepassing die op de lokale knoop uitgevoerd wordt. In het ANTS-platform kan deze toestandsinformatie bijgehouden worden in de soft-statecache op de knopen. Wanneer deze informatie in de knopen van de boom opgezet is, kunnen de DATA-capsules, die door de server verzonden worden, hun weg naar de gebruikers vinden. Hiervoor dragen de capsules specifieke functionaliteit met zich mee die zorgt dat de stroom in de richting van de verschillende wijzers verzonden wordt. Eventueel wordt ook voor een transcodering naar een ander formaat gezorgd. Voor het transcoderingsproces wordt dan beroep gedaan op de functionaliteit van een specifieke extensie die op de transcoderende knoop ge¨ınstalleerd wordt. Hoe deze verschillende aspecten gecombineerd worden tot procedures voor het opzetten van de toestandsinformatie en het verzenden van een stroom over de multicastboom is ge¨ıllustreerd in Figuur 5.4. Wanneer door de toepassing van gebruiker 3 in Figuur 5.4(a) een JOIN -capsule verzonden


5-7

server

server

(1) Join

3

(6) Code-req

(7) Code-repl

(5) Data

2

to c 2 A

to c 3 A

re

pl

ta

-re q

Da

od

repl

(9)

(3) Code-

(2) Code-req (3) Code-repl (4) uitvoering

(8) uitvoering

-re od q ere pl

req

codecache (3') Join

(5 ) Jo in (6 (7 ) Co )C de

(2) Code-

codecache Join (7') Data

to c 3 A (8) uitvoering

2

(1 (1 0) C 1) C ode

codecache (7') Join

1


(11) Code-repl

(10) Code-req

(9) Join

centrale codecache


1

codecache (11') Join

(1) Data

e-

(13) Join


4


3

(13) Data

to c 3 A

4

(12) uitvoering

toepassing

toepassing

toepassing

toepassing

gebruiker

gebruiker

gebruiker

gebruiker

(a)

(b)

server codecache Join Data

1

codecache Join Data

to c 3 A 4 B

xt-req

(7) E

(6) uitvoering

Cod

e-re

q

e-re

in

Cod

A>B (8')

Jo

(3)

(8) Ext

(5)

(2)

2

-repl

centrale codecache

to c 2 A

codecache (3') Join

pl

codecache Join

3

4

to c 3 A (1) Join

to c 4 B (4) uitvoering

toepassing

toepassing

gebruiker

gebruiker

(c)

Fig. 5.4: Illustratie van de praktische aanpak voor het opzetten van een multicastboom en het verzenden van een stroom op basis van het ANTS-platform.

5-8

Hoofdstuk 5

wordt naar de server, wordt deze eerst verwerkt in knoop 3. Aangezien de capsules slechts een referentie naar de benodigde functionaliteit met zich meedragen, moet eerst geverifieerd worden of deze in de codecache van de knoop aanwezig is. Indien dit niet zo is, wordt een CODE-REQUEST capsule gezonden naar een centrale codecache die hierop antwoordt met een CODE-REPLY -capsule. De gevraagde code wordt dan naar knoop 3 verzonden, waar ze in de codecache opgeslagen wordt. Vervolgens wordt de code uitgevoerd waarbij een wijzer naar knoop 3 met codec A opgezet wordt die de stroom verwijst naar de lokale ontvangende toepassing. Daarna wordt de JOIN -capsule op basis van de standaard IP-routeringstabel verdergezonden in de richting van de serverknoop, waarbij eerst knoop 2 gepasseerd wordt. In deze knoop is de nodige functionaliteit opnieuw afwezig in de codecache, maar deze keer wordt de code opgehaald van de vorige knoop. In deze naburige knoop wordt de gevraagde code immers voor een bepaalde tijd gecachet. De uitvoering van de code zorgt opnieuw voor het opzetten van een wijzer in de richting van de gebruiker. Uiteindelijk wordt ook een wijzer opgezet in knoop 1 en de JOIN -capsule wordt afgeleverd aan de servertoepassing. De server weet nu dat een eerste gebruiker met de multicastboom verbonden is en zal starten met het verzenden van DATA-capsules waarin de stroom verpakt is. Deze procedure wordt in Figuur 5.4(b) verduidelijkt. Opnieuw moet voor de eerste capsule de code van de verwerkingsroutine opgehaald worden. Aangezien deze essentieel is voor de distributiedienst kan deze code ook bewaard worden op de server en kan ze dus daarvan afgehaald worden. Bij de uitvoering van de code wordt dan de toestandsinformatie voor de betreffende stroom bekeken. Aangezien in de richting van knoop 2 enkel formaat A gevraagd wordt, kan de originele stroom ongewijzigd verdergezonden worden. Nadat de capsules ook in knoop 2 verdergezonden worden, wordt in knoop 3 de stroom afgeleverd aan de toepassing van de gebruiker. Wanneer vervolgens ook gebruiker 4 de stroom wil ontvangen met formaat B, wordt een JOIN -capsule verzonden die de nodige wijzers in knoop 4 en 2 opzet. Hierbij stelt men in knoop 2 vast dat het gevraagde formaat B verschilt van het reeds aanwezige formaat A, zodat een transcodering ge¨ınstalleerd moet worden. Bij het opzetten van de wijzer naar knoop 4 voor formaat B wordt dan ook de extensie opgehaald en ge¨ınstalleerd die zal zorgen voor de transcodering van formaat A naar B. Na afloop van deze procedure, die in Figuur 5.4(c) getoond wordt, zullen de aankomende DATA-capsules in knoop 2 verdergezonden worden naar zowel knoop 3 als knoop 4, waarbij in het laatste geval de gegevens van de stroom eerst getranscodeerd worden.


5.2.2

5-9

Opzetten van een multicastboom in een onbelast netwerk server

server

1

(6)

(2)

Joi n

Joi n

n Joi

A

ck J-a

A

A

4 gebruiker

J -a ck

Joi n

Joi (1)

(a)

(1)

n

5 gebruiker

(

3 in Jo

Joi

4 gebruiker

B

B

2 (5)

(3)

A

k

ac

J4)

(8 )

3

A>B

n

2

A>B

(7)

(2)

1

k

-ac

J (3)

B

5 gebruiker

(b)

Fig. 5.5: Illustratie van de procedures voor het opzetten van de multicastboom in de stroomopwaartse (5.5(a)) en de stroomafwaartse (5.5(b)) richting.

De procedure van Figuur 5.4 is ook de algemene procedure voor het opzetten van de toestandsinformatie voor een multicastboom in een onbelast netwerk. Hierbij wordt de toestandsinformatie voor de multicastboom onmiddellijk door de JOIN -capsules in de tussenliggende knopen opgezet terwijl ze zich in de stroomopwaartse richting begeven van de gebruikers naar de server. Aangezien de capsules op basis van de standaard IP-routeringstabellen het kortste pad van de gebruikers naar de server volgen, wordt zo een boom van kortste paden opgezet. Wanneer echter in het netwerk asymmetrische paden mogelijk zijn, kan het kortste pad van gebruiker naar server verschillend zijn van het pad tussen beide in de omgekeerde richting. Bijgevolg is het niet zeker dat met de beschreven procedure de stroom steeds het kortste pad van de server naar de gebruiker zal volgen. Om in dergelijke situatie toch de kortste paden in de stroomafwaartse richting op te zetten kan een alternatieve procedure gebruikt worden waarbij de JOIN -capsules zich eerst tot aan de server begeven. Vervolgens wordt een JOIN-ACK -capsule teruggezonden langs het kortste pad naar de gebruiker, waarbij de nodige toestandsinformatie in de knopen opgezet wordt. Hoewel deze procedure steeds resulteert in een boom bestaande uit de kortste paden in de stroomafwaartse richting wordt binnen dit werk toch gekozen voor de stroomopwaartse procedure. Deze laatste resulteert immers in een snellere

5-10

Hoofdstuk 5

procedure, is minder complex en zorgt voor minder bijkomende belasting in het netwerk ten gevolge van de controleboodschappen. Bovendien beschouwen we in hoofdzaak het gebruik van de dienst binnen eenzelfde domein van een netwerkvoorziener, waardoor de kans op asymmetrische paden vrij klein is. Bijgevolg zal de extra complexiteit en belasting niet opwegen tegen het klein aantal gevallen waarin de stroomafwaartse procedure een betere oplossing biedt. De procedures voor de beide richtingen worden nog kort ge¨ıllustreerd in Figuur 5.5.

5.2.3

Opzetten van een multicastboom in een belast netwerk

In de voorafgaande procedures wordt ondersteld dat de knopen van het netwerk nauwelijks belast zijn en dat dus alle nodige transcoderingen zonder problemen opgezet kunnen worden. Elke transcodering zorgt echter voor een zekere belasting op de knoop door het gebruik van verwerkingscapaciteit en geheugen. Wanneer meerdere van deze processen op eenzelfde knoop ge¨ınstalleerd worden, moet dus rekening gehouden worden met de eindige voorraad middelen waarover elke knoop beschikt. Hiervoor is het nodig dat voor elk transcoderingsproces bepaald wordt welke belasting gegenereerd wordt. Wanneer dan op elke knoop de hoeveelheid beschikbare middelen bijgehouden wordt, kan bij de installatie van een nieuw proces beslist worden of de nodig middelen aanwezig zijn om het te ondersteunen. De vereiste middelen voor de verschillende transcoderingsprocessen werden reeds kort besproken in Hoofdstuk 4 op basis van de gemeten verwerkingstijden op een 1GHz-processor. Uit de in Tabel 4.7 voorgestelde verwerkingstijden voor een spraakfragment van 10ms kan afgeleid worden hoeveel transcoderingen parallel ondersteund kunnen worden. Hierbij is de belangrijkste randvoorwaarde dat de verwerkingstijd van een fragment kleiner is dan zijn tijdsduur, zodat een stroom in ware tijd verwerkt kan worden. Bijgevolg kunnen op een 1GHz-processor 500 tot 1000 transcoderingen naar de G.711 µ-law codec ondersteund worden, 60 tot 70 transcoderingen naar de G.726-7 4bit codec, 13 tot 16 transcoderingen naar de G.728 codec of een tweetal transcoderingen naar de G.729 codec. Wanneer nu bij de installatie van een transcoderingsproces op een knoop een tekort aan middelen vastgesteld wordt, moet dit proces op een andere plaats in het netwerk uitgevoerd worden. Daarvoor worden de drie procedures uit Figuur 5.6 voorgesteld. In het algemeen wordt hierbij het gevraagde transcoderingsproces verplaatst naar een naburige knoop met voldoende beschikbare middelen. In de eerste en tweede procedure, die push upstream en push downstream genoemd worden, wordt gepoogd om het transcoderings-


5-11

proces in een knoop van de reeds opgezette boom onder te brengen, zodat de stroom over de bestaande boom verzonden wordt. Hiervoor wordt het transcoderingsproces respectievelijk in de stroomopwaartse of de stroomafwaartse richting binnen de boom verschoven tot een knoop met voldoende middelen gevonden wordt. In de derde procedure wordt de stroom rondgeleid langs een knoop die fungeert als een proxy voor het transcoderingsproces. Op de overbelaste knoop wordt deze proxyknoop bepaald op basis van de routeringsinformatie in het netwerk en de belastingsinformatie die door de verschillende knopen verspreid wordt. Hierbij wordt de dichtsbijzijnde knoop gekozen die verder over de grootste hoeveelheid bruikbare verwerkingsmiddelen beschikt voor het uitvoeren van het transcoderingsproces. Deze procedure wordt push to proxy genoemd. In de voorbeelden van Figuur 5.6 wordt in de drie gevallen initieel een stroom voor codec A opgezet van knoop 1 naar knoop 3. Wanneer knoop 4 codec B aanvraagt, moet normaal een transcodering van codec A naar B op knoop 2 ge¨ınstalleerd worden. Aangezien deze knoop volledig belast is, moet dit proces echter elders ondergebracht worden. In het geval van push upstream wordt de transcodering in knoop 1 geplaatst en worden codec A en B tegelijk naar knoop 2 gezonden. Bij de push downstream procedure wordt echter de codec met de hoogste bandbreedte – codec A – vanuit knoop 2 verdergezonden naar knoop 4, waar dan de transcodering gebeurt. Tenslotte in het geval van push to proxy wordt codec A eerst naar knoop 5 gezonden waar dan de omzetting naar codec B gebeurt. Codec B wordt dan teruggezonden naar knoop 2 en vandaar verder naar knoop 4. Aangezien in het eerste geval verschillende formaten van de stroom tegelijk over dezelfde verbindingen gezonden worden en in het derde geval de stroom omgeleid wordt naar de proxyknoop is er in de multicastboom bijkomende toestandsinformatie nodig. In deze complexe bomen wordt daarom naast de wijzers (to-veld) en de gevraagde codec (c-veld) nog twee bijkomende velden in de toestandsinformatie gebruikt: het tc-veld en het pshveld. Wanneer in een niet overbelaste knoop de stroom vanuit de zenderknoop aankomt, wordt deze ofwel verdergestuurd ofwel getranscodeerd naar één of meerdere codecs met lagere bitrate. In dit geval zijn alle codecs aangeduid met tc=yes omdat de stroom vanuit de zender naar al deze codecs mag omgezet worden. Wanneer echter in het geval van push upstream vanuit een stroomopwaartse knoop ook een codec met lagere bitrate parallel verzonden wordt en aankomt in de knoop, mag deze enkel verdergezonden worden zonder transcodering. De wijzers voor deze codec worden dan aangeduid met tc=no, terwijl wijzers voor alle andere codecs nog met tc=yes aangeduid zijn. Verder worden in dit geval de wijzers die voor de parallelle codec opgezet worden in de stroomopwaartse knopen aangeduid met

5-12

Hoofdstuk 5

A

A

1 A

A

3

1

A>B

B

1

A

2

100% belast

A

2

100% belast

B

A

4

A

B push upstream

3 A

A

A

A

4 B

push downstream

A>B

A

2

100% belast

B

5

A>B

B

3

4

A

B push to proxy

Fig. 5.6: Verschillende strategieën voor het verplaatsen van een transcoderingsproces van een overbelaste knoop naar een naburige knoop.

psh=yes, aangezien deze codec afkomstig is van een transcoderingsproces dat naar een stroomopwaartse knoop verplaatst werd. Deze aanduiding is noodzakelijk om te voorkomen dat deze parallelle stroom gewijzigd wordt tijdens bepaalde opzet- of afbraakprocedures in de boom. Alle andere wijzers worden normaal met psh=no aangeduid. Het gebruik van deze procedures en de nodige toestandsinformatie worden ge¨ıllustreerd in Figuur 5.7. In Figuur 5.7(a) is in knoop 5 een transcodering nodig van codec A naar B terwijl knoop 5 volledig belast is. Aangezien ook knoop 3 volledig belast is, wordt de transcodering stroomopwaarts verschoven naar knoop 2. Hierdoor wordt op de verbindingen tussen knoop 2 en 5 zowel codec A als B getransporteerd, waarbij de overeenkomstige wijzers voor codec B in knoop 2 en 3 aangeduid zijn met psh=yes. De stroom met codec B is immers afkomstig van een verplaatst transcoderingsproces. Tegelijk moet in knopen 3 en 5 de stroom met codec A niet getranscodeerd worden naar codec B. Daarom zijn in die knopen de wijzers voor codec B ook aangeduid met tc=no. Verder is op de onbelaste knoop 4 ook een normale transcodering van codec B naar C ge¨ınstalleerd, waarbij de wijzers aangeduid zijn met de normale waarden tc=yes en psh=no. In Figuur 5.7(b) is de transcodering van codec A naar B op knoop 2 verschoven naar knoop 5 die als proxy fungeert. Bijgevolg wordt codec B van knoop 2 via knoop 3 naar knoop 5 verzonden, waarna de getranscodeerde codec B teruggezonden wordt langs hetzelfde pad. Hierbij wordt de stroom van knoop 5 naar 2 aangeduid met psh=yes. In knoop 2 wordt codec B dan verderge-


to 3 3 4

A B

2 c A B B

tc y y y

psh n y n

5

A

B

8

A B

4 to c tc psh 6 B y n 7 C y n

6

9

C

3

A A to 3 6 7

c A B A

tc y n y

B

B

2

B

psh n n n

to c tc psh 3 B y y

A

5 A>B

A

B

3

B

to c tc psh 5 A y n 2 B n y

to c tc psh 8 B n n 9 A y n

B>C

A>B


5-13

6

A

7

7

(a)

(b)

2

to c tc psh 3 A y n 4 A y n

A

A>B

3

A A

4

B

6

to c tc psh 6 B y n

(c)

Fig. 5.7: Illustratie van de toestandsinformatie in complexe multicastbomen met overbelaste knopen en verplaatste transcoderingen.

zonden naar knoop 6. In het geval van Figuur 5.7(c) is de transcodering in de stroomafwaartse richting verplaatst van knoop 2 naar knoop 4. Hierbij volstaat echter enkel de gewone toestandsinformatie. Om de toestandsinformatie voor deze procedures in het netwerk op te zetten zijn bijkomende capsules vereist. In het geval van push upstream en push downstream volstaat een eenvoudige PUSH -capsule die in de respectieve richting verstuurd wordt. Hierbij wordt ze verdergezonden tot een knoop gevonden wordt met voldoende middelen om de verplaatste transcodering te ondersteunen, terwijl onderweg de nodige toestandsinformatie opgezet wordt. In gevallen van hoge belasting van het netwerk kan zo het proces verschoven worden naar de server of naar de machine van de gebruiker. De procedure voor push to proxy is complexer en maakt gebruik van PUSH -, PUSH-ACK - en PUSH-REPLY -capsules. Deze zorgen ervoor dat de toestandsinformatie tussen de overbelaste knoop en de transcoderende proxyknoop in beide richtingen opgezet wordt. In Figuur 5.8 wordt de algemene procedure en een aantal specifieke gevallen ge¨ıllustreerd. In de algemene procedure, voorgesteld in Figuur 5.8(a) is een transcodering van codec A naar B nodig op knoop 2 die reeds volledig belast is. Daarom wordt op basis van de routeringsinformatie en de belastingsinfor-

5-14

Hoofdstuk 5

(5) P-ack

2

A B

3

B

3

(2) Push

A B

4 B

(1)

(1)

5

B

(3) P-ack

2

A>B

Join

B

4

(3) Push proxy knoop

(2) Push

A

A

(4) P-ack

A B

Join

A

5

6

6

gebruiker gebruiker

gebruiker gebruiker

(a)

(b)

(5') P-repl (5) P-ack

(4) P-ack

C

A C

2

3

(2) Push

4

(5) P-ack

2

A>C

(3) Push proxy knoop A

5

(4) P-ack

3

C (2) Push

A C

B C

4

B>C

(3) Push proxy knoop B

(1)

(1)

C

Join

A

A

Join

A

6

5

gebruiker gebruiker

6

gebruiker gebruiker

(c)

(d)

(6) P-ack

2

B

(5) P-ack

3

(3) Push

(2) Push

C

D

(1)

B

proxy knoop

4

Join

A

B

CA A>B A>C A>D

(4) Join

A

5

6

gebruiker gebruiker

(e)

Fig. 5.8: Procedures voor het opzetten van toestandsinformatie tussen een overbelaste knoop en een transcoderende proxyknoop.


5-15

matie van de knopen de dichtsbijzijnde knoop bepaald die de transcodering kan ondersteunen. Hierbij wordt eerst voor de onmiddellijk buurknopen nagegaan of ze over voldoende verwerkingsmiddelen beschikken om de transcodering uit te voeren. Indien meerdere knopen aan deze voorwaarde voldoen, wordt de knoop met de grootste hoeveelheid bruikbare middelen gekozen. Wanneer deze eerste stap niets oplevert, worden in opeenvolgende stappen de knopen beschouwd die steeds verder (uitgedrukt in aantal tussenliggende knopen) van de overbelaste knoop verwijderd zijn. In dit geval wordt knoop 4 verkozen en een PUSH -capsule wordt naar deze knoop gezonden met de vraag codec A om te zetten in codec B. Bij aankomst in knoop 4 wordt de nodige toestandsinformatie opgezet en wordt een PUSH-ACK -capsule teruggezonden naar knoop 2. Onderweg zet deze capsule de toestandsinformatie voor de stroom in beide richtingen op. Tenslotte wordt ook in knoop 2 de toestand opgezet en kan de stroom zijn weg vinden naar knoop 4 en terug naar knoop 2. Daar wordt codec B dan verdergezonden naar knoop 6. Aangezien in deze procedure de capsules zich niet noodzakelijk langs de bestaande boom verplaatsen, kan het gebeuren dat ze onderweg op een ander deel van de multicastboom stoten. Wanneer hierbij toestandsinformatie voor de verplaatste transcodering opgezet wordt in een reeds bestaand gedeelte van de boom, moet rekening gehouden worden met mogelijke effecten van interferentie tussen de beide stromen. Daarom worden tijdens de procedure een aantal controles uitgevoerd. Eerst wordt op weg van de belaste knoop naar de proxyknoop gecontroleerd of in de tussenliggende knopen de gevraagde codec B reeds aanwezig is. Wanneer zoals in Figuur 5.8(b) codec B in knoop 3 gevonden wordt, kan deze gewoon verdergezonden worden naar knoop 2, zodat geen transcodering nodig is. Daarom wordt in knoop 3 de nodige toestand opgezet en een PUSH-ACK -capsule wordt naar knoop 2 verzonden. Deze zorgt er dan voor dat het pad opgezet wordt om codec B van knoop 3 naar knoop 2 te transporteren. Wanneer na aankomst van de PUSH -capsule in de proxyknoop de PUSH-ACK -capsule teruggezonden wordt, controleert deze in de tussenliggende knopen of een codec met voldoende hoge bandbreedte aanwezig is, waarvan de gevraagde codec kan worden getranscodeerd. Indien dit het geval is, moet de originele codec niet helemaal van de belaste knoop naar de proxyknoop gezonden worden. In plaats daarvan kan de gevonden codec naar de proxyknoop gestuurd worden. In het geval van Figuur 5.8(c) wordt codec A gevonden, waarvoor reeds door de PUSH-ACK -capsule een pad naar de proxyknoop is opgezet. Bijgevolg moet enkele nog het pad verder opgezet worden naar knoop 2 voor codec C. Daarentegen in het geval van Figuur 5.8(d) wordt codec B gevonden terwijl reeds toestandsinformatie is opgezet voor codec A. Daarom wordt een PUSH-REPLY -capsule naar de proxyknoop verzonden om deze

5-16

Hoofdstuk 5

informatie aan te passen. Tenslotte kan ook op de proxyknoop reeds een codec met voldoende bandbreedte aanwezig zijn, zodat de gevraagde codec B ervan getranscodeerd kan worden. Voor de originele codec A moet dan helemaal geen pad opgezet worden. Wanneer nu op de proxyknoop een codec met onvoldoende bandbreedte gevonden wordt, moet dus codec A naar de proxyknoop gezonden worden. Hierdoor ontstaat echter een situatie waarbij dezelfde stroom in verschillende formaten en langs verschillende paden in een knoop terecht komt, waarbij geen van beiden formaten afkomstig is van een verplaatste transcodering. Om deze situatie te vermijden wordt ervoor gekozen om, zoals voorgesteld in Figuur 5.8(e), in de proxyknoop een JOIN -capsule in de stroomopwaartse richting te versturen om de gevonden codec C te vervangen door codec A. Vervolgens kan dan met een PUSH-ACK -capsule het pad voor codec B opgezet worden naar knoop 2.

5.2.4

Stabiliteit en samenhang van procedures voor het opzetten van multicastbomen

Door de dynamische manier waarop nieuwe takken aan een boom toegevoegd worden, bestaat het gevaar dat tijdens deze procedure de bestaande stroom over de multicastboom verstoord wordt of dat verschillende procedures elkaar gaan be¨ınvloeden. Immers, voor elke nieuwe gebruiker worden JOIN -capsules in het netwerk verzonden die de nodig toestandsinformatie opzetten of bestaande informatie aanpassen. Vooral deze laatste actie kan ervoor zorgen dat bepaalde stromen tijdelijk onderbroken worden. Verder kan een procedure ook permanent resulteren in een meer belastende boom of zelfs in een onderbroken tak wanneer verschillende procedures met elkaar interfereren. In Figuur 5.9(a) wordt ge¨ıllustreerd hoe het opzetten van een nieuwe tak van een multicastboom de aanwezige toestandsinformatie kan be¨ınvloeden en bijgevolg ook de opgezette stroom. In deze situatie is gebruiker 4 reeds verbonden met de server en ontvangt hij de stroom in codec B. Wanneer gebruiker 5 de stroom wil ontvangen met codec A, wordt een JOIN -capsule verzonden die in knoop 3 de aanwezigheid van codec B vaststelt. Aangezien codec A de hoogste bandbreedte heeft, moet deze nu in plaats van codec B vanuit de stroomopwaartse richting in knoop 3 afgeleverd worden. Zo kan de geleverde codec A verdergezonden worden naar knoop 5 en eveneens getranscodeerd worden naar codec B. Nadat de wijzers voor beide codecs opgezet zijn, wordt de JOIN -capsule naar knoop 2 gezonden. Daar moet de toestandsinformatie opgezet worden om codec A af te leveren in plaats van codec B. Wanneer nu gewoon de wijzer voor codec B aangepast wordt naar codec A, wordt de bestaande stroom onderbroken aangezien nog steeds de


to c tc psh 2 B y n

1

A

to c tc psh 3 B y n

(2')

2

to c tc psh 3 A y n

to c tc psh 3 B y n

(4)

(3)

B

to c tc psh 2 A y n

(3')

1

Jo in J-c ln

to c tc psh 2 B y n

(2')

2

3

(1')

(a)

3

(1')

A>B

A

B

4

tc n y tc y

psh n n psh n

to c tc psh 4 B y n 5 A y n

in Jo

in Jo

5

to c tc psh 4 B y n

(1)

(1)

4


(5) J-c ln

(2) Join

(2)

Jo in

A

to c B A to c 3 A

* 33

(4')

to c tc psh 4 B y n

5-17

5 (b)

Fig. 5.9: Illustratie van de invloed van de opzetprocedure op de bestaande stromen in het netwerk en de aanwezige toestandsinformatie.

versie met codec B verstuurd wordt door knoop 1. Pas als de JOIN -capsule knoop 1 bereikt en de wijzer wordt aangepast voor codec A wordt de stroom hersteld. Hoe dit probleem voorkomen kan worden door een iets complexere procedure te volgen wordt in Figuur 5.9(b) getoond. In plaats van onmiddellijk de bestaande wijzer aan te passen met de nieuwe codec, wordt in parallel een wijzer voor codec A opgezet naast de wijzer voor codec B. Op die manier kan de bestaande stroom nog steeds verzonden worden en krijgt men geen onderbrekingen. Wanneer de capsule in knoop 1 aankomt, wordt de wijzer voor codec B wel aangepast naar codec A en schakelt de stroom probleemloos over naar codec A, waarvoor het volledige pad reeds is opgezet. Hierbij wordt het pad voor codec B verder niet meer gebruikt. Daarom wordt een JOIN-CLEAN -capsule teruggestuurd om de overgebleven wijzers voor codec B te verwijderen. In de publicatie van Appendix F wordt deze problematiek uitgebreider behandeld en worden nog een aantal specifieke gevallen en de daarbij horende oplossingen besproken. Naast deze problematiek waarbij de consistentie van de reeds opgezette multicastboom bewaard moet worden, bestaat ook het gevaar dat twee opzetprocedures voor verschillende gebruikers met elkaar kunnen interfereren. Enerzijds bestaat het gevaar dat capsules afkomstig van verschillende procedures tegelijk toestandsinformatie opzetten op dezelfde knoop. Dit probleem wordt opgelost door het feit dat een knoop slechts één capsule

5-18

Hoofdstuk 5

tegelijk mag afhandelen en dat de uitvoering ervan volledig afgewerkt moet zijn vooraleer een nieuwe capsule verwerkt wordt. Hierdoor zal op basis van de volgorde van aankomst steeds een van de concurrerende capsules als eerste uitgevoerd worden en zal vanaf dat moment de toestand van de knoop eenduidige zijn. Een volgende capsule zal dan enkel de reeds bestaande toestandsinformatie aanpassen zoals in de normale procedure. Deze voorzorgsmaatregelen zijn voorzien in de gebruikte ANTS-knoop. Anderzijds kan het gebeuren dat een bepaalde procedure in een knoop gebruik maakt van tijdelijke toestandsinformatie die door een andere procedure opgezet werd. Indien deze informatie dan in de laatste procedure overbodig wordt en verwijderd wordt, wordt de eerste opzetprocedure ondermijnd. Dit kan kort ge¨ıllustreerd worden aan de hand van Figuur 5.9(b) waar bij stap (2’) de wijzer voor codec A opgezet wordt naast die voor codec B. Na Stap (3) wordt vervolgens de wijzer voor codec B op knoop 2 overbodig aangezien dan enkel codec A van knoop 1 naar knoop 3 verzonden wordt. Wanneer echter vó´ or de uitvoering van stap (4’) een JOIN -capsule knoop 2 bereikt met de vraag naar codec B, neemt deze aan dat codec B aanwezig is, hoewel de andere procedure reeds gestart is met het opruimen van de overbodige toestandsinformatie. Bijgevolg wordt een bijkomende wijzer voor de nieuwe tak met codec B opgezet, niettegenstaande deze toestandsinformatie niet meer gebruikt wordt. In dit geval moeten de JOIN -capsules deze specifieke wijzers markeren (met *), zodat andere procedures er geen rekening mee houden en zodat ze ook eenvoudig verwijderd kunnen worden door de JOIN-CLEAN -capsules. Een aantal bijkomende voorbeelden worden ook beschreven in de publicatie van Appendix F. Tot slot moet ook speciaal aandacht besteedt worden aan het afhandelen van een procedure wanneer deze faalt. Wanneer een capsule bijvoorbeeld de server niet kan bereiken of door gebrek aan middelen de procedure moet afbreken, moet ervoor gezorgd worden dat de reeds opgezet informatie opnieuw verwijderd wordt. Hierbij moeten ook de bijkomende takken die ondertussen verbonden werden met de oorspronkelijk opgezette boom afgebroken worden. Dit aspect wordt eveneens behandeld in de publicatie van Appendix F.

5.2.5

Stabiliteit van de multicastboom bij wijzigingen in de multicastgroep

Naast de stabiliteit en samenhang van de opzetprocedures is ook de stabiliteit van de opgezette multicastbomen onder invloed van veranderingen in de multicastgroep van belang. Wanneer initieel een aantal gebruikers zich bij een sessie voegen met een bepaalde codec en in een bepaalde volgorde, wordt


5-19

een multicastboom opgezet die zorgt voor een zo goed mogelijk presterende oplossing en die zo goed mogelijk gebruik maakt van de beschikbare middelen. Deze boom zal in vele gevallen niet overeenkomen met de optimale theoretische oplossing, maar onder de gegeven omstandigheden en met de gebruikte opzetprocedure zal deze de best haalbare oplossing geven. Wanneer echter een aantal gebruikers deze sessie verlaten en nieuwe gebruikers zich bij de sessie voegen, ontstaat een nieuwe boom die voor de gegeven omstandigheden niet meer noodzakelijk de beste oplossing zal zijn. Aangezien voor nieuwe gebruikers een bijkomende tak aan de reeds bestaande boom toegevoegd wordt, zal de toestand van deze nieuwe boom immers steeds bepaald worden door de reeds bestaande boom. Bovendien kan het gebeuren dat bij het verwijderen van een gebruiker overbodige toestandsinformatie achtergelaten wordt zodat de overblijvende boom niet meer de best haalbare oplossing is. Deze problematiek en de vraag of na verloop van tijd de boom nog op de best haalbare wijze gebruik maakt van de beschikbare middelen is vooral van belang voor de beheerder van het netwerk. Dit aspect is immers van belang in verband met de efficiëntie van de dienst en voor het optimale gebruik van de infrastructuur. Aangezien dit aspect van de stabiliteit vooral bepaald wordt door de procedures die gebruikt worden wanneer een gebruiker de boom verlaat, worden deze hier toegelicht. Wanneer een gebruiker een sessie verlaat, zendt deze een LEAVE -capsule in de stroomopwaartse richting die onderweg in de verschillende knopen zorgt voor het verwijderen van de toestandsinformatie die bij het vertrek van de gebruiker overbodig geworden is. Alle toestandsinformatie die echter nog gebruikt wordt voor het versturen van de stroom naar andere gebruikers blijft hierbij onaangeroerd. Dit impliceert echter dat in bepaalde gevallen een minder goede multicastboom overblijft. Dit wordt ge¨ıllustreerd in Figuur 5.10(a), waarbij gebruiker 3 de sessie verlaat. Hierbij wordt door de LEAVE -capsule de wijzers voor codec A in knoop 3 en 2 verwijderd. Ondanks het feit dat tussen knoop 1 en 2 nu enkel codec B nodig is, wordt de toestandsinformatie in knoop 1 echter niet aangepast. Bijgevolg blijft een minder goede boom over waarbij in knoop 2 een transcodering naar codec B nodig is, zodat deze verstuurd kan worden naar knoop 4. De filosofie hierachter is dat gepoogd wordt zo weinig mogelijk bestaande toestandsinformatie aan te passen wanneer deze nog in gebruik is voor het transport van de stroom en waarbij dus de gebruikers een bepaalde invloed op de ontvangen stroom zouden kunnen ondervinden. Enkel in het geval waarbij de aanpassing nodig is om een nieuwe gebruiker met de boom te verbinden is een aanpassing toegelaten. De optimalisatie van de bestaande toestand na het verwijderen van een gebruiker wordt dus niet uitgevoerd. Gelijkaardige situaties komen ook voor bij de procedures voor het verplaat-

5-20

Hoofdstuk 5

3

4 (a)

e av Le

B

A

A

(1)

A

3

4 (b)

3

A>B

(c)

A B

2

2

4

Le av e

e a ve

B

(1) Leave

av Le (1)

A

A

A

A B

2

A>B

e

2

(2) L

A

1

1

1

A

5

A>B

B

(1)

1

3

4 (d)

Fig. 5.10: Illustratie van de procedure bij het verdwijnen van een gebruiker en de overblijvende niet-optimale multicastboom.

sen van een transcoderingsproces van een overbelaste naar een onbelaste knoop. In Figuur 5.10(b) wordt eerst getoond dat bij de push upstream procedure het eenvoudig mogelijk is om de parallel opgezette stroom met codec A te verwijderen zonder de rest van de stroom te hinderen. Op die manier wordt de overblijvende boom geoptimaliseerd. In het geval van push downstream of push to proxy is dit echter niet mogelijk en kan er een minder goede boom uit de procedure resulteren zoals getoond in Figuur 5.10(c) en 5.10(d). Om een idee te krijgen van de verminderde prestatie en de stijging van de gebruikte middelen wanneer de multicastgroep langzaam evolueert onder invloed van verdwijnende en nieuwe gebruikers werden een aantal simulaties uitgevoerd die in de publicatie van Appendix F worden beschreven. Bij deze simulaties wordt een initiële multicastgroep bepaald waarvan de gebruikers in een bepaalde volgorde en met een bepaalde gevraagde codec zich bij de sessie voegen. Dit resulteert dan in een eerste multicastboom. Vervolgens worden geleidelijk een aantal gebruikers verwijderd en nieuwe gebruikers toegevoegd tot een nieuwe multicastgroep verbonden is met de boom. Hierbij bestaat de kans dat deze boom niet de best haalbare is voor de gegeven groep van gebruikers, de volgorde waarin ze toegevoegd werden en hun gevraagde codec. In een laatste stap wordt opnieuw een multicastboom opgezet voor deze laatste multicastgroep met dezelfde volgorde van de gebruikers maar deze keer zonder dat andere gebruikers reeds verbonden zijn. Dit geeft dan de best haalbare boom voor deze opstelling. Voor de boom van zowel de best haalbare als de minder goede oplossing worden


5-21

tenslotte de gebruikte bandbreedte en het aantal transcoderingen bepaald. Deze simulaties werden voor de verschillende procedures uitgevoerd voor verschillende instellingen betreffende de locatie van de initiële en de resulterende multicastgroep en voor verschillende belasting van het netwerk. Uit de resultaten blijkt dat de toename van zowel de gebruikte bandbreedte als van het aantal transcoderingen in de multicastboom maximaal 2,5 % bedraagt.

5.3

Prestatie-evaluatie van de geavanceerde multicastdienst

Na de beschrijving van de verschillende procedures die de beschouwde multicastdienst ondersteunen en mogelijk maken, evalueren we tot slot de prestaties van deze dienst en de dienstkwaliteit ervaren door de gebruikers. De prestatie-evaluatie wordt in de eerste plaats bekeken vanuit het oogpunt van een netwerkbeheerder, waarbij de belasting van de dienst op de onderliggende infrastructuur nagegaan wordt. Op die manier wordt de efficiëntie van de dienst geëvalueerd voor wat betreft het gebruik van de beschikbare netwerkmiddelen. Verder worden de prestaties van de dienst ook geëvalueerd vanuit het oogpunt van de gebruikers, waarbij de klemtoon ligt op de geleverde dienstkwaliteit.

5.3.1

Evaluatie van de netwerkbelasting

De analyse van de netwerkbelasting is gebaseerd op simulaties uitgevoerd in de NS-2 [4] omgeving waarin de netwerkknopen uitgebreid werden met een agent die toelaat de functionaliteit van Actieve Netwerken te gebruiken. De aanpak van deze simulaties wordt beschreven in de publicatie van Appendix D. In het algemeen wordt voor een gegeven serverknoop en een bepaalde groep van gebruikers die elk een specifieke codec aanvragen een multicastboom opgezet. Hierbij wordt gebruik gemaakt van één van de beschreven opzetprocedures en ondervindt het onderliggende netwerk reeds een zekere belasting. Meer bepaald zijn een zekere fractie van de netwerkknopen reeds overbelast zodat ze geen transcoderingsprocessen meer kunnen ondersteunen. Verder wordt in de transcoderende knopen rekening gehouden met de uitvoering van het transcoderingsproces waardoor de stroom een bijkomende vertraging ondervindt. Hiervoor worden de gemeten verwerkingstijden voor de verschillende transcoderingen op een 1GHz-processor gebruikt die reeds in Hoofdstuk 4 in Tabel 4.7 voorgesteld werden. Voor de opgezette multicastboom wordt steeds de netwerkbelasting bepaald op basis van de totale bandbreedte gebruikt in de boom en het totaal aantal transcoderingen in

5-22

Hoofdstuk 5

de boom. Verder wordt ook de belasting van de serverknoop beschouwd op basis van de uitgaande bandbreedte en het aantal transcoderingen in de serverknoop. Deze simulaties werden uitgevoerd voor de verschillende opzetprocedures, voor verschillende aantallen gebruikers in de multicastgroep en voor verschillende fracties van overbelaste knopen in het netwerk. Bandbreedtegebruik in multicastboom 2200 onbelast belast 20% push upstream belast 60% push upstream belast 100% push upstream belast 20% push downstream belast 60% push downstream belast 100% push downstream belast 20% push to proxy belast 60% push to proxy belast 100% push to proxy

2000

Bandbreedtegebruik (kbps)

1800

1600

1400

1200

1000

800

600

400

5

6

7

8

9

10

11

12

13

14

15


Fig. 5.11: Bandbreedtegebruik in de multicastboom bij verschillende procedures, belasting en multicastgroepen.

De hier gepresenteerde resultaten komen voort uit simulaties op hetzelfde vermaasde netwerk met 19 knopen en 37 linken dat ook gebruikt werd voor de berekeningen die in paragraaf 5.1 aan bod kwamen. In Figuren 5.11 en 5.12 wordt eerst het gebruik van bandbreedte en het aantal transcoderingen in de multicastboom ge¨ıllustreerd. Aangezien bij de push upstream procedure in een volledig belast netwerk alle transcoderingen naar de serverknoop verplaatst worden, komt dit geval neer op de oplossing voor de beschouwde dienst in een passief netwerk. Voor elke codec wordt immers een afzonderlijke multicastboom opgezet. De resultaten voor de push upstream procedure bij 100% belasting in het netwerk kan dus als referentie beschouwd worden. Wanneer eerst de resultaten voor een onbelast netwerk bekeken worden, is het duidelijk dat in het actieve geval 11% tot 17% minder bandbreedte ingenomen wordt ten opzichte van de passieve oplossing. Deze vermindering is iets kleiner dan de theoretisch haalbare optimalisatie die in de eerste paragraaf werd voorgesteld aangezien de gebruikte boom van


5-23

Aantal transcoderingen in multicastboom 12 onbelast belast 20% push upstream belast 60% push upstream belast 100% push upstream belast 20% push downstream belast 60% push downstream belast 100% push downstream belast 20% push to proxy belast 60% push to proxy belast 100% push to proxy

11


10

9

8

7

6

5

4

3

2

5

6

7

8

9

10

11

12

13

14

15


Fig. 5.12: Aantal transcoderingen in de multicastboom bij verschillende procedures, belasting en multicastgroepen.

kortste paden immers niet noodzakelijk de optimale boom is. Het is ook duidelijk dat onder alle belastingen de push upstream procedure steeds beter of gelijk presteert ten opzichte van de passieve oplossing. Wanneer immers bij stijgende belasting transcoderingen in de stroomopwaartse richting langs de boom verschoven worden, worden eerst transcoderingen voor de aanwezige codecs met de laagste bandbreedte verschoven. Zo neemt de bandbreedte slechts in beperkte mate toe. Wanneer bij 100% belasting alle transcoderingen verplaatst worden naar de serverknoop, is de gebruikte bandbreedte gelijk aan het passieve geval. De push to proxy procedure presteert beter voor lage netwerkbelasting maar heeft een lichtjes hoger bandbreedtegebruik bij hoge belastingen. Het omleiden van de stroom via een proxyknoop zorgt immers voor het gebruik van extra bandbreedte. De push downstream procedure presteert enkel beter dan het passieve geval voor heel lage belasting. Bij hoge belasting worden steeds meer transcoderingen verschoven in de stroomafwaartse richting, waarbij eerst de transcodering voor de codecs met de hoogste bandbreedte verplaatst worden. Bovendien moet de verschuiving gebeuren langs elke stroomafwaartse link waarover de betreffende codec verzonden wordt. Ook betreffende het aantal transcoderingen kunnen besluiten getrokken worden. Bij toenemende belasting worden in de push

5-24

Hoofdstuk 5

upstream en push to proxy procedures geleidelijk minder transcoderingen gebruikt in de boom. In beide gevallen zullen immers door het verschuiven van de transcoderingen naar onbelaste knopen en het toenemen van het aantal overbelaste knopen steeds meer transcoderingen samenvallen op dezelfde knopen. In het geval van de push downstream procedure worden de transcoderingen echter steeds verder stroomafwaarts in de richting van de gebruikersknopen verplaatst, waardoor het aantal geleidelijk toeneemt. Hieruit blijkt duidelijk dat betreffende de algemene belasting van het netwerk door de multicastboom de push upstream procedure het beste presteert. De push to proxy procedure heeft een lichtjes lagere prestatie, terwijl de push downstream procedure in de meeste gevallen zelfs slechter presteert dan het passieve geval. Bandbreedtegebruik in server 550 onbelast belast 20% push upstream belast 60% push upstream belast 100% push upstream belast 20% push downstream belast 60% push downstream belast 100% push downstream belast 20% push to proxy belast 60% push to proxy belast 100% push to proxy

Bandbreedtegebruik (kbps)

500

450

400

350

300

250

200

5

6

7

8

9

10

11

12

13

14

15


Fig. 5.13: Uitgaande bandbreedte in de serverknoop.

Wanneer echter ook de in Figuren 5.13 en 5.14 gepresenteerde belasting van de serverknoop beschouwd wordt, kunnen een aantal bijkomende besluiten getrokken worden. Opnieuw komen de prestaties van de push upstream procedure met 100% belasting overeen met het passieve geval. Voor zowel het bandbreedtegebruik als het aantal transcoderingen komt dit overeen met de hoogste waarden. Bijgevolg presteren dus alle procedures even goed of beter dan het passieve geval. De push downstream procedure presteert hierbij het best van allemaal aangezien transcoderingen enkel stroomafwaarts verschoven worden. De situatie in de serverknoop wijzigt dus niet ten op-


5-25

Aantal transcoderingen in server 5 onbelast belast 20% push upstream belast 60% push upstream belast 100% push upstream belast 20% push downstream belast 60% push downstream belast 100% push downstream belast 20% push to proxy belast 60% push to proxy belast 100% push to proxy

4.5


4

3.5

3

2.5

2

1.5

1

0.5

5

6

7

8

9

10

11

12

13

14

15


Fig. 5.14: Aantal transcoderingen in de serverknoop.

zichte van het onbelaste geval. Bij de push upstream en push to proxy procedure neemt echter de belasting op de serverknoop geleidelijk toe met stijgende netwerkbelasting. De maximale belasting van de server is echter nooit groter dan in het passieve geval.

5.3.2

Evaluatie van de dienstkwaliteit

Voor de evaluatie van de dienstkwaliteit die door de gebruikers ervaren wordt, worden de volgende aspecten beschouwd. Enerzijds wordt de reactietijd onderzocht wanneer een nieuwe gebruiker zich verbindt met de multicastboom. De reactietijd is hierbij gedefinieerd als de tijd tussen het verzenden van de JOIN -capsule en het ontvangen van de eerste DATA-capsule van de stroom. Anderzijds wordt de spraakkwaliteit van de ontvangen stroom beschouwd. Hierbij wordt gekeken naar het aantal opeenvolgende transcoderingen die de stroom ondervindt op weg van de serverknoop naar de gebruiker. Hierbij wordt gebruik gemaakt van de resultaten in verband met de spraakkwaliteit van transcoderingen die in Hoofdstuk 4 voorgesteld werden. Op basis van de hierboven beschreven simulaties kan ook de reactietijd van de opzetprocedure geanalyseerd worden. In Figuur 5.15 worden de gemeten reactietijden van de opzetprocedure in de stroomopwaartse en de

5-26

Hoofdstuk 5

Reactietijd voor verschillende procedures 22

21

Reactietijd [ms]

20

19

18

17

16

15

14

upstream downstream upstream (niet actief) 5

6

7

8

9

10

11

12

13

14

15


Fig. 5.15: Gemiddelde reactietijd voor het opzetten van een verbinding met de multicastboom voor de stroomopwaartse en stroomafwaartse procedure.

stroomafwaartse procedure voorgesteld. In de stroomafwaartse procedure moet de JOIN -capsule steeds verdergestuurd worden tot aan de serverknoop vooraleer een JOIN-ACK -capsule teruggezonden wordt die de toestandsinformatie voor de nieuwe gebruiker zal opzetten. Bijgevolg resulteert deze procedure steeds in de maximale reactietijd onafhankelijk van het aantal gebruikers in de multicastgroep. Deze reactietijd bedraagt ongeveer tweemaal de gemiddelde tijdsvertraging tussen twee willekeurige knopen in het netwerk plus de gemiddelde vertraging die door de transcoderingen in het netwerk opgelopen kan worden. In de stroomopwaartse procedure zet de JOIN -capsule onderweg reeds de nodige toestandsinformatie op en wanneer een bestaand deel van de multicastboom bereikt wordt, kan de stroom onmiddellijk verzonden worden naar de nieuwe gebruiker. De reactietijd is in dit geval duidelijk kleiner en neemt bovendien ook af voor grotere multicastgroepen. Immers hoe groter de multicastgroep is, hoe groter de kans is dat de JOIN -capsule snel de bestaande multicastgroep bereikt die meer verspreid is over het netwerk. De derde curve uit de figuur stelt de reactietijd voor in het passieve geval, waarbij voor elke codec een afzonderlijke multicastboom opgezet wordt. De JOIN -capsule moet in dit geval verdergestuurd worden tot een knoop van de multicastboom bereikt wordt die de gevraagde codec reeds bevat. In Hoofdstuk 4 werd reeds op basis van de resultaten in Tabel 4.6 besloten dat het uitvoeren van één of twee transcoderingen op een spraaksignaal


5-27

Distributie van het aantal opeenvolgende transcoderingen 70

58.9%

Frekwentiedistributie [%]

60

50

40

30

24.1% 20

16.3%

10

0

0

1

2

0.7%

0.004%

3

4

Aantal opeenvolgende transcoderingen

Fig. 5.16: Distributie van het aantal opeenvolgende transcoderingen ondervonden door de stroom op weg van de serverknoop naar de gebruiker.

nog steeds resulteert in een aanvaardbare spraakkwaliteit. In Figuur 4.11 werd verder de invloed van drie of vier opeenvolgende transcoderingen op de spraakkwaliteit ge¨ıllustreerd. Hieruit blijkt dat in deze gevallen de resulterende MOS-waarden heel dicht bij de nog aanvaardbare waarde van 3 komen. Voor de transcoderingen die een overgang tussen de G.728 codec en de G.729 codec bevatten, wordt de MOS-waarde zelfs licht kleiner dan 3. Bij drie of vier opeenvolgende transcoderingen loopt men dus het risico dat de kwaliteit onaanvaardbaar wordt. Om na te gaan hoe groot de kans is dat een deel van de stroom drie of vier transcoderingen moet ondergaan, werd in de simulaties ook voor elke gebruiker het aantal transcoderingen op het pad tussen de server en de gebruiker gemeten. De daaruit resulterende frekwentiedistributie voor het aantal opeenvolgende transcoderingen is voorgesteld in Figuur 5.16. Het is duidelijk dat de kans dat de stroom drie of vier transcoderingen ondergaat zeer klein is en dat in het overgrote deel van de gevallen de spraakkwaliteit aanvaardbaar zal zijn.

5-28

Hoofdstuk 5

Referenties [1] F. K. Hwang, D. S. Richards, P. Winter, The Steiner Tree Problem, Annals of Discrete Mathematics 53, North-Holland, 1992, pp. 203-282. [2] ILOG, CPLEX: Linear programming http://www.ilog.com/products/cplex/.

optimizer,

[3] T. Lambrecht, B. Duysburgh, T. Wauters, F. De Turck, B. Dhoedt, P. Demeester, Optimizing Multimedia Transcoding Multicast Trees, Submitted for publication in Elsevier Computer Networks Magazine. [4] UCB/LBNL, Network Simulator, http://www.isi.edu/nsnam/ns.

version

2,

NS-2,

1997.

6

Besluit

I

N dit doctoraatswerk werd onderzocht hoe geavanceerde netwerkdiensten opgebouwd kunnen worden steunend op de nieuwe mogelijkheden geboden door Actieve Netwerken. Vanuit een specifiek toepassingsgedreven aanpak werd een bepaald type netwerkdienst onderzocht waarbij inzicht verschaft werd in de revolutionaire mogelijkheden van Actieve Netwerken en in de opbouw en de verschillende facetten van de geavanceerde dienst. Binnen dit kader werd een distributiedienst voor mediasignalen ontwikkeld waarbij verschillende formaten van dezelfde mediastroom over één en dezelfde multicastboom getransporteerd worden. Hierbij wordt initieel één formaat in de boom verzonden en wordt in bepaalde netwerkknopen het originele formaat getranscodeerd naar de andere gevraagde formaten. Dit wordt mogelijk gemaakt door het gebruik van een netwerkinfrastructuur op basis van Actieve Netwerken. Hierdoor kunnen de pakketten naast gegevens ook bijkomende functionaliteit met zich meedragen, die bovendien in de netwerkknopen uitgevoerd kan worden. Op die manier kan tijdens het transport een transformatie van de meegedragen gegevens uitgevoerd worden. Dit laat toe een flexibele netwerkdienst op te bouwen, waarbij bijkomende functionaliteit in het netwerk gebracht wordt en waarbij gebruikers de dienst kunnen aanpassen aan hun eigen wensen, rekening houdend met hun beperkingen. Allereerst werd in Hoofdstuk 2 dieper ingegaan op de verschillende aspecten en mogelijkheden van Actieve Netwerken, waarbij uitgebreid aandacht geschonken werd aan de opbouw en werking van de belangrijkste bouwsteen:

6-2

Hoofdstuk 6

de actieve knoop. Vervolgens werd een zakenmodel voor Actieve Netwerken voorgesteld, waarbij de verschillende partijen aan bod kwamen. Belangrijke nieuwe partijen zijn hierbij actievenetwerken- en actievetoepassingenaanbieders. Verder is een belangrijke rol weggelegd voor connectiviteitsaanbieders die nu ook voor de actieve knopen in hun netwerk moeten zorgen. Aangezien binnen dit model een gebruiker niet de beschikking heeft over de mogelijkheden van een Actief Netwerk om zelf geavanceerde toepassingen op te bouwen, bieden Actieve Netwerken in de applicatielaag een aantrekkelijk alternatief. Hierbij wordt op basis van overlaytechnologie een actief netwerk opgezet tussen verschillende gebruikersmachines die een virtuele actieveknoopomgeving uitvoeren in de applicatielaag. Op deze manier heeft een gebruiker de vrijheid om de mogelijkheden van Actieve Netwerken te gebruiken, onafhankelijk van het onderliggende netwerk. Tot slot werd een overzicht gegeven van verschillende toepassingen gebaseerd op Actieve Netwerken en werd de ontwikkelde geavanceerde distributiedienst voorgesteld. Aangezien het gebruik van Actieve Netwerken in de applicatielaag voorlopig een valabel alternatief biedt in afwachting van een echte actieve netwerkinfrastructuur werd Hoofdstuk 3 gewijd aan de prestatie-evaluatie van deze benadering. Hierbij wordt vooral aandacht besteedt aan de onderliggende concepten: overlaytechnologie en routering in de applicatielaag (ALR). Eerst werd de actieveknoopimplementatie op basis van het ANTSplatform voorgesteld die binnen dit werk in de experimentele opstellingen gebruikt werd. Vervolgens werd aan de hand van deze implementatie de prestaties van routering in de applicatielaag in verschillende stappen geanalyseerd. Achtereenvolgens werden de prestaties van een Linuxrouter, een Javarelaisknoop en een ANTS actieve knoop geëvalueerd op basis van een theoretisch model en metingen op een experimentele opstelling. Er werd aangetoond dat ondanks de aanzienlijke belasting ten gevolge van de pakketverwerking in een actieve knoop toch nog snelheden van 25Mb/s tot 30Mb/s haalbaar zijn. Rekening houdend met de beperkte mogelijkheden van de hardware en de beperkte prestaties van de onderliggende Javatechnologie zijn dit beloftevolle resultaten die reeds toelaten dat meerdere mediastromen parallel door een ANTS-knoop ondersteund en verwerkt worden. Aangezien binnen dit werk meer specifiek aandacht besteed werd aan een geavanceerde distributiedienst voor spraaksignalen, werd in Hoofdstuk 4 dieper ingegaan op het transport van spraaksignalen over een IP-netwerk (Voice over IP) en op de daaruit resulterende kwaliteit van de signalen. Binnen dit kwaliteitsonderzoek werden eerst de prestaties van het Internet geëvalueerd over de afgelopen jaren op basis van een aantal continue metingen. Vervolgens werd de invloed van deze waargenomen netwerkomstandigheden, in termen van pakketverlies, tijdsvertraging en variatie van de tijdsvertraging

Besluit

6-3

(jitter), geëvalueerd op de kwaliteit van de getransporteerde spraaksignalen. Hierbij werd ook de invloed van digitalisering en codering onderzocht. Tenslotte werd ook de invloed van één of meerdere transcoderingen op een spraaksignaal nagegaan. Hierbij werd gebruik gemaakt van een objectieve meetmethode waardoor de kwaliteit van de signalen uitgedrukt kon worden door middel van een MOS-waarde. Er werd aangetoond dat het gebruik van pakketverliesverhullende technieken en dejitterbuffers de degradatie van de spraakkwaliteit onder invloed van respectievelijk pakketverlies en jitter kunnen beperken. Verder werd vastgesteld dat, uitgaande van de gangbare spraakcodecs, twee opeenvolgende transcoderingen nog steeds een aanvaardbare kwaliteit opleveren. Tot slot werden in Hoofdstuk 5 de verschillende aspecten van de distributiedienst belicht die in de loop van dit werk aan bod kwamen. Eerst werd kort een theoretische beschouwing gemaakt over de optimalisering van de gebruikte netwerkmiddelen in deze dienst, waarbij zowel de actieve als de passieve oplossing geëvalueerd werd. Er werd aangetoond dat door het gebruik van de actieve oplossing 15% tot 20% minder bandbreedte gebruikt wordt in het netwerk ten opzichte van de passieve oplossing en dat ook de server minder belast wordt. Vervolgens werd praktisch bekeken hoe de nodige multicastboom opgezet kan worden in een actief netwerk, waarbij rekening gehouden wordt met de aanvragen van de gebruikers en waarbij de nodige transcoderingsfunctionaliteit ge¨ınstalleerd wordt. Hiervoor werden verschillende procedures voorgesteld die bovendien rekening houden met de belasting van de netwerkknopen en in staat zijn transcoderingen te verplaatsen van een overbelaste naar en onbelaste knoop. De prestaties van deze procedures werden onderzocht op basis van simulaties voor verschillende configuraties. Verder werd ook aandacht besteedt aan de invloed van de procedures op de stabiliteit en samenhang van de multicastbomen, hetgeen leidde tot een aantal uitbreidingen van de voorgestelde procedures. Tot slot werd ook de algemene dienstkwaliteit van de distributiedienst geëvalueerd vanuit het oogpunt van zowel de gebruiker als van de netwerkbeheerder. Hierbij werd vastgesteld dat de Push Upstream procedure voor de laagste netwerkbelasting zorgt. Verder werd aangetoond dat de kwaliteit van getranscodeerde spraaksignalen in zowat 99% van de gevallen aanvaardbare is, waarbij niet meer dan twee opeenvolgende transcoderingen uitgevoerd worden. Tot slot vermelden we hier nog een aantal uitbreidingen of suggesties tot verder onderzoek die vanuit dit werk gesuggereerd kunnen worden. Recent kan men twee relevante evoluties vaststellen op het vlak van spraakcodering. Hierbij worden geavanceerde codecs ontwikkeld die enerzijds robuust zijn tegen fouten en die anderzijds gebruik maken van verschillende bitrates

6-4

Hoofdstuk 6

binnen dezelfde codec. Hiervoor kan eveneens een evaluatie van de prestatie en de resulterende kwaliteit uitgevoerd worden. Op basis van de hier beschreven distributiedienst, die enkel uitgewerkt werd voor het transport van spraaksignalen, kunnen ook diensten voor distributie van video en multimedia opgebouwd worden. Voor de ondersteuning van videodistributie en transcodering kan dan gesteund worden op gelaagde codering, waarbij het signaal bestaat uit een basislaag en verschillende bijkomende lagen die voor verbeterde kwaliteit zorgen. Door het verwijderen van deze bijkomende lagen kan het signaal eenvoudig omgezet worden naar een lagere bitrate. Verder kan transcodering van een MPEG-gebaseerd videosignaal ook ondersteund worden door het verwijderen van bepaalde frames uit het signaal. Hoewel deze filtertechnieken zeer aantrekkelijk zijn door hun eenvoud, kunnen ze echter snel resulteren in een onaanvaardbare kwaliteit. Bijgevolg moeten ook meer geavanceerde technieken aan bod komen, waarbij de haalbaarheid van deze complexe berekeningen in ware tijd een belangrijk aspect vormt. Wanneer men een multimediadienst ontwikkelt, moet men met een aantal bijkomende aspecten rekening houden: synchronisatie van de verschillende signalen (audio, video) die getranscodeerd worden en installatie van meerdere transcoderingsprocessen voor de verschillende componenten van de stroom. Naast transcodering van mediastromen kan ook het probleem van transmodering bekeken worden. Hierbij wordt een mediasignaal op basis van bijkomende informatie in de stroom omgezet in een tekstuele beschrijving of samenvatting. Op die manier kan een videosignaal omgezet worden naar een beschrijving van de beelden die op een niet-grafisch toestel, bijvoorbeeld een gsm, geraadpleegd kan worden. Door de transcoderingsfunctionaliteit te vervangen door filterfunctionaliteit kan de beschreven dienst ook gebruikt worden als een framework voor gegevensdistributie met ingebouwde filtering. De filters kunnen hierbij opgezet worden op basis van de aanvragen van de gebruikers die een bepaalde soorten informatie of een specifieke selectie van de beschikbare gegevens wensen te ontvangen. De voorgestelde dienst kan ook uitgebreid worden met bijkomende intelligentie, zodat het opzetten van transcoderingen vanuit de boom ge¨ınitieerd kan worden. Op die manier kan bijvoorbeeld dynamisch ingespeeld worden op de wisselende belasting van het netwerk en kan, om overbelasting te vermijden, de bitrate in sommige delen van de boom tijdelijk gereduceerd worden.

Appendices

Performance Measurements on the Current Internet Stefaan Vanhastel, Bart Duysburgh, Piet Demeester. 7th Workshop on Performance Modelling and Evaluation of ATM & IP Networks - IFIP Working Conference TC6 (Communication Systems), June 28-30, 1999, Antwerp, Belgium. Abstract — The goal of this paper is to provide a summary of the typical conditions encountered on the current Internet. Typical values for the four most important parameters - hopcount, packet loss ratio, delay and delay jitter - are presented, giving an indication of the typical degradation in quality that a voice/video stream over the current Internet is likely to experience. To conclude, these results will be used to answer the question whether VoIP is feasible over a best effort network.

A.1

Introduction

Currently, Voice over IP (VoIP) is one of the hottest topics in the world of telecommunications. VoIP comprises the integration of voice or telephone traffic in the Internet, a best effort packet based network. This integration has some major advantages, resulting in a lot of research being performed on the subject of VoIP. The main advantage is that integrating different types of traffic on a single network eliminates the need for seperate dedicated networks and hardware. A second advantage is that network operators can diversify their product range; typical data carriers can now offer voice/telephony services as well. A third advantage (from the consumers point of view) is generally cheaper or even free (long-distance) calls and video-conferencing sessions, albeit with lower quality. There is however a trend to start billing VoIP calls, certainly on dedicated VoIP backbones [1]. This will again stimulate the deployment of VoIP, opening a new profitable market for players on the telecommunications field. A fourth advantage is that VoIP enables new players in the telecom sector to enter the mar-

A-2

Publicatie A

ket in a relatively easy way. It is no longer necessary to provide an access network to the consumers premises; instead, an operator can assume that the customer uses the traditional telephone network to access and use the providers backbone. So new operators only have to invest in a (dedicated VoIP) backbone. There are however some disadvantages involved with the transport of voice traffic over a packet based network such as the Internet. The most important problem is the fact that the Internet does not provide any Quality of Service (QoS), whereas the traditional PSTN does. The PSTN provides a dedicated circuit to the customers premises to transport the speech signal, thus ensuring a short and constant delay and no loss of data. On the contrary, end-to-end connections over the current Internet typically suffer from a degraded overall quality, caused by intrinsic network behavior. The links used to transport the speech data are shared links, also used to transport other (voice or traditional) data, leading to a possible lack of bandwidth or to congestion in certain nodes of the network. Congested links and heavily loaded nodes introduce delay, variations in delay (jitter) or even packet loss, all of which increase with the number of nodes a packet has to traverse (the hopcount). Below, a summary of the typical conditions encountered on the current Internet is provided. To describe the performance of the Internet, the four most important parameters are observed: hopcount, packet loss ratio, delay and delay jitter. These were measured for different hosts and different backbone networks over a sufficiently long period of time, so that useful conclusions can be drawn.

A.2

Setup

In order to be able to create a comprehensive overview of the overall performance of the Internet, a list of geographically seperated hosts had to be gathered. For each of these hosts, a large number of performance measurements was performed on the link from the departments test network (“Atlantis”) to that specific host. This way, typical performance characteristics for some major routes through the Internet could be identified. Target host selection was based on two criteria: 1. The number and location of hosts was chosen in accordance with the perceived economical and/or political importance of a particular region. The reason behind this is that highly developed regions have larger and more developed networks and attract more traffic due to the amount of interesting content that can be found on local servers.

Performance Measurements on the Current Internet

A-3

2. Hosts were chosen so that a minimum number of hosts per location were accessed through more or less the same route over the Internet. This means that for each major route or backbone that was tested, a sufficient number of target hosts was available to eliminate any influences of local access networks. The list of hosts that was used for the final measurements dates from mid-1998 and includes 250 different targets, roughly grouped in 48 geographical distinct regions (Figure A.1). The workstation from which the measurements were conducted, has a direct connection to the Internet through the university network RUGNet and the Belgian academic network BelNet [7]. A number of experiments were performed to check for (any excessive) influence of the local network. Three of the four above-mentioned parameters were measured for a number of hosts in this network (jitter was not specifically checked because delay measurements showed that delay was almost constant even over a large period of time): Hopcount The local network adds six hops to the total hopcount. Although this might seem quite a lot, this is actually an acceptable value (see Section 3.1 ), therefore this offset was not subtracted from the total hopcount values. Packet Loss Packet loss is virtually non-existent (magnitude 10−5 ) and neither is there a busy-hour phenomenon. The packet loss is constant throughout the day and can safely be neglected. Delay Round Trip Times to the hosts in the local backbone remain mostly constant (12ms). There is no fluctuation over time, so the local network will only introduce a constant offset in the measurements on the Internet.

A.3

Measurements

Measurements were conducted during a 30-day time span in mid-1998, in which all the hosts on the target list were probed with 20 packets every 15 minutes. Figure A.2 defines some of the terminology used in the rest of this paper. A user is connected to an Internet Service Provider (BelNet in this case) through an access network and the network of the ISP is connected to the large “Internet” backbones through an uplink. Prior to the final measurements, a test run was conducted to identify anomalies. Hosts that displayed erratic behavior (large periods of time

A-4

Publicatie A

San Francisco

European routes backbone

Fig. A.1: Geographical location of target regions and routes to those regions.

Local Access (ISP)

BACKBONE NETWORK

Local Access (ISP)

Local host

Remote host

Uplink to Bbone

Uplink to Bbone

Fig. A.2: Reference Network.

A-5


with 100% packet loss for example) were omitted from the list since this was caused by either the host being off-line for prolonged periods of time or the target hosts security policy.

A.3.1

Routes & Hopcount

Since each node on a network needs some time to perform a route table lookup and to forward a packet, and each congested node represents an increased chance for packet loss, the typical number of nodes in a connection is a relevant parameter. Although packet loss, jitter and delay are measured over the end-to-end connections and not as single-hop parameters, and therefore the hopcount is not explicitly required for the measurements, typical values are useful data for theoretical models. The route to a host and its hopcount was determined using traceroute, a standard tool. Traceroute attempts to elicit an ICMP TIME EXCEEDED response [9] from each gateway along the path to a specific host, by sending successive UDP [10] packets with an incrementing Time To Live (TTL) value [11] to the target host. Each node decrements the TTL value by one; consequently the node where the TTL reaches zero will drop the packet and return a TIME EXCEEDED message, thus revealing itself to the source host. Traceroute also uses incremental target UDP ports as a sequencing mechanism. 19

Hopcount (hops)

18.5

18

17.5

17

16.5 Middle North South Africa East America America Average

18.0741

17.2857

18.7

Asia

18.0625 17.8462

Oceania Europe 17.4375

17.85

World 17.8387

Fig. A.3: Average hopcount for different regions.

Figure A.3 shows average values for the hopcount to different regions. The most striking feature is that geographical distance does not translate into the hopcount. The average hopcount for South America and Oceania

A-6

Publicatie A

are lower than the average European hopcount. There are two main reasons for this. First, individual countries do not necessarily interconnect (or peer) with their neighbors (a notable exception being of course the pan-European Ten-155 network). Instead, they can opt for a direct satellite link with for example San Francisco, as is the case for Cyprus. A second reason is that in highly developed (mostly Western) countries with a longer Internet tradition, networks tend to be denser, interconnect more sites, and consequently count more nodes. The route traces also revealed that during the entire duration of the measurements, the routes did not change once. The fact that all routes displayed static behavior is caused by a lot of networks having a star topology, making rerouting of connections impossible. This was evidenced when Belnet’s San Francisco uplink broke down during a preliminary test; for days, large parts of the Internet were unreachable from Belgian universities. The failure was traced down to a single interface failure, but this illustrates the fact that although dynamic routing protocols are used to configure the routers initially, the routing tables are mostly static. Overall, the hopcount averages about 18. Examination of the route traces showed that for most connections the hops are evenly divided between source local network, backbone, and destination local network. Applied to a real-life example, an 18-hop connection from Ghent to Houston would count 6 hops in RUGnet/Belnet, 6 on the Cable&Wireless backbone, and 6 in the local ISP’s network in Houston.

A.3.2

Packet Loss

Similar to delay, packet loss is mainly a function of the load on nodes. When a router experiences extremely high load and can no longer process incoming packets (or store them in queues for later processing), packets will be dropped. Packet loss is measured on end-to-end connections using ping, which, besides delay, also returns the number of packets that the destination host did not reply on. Figure A.4 shows the actual packet loss ratio to two destinations in function of the time. The data are averaged over several hosts in Belgium and several hosts in New York and are representative for other routes. The graph covers a nine day period at the end of October 98. The values are the average packet loss ratios over one hour, so an average was made over the 80 packets that were sent each hour. The graph clearly shows busy hour patterns: the 9 individual days can clearly be distinguished, starting with Saturday October 24th 1998, and ending with Sunday November 1st, 1998. The most obvious pattern is formed by the 5 weekdays, where the busy peri-

A-7


Packet Loss (%)

30.00%

new york belgium

25.00% 20.00% 15.00% 10.00%

11/01/98

10/31/98

11/01/98

10/30/98

10/31/98

10/29/98

10/30/98

10/28/98

10/29/98

10/28/98

10/27/98

10/27/98

10/26/98

10/26/98

10/25/98

10/25/98

10/24/98

0.00%

10/24/98

5.00%

Fig. A.4: Average two-way packet loss for different regions over a 7-day period.

Packet Loss (%)

35.00% 30.00% 25.00% 20.00% 15.00% 10.00% 5.00% 0.00% Europe

South North Oceania America America

Middle East

Asia

Africa

World

Packet Loss (Busy)

13.44%

20.00%

18.12%

15.43%

29.08%

29.43%

19.23%

19.17%

Average Packet Loss

11.23%

16.98%

15.27%

12.64%

23.36%

26.60%

14.41%

16.16%

13.47%

11.90%

9.36%

16.76%

23.23%

8.78%

12.64%

Packet Loss (Non-Busy) 8.66%

Fig. A.5: Average two-way packet loss for different regions.

ods coincide with the working hours. When looking closely at the graph for Belgium (monday October 26th for example)), it is possible to distinguish 3 peaks: 2 caused by business traffic (before and after lunchbreak), and the 3rd peak in the evening caused by residential traffic. Weekend traffic is lighter, but imposes a high strain on the transatlantic links. What is interesting, is the fact that the busy periods on these routes coincide, even though the target hosts are located in different timezones. Since the local network (BelNet) does not introduce time-dependent behaviour (see Section 2 ), and the overall link shows busy periods aligned with the local timezone, we can only conclude that the time-dependent behaviour is induced by the ISP’s uplink, and thus that the Belnet uplink is underdimensioned1 . Further evidence for this is presented in the section on jitter. 1 Note that shortly after the measurements, Belnet upgraded all its international uplinks

A-8

Publicatie A

Because there is a clear difference between packet loss ratios for busy and non-busy hours, averages for both were calculated seperately for each region (Figure A.5). For all regions, there is a significant difference between the values for busy and non-busy hours: for example, Europe and North America show a 50% increase in packet loss during busy hours, while the packet loss for the Middle East almost doubles during the busy hours. Typical values for two-way packet loss (busy hours) are 15% to 20%.

A.3.3

Delay

Delay is introduced when a router or node in a network is not able to process and forward an incoming packet in a timely fashion. This occurs when the node is heavily loaded or when the node uses a priority mechanism and higher priority packets arrive at the same moment. Delays were measured as Round Trip Times on end-to-end connections with ping (a standard tool), because measuring one-way delays involves synchronising at least two machines. Unless resorting to expensive GPSbased solutions, only precisions of 10−2 to 10−1 can be achieved with NTP (Network Time Protocol) [12]. When measuring Round Trip Times, sender and receiver are on the same machine and syncing is not an issue. Ping sends ICMP ECHO REQUEST messages at a specific rate (default 1 Hz) to the target host, which replies with an ICMP ECHO REPLY message. The ECHO REPLY also includes the original payload, which contains a timestamp representing the time at which the ECHO REQUEST was sent. This effectively provides the sender with an accurate timestamp without the need to keep track of all the sent packets internally. Delays to intermediate nodes were not measured, because intermediate nodes are mostly dedicated routers with hardware optimized for forwarding packets, not decoding packets and composing a reply. The results discussed below represent two-way delays (round trip times). There is no straighforward way to derive one-way delays from the Round Trip Time: routes display asymmetrical behaviour [15] [16], resulting in different end-to-end delays for up- and downstream connections. Figure A.6 shows the RTT in function of the time during the same period as in Figure A.4. The same fluctuation pattern as for packet loss can be observed, only less pronounced. This is logical, since during the working hours, more packets will be sent. This results in overloaded links, which in turn results in routers dropping packets. The remaining packets will suffer from almost the same delay as packets experience during nonworking hours (still the same transmission delay and modem delay, only the queueing delay might be slightly higher). Therefore, the impact of high traffic load on packet loss is more pronounced than on round trip times.

A-9


800 new york 700

belgium

RTT (ms)

600 500 400 300 200

11/01/98

11/01/98

11/01/98

10/31/98

10/31/98

10/30/98

10/31/98

10/30/98

10/30/98

10/29/98

10/29/98

10/28/98

10/29/98

10/28/98

10/28/98

10/27/98

10/27/98

10/26/98

10/27/98

10/26/98

10/26/98

10/25/98

10/25/98

10/24/98

10/25/98

10/24/98

0

10/24/98

100

Fig. A.6: Average Round Trip Times for different regions over a 7-day period.

RTT (ms)

1500

1000

500

0 Europe

South North Oceania America America

Middle East

Asia

Africa

World

Delay(Busy)

405

879

429

723

1396

865

951

Average Delay

353

883

417

739

1271

841

808

684 650

Delay(Non-Busy)

293

887

404

757

1125

813

642

610

Fig. A.7: Average Round Trip Times for different regions.

A.3.4

Jitter

Jitter is introduced on a connection when the delay is not constant over a series of packets belonging to the same connection (be it a real connection such as a TCP connection or a connection-less flow such as UDP datagrams). This behaviour could result from for example a fluctuating load on a router. The measurements were concentrated in two-minute timespans on endto-end connections, since these are typical voice session profiles. During these 120 seconds, a number of packets (suitably sized) corresponding to voice codec output was sent and received, and the delay for each packet was calculated. Ping was modified, to allow setting the interpacket time with sufficient precision for the test purposes. Two scenario’s were considered: for the 8kb/s emulation [17], [18] a sequence of 140-byte ECHO REQUEST packets was sent with 100ms intervals. Taking into account that the TCP and IP header consume 40 bytes

A-10

Publicatie A

160 amsterdam 140

RTT(ms)

120 100 80 60 40 20

955

902

849

796

743

690

637

584

531

478

425

372

319

266

213

160

107

1

54

0

Fig. A.8: RTTs for a 2-minute burst of packets, emulating an 8Kbit/s connection.

of the packet size, this gives indeed an emulated datastream of 8kb/s. This was done during approximately 2 minutes - the average duration of a phonecall - resulting in 1200 packets being sent. A typical result is depicted in Figure A.8. For the 64kb/s emulation [19] a packet was sent every 50 ms, containing 440 bytes in total, resulting in 2400 packets over a period of 2 minutes. Not all hosts responded in a satisfying way however. In fact, the packet loss on certain links was too large (often over 50%) to provide useful data. A possible explanation is the fact that the amount and the frequency of the ICMP packets sent to the hosts could not be processed in time by the target hosts kernel, thus resulting in a temporary denial of service (DoS) attack. These hosts were omitted from further tests. 8kb/s min max avg stdev 64kb/s min max avg stdev

Amsterdam 17.453 145.033 56.963814 20.710723 Amsterdam 24.647 394.2 65.67948 30.71237

New York 358.101 1010.306 496.5306 64.42834 New York 698.87 1731.823 1022.72 101.046

Zurich 82.413 317.666 128.0041 17.62624 Zurich 97.239 829.365 153.0766 37.39813

Tokyo 446.866 2391.383 756.2973 88.29878 Tokyo 489.244 2235.049 821.5225 302.0584

Moscow 658.983 1324.691 815.7827 88.29878 Moscow 653.891 1675.713 911.1496 171.1792

TABEL A.1: Minimum, maximum, average RTTs and standard deviation for simulated 8kb/s and 64kb/s connections.

Table A.1 shows typical values obtained for simulated 8kb/s and 64kb/s

A-11


connections to 5 selected hosts. The results for the 64kb/s emulation are far worse than the 8kb/s results. There are two obvious explanations: the frequency at which packets are sent in the former scenario is twice as high as in the latter, and the packet size is 3 times bigger. These two factors cause longer transmission delays and higher node load. A last figure for jitter (Figure A.9) shows the evolution of jitter during the day. The only way of checking jitter on a somewhat longer basis (without resulting in a DoS attack on the target machine) was to perform some experiments at discrete moments, spread over a 24-hour period. The results for New York are presented. The graph shows (per hour) the average RTT over several 2-minute simulated 8kb/s connections, as well as the average standard deviation on the RTT. The evolution of the standard deviation is strongly linked to the evolution of the average RTT. It is also clear that a busy hour pattern is present in both RTT and standard deviation. Of interest here (and refering to the section on Packet Loss), is the fact that the busy hour to New York is now situated between 17h and 23h – in other words, not during the Belgian working hours, but during the East Coast working hours. The explanation for this lies in the fact that the measurements were performed shortly after the new backbone and international uplinks of BelNet were installed. These links are apparently well dimensioned, since the bottleneck on this connection (and on other connections using the same link) is now the local ISP network on the destination side of the backbone.

1600

Stdev Avg

1400

RTT(ms)

1200 1000 800 600 400 200

23

21

19

17

15

13

11

9

7

5

3

1

0 hours

Fig. A.9: Average Round Trip Times and StDev vs. time of day.

A-12

A.4

Publicatie A

Conclusions

To conclude, some conclusions and typical parameter values are repeated, together with a brief discussion of the impact these values have on VoIP. Hopcount The average hopcount is 18, with the number of hops equally devided between local access/ISP, backbone and remote access/ISP networks. Although dynamic routing protocols are used, networks display a static behaviour. There seems to be no obvious relation between the hopcount and delay and packet loss ratios. Packet Loss Ratio The two-way packet loss averages about 20% and displays a clear busy hour pattern. On average, there is a 50% increase in packet loss during busy hours. Most codecs can cope with a 10% packet loss, so connections within Europe or to North America are feasible within busy hours. During the non-busy hour, more destinations fall within acceptable limits. Delay Round Trip Time values are large, 400ms for Europe and North America and up to 680ms for the world average. Most users seem to find 300ms to 400ms Round Trip Time acceptable but categorize the connection as half-duplex. An 800ms RTT is considered to be the upper limit for an interactive conversation, making destinations other than North America and Europe less attractive for conferencing. Delay Jitter Delay jitter is one of the main obstacles for the deployment of VoIP over the Internet. A delay variance of 75ms to 300ms is considered to result in rather poor quality. Only connections to NorthAmerica and Europe, with a delay variance of 20ms to 100ms, are below this limit.

A.5

Acknowledgements

This work has been supported by the Flemish Government through the IWT/LIMSON project.

Referenties [1] T.J. Kostas, M.S. Borella, I. Sidhu, G.M. Schuster, J. Grabiec, J. Mahler, “Real-Time Voice over Packet-Switched Networks”, IEEE Network, pp. 18-27, Jan./Feb. 1998.

A-13


[2] S.R. Ahuja, K.G. Murti, “Packet Telephony”, Bell Labs Technical Journal, pp. 5-14, Spring 1997. [3] A. Cray, “Voice over IP, Hear’s how”, Data Communications, pp. 44-58, Apr. 1998. [4] R. Gareiss, “Voice over IP Services: The Sound Decision”, Data Communications, pp. 75-84, Mar, 1988. [5] K. Van Der Wal, M. Mandjes, H. Bastiaansen, “Delay Performance Analysis of the New Internet Services with Guaranteed QoS”, Proceedings of the IEEE, Vol. 85, No. 12, pp. 1947-1957, Dec. 1997. [6] T. Lewis, “VoIP; Killer App for the Internet”, IEEE Internet Computing, pp. 110-112, Nov.-Dec. 1997. [7] Hyperlink “BelNet: http://www.belnet.be/

The

Belgian

Research

Network”,

[8] J. Postel, “Transmission Control Protocol”, RFC 793, Sep. 1981. [9] J. Postel, “Internet Control Message Protocol”, RFC 792, Sep. 1981. [10] J. Postel, “User Datagram Protocol”, RFC 768, Aug. 1980. [11] J. Postel, “Internet Protocol”, RFC 791, Sep. 1981. [12] D. Mills, “Network Time Protocol (v3)”, RFC 1305, Apr. 1992. [13] W.R. Stevens, “Unix Network Programming Volume 1”, Prentice Hall, 1998. [14] W.R. Stevens, “TCP Illustrated Volume 1”, Addison-Wesley, 1994. [15] K. Claffy, G. Polyzos and H.-W. Braun, “Measurement Considerations for Assessing Unidirectional Latencies”, Internetworking: Research and Experimence, vol. 4, no. 3, Sept. 1993, pp. 121-32. [16] V. Paxson, “End-to-End Routing Behavior in the Internet”, IEEE/ACM Trans. Networking, vol. 5, no. 5, Oct. 1997, pp. 601-15 [17] ITU Rec. G.729, “Coding of Speech at 8 kbit/s using ConjugateStructure Algebraic-Excited Linear-Prediction (CS-ACELP)”, Mar. 1996. [18] ITU Rec. G.729 Annex A, “Reduced Complexity 8 kbit/s CS-ACELP Speech Codec”, Nov. 1996. [19] ITU Rec. G.711, “Pulse Code Modulation (PCM) of Voice Frequencies”, 1988.

A-14

Publicatie A

Data Transcoding in Multicast Sessions in Active Networks Bart Duysburgh, Thijs Lambrecht, Bart Dhoedt, Piet Demeester. 2nd International Working Conference on Active Networking (IWAN2000), October, 2000, Tokyo, Japan. Abstract — In this paper a multicast application is presented, based on active networking techniques, in which processing of the multicasted data is done in intermediate network nodes, according to requests or demands done by users joining the multicast session. The problem of transcoding in multicast sessions is divided into two subproblems. First some issues about the application of active networking techniques are briefly discussed. Then, the problem concerning the optimisation of the location of transcoding nodes in the multicast tree will be the main subject of this paper. The exact solution and a number of heuristics are discussed and simulations of the solutions will illustrate the advantages of the application of transcoding in multicast sessions.

B.1

Introduction

The revolutionary technique of active networking [1–4] brings a whole range of new possibilities to the field of packet based networking. Present networks, in which the only functionality is based on storing and forwarding of packets in the nodes, will be replaced with an active network, enabling extra functionality in the network. In active nodes, the traditional concept of Store-and-Forward will be replaced by the new concept of Store-Computeand-Forward, enabling some extra processing to be done on the packets and their content, before they are forwarded. In this new concept, packets will not only contain data, but will also be able to transport pieces of code that can be executed while passing through an active node. In this way, active packets containing active code will be able to travel through the network, executing the code in the active nodes. The code can be carried out-band,

B-2

Publicatie B

64kbps 64kbps 64kbps

64kbps

user on ISDN-line requests 64kbps

40kbps 40kbps

40kbps

Audio Multicast Server user on 56k modem requests 40kbps 13kbps

transcoding nodes 64 > 40 40 > 13

user on 33k modem requests 13kbps

Fig. B.1: Transcoding in an audio multicast session

in packets exclusively transporting active code, or in-band together with an amount of data in one packet. Furthermore, it is possible to load extra code into an active node, providing extra functionality in the network in a dynamic way. These new techniques and possibilities of performing extra processing on datastreams passing through active nodes, injecting code in the network and configuring the network dynamically by loading extra functionality into the nodes, give rise to extensions of existing applications and new applications finally becoming feasible. Whereas present applications in networks are exclusively based on functionality provided in the end-points of communication and the network is only serving for the forwarding of packets, it is possible with active networks to base the application on functionality provided both in the network and in the end-points. A category of applications that will surely benefit from the new abilities provided by active networks are multicast applications. In this paper a multicast application is presented, based on active networking techniques, in which processing of the multicasted data is done in intermediate nodes, according to requests or demands done by users joining the multicast session. In traditional multicast applications, all users receive the same version of the data when joined to the multicast session. This implicates that all users receive the data in the same encoding and at the same rate, irrespective of the capabilities of the terminals or machines used by the users. The users have no choice about how and in what form they receive the data. It would however be a welcome extension to provide the users with a number of versions of the data with different bitrates to choose from. In this way, a certain customisation of the data streams is possible and a user can choose an appropriate data rate, according to the actual capabilities of his access or up-link to the network. For instance, an audio stream can be multicasted using a number

Data Transcoding in Multicast Sessions in Active Networks

B-3

of codecs, resulting in a number of available bitrates. Users can for example choose from the 64kbit/s A-law codec [5], being the data at full rate, the 40kbit/s ADPCM codec [6] or the 13kbit/s GSM-FR codec [7]. Then a user connected via an ISDN line will probably opt for the 64 kbit/s codec, a user connected via a 56K6 voice modem may choose the 40 kbit/s codec, whereas the user on the 33K modem will have to go for the 13kbit/s codec. Providing this kind of service in present networks is only possible by setting up a multicast session for each of the different versions of the data. A user then has to join the appropriate session to receive the desired version. On the contrary, in active networks it is possible to provide this service using only one multicast session and using transcoding of the data in the active nodes. One multicast session is set up and the full-rate version of the data is injected in the multicast tree. Then, in intermediate nodes of the tree a conversion of the incoming data stream to a lower bitrate may be done, according to the demands of the users serviced downstream by this node. The active solution for the example described above will need the set up of a multicast session servicing the three users. In the multicast tree the full-rate data (64kbit/s) will be injected and in total two conversions of the data to a lower bitrate (40 and 13kbit/s) will need to be done in certain intermediate nodes of the tree. The resulting data streams and necessary transcoding nodes in the tree of a possible solution are shown in Figure B.1. The problem of data transcoding in multicast sessions can be divided into two sub-problems. A first problem concerns the application of active networking techniques to realise the transcoding of data in intermediate active nodes. The second problem concerns the optimisation of the location of these transcoding nodes in the multicast tree. The first problem will be briefly discussed in paragraph 2, pinpointing the most important problems and points of attention. A look will be taken at some architectural issues, concerning the necessary active networking capabilities and the possibilities for data transcoding. The second problem will then be discussed in detail in the remaining paragraphs 3 and 4 of this paper. In paragraph 2, in addition to the active networking issues, also the advantages of this concept in contrast with traditional solutions will be shown and a number of relevant applications based on the concept will be suggested.

B.2 B.2.1

Transcoding in Multicast Sessions Transcoding in Active Networks

To be able to do processing in intermediate nodes in the network, the existence of active nodes in the network is needed. Apart from these active

B-4

Publicatie B

I BPBP I BPBP I BPBP I

I

I

I

I

I

I

MPEG video source dropping of B- and P-frames

dropping of I-frames B

I

P

Fig. B.2: Frame dropping in MPEG video stream

nodes, the transcoding of data will only be possible in the source node of the multicast tree. With this assumption it is not necessary that the whole network becomes active all at once. It is even possible to introduce an application based on transcoding in a network with no active nodes present yet. In this case there will only be transcoding in the source and for each version of the data a multicast tree will be used. Then, when a gradual introduction of active capabilities in the network takes place, transcoding can be done in the active nodes and the source will gradually be relieved from transcoding. Before any transcoding can take place in an active node, the necessary code will have to be in place. This code can be put in place during configuration and kept in the node forever. It can however be more favourable and efficient to load the necessary code dynamically from a codebase when the functionality is needed and to discard the code when it has expired, thus freeing the node resources for other applications. This technique implies the use of the active node concept, in which the functionality to process the data is located in the active nodes and active packets only carry identifiers or references to the functions to be executed on the content of these packets. Processing of data passing through an active node requires a certain amount of resources from the node. The resources from the active node will have to be shared by the normal routing and forwarding activities at one side and the active processes on the other side. It is obvious that enough resources will have to be reserved for the normal activities of the node, in order to enable the best-effort forwarding service to remain. By consequence, only resources not needed by the routing and forwarding process are available for active processes. The number of active processes able to run without disturbing the normal functionality will thus be limited and it will be necessary to study the available resources and processing power. In this way, an estimation of the available resources in an average node can be made and a prediction can be done of the number of active processes being able to run in parallel. With the limitation of the processing power in mind, the question rises whe-


B-5

ther transcoding in active nodes is really feasible. Coding and decoding of a voice or video stream requires a considerable amount of processing power and especially when working in real-time, the timing constraints become very rigid, making it clear that for the moment only conversions of data with rather low demands on processing power are feasible. Conversions between two audio or video codecs, requiring the decoding of the incoming signal to the original sampled data and the coding of this data into the new codec, are not yet feasible. Some other conversion on the contrary, while not requiring that much processing power, can already be very useful. First there are some embedded codecs, such as the G.727 embedded ADPCM voice codec [8]. This codec generates a number of bits per sample, allowing to drop some of the least significant bits from each sample, resulting in a lower bitrate stream of lower quality. The conversion only involves dropping of some bits and does not need any heavy processing. Similar to this, layered media compression [9] gives a cumulative set of layers, where info is combined across layers to produce progressive refinement. Again, by dropping some of the information layers, the bitrate is reduced together with the quality, while preserving the basic information or data. The same is possible for the MPEG video codec [10] where the information is sent in I-, P- and B-frames. In a first stage the P- and B-frames can be dropped and later even some of the I-frames can be ignored to further reduce the bitrate [11]. This is illustrated in Figure B.2. These conversions, while offering a very simple bitrate reduction mechanism, need some specific coding and decoding schemes to enable this possibility. This is not the case when using simple frame dropping in a JPEG video stream. Every frame is compressed using JPEG and reducing the frame rate is only achieved by dropping certain frames entirely.

B.2.2

Advantages

Now, a number of advantages brought by transcoding in multicast sessions, in comparison with traditional solutions, will be discussed. First of all, this application offers extra functionality to the users of multicast sessions, enabling them to do a customisation of the data they want to receive, according to the capabilities of their system and access network. It provides more flexibility in the application towards the users, giving them the ability to choose how they want to receive the data and in what format. A second advantage is particularly interesting because it concerns some of the weak spots of the present Internet. Recently it has become obvious that in the current best-effort Internet some of the main bottlenecks are situated in the user’s access network at one side and at the application providing servers on the other side. It is clear that the capabilities of the user’s up-link to

B-6

Publicatie B

the Internet limit the maximal speed or bandwidth available for the applications. So the local access of the user restricts the possibilities and thus the capability to have for example a satisfactory real-time communication will depend on the available bandwidth of the up-link. Another impediment for a fast working service in the present network is the fact that popular web- or application servers have to handle a large amount of connections, often resulting in servers being overloaded. This overload leads to connections being rather slow and other incoming connections being denied service. Transcoding in multicast sessions can be a cure for both of these problems. Whereas the currently available solution would be to set up different multicast trees for each of the data versions, in the active solution only one multicast tree needs to be set up, in which only one version of the data has to be injected. In this way a reduction of the server load is achieved. Furthermore, using network-based transcoding the user is not restricted to one version of the data anymore. By enabling to choose the appropriate data format, the influence of the access network is reduced and the user can opt for a customised version that suits best the abilities of his local access. Another advantage of the transcoding concept is an optimisation of the overall network load. By transmitting the data over a multicast tree, already a reduction of network load is achieved and the use of transcoding gives in turn an additional reduction of the required bandwidth. To conclude, the transcoding concept brings extra flexibility in the application and offers optimisation of the server load, the load on the access network and the general bandwidth usage in the network.

B.2.3

Application

As mentioned above, a number of audio and video codecs are very well suited to provide some easy transcoding abilities, making audio and video streaming some of the most obvious applications to benefit from the concept of transcoding in multicast sessions. Furthermore, these applications are very attractive for the general public, providing a very interesting and appealing illustration of the capabilities of active networks. Other applications can for example be found in services distributing a large amount of data in the network, on a regular basis. When the multicasted data has rather a heterogeneous character (i.e. it contains different types of information), not every user will be interested in all the data at once. Consequently, in intermediate nodes, the data streams can be stripped of all redundant information (for the downstream users), resulting in a lower bandwidth being required. An example could be a real-time stock quotes distribution service, sending every minute the new values of all quotes in the tree. Then, based on the users requirements or preferences, quotes are passed through or are


B-7

dropped. In this way, users receive only the data they are interested in and also the rate at which new data are passed through can be adjusted, for example delivering the data every minute to one user and every 15 minutes to another user. A news distribution service can be functioning in the same way.

B.3

Transcoding Tree Optimisation

When using transcoding in a multicast session, some of the active nodes in the network have to do the necessary data conversions. These nodes will be called transcoding nodes. There have to be enough nodes of this type, in order to make sure that all conversions are done and that every user receives the requested version of the data. The location of the transcoding nodes in the multicast tree is now subject to some optimisation, according to for example the total bandwidth usage in the tree and the number of conversions in the nodes. First a general description of the optimisation problem is given and then a number of solutions are described: the exact solution and two heuristics.

B.3.1

Optimisation Problem

First some general assumptions, concerning the optimising problem, are discussed. The network contains a number of nodes, interconnected by a number of edges. Initially it is assumed that all the nodes are active, so every node is capable of performing transcoding tasks. Every link is characterised by its bandwidth capacity and by a cost, related to the use of the available bandwidth. The nodes in turn are characterised by a capacity, related to the available resources and the number of data conversions that can be done. Consequently, a non-active node, not able to do any transcoding, will have a zero capacity. Additionally a cost function for the node is related to the use of the available processing power for transcoding. In this network, a multicast session needs to be set up from a certain source node to a number of destination nodes. The data can be delivered in a limited number of versions or types and for every destination, a specification of the requested data type is given. Every version of the data is characterised by its bitrate or bandwidth and a conversion between two versions is characterised by the amount of necessary processing power and resources. A data transcoding is only possible between two types, when it concerns a conversion from a higher bitrate to an equal or a lower bitrate. A number of destinations asking for the same version or type of the data are grouped in a class. The classes are ordered, according to the required bandwidth for that data

B-8

Publicatie B

64

64kbps

64 40

Source 64

64

64 64>13

(1) Steiner minimal tree BW use = 192kbps 64>40 64>13 64

Source 64

64

64

13 13kbps

64 40

Source 64 40kbps

(2) Optimised bandwidth use BW use = 181kbps

13 13kbps

64>40

64

64kbps

40

13

40kbps

64>40

(3) Optimised distribution of transcoding nodes BW use = 181kbps

64

64kbps

40 40 13

40>13

40kbps

13 13kbps

Fig. B.3: Transcoding Tree optimising

type. Class 1 destinations request the data type with the highest amount of bandwidth required. Consequently, transcodings are only possible from a lower class to a higher one (e.g. from class 1 to class 3). Now, given every destination’s class, a multicast tree needs to be set up from the source to the destinations, containing a number of transcoding nodes, taking care of the conversions of the data into the requested versions. The total cost of the tree will be determined by a cost function, depending on the costs of links and (transcoding) nodes in the tree. This cost can be optimised by adjusting the location of the transcoding nodes, reducing the number of transcoding nodes and the total bandwidth usage. Returning to the example given above, the optimisation process can be illustrated as follows (see Figure B.3). In a first stage, just the Steiner minimal tree is used to connect the source and the three destinations. While only using 3 links, the total bandwidth used amounts 192kbps (3*64kbps). In the second case the total bandwidth is reduced to 181kbps by using another multicast tree, containing one more link. However, with this tree the two transcodings will have to be done in the same node. By restricting the number of transcodings in a node this can be avoided and a better distribution of the transcoding nodes over the multicast tree can be achieved. So, in the third case, again a bandwidth of 181kbps is consumed but the transcodings are done in separate nodes. In the following paragraphs the solution of this problem will be described. First the exact solution based on Integer Linear Programming (ILP) is discussed. Because the problem is closely related to the Steiner Tree problem, it is obvious that this problem is also NP complete and the exact solution will not be useful when dealing with large networks. Therefore a number of solutions have been derived, based on heuristics, allowing the calculation of the solution in a faster way, but possibly resulting in a non-optimal solution. Further


B-9

on, the implementations of these solutions, both exact and heuristic, will be used to perform a number of simulations, calculating the optimal multicast tree and the transcoding nodes.

B.3.2

Exact Solution and Heuristics

First of all, a look is taken at the problem in the situation where no active nodes are present in the network. A first solution can then be the delivery of the different data types using point-to-point connections. This results in a large number of users connected to the server and in an inefficient use of bandwidth in the network. Because each type of data is requested by a number of different users at the same time, a better solution is achieved by using a multicast tree for each type to deliver the data. This way, server load and bandwidth usage are partly optimised. This second non-active solution will be used to compare with the active solutions, illustrating the possible optimisation when using transcoding in multicast sessions. To find the exact solution for the problem described above, it was formulated as an Integer Linear Programming (ILP) problem. The details of this ILP mathematical formulation of the problem will not be discussed here. It is based on an ILP formulation of the Steiner Tree problem and a number of extra constraints and variables have been added. The objective function that is to be minimised, is a cost function based on the contributions of the links and nodes of the tree. Because of the NP complete character of the problem, as already mentioned before, a number of heuristics were determined. Now two heuristics for the problem are presented: a first called the Skinned Steiner Tree Heuristic and a second called the Branch Attach Heuristic. Both the heursitics are based on the calculation of one or more Steiner trees [12]. For the calculation of these trees, in turn a heuristic [13] is used, because of the NP-complete character of the Steiner tree problem. B.3.2.1

Skinned Steiner Tree Heuristic

In this heuristic, it is attempted to calculate the Steiner tree containing the source and all destinations (of all classes), with a reserved bandwidth equalling the highest bandwidth requested. This way, it is assured that every edge in the tree has enough capacity to allow flows of any type. Due to this bandwidth demand, requiring the reservation of the highest bandwidth requested, it is possible that some of the destination nodes are not yet attached to the tree. These nodes are then attached as well. First the edges with less capacity than the bandwidth needed for that specific destination are discarded. Then the cost of the edges already in the tree are set to zero and the shortest path from this node to the source is cal-

B-10

Publicatie B

1-1

?

?

?

1

?

1

2

a

?

?

1 1-1

1 2

b

2

1 1-1

1

1-1 1-2

1-1 1-2

1 2 2-2

c

1

2

1 1-1

1 2 2-2

d

2

1 1-1

2 2-2

e

Fig. B.4: Skinning the bandwidth

culated. Edges belonging to this shortest path are added to the tree. At this stage, a tree connecting all of the destination nodes and the source is found, but no bandwidth optimisation has been done. This can be achieved by ”skinning”the tree in order to reserve only the minimal amount of bandwidth needed. This is done by walking through the tree from the leaves to the source. In the leaves the required bandwidth on the incoming edges is known. When the bandwidth on the edges to the leaves is reserved, the algorithm works his way up the tree, determining the bandwidth needed on the other edges and the transcoding that needs to be done in the nodes. Figure B.4 illustrates the skinning step. In Figure B.4a a simple tree from a source to two destination nodes is shown. Node 1 is a class 1 destination, requesting type 1 of the data, and node 2 is a class 2 destination. Initially, on all of the edges enough bandwidth is reserved to accommodate the required data types, so the edges can certainly handle the requested bandwidth. The algorithm starts walking through the tree until it encounters a leaf. In the leaf, no transcoding needs to be done, only the requested data version has to be received. So the amount of bandwidth to reserve on the incoming edge is known. So, in Figure B.4b, in the marked node a data stream of type 1 is received (transcoding from type 1 to 1) and the incoming edge needs enough bandwidth to carry the type 1 flow. In Figure B.4c the same is done in the next leaf: a type 2 data stream needs to be received (transcoding from type 2 to 2) and enough bandwidth is reserved to carry a type 2 flow on the incoming edge. Since all outgoing edges of the node marked in Figure B.4d have been handled, the transcodings needed in this node can be determined, as well as the bandwidth needed on the incoming edge. It is clear that enough bandwidth has to be reserved for a type 1 flow on the incoming edge (the largest bandwidth flow of both). Therefore transcodings from type 1 to 1 and from type 1 to 2 are needed in that node. In Figure B.4e finally the source is reached. In all of the edges that are part of the tree enough bandwidth has been reserved and the required transcodings in


B-11

the nodes have been determined. B.3.2.2

Branch Attach Heuristic

This heuristic is based on the calculation of a Steiner Tree for each class of destinations. In the algorithm, edges used in trees with higher bandwidth requirements are favoured to be used in the lower bandwidth trees as well. The resulting trees for every class are merged to one final multicast tree. First the Steiner Tree is calculated for the destinations of the lowest class (highest bandwidth requirement). The edges of this tree are added to the final data transcoding tree and in this tree bandwidth is reserved for the current type of data. Then the cost of these edges is set to zero in the original network, making it favourable to reuse these edges in the trees for the other types. When not all destination classes have been added to the final tree, the following procedure is followed. The Steiner Tree is calculated for the destination nodes of the next class in order (lower bitrate). The edges of this Steiner Tree are added to the final tree and enough bandwidth is reserved. If the new found edge is already part of the final tree, a transcoding may be necessary in the target node of the edge. The needed transcodings are determined, based on the incoming and outgoing flow. In a last step, the cost of the new edges is set to zero in the network and this procedure is repeated for each destination class in turn, in decreasing order of bandwidth requirements. Consequently this algorithm calculates not one Steiner Tree, as in the first heuristic, but calculates different smaller ones that are combined to one tree.

B.4

Simulations and Results

With the non-active solution, the exact active solution and the two heuristics, a number of simulations have been performed, in order to illustrate the advantages brought by transcoding and to test the performance of the different solutions. A network containing 36 nodes and 57 bi-directional links is used. The edge cost per unit of bandwidth is set to 1. The node cost (for transcoding) is also set to 1. The capacity of the edges and the nodes is not restricted, enabling to carry all necessary traffic on the edges and to do all necessary transcodings in the nodes. This gives a rather simplified model, which in a next stage will be refined, allowing to account for the restricted transcoding resources and the various real costs of the codecs and their transcoding. The multicast data can be delivered in a number of different versions. Every data class requires a specific number of bandwidth units. Two series of simulations have been performed. In a first series the amount

B-12

Publicatie B

350 Not Active 300

Active

Cost

250 200 150 100 50 0 1

2

3

4 5 6 7 Number of classes

8

9

10

Fig. B.5: Tree cost (fixed number of destinations)

of destination classes in the tree is gradually increased, keeping the number of destinations constant. In a second series the amount of classes was kept constant while gradually increasing the amount of destinations in the tree. In the first series, random sets containing 1 source node and 10 destination nodes are used. In these sets the amount of classes is gradually increased from 1 to 10, spread over the 10 destinations. The 10 classes require the following bandwidth: class 1 needs 10 units, class 2 needs 9 units,..., and finally class 10 needs 1 unit. For every situation, i.e. a certain number of classes spread over the 10 destinations, several random sets are generated, enabling to do an averaging of the results. In the second series, the number of classes spread over the destinations is kept constant to 5 and only classes 1 to 5 are available. Here, class 1 requires 5 units of bandwidth, class 2 needs 4 units,..., and finally class 5 needs 1 unit. Now, the sets contain 1 source node and an increasing number of destination nodes. Again an averaging of the results is done over a number of random sets for each situation. The simulation results are discussed below. For the first series, in Figure B.5 the tree-cost for the active and non-active case is shown. Since the edge-cost is set to 1 per unit of bandwidth, the tree-cost is also the total amount of bandwidth needed in the tree. In the active situation, the cost is less than 60% of the non-active cost, when 4 or more classes are used. Although less bandwidth is used, more transcodings are required due to the increasing number of classes. As is shown in Figure B.6, in the non-active case N-1 transcodings are needed, where N is the number of classes. These N-1 transcodings are all done by the source-node. In the active case more transcodings have to be done, but they are distributed in the network and only a few have to be done in the source node.


B-13

10 9

Not Active

8

Active

Cost

7 6 5 4 3 2 1 0 1

2

3

4

5 6 7 Number of classes

8

9

10

Fig. B.6: Node cost (fixed number of destinations)

60

Not Active Active Min

50

Flow

40 30 20 10 0 1

2

3

4


8

9

10

Fig. B.7: Amount of flow leaving source

Furthermore, the bandwidth used by the total data flow leaving the source node is shown in Figure B.7. For the active case the average flow coming from the source is about 17 units. In the non-active case the flow amounts at least the values set out by the Min-curve, i.e. the sum of the bandwidths needed by the available classes. From these results, coming from simulations with the exact solution, it is already clear that using transcoding in a multicast session gives an optimisation of the total bandwidth used and the load on the server or source node. Some calculations of the exact solution took more than 2 hours to complete on a PentiumIII 450MHz. Therefore simulations were also performed using the two heuristics described above. In Figure B.8 the results of the heuris-

B-14

Publicatie B

4.0 3.5

% difference

3.0 2.5 2.0 1.5 1.0 Strip

0.5

Branch 0.0 1

2

3

4


8

9

10

Fig. B.8: Difference in tree cost between heuristics and exact solution

250 Not Active

Cost

200

Active

150 100 50 0 5

8

11

14 17 20 23 26 Number of destinations

29

Fig. B.9: Tree cost (fixed number of classes)

32

35


B-15

25 Not Active

Cost

20

Active

15 10 5 0 5

8

11

14

17

20

23

26

29

32

35

Number of destinations

Fig. B.10: Node cost (fixed number of destinations)

tics and the exact solution are compared and the difference in the total tree cost between them is shown. The heuristics give a good approximation of the exact tree: the cost of the tree calculated by the heuristics differs only up to 3.5% from the optimal solution, while calculation times remain below 300 milliseconds. Now, for the second series, again the tree cost and node cost are shown. It is seen in Figure B.9 that the bandwidth needed in the active case is again about 60% of the bandwidth needed in the non-active case. The node cost and consequently the number of transcoding operations increases linearly with the increasing number of destinations, as shown in Figure B.10.

B.5

Conclusions and Further Work

In this paper, the concept of data transcoding in multicast sessions was described. Some issues on the use of active networks were briefly discussed. Then, a number of the main advantages were presented, together with some new applications benefiting from the new concept. A more detailed discussion was given on the multicast tree optimisation problem, for which an exact solution and two heuristic solutions were proposed. To conclude, the results from a number of simulations were presented, illustrating the advantages mentioned before. In future work, a more refined model will be used, enabling to look at realistic situations where nodes have restricted resources for transcoding and with realistic costs for transcoding and bandwidth use. Then, the implementation of this concept will be tackled. The transcoding problem will be handled, together with the problem of setting

B-16

Publicatie B

up a multicast tree, able to do these transcodings. An implementation will then give the opportunity to further explore some major performance and optimisation issues.

Referenties [1] Tennenhouse D. et al., A survey of active network research, IEEE Commun. Mag., vol. 35,Jan. 1997, pp.80-86 [2] Smith, J.M., Calvert, K.L., Murphy, S.L., Orman , H.K., Peterson, L.L., Activating Networks: A Progress Report, IEEE Computer Mag., April 1999, pp.32-41 [3] Calvert, K.L., Bhattacharjee, S., Zegura, E., Sterbenz, J., Directions in Active Networks, IEEE Communications Mag., vol. 36, Oct. 1998, pp.72-78 [4] Psounis, K., Active Networks: Applications, Safety, and Architectures, IEEE Communications http://www.comsoc.org/pubs/surveys, First Quarter 1999

Security, Surveys,

[5] ITU-T, Recommendation G.711: Pulse Code Modulation (PCM) of Voice Frequencies, 1972 [6] ITU-T, Recommendation G.726: 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM), 1990 [7] ETSI ETS 300 580-1: Digital Cellular Telecommunications system (Phase 2); Full Rate Speech; Part1: Processing Functions (GSM 06.01), 1997 [8] CCITT, Recommendation G.727: 5-, 4-, 3- and 2-bits sample embedded adaptive differential pulse code modulation (ADPCM),1990 [9] McCanne, S.R., Scalable Compression and Transmission of Internet Multicast Video, PhD thesis, 1996 [10] Mitchell, J.L, Pennebaker, W.B., Fogg, C.E. and LeGall, D.J., MPEG Video Compression Standard, in Digital Multimedia Standards Series, Chapman & Hall, New York, 1997 [11] Busse, I., Covaci, S., Leichsenring, A., Autonomy and Decentralization in Active Networks: A CaseStudy for Mobile Agents, IWAN99, Jun./Jul.1999, pp.165-179


B-17

[12] Wei, L., Estrin, D., A Comparison of Multicast Trees and Algorithms, INFOCOM, 1994 [13] Kou, L., Markowsky, G., Berman, L., A fast algorithm for Steiner trees, Acta Informatica, 1981

B-18

Publicatie B

On the influence of best-effort network conditions on the perceived speech quality of VoIP connections Bart Duysburgh, Stefaan Vanhastel, Bart De Vreese, Cristinel Petrisor, Piet Demeester. 10th International Conference on Computers Communications and Networks (ICCCN2001), October, 2001, Scottsdale, AZ, USA. Abstract — When voice traffic is transported over a packet-based network, a number of conditions different from the ones in the traditional circuit-switched network will have an influence on the quality of the speech signal as perceived by the users. In particular, distortion of the voice signal due to delay jitter and partial loss of signal caused by packet loss will have an important impact. Therefore, in order to determine the influence of delay jitter and packet loss on the perceived quality, an objective speech quality assessment system, called DSLA, is used to predict the Mean Opinion Score for voice connections, which are set up on a test-bed, subject to artificially introduced network conditions. A decomposition of the voice degradation is made into different parts, due to sampling, digitization, encoding/decoding, packet loss and delay jitter, respectively. It is found that delay jitter has a devastating influence on the perceived quality, when no dejittering buffer is used. However, when the received signal is dejittered, the degradation due to jitter is similar to the one caused by packet loss.

C.1

T

Introduction

HE conditions in the Public Switched Telephone Network (PSTN) are totally different from the ones in a packet-based network. The circuitswitched PSTN network provides a seperate closed loop for each connection, with stable delay and noise level conditions, whereas in a packet-based network links are shared between different connections, resulting in interaction

C-2

Publicatie C

between various traffic types. Hence, voice connections over best-effort IP networks are subject to unstable conditions, including unpredictable delays, delay jitter and packet loss. This problem is tackled by the introduction of Quality of Service (QoS) in the network, based on techniques such as Integrated Services [1] and Differentiated Services [2]. However, for the time being most people are stuck with the best-effort network service and beside the different QoS classes provided for, the best-effort service will always be available and used. Consequently, it is useful to have an idea of the attainable voice quality under different conditions on a best-effort network. Therefore, a number of experiments have been conducted to determine the influence of various network conditions on the voice quality as perceived by users. In the experiments, the influence of packet loss, delay and delay jitter were observed, as well as the effect of sampling, digitization, coding/decoding and packetization. Similar experiments are described in [3–6]. The results show the gradual degradation in quality with increasing amounts of packet loss and the extremely harmful influence of delay jitter on a signal that is not dejittered. They also show a similar degradation for packet loss and delay jitter on a dejittered signal. The remainder of the paper is organized as follows. In Section 2 and 3, the setup for the experiments and the measurement procedures are described. In Section 4, the results of the experiments are presented and in the final sections future work and the conclusions are presented.

C.2

Setup

The setup used for the experiments and measurements is illustrated in Fig. C.1. The setup is based on standard PCs running Linux, which are interconnected by 100BaseT ethernet links to form a test network over which VoIP connections can be set up. This test network is subject to artificially controlled conditions in terms of delay, delay jitter and packet loss, allowing to conduct objective quality measurements of voice transmitted over VoIP connections under various conditions. The different experiments follow the general procedure described below. A reference analogue voice signal is generated by the Digital Speech Level Analyser (DSLA) tool and is captured on the soundcard of a Linux PC. On that PC, the sender node, the signal is sampled at a rate of 8 kHz and the samples are read from the soundcard. These samples are then encoded by means of one of the nine available codecs, the encoded samples are put into UDP packets of a certain length and the packets are sent at a constant rate towards the receiver node. Between the sender and receiver

On the influence of best-effort network conditions on the perceived speech quality of VoIP connections C-3 MOS value

reference signal

DSLA Measurement Tool

degraded signal

Linux PC

Linux PC Linux PC router

sound card

conferencing software

100BaseT ethernet

Impairment Node

sound card

100BaseT ethernet

sender node

conferencing software

receiver node network interface card

adjustable packetloss delay delay jitter

Fig. C.1: Measurement setup

node, another Linux PC is placed, which is configured both as a router and as an impairment generator. This way, it is possible to artificially create certain conditions on the network connection, by introducing certain amounts of packet loss, delay and delay jitter in the impairment node. The packets that have made it through this node are subsequently delivered to the receiver node. There, the samples are extracted from the packets, they are decoded and they are then put in the play-out buffer of the soundcard. The resulting analogue voice signal is captured by the DSLA measurement tool, which then compares the reference signal and the received degraded signal and calculates a prediction for the Mean Opinion Score, by means of the PAMS algorithm. This MOS value gives the opinion of an average public on the perceived quality of the voice signal, on a scale from one (bad quality) to five (excellent quality). This way, it is possible to do repeatable and objective MOS measurements, for a number of different network conditions, allowing to determine the influence of packet loss, delay and delay jitter on the quality perceived by an average public. It has to be noted that the setup is almost entirely software based, which can have an influence on the performance of the experiments. Encoding and decoding will not be as fast as on a hardware based system and memory and buffer access operations will also take longer than for a hardware implementation. However, the PCs are fully dedicated to the experiments and only single one-way connections are used, assuring a satisfactory performance. Moreover, some preliminary results from a limited number of experiments on a hardware based setup show similar results as for the software based

C-4

Publicatie C

TABEL C.1: Overview of available codecs Codec G.711 µ-Law G.711 A-Law G.726-7 ADPCM 5bit G.726-7 ADPCM 4bit G.726-7 ADPCM 3bit G.728 GSM-FR G.729 G.723.1

Bitrate 64 kb/s 64 kb/s 40 kb/s 32 kb/s 24 kb/s 16 kb/s 13 kb/s 8 kb/s 5.3 kb/s

setup. The complete set of results on the hardware based setup will be presented in a future publication. The different components of the setup are described in greater detail below.

C.2.1

VoIP conferencing software

The sender and receiver node are both standard PCs with an AMD K6 550MHz processor, running a Debian Linux 2.2.15 kernel and provided with a Creative Labs Sound Blaster PCI128 soundcard. The soundcard is driven by the es1370 driver, combined with the Linux Open Sound System driver. On both PCs the conferencing software, developed by the authors and written in C, is running. At the sender side, the software reads 8 kHz samples from the soundcard, which are then run through one of the available codecs (listed in Table C.1). The codecs are based on freely usable ANSI-C implementations of the respective ITU-T and ETSI specifications. The encoded data is then packed in a UDP datagram of a certain length (carrying a certain number of milliseconds of speech) and is sent to the receiver at a constant rate. At the receiver side, the data are extracted from the packets, are decoded and the resulting samples are written to the soundcard, which then plays the reconstructed signal. At the sender side, a simple Voice Activity Detection and silence suppression mechanism is used and sequence numbers are included in the datagrams, allowing to detect packet loss and to survive packet reordering. At the receiver, a dejitter buffer is used to reduce the effect of delay jitter, which uses the sequence numbers to determine the play-out times of the speech fragments.

On the influence of best-effort network conditions on the perceived speech quality of VoIP connections C-5

C.2.2

Impairment Node

The impairment node is a standard PC, with an AMD K6 450MHz processor, running a Debian Linux 2.2.14 kernel, configured as a router and extended with the NistNet kernel module release 2.0.5, developed by NIST. The NistNet module [7] allows to introduce a range of network conditions on flows passing through the node. For each flow, the percentage of packet loss, the average delay and the standard deviation on the delay to be experienced by the packets can be specified. This way, the end-to-end characteristics of the voice traffic, otherwise resulting from traversing different nodes and links in the network and described by the total amount of delay, delay jitter and packet loss, can now be emulated on the small-scale test-bed by introducing the same end-to-end characteristics on the traffic.

C.2.3

Digital Speech Level Analyser

In order to determine the subjective quality of voice over IP conversations, as perceived by an average public of listeners, an objective speech quality assessment tool, called DSLA, is used. The operation of this Digital Speech Level Analyser, manufactured by Malden Electronics Ltd., is based on the Perceptual Analysis/Measurement System (PAMS) developed at the British Telecom laboratories [8–10]. This software algorithm evaluates the quality of a speech signal passing through a system under test by comparing the reference and the degraded signal. In the comparison, a psycho-acoustical model is used to take into account the human auditory system and error parameterisation to account for a variety of error classes. Based on the calculated difference, a prediction of the quality is made on the Absolute Category Rating scale [11], resulting in a Mean Opinion Score (MOS). This MOS expresses the opinion of an average public on the perceived quality. The MOS scale is illustrated in Table C.2. The DSLA tool is able to generate a large number of linguistically motivated artificial speech test signals. These signals are composed of a number of phonemically grouped sounds, which are combined in linguistically legal sequences. For both male and female voice, a set of 12 so called P honytalk T M test signals is available, with each of the signals being representative for thousands of related sounds from British English speech. These test signals can be combined to compose a more complex signal to use in the speech quality testing, providing a useful insight into the path performance of real speech.

C-6

Publicatie C

TABEL C.2: ACR or MOS scale MOS 5 4 3 2 1

Opinion Excellent Good Fair Poor Bad

TABEL C.3: Difference in MOS for long and short male and female voice test signals G.711 µ-Law Short (4 sec) Long (9 sec)

C.3

Male 3.63 3.74

Female 3.53 3.60

Measurement Procedures

Before the start of the actual experiments, a number of tests have been done to determine the best quality that can be achieved and measured. First, the quality is measured when the signal from the output port on the DSLA tool is immediately redirected to the input port. In a second test, the test signal is sent over the local telephony network in our office, through a connection over an Ericsson BP180 central. This way it is found that the best quality measured with the DSLA tool is a MOS of 4.1, whereas the quality achieved over a traditional telephony network is a MOS of 3.8. These MOS values are more or less the same as the ones known from literature for optimal POTS quality (toll quality). These optimal values can be used as a reference when comparing the quality of signals subject to various conditions and the optimal quality. Additionally, the influence of the length of the test signal has been determined, as well as the difference in quality when using male or female test signals. The results are shown in Table C.3 for the G.711 µ-Law codec. For both male and female voice, a short test signal of four seconds and a long one of nine seconds was used. From the measurements, a small but negligible difference of about 0.1 MOS can be seen for the male and female signal, as well as the short and long signal. In all of the further experiments, the short test signals of male speech were used. These contain a sequence of three utterances, taken from the P honytalk T M samples and corresponding to the phoneme sequences called ’dusthis’, ’oatlet’ and ’willed’. All MOS values shown in this paper are the result from a large number of


experiments, conducted under the same conditions. In most cases the results from 10 or 20 repeated experiments are averaged out to get a reliable value. In all cases the standard deviation for these series of repeated measurements is about 0.1 MOS.

C.4

Results

In this section, an overview is given of the different experiments, their results and the conclusions drawn from them. First, the optimal quality attainable for the different codecs is determined, as well as the influence of sampling, digitization and encoding/decoding on the voice quality. Then, the influence of packet loss and delay jitter on the voice quality is studied and the relation between these two network conditions is shown.

C.4.1

Influence of sampling and encoding/decoding

In Fig. C.2, the MOS values for different codecs are shown, obtained from measurements on a network without any impairment. All codecs are used with packets carrying 10 ms of speech, except for the G.723.1 and the GSMFR codec, where packets carry 30 ms and 20 ms of speech, respectively. Beside the MOS for the nine codecs, also the results are shown from MOS measurements using the 16 bit Pulse Code Modulation (PCM) samples, taken at a sample rate of 44.1 kHz and 8 kHz, without any encoding and decoding. 5.0 4.0 3.8

4.0

3.7

3.7

3.8

3.7 3.3

3.5 3.2

3.2

GSM-FR

G.729

3.1

MOS

3.0

2.0

1.0

0.0 16bit PCM 44.1kHz

16bit PCM 8kHz

G.711 u_Law

G.711 A_Law

G.726-7 ADPCM 5bit

G.726-7 ADPCM 4bit

G.726-7 ADPCM 3bit

G.728

Fig. C.2: MOS for all codecs of Table C.1

G.723.1 5.3kbps

C-8

Publicatie C

4 G.711 u-Law G.711 A-Law

MOS

3.5

3

2.5

2 0%

2%

4%

6%

8%

10%

packet loss (%)

(a)

4 G.726-7 5bit G.726-7 4bit

MOS

3.5

G.726-7 3bit

3

2.5

2 0%

2%

4%

6%

8%

10%

packet loss (%)

(b)

4 G.728 GSM-FR 3.5

G.729

MOS

G.723.1 5.3 3

2.5

2 0%

2%

4% 6% packet loss (%)

8%

10%

(c)

Fig. C.3: MOS vs. packet loss for all codecs

From these values, the influence of sampling and digitization on the perceived quality of the signal can be seen. Sampling at 44.1 kHz with 16 bit samples results in a next to optimal MOS of 4.0, whereas sampling at 8 kHz gives a MOS of 3.8. This degradation is caused by the filtering effect


4 10ms 30ms

MOS

3.5

50ms

3

2.5

2 0%

2%

4%

6%

8%

10%

packet loss (%)

(a)

4 10ms 30ms

MOS

3.5

50ms

3

2.5

2 0%

2%

4%

6%

8%

10%

packet loss (%)

(b)

4 10ms 30ms

MOS

3.5

50ms

3

2.5

2 0%

2%

4%

6%

8%

10%

packet loss (%)

(c)

Fig. C.4: MOS vs. packet loss for different packet sizes for G.711 µ-Law (C.4(a)), G.726-7 4 bit (C.4(b)) and G.728 (C.4(c))

of sampling, also known as the Nyquist theorem, resulting in all frequencies larger than half the sampling rate being filtered out of the signal. So, sampling at 8 kHz has the same effect as the application of a low-pass filter

C-10

Publicatie C

for the 0-4 kHz range on the signal. Such a filter is also applied in the traditional PSTN, and indeed, as is shown above, the same degradation is seen on a PSTN connection with a MOS of 3.8. Beside this effect, also a loss in quality is seen due to the encoding and decoding step. After all, encoding a signal results in part of the information characterising the signal being discarded. The degradation caused by the G.711 and G.726-7 (5 and 4 bit) waveform codecs is rather small (about 0.1 MOS). However, the decrease in quality for the low bitrate codecs, such as G.726-7 (3 bit), G.728, GSM-FR, G723.1 and G.729, is more important, ranging from 0.3 to 0.7 MOS.

C.4.2

Influence of packet loss

To determine the influence of packet loss on the perceived quality, a number of experiments have been conducted, where amounts of packet loss of 0%, 1%, 2%, 5% and 10% were introduced successively. The MOS values resulting from these measurements are shown in Fig. C.3 for all codecs. The same packet sizes are used as in the experiments of Fig. C.2. For all codecs, a similar evolution of the MOS value with increasing amount of packet loss can be seen. Some codecs, such as G.726-7 and G.728, show a decrease in quality of about 1.2 MOS for a packet loss of 10%, whereas other codecs, such as G.711, GSM-FR, G.729 and G.723.1 show a smaller decrease of about 0.7 MOS. These results for each codec can now be fit to the following model that was suggested by Yamamoto [14], with M OSopt the optimal MOS value without any impairment for a certain codec, loss the amount of packet loss in percentage and C a constant factor: M OSpred = M OSopt − C ∗ ln(loss + 1). For this factor C, values of about 0.25 are found for the codecs that have a smaller degradation of quality (G.711, G.723.1, G.729), whereas values of about 0.4 are found for the codecs that are more sensitive to packet loss (G.726-7, G.728). Additionally, a number of experiments have been conducted to determine the influence of the used packet size on the attained quality. The results for three codecs are shown in Fig. C.4, with packet sizes ranging from 10 ms to 50 ms, indicating a small influence of the packet size. To take this influence into account in the model, an additional term due to packet size can be introduced, with size the used packet size in milliseconds, sizemin the minimal usable packet size for a certain codec (10 ms in most cases) and D a constant factor:


M OSpred = M OSopt − C ∗ ln(loss + 1) − D ∗ ln(size/sizemin). For the factor D, values of about 0.15 are found, indicating the small but noticeable influence of the packet size. In these experiments, no packet loss concealment schemes are used. It must however be noted that, as was indicated by Kostas [13] by means of informal tests on the G.723.1 codec, the application of these techniques allows to have a less noticeable degradation for packet loss ratios smaller than 10%.

C.4.3

Influence of delay jitter

The degradation caused by delay jitter in the network has been determined for two cases. First, VoIP connections are tested where no dejitter buffer is used at the receiver side. Second, quality measurements are conducted for connections with a dejitter buffer. In the first case, arriving samples are immediately decoded and sent to the play-out buffer of the soundcard. This way the extremely harmful influence of even very small amounts of delay jitter can be determined. During the experiments, an average delay of 100 ms is introduced in the network, with a standard deviation on the delay ranging from 0.1 ms to 10 ms. In Fig. C.5(a), the resulting MOS values can be seen for an experiment with the G.711 µ-Law codec and 10 ms packets, showing the devastating influence of delay jitter. For a standard deviation of only 0.5 ms, the MOS value drops to the lowest possible value of 1.0. In this case, the influence of delay jitter consists of, at irregular times, packets arriving too late to be played out on time, causing gaps in the played signal. This way, a large amount of distortion is introduced in the signal, resulting in a very poor quality. In a second series of experiments, the influence of delay jitter is determined on connections using a dejitter buffer at the receiver. In this case, samples delivered to the receiver are delayed for a while, in order to reduce the delay jitter by allowing packets to arrive a little later than expected. However, packets that have not arrived at the time they are supposed to be played out, are effectively lost. This way, the influence of delay jitter will be similar to that of packet loss. For larger values of the standard deviation on the delay, more packets will arrive too late and will consequently be lost. The results of these experiments for the G.711 µ-Law codec are shown in Fig. C.5(b) and C.5(c). Similar results are found for the other codecs. Packet sizes of 10 ms are used and the dejitter buffer delays the incoming samples for 10 ms. Again an average delay of 100 ms is introduced in the network with a standard deviation on the delay ranging from 0 ms to 30 ms. First,

C-12

Publicatie C

in Fig. C.5(b) the measured MOS values are shown for increasing amounts of jitter. This graph clearly shows that the dejitter buffer makes standard deviations of up to 12 ms still acceptable with a MOS of 3.0. Additionally, a graph is shown which is derived from the results shown in Fig. C.3(a) and Fig. C.5(c). The relation between the standard deviation introduced in the network and the measured amount of packet loss resulting in the dejitter buffer, shown in Fig. C.5(c), is combined with the measured MOS values for certain amounts of packet loss, to derive the influence of jitter on the quality. It can be seen that the measured and the derived values have a very similar evolution and it can be concluded that the application of a dejitter buffer changes the influence of jitter on the speech quality in an influence similar to the one of packet loss. It has to be noted that the influence of jitter depends on the depth of the dejitter buffer. With a depth of 10 ms an important degradation will be seen much faster (from stddev values of 5 to 10 ms), whereas a larger buffer depth of about 100 ms will only be showing degradation from stddev values of 50 ms and more.

C.4.4

Combined influence of packet loss and delay jitter

In a last experiment, the influence of both packet loss and delay jitter at the same time is determined. Therefore the same measurements are repeated to determine the influence of packet loss, but additionally an amount of delay jitter is introduced in the network. This way, a combination of different conditions is created with packet loss values ranging from 0% to 10% and with standard deviations on the delay ranging from 0 ms to 20 ms. Again the received samples are delayed 10 ms in the dejitter buffer and in the network an average delay of 100 ms is introduced. The resulting MOS values for the various combinations are shown in Fig. C.6 for the G.729 codec. Similar results were obtained for the other codecs. It is clear that the combined influence of jitter and packet loss highly reduces the margins, between which a voice connection attains an acceptable quality. Here, packet loss and jitter have to be restricted to low values (5% and 5 ms) in order to have a MOS of 2.6 or more. Again the remark on the buffer depth, as noted in previous section, is in place here.


4 3.5 3

MOS

2.5 2 1.5 1 0.5 0 0.01

0.1

1

10

stddev on delay (ms)

(a)

4

40

0%

0%

measured MOS

35

derived MOS

3.5

3%

packet loss (%)

30

MOS

3 12%

2.5 20%

25 20 15 10

2

5 34%

1.5 0

5

10 15 20 stddev on delay (ms)

(b)

25

36% 30

0 0

5

10

15

20

25

30

stddev on delay (ms)

(c)

Fig. C.5: C.5(a) MOS vs. jitter without dejittering buffer (G.711 µ-Law); C.5(b) MOS vs. delay jitter for dejittered signal (G.711 µ-Law) from measurements and derived from the results of Fig. C.3(a) and C.5(c); C.5(c) Introduced jitter vs. resulting packet loss in dejittering buffer (G.711 µ-Law)

C.5

Future work

A number of additional measurements on a hardware-based setup, using hardware codecs, are planned. Furthermore, the effectiveness of a number of packet loss concealment schemes will be studied.

C.6

Conclusions

The measured voice quality degradation has been decomposed into its major contributing factors. First, the influence of sampling and digitization has been shown to be small but not negligible. Second, the degradation due to coding/decoding was illustrated and the influence of the resulting bitrate

C-14

Publicatie C

3.5

stddev 0ms stddev 5ms stddev 10ms stddev 15ms stddev 20ms

3

MOS

2.5

2

1.5

1 0%

2%

4%

6%

8%

10%

packet loss (%)

Fig. C.6: Combined influence of delay jitter and packet loss on the perceived quality (G.729)

was shown. Low bitrate codecs show a larger degradation of speech quality. Then, the influence of packet loss in the network has been determined and the results have been fit to a model, incorporating both the influence of the packet loss ratio and the packet size. A number of codecs (G.726-7 and G.728) are shown to be more sensitive to the influence of packet loss than the others (G.711, GSM-FR, G.729 and G.723.2). For high bitrate codecs, the quality is acceptable for packet loss values up to 10%, whereas for the low bitrate codecs only 4-5% is sustainable. All codecs show a similar and smaller sensitivity to the influence of packet size. Also the degradation caused by delay jitter has been shown. On a connection without dejitter buffer, a devastating influence of jitter is seen, whereas the influence on a connection with dejitter buffer is found to be similar to the effect of packet loss in the network. After all, the influence of jitter in the network is translated into an effect of packet loss in the dejitter buffer, which drops the late packets. For a buffer depth of 10 ms a standard deviation on the delay of up to 13 ms still gives an acceptable quality. Finally, the combined influence of packet loss and delay jitter on the speech quality was observed. Due to the combination of the effects, packet loss should be restricted to 5% and jitter to 5 ms to keep an acceptable quality.


Acknowledgments This work was funded by the Flemish institute for the promotion of scientific and technological research in the industry (IWT) and was carried out within the framework of the project LIMSON. The authors want to thank the reviewers for their comments and suggestions, which helped to improve the final manuscript.

Referenties [1] R. Braden, D. Clark, S. Shenker, Integrated Services in the Internet Architecture: an Overview, RFC 1633, Jun. 1994. [2] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, An Architecture for Differentiated Services, RFC 2475, Dec. 1998. [3] GTE Laboratories, VoIP speech quality as a function of codec, manufacturer, jitter and packet loss, GTE Laboratories, May 1999. [4] GTE Laboratories, VoIP speech quality as a function of delay, jitter and packet loss, GTE Laboratories, April 2000. [5] H. W. Gierlich, F. Kettler, Conversational Speech Quality - The Dominating Parameters in VoIP Systems, Internet Telephony Workshop, Apr. 2001. [6] L. Sun, G. Wade, B. Lines, E. Ifeachor, Impact of Packet Loss Location on Perceived Speech Quality, Internet Telephony Workshop, Apr. 2001. [7] National Institute of Standards http://www.antd.nist.gov/itg/nistnet/

and

Technology,

[8] M.P. Hollier, M.O. Hawksford, D.R. Guard, Characterisation of Communications Systems Using a Speech-Like Test Stimulus, Journal of the Audio Engineering Society., Vol.41, No.12, 1993. [9] M.P. Hollier, M.O. Hawksford, D.R. Guard, Objective Perceptual Analysis: Comparing the audible performance of data reduction schemes, Presented to the 96th AES Convention in Amsterdam, Preprint No.3879, 1994. [10] ITU-T, P.56: Telephone transmission quality objective measuring apparatus, ITU-T, 1993. [11] ITU-T, P.800: Methods for subjective determination of transmission quality, ITU-T, 1996.

C-16

Publicatie C

[12] S. Rudkin, A. Grace, M.W. Whybray, Real-time applications on the Internet, BT Journal, Vol. 15, No. 2, 1997. [13] T.J. Kostas, M.S. Borella, I. Sidhu, G.M. Schuster, J. Gabriec, J. Mahler Real-Time Voice over Packet-Switched Networks, IEEE Network, Jan/Febr 1998. [14] L.Yamamoto, J. Beerends, KPN Research, Impact of network performance parameters on the end-to-end perceived quality, Expert ATM Traffic Symposium, 1997.

An active networking based service for media transcoding in multicast sessions Bart Duysburgh, Thijs Lambrecht, Filip De Turck, Bart Dhoedt, Piet Demeester.

IEEE Transactions on Systems, Man and Cybernetics, Part C, Special Issue on Computational Intelligence in Telecommunications Networks and Internet Services

Abstract — Active networking is one of the suggested technologies to introduce additional intelligence and programmability in the network and its services. In this paper, the use of active networking to support advanced multicast services providing media transcoding inside the network is investigated. In the multicast service different versions of the streamed data are made available and customers can select a specific version according to their wishes or their capabilities. Based on the active networking facilities of the underlying framework the different versions of the streamed data can be created inside the network, through transformations or transcodings of the original data. Both design and performance issues of the detailed service are discussed. A new multicast tree set-up protocol, taking into account the required transcodings, is introduced. A number of different strategies are discussed optimising the location of the transcodings as well as the use of bandwidth in the network, while considering the availability of sufficient processing power in the nodes. The performance analysis is done for a voice stream multicast service, addressing the efficiency of the tree set-up strategies, the optimisation of network resource utilisation, the use of processing power for transcodings and the resulting quality of streamed voice signals after multiple transcodings.

D-2

D.1

Publicatie D

Introduction

With the fast expansion and the increasing use of the Internet over the past few years, a number of issues concerning the current network infrastructure and the available functionality have become apparent. With most of its basic concepts and protocols dating back a few decades ago, the current Internet suffers from a lack of flexibility as well as functionality. For a long time it was believed that it was sufficient to provide a robust, best-effort, unicast service and that all intelligence should be pushed to the edges of the network. However, with the increasing need for flexible and advanced network services, it is becoming ever more clear that this traditional viewpoint severely hampers the evolution of network services. After all, a lot of effort is needed to introduce new services or to adapt existing ones and it is hard to accommodate advanced features in the network. With the identification of these problems the network research community started to express the need for an advanced networking infrastructure and various initiatives emerged to devise the concepts and technologies for future computer and communication networks. To increase the flexibility and functionality of these future networks, different strategies were suggested. At one hand, the use of open programming interfaces was proposed in order to speed up service development and deployment. On the other hand, a more progressive concept suggested to introduce additional intelligence and functionality inside the network and to move part of the application funtionality from the edge to the network nodes. Whereas the first option is mainly driven by the changes in the liberalised and deregulated communication market, requiring a new business model to tackle the growing competition, the second option aims to really revolutionise future network infrastructures by injecting and executing additional code in the network nodes. The last option, which is the preferred concept for the framework used in this work, is inspired by the observation that a large group of services and applications might profit from the introduction of extra functionality in the network. For instance, multicast services require additional intelligence in the network to replicate and forward packets to various destinations simultaneously and for this purpose need to maintain a non-trivial amount of state in the nodes as well. A second example are on-line auction applications, where considerable performance gains could be achieved by filtering and aggregating messages in the network. Also, content distribution services could profit from node programmability by caching replicas in network nodes to reduce response times. Currently, a number of services are already available providing some of this

An active networking based service for media transcoding in multicast sessions

D-3

additional functionality in the network. Firewalls process and filter packets, thus applying specific security policies. Web proxies handle HTTP requests and cache popular pages in dedicated nodes at the edge of the network. Dedicated gateways provide transcoding of media streams for specific applications. However, these services are all located at the edge of the network and they are introduced and tailored individually for a specific situation. Therefore, to tackle the need for flexibility and functionality in current networks in a more general way, active networks [1–4] have been devised. Active networking is based on the Store-Compute-and-Forwarding paradigm and allows processing of packets inside the network. This way, part of the application’s functionality can be moved inside the network and flexibility is increased. These active capabilities are realised in the nodes as follows: (i) packets are allowed to carry chunks of code, which can be executed in the network nodes, (ii) an amount of state information can be maintained and consulted on the nodes in a soft-state cache and (iii) additional functionality can be installed on the nodes by means of extensions. Based on this new concept, a framework supporting flexible service creation and advanced network functionality was developed. Each network node is provided with the basic active networking capabilities and is hence called an active node. As a consequence, new services can be built by introducing packets carrying specific code and functionality, called capsules, and by using specific status information maintained in the soft-state cache. Routing decisions can then be made in each node for each packet and processing of the carried data can be done, based on the present state. Additionally, more complex functionality which is too large to be carried efficiently in a capsule can be installed on the nodes as an extension. Based on this framework, we designed an advanced multicast service, allowing transformations of the streamed data inside the network. For the set-up, teardown or modification of the multicast tree a number of capsules were designed, implementing a number of different strategies and protocols. In the set-up strategies, forwarding state for the multicast tree is installed in the soft-state cache and transcodings are placed in the network where needed. When installing transcodings the availability of processing power in the node is taken into account. Therefore an extension is installed on the nodes, which keeps track of the processing load on the node and which is consulted during the tree set-up procedure. The functionality for the media transcoding processes is not carried in every capsule, but is installed on the nodes as an extension as well. With the design and analysis of this service, we aim to investigate the use of active networking techniques for the support of advanced multicast services. More specifically we look into the advantages and disadvantages of

D-4

Publicatie D

multicast services enhanced with transcoding capabilities in the network. A similar service is described in [5], providing a robust multicast stream by stripping redundant information from the signal according to the losses detected in the network. The use of simulcast (i.e. simultaneous distribution of different versions along separate trees) and layered encoding to provide self organised transcodings, in order to reduce load on congested links, is demonstrated in [6]. However, in both cases customisation of the service and receiver driven transcodings are not provided. On the other hand, receiver driven layered multicast (RLM) is presented in [7], where different layers of the hierarchical signal are striped across multiple multicast groups and receivers adapt to congestion by adding or dropping layers. However, this solution is restricted to a scheme based on hierarchical encoding of the signal and can not provide a wider range of codecs as is done in our service. In [8], the set-up of end-to-end unicast paths with transcoding functionality is detailed. Although this service allows users to access media objects from terminals with limited encoding and decoding capabilities, the solution is limited to unicast traffic. Alternative approaches for the set-up of multicast trees, especially in active networks, are presented in [9] and [10]. The former proposes the use of ephemeral state to determine links and branching points of the tree, whereas the latter shows how to set up multicast trees based on a recursive unicast approach. Another alternative scheme to support multicast communication is offered by application level multicast (ALM), presented in [11, 12]. Here, the session participants are connected via a virtual multicast tree, forming an overlay network based on a minimum spanning tree of unicast connections. This way packets are replicated at the end hosts. Although each of these efforts tackles a part of our problem, none of them provides an integrated solution, using flexible routing strategies to set up multicast trees and transcodings, while considering available resources in the nodes. In contrast to other similar discussions, the performance of the designed service and the resulting quality of the streamed data will be discussed here as well. In extensive simulations the performance of the different tree set-up strategies was analysed and the resulting quality of a voice stream subject to intermediate transcodings was evaluated. The remainder of this paper is structured as follows. Section 2 gives a more detailed description of the advanced multicast service. Section 3 focuses on the active networking based framework, offering the underlying functionality for the designed service. Section 4 presents the different multicast tree set-up strategies that were considered. Section 5 details the results from the performance analysis of the service. Section 6 gives a summary of the results and outlines the conclusions.


D.2

Multicast service with transcoding capabilities PCM16

128 > 32

128kbps

128kbps

32kbps

128kbps 32kbps

32kbps 16kbps

transcoding extension

receiver G726-7

128kbps

server

D-5

receiver

G728 receiver

32 > 16

Fig. D.1: Voice multicast service with transcoding in intermediate nodes.

From the beginning, multicast technology has been considered the perfect technique to support the distribution of multimedia streams to a large group of users simultaneously. In the traditional application of multimedia streaming one specific version, in terms of encoding or bitrate, is distributed to all users. This approach however lacks a lot of flexibility and does not allow any customisation of the service by the users. Therefore, it could be favourable to provide multiple versions of the streamed multimedia. This way, customers can choose a version according to the capabilities of their terminal and of their network connection. They can customise the service according to their own needs and wishes, while considering the available support for different codecs on their terminal or the technology and bandwidth of their connection. In order to support this advanced feature of multicast streaming in the traditional Internet, separate multicast trees are needed for each version of the stream. This results in a significant increase of the load on both the server and the network. However, on an active network this advanced feature can be supported with a considerable reduction in network and server load. Only one multicast tree is used, sending only one version of the data and performing transformations of the original data to the requested versions in intermediate nodes of the tree. This advanced multicast service can be used to stream a wide variety of multimedia content. The presented service functionality, providing the set-up and maintainance of the multicast tree and the transcodings, can be used to support either voice, audio or video content. The only difference lies in the implementation and the complexity of the respective transcoding processes. Although transcoding of audio and video streams between dif-

D-6

Publicatie D

ferent codecs is not trivial, layered encoding schemes allow to reduce the bitrate and quality of the signal by discarding parts of the stream. In addition, dropping of well-chosen frames from a video stream can result in the necessary reduction of bitrate or quality. In the remainder of this paper, we will focus on the specific case of a multicast service providing voice streams at different encodings and bitrates. The voice codecs that are offered to the customers in our service are listed in Table D.1. Transcodings are only allowed from a higher bitrate codec to a lower bitrate codec, in order to preserve an acceptable quality of the voice stream. Customers can request a specific encoded version of the voice stream, for example according to their uplink capabilities. A user on a high-speed ADSL connection can easily choose the full rate version PCM16 encoding of the stream, whereas a user on a 33K modem can only choose the G.728 or G.729 encoding. An example of a session of this service is shown in Figure 1. Three users requested the PCM16, the G.726-7 and the G.728 codec, respectively. A single version of the stream is sent through the network (PCM16) and the requested versions are derived from the original stream by transcoding in intermediate network nodes. Therefore, additional functionality installed on these transcoding nodes is used. TABEL D.1: Voice codecs provided in multicast service Codec PCM 16 bit G.711 µ-law G.726-7 4 bit G.728 G.729

D.3

Bitrate 128 kbit/s 64 kbit/s 32 kbit/s 16 kbit/s 8 kbit/s

[17] [18, 19] [20] [21]

Active networking framework

In this section, we briefly discuss the framework providing extra flexibility and functionality in the network and supporting the introduction of new and the evolution of existing services. The cornerstone of this framework is the active networking node. A functional decomposition of such an active node is shown in Figure D.2. In this node the traditional IP forwarding is extended with a classification mechanism. Active packets or capsules are delivered to an active execution environment, where the code carried in the capsules is executed. This code can be carried in each capsule (in-band) or the code can be loaded once into the node and a reference to this code can


D-7

be carried in the capsules needing its functionality (out-of-band). After execution, the capsules are handled by the IP forwarding routine, which also provides the default forwarding for the non-active packets.

soft-state cache

dynamically loadable extensions

extension capsule execution

Active execution environment active packets/capsules

IP forwarding

unicast routing table

Active node

Fig. D.2: Active networking node.

The implementation of the active node is based on the Active Network Transport System (ANTS) [13]. ANTS provides a JAVA based execution environment, running in user-space and allowing to execute JAVA bytecode carried in the capsules. In a soft-state cache temporary information can be stored by the capsule code. This existing ANTS system was extended with extra functionality to support dynamically loadable extensions. In the capsule code, functionality provided in extensions can be called. When the required extension is not present at the node, the necessary byte-code is automatically downloaded from a code-base and the extension is loaded into the system. To support the evolution between different versions of the same extension, a specific version can be requested in the capsule code. If not present, a new version can be installed and different versions can be running in parallel on the same node. To conclude this section, the following issues considering the active networking concept should be mentioned. Both security and the deployment of active networking are critical issues, which are tackled in specific efforts dealing with active networking platforms [13, 14]. Through application and kernel level implementations the feasibility of the proposed concepts is shown and schemes are developed for the introduction of active nodes in a transparent way. Regarding security, schemes are provided to restrict access to resources and functionality in the nodes, preventing malicious users from abusing the system. Authorisation and authentication procedures are set up to identify the users that introduce or use active code and to check the integrity of code traversing the network [15, 16]. In our work, we focus on

D-8

Publicatie D

the development of advanced applications and services based on the functionality provided in the active platforms. Therefore, a fully active network is assumed to be at our disposal and we rely on the respective efforts to provide a secure and well-performing active networking platform. Hence, we refer to other efforts for more information on the security and deployment issues.

D.4

Multicast tree set-up

The main design issue of our advanced multicast service is the set-up of a multicast tree in an active network, thereby taking into account all features of the service. A multicast tree should be set up, while considering the specific requests of the users for certain versions of the data. Therefore, decisions should be made during the set-up whether transcodings are needed and where to place them in the network. In addition, the availability of processing resources should be taken into account when installing transcodings in the nodes. All these requirements should be incorporated in a set-up procedure that is working in a distributed way, making decisions in each node individually, based on the information available there. In general, the set-up of the multicast tree comes down to JOIN messages being sent by the users, triggering the set-up of additional branches to the tree. In the JOIN messages the users specify the session they want to join and the requested version or codec of the data. These requests are typically sent towards a central node, which will act as the root or core of the tree. In this discussion, the multicast server will function as the central node. However, in situations where the users are more wide-spread over the network, a core based approach may be more favourable. In that case, the same procedures as discussed below can be used to set up the tree towards the core. Starting from these initial assumptions, a number of procedures have been developed. The variations between these procedures are mainly determined by the following aspects: (i) the direction in which the multicast tree is set up and (ii) the measures that are taken to overcome processing power scarcity in nodes where a transcoding is needed. Before handling these aspects, the tree state maintained in the nodes should be discussed briefly. The tree state is maintained per multicast session, in the same way as it is done per multicast group in the traditional multicast routing protocols. It is maintained in a soft-state cache and therefore the entries should be refreshed on a regular basis. Data that are not refreshed will be removed after a certain time. Per session the following information is kept: (i) an identification of the session, (ii) the next hop towards the


D-9

server and the version or codec expected from that link and (iii) a number of entries indicating the branches starting from the node in the downstream direction. These entries consist of a pointer to the next downstream hop of the tree and an indication of the requested version down that link. The codec delivered by the upstream link is referred to as C uplink below. Also information considering the relocation of transcodings will be stored in these entries. For an explanation of this extra information (the TC and Psh field in Figure D.3) we refer to the discussion in subsection B.

D.4.1

Tree set-up direction

Because of its simplicity and the fact that it can easily be done in a distributed way, a shortest path tree is the obvious choice for the multicast tree. However, considering the fact that asymmetric routes may occur in current networks, the result of the set-up depends on the direction in which it is performed. After all, shortest paths between two nodes may differ depending on the direction of the paths. Therefore, two approaches are possible. In order to set up a tree with shortest paths from the server towards the users, the JOIN messages must first travel up to the server. The multicast tree and the state maintained for it in the nodes is then installed by a JOIN ACK message on its way back from the server to the user. On the other hand, the tree state can also be installed in the nodes along with the JOIN message travelling up to the server. This will result in a tree with shortest paths from the users to the server, which may be a less optimal solution. These two approaches are called the downstream and the upstream set-up procedure, respectively. The downstream set-up will obviously result in a more optimal shortest path tree than the upstream set-up. However, the latter will be considerably faster and will also reduce the amount of messages travelling through the network and the number of JOIN messages to be handled by the server during the set-up. This can clearly be seen from the detailed discussion below. D.4.1.1

Downstream set-up

In this case, each JOIN message is forwarded up to the server, where a JOIN ACK message is sent back to the initiating user. The message is forwarded in each node, until the initiating user is reached. On its way back, the JOIN ACK message will trigger the following decisions in the nodes, which are illustrated below. In the description, NxtHop and PrevHop are used according to the direction in which the messages (JOIN ACK and JOIN ) travel through the network.

D-10

Publicatie D

JOIN_ACK <ses S, cod C> : on each node { if ( state <ses S> present ) { if ( entry present ) { if ( BW(C)>BW(C’) ) { update entry to ; } } else { add entry ; } } else { add state <ses S> ; add entry ; C uplink=C; } if ( BW(C)>BW(C uplink) ) { C uplink=C; } forward JOIN_ACK <ses S, cod C> ; } If no tree state is present for the requested session, tree state is installed in the cache and an entry pointing to the next hop towards the initiating user with the requested codec is added. Otherwise, the existing entries are update according to the new request. If a higher bitrate codec is requested compared to the present one in the entry, the entry is update with the requested codec. If necessary, the codec on the upstream link (C uplink ) is updated.

D.4.1.2

Upstream set-up

When a JOIN message is sent, tree state is immediately set up on the way to the server. The decisions that are made in the nodes are shown below. The tree state for a session and its entries are set up almost in the same way as in the downstream procedure. However, entries are set pointing to the previous hop visited by the JOIN message. Furthermore, the JOIN message is only forwarded towards the server until a node of the tree is reached where the required codec is available. This can be the case if the requested codec is the one on the upstream link or when it can be transcoded from that higher bitrate codec on the uplink. If the bitrate of the requested codec is higher than the present codec on the upstream link, the JOIN message is forwarded further upstream and the codec on the upstream link (C uplink ) is updated.


D-11

JOIN <ses S, cod C> : on each node { if ( state <ses S> present ) { if ( entry present ) { if ( BW(C)>BW(C’) { update entry to ; if ( BW(C)>BW(C uplink) ) { C uplink=C; forward JOIN <ses S, cod C> ; } } } else { add entry ; if ( BW(C)>BW(C uplink) ) { C uplink=C; forward JOIN <ses S, cod C> ; } } } else { add state <ses S> ; add entry ; C uplink=C; forward JOIN <ses S, cod C> ; } }

In Figure D.3, an illustration of the upstream set-up procedure is shown. The users on node 1 and 2 are joining the session X, requesting the codec G.711 and G.728, respectively. The JOIN message of user 1 is sent to the server on node 7 and on its way up, tree state is installed on the traversed nodes. When the JOIN message reaches node 7, the server processes the request and starts to send DATA capsules, containing the G.711 codec. These capsules forward themselves along the entries specified in the tree state and the original data are transcoded when a different codec than the delivered one is specified. The user 2 JOIN message only has to travel up to node 5, where tree state for session X already exists and the G.728 codec can be transcoded from the G.711 codec on the upstream link. This way, user 2 will see a faster response to his JOIN message by a DATA capsule than user 1. If on the contrary the downstream set-up procedure was used, the JOIN message of user 2 would also have to travel to the server, resulting in a more or less equal response time for user 1 and 2.

D-12

Publicatie D

(4')

Ses To Cod TC Psh X 6 g711 yes no

7

(4) join <sesX,g711> (5)data <sesX,g711>

(3')


6

(3) join <sesX,g711>

transcoding g711 > g728

5 (2) join <sesX,g711>

(1')


(1) join <sesX,g711>

Ses To Cod TC Psh X 3 g711 yes no (2') X 4 g728 yes no (7') (7) join <sesX,g728>

3

4 (5)data <sesX,g711>

Ses To Cod TC Psh X 2 g728 yes no (6') (6) join <sesX,g728>

(8) data <sesX,g728>

1

2

Fig. D.3: Upstream tree set-up procedure.

D.4.2

Overcoming processing power scarcity

During the installation of tree state on the nodes, the need for transcodings has to be considered. When a transcoding is necessary on a certain node, the availability of sufficient processing power has to be checked. The processing time necessary to perform specific transcodings will be discussed in Section 5.A. With the knowledge of this required amount and the results provided by the load monitoring mechanism, a decision can be made whether the transcoding can be performed on a node. If a node has not enough processing power available, i.e. the node is overloaded, measures have to be taken. In Figure D.4, three strategies are illustrated. Each of these strategies involve the relocation of the necessary transcoding to another node with sufficient processing power. This action is referred to as pushing the transcoding to another node. A first option is to push the transcoding to a neighboring node, which is already part of the multicast tree. In this case, the transcoding can be pushed either in the upstream or in the downstream direction. A second and more general option is to select a node from the network, not necessarily a neighbor or a part of the tree, with sufficient processing power for the transcoding. This node can then function as a proxy for the transcoding. The original version is then sent to the proxy

An active networking based service for media transcoding in multicast sessions server 128 > 64

server

128kbps

server

128kbps

64kbps + 128kbps

D-13

128kbps

128kbps 128kbps

64kbps 128kbps

64kbps

128kbps

128kbps

128 > 64

128kbps

overloaded 64kbps

128 > 64

64kbps

receiver

receiver

push upstream

push downstream

64kbps

not overloaded

receiver transcoding extension

proxy

Fig. D.4: Strategies to overcome processing power scarcity in a node.

node where the required transcoding is performed and the resulting version is sent back to the node that started the process. When transcodings are pushed to another location, extra information should be maintained in the tree state. This is illustrated in Figure D.5 for the push upstream strategy. If a transcoding is pushed up the tree (from node 5 to 6), an entry will be created on the upstream node 6 pointing to the downstream node 5 with the required codec. This entry however should never be updated or overwritten by another JOIN message passing the node. Therefore, the entry is explicitly marked as pushed (Psh=yes). On the other hand, the entry on the downstream node 5 should be marked too, indicating that the requested codec should not be transcoded from the received version on the upstream link (G.711). By indicating that the entry should not be transcoded (TC=no), this entry will only be used by DATA capsules carrying the requested codec (G.728). All other regular entries are not pushed and should be transcoded from the delivered version (Psh=no, TC=yes). This extra tree state is required for the push upstream and the proxy strategy, because different versions of the data may be transported in parallel over the same link. The push downstream strategy is considerably simpler than the others and does not need the extra state. To perform the relocation of a transcoding during the tree set-up procedure, a dedicated PUSH message is sent to install the specific state for the pushed transcoding in the nodes. The different options are discussed in greater detail below.

D-14

Publicatie D

D.4.2.1

Push upstream

When a node needing an extra transcoding is overloaded and multiple transcodings are already present, a decision should be made which transcoding to push to another node. This choice can be optimised while considering the extra bandwidth that will be used on the upstream link. The resulting stream from the pushed transcoding will be transported in parallel with the uplink codec over the upstream link. Therefore, the transcoding to the codec with the lowest bitrate available on the node and which is not already moved up should be pushed first. The PUSH message is sent to the first upstream node via the upstream link. If there is a sufficient amount of processing power on the node, the necessary entry is added in the state and the procedure terminates. Otherwise, the message is forwarded to the following upstream node, until an appropriate node is found or the server is reached. In the latter case, the transcoding is placed on the server. Ses To Cod TC Psh X 6 g711 yes no

7


(4')

Ses To Cod TC Psh X 5 g711 yes no X 5 g728 yes yes

transcoding g711 > g728

6 (4) push <sesX,g728>

Ses To Cod TC Psh X 3 g711 yes no (3') X 4 g728 no no

no processing power for transcoding g711 > g728

5

(3) join <sesX,g728> Ses To Cod TC Psh X 1 g711 yes no

3


1

4 (5) data <sesX,g728>

Ses To Cod TC Psh X 2 g728 yes no (2') (2) join <sesX,g728>

2

Fig. D.5: Upstream tree set-up procedure with transcodings pushed upstream to overcome processing power scarcity.

D.4.2.2

Push downstream

To choose the appropriate transcoding to push downstream, following considerations can be made. A transcoding is always done from the highest


D-15

bitrate codec available on the node in order to limit the deterioration of the final quality. Therefore the highest bitrate codec should be forwarded downstream, where it will be transcoded to the required codec. When considering the extra bandwidth used on that downstream link by overwriting the present codec with the highest bitrate codec, the choice of the pushed transcoding can be optimised accordingly. Therefore, the one but highest bitrate codec should be pushed down first. In this case, the PUSH message should be sent downstream along all of the entries specifying the resulting codec of the pushed transcoding. The push action may therefore affect multiple downstream links and nodes. The message is fowarded downstream until a node with a sufficient amount of processing power is encountered. Otherwise, the message is forwarded until a user node is reached where the transcoding is then installed.

D.4.2.3

Proxy

As in the push downstream strategy, the highest bitrate codec will be pushed to the proxy node to be transcoded there. To optimise the extra bandwidth used by sending the stream to and from the proxy node, the transcoding for the lowest bitrate codec present on the node, which is not yet relocated, will be pushed first. Another important issue is where to push the transcoding. To select the appropriate node, probe capsules can be flooded into the network, looking for nodes in the neighborhood with a sufficient amount of processing power. If a probe encounters such a node, it can return to the initiating node to indicate the possible proxy node. The first probe capsule returning with an answer will then indicate the closest possible proxy node, in terms of round trip time. The PUSH message can then be sent to the proxy node to set up the necessary tree state. Another option is to use a mechanism which floods the load monitoring information of the different nodes through the network on a regular basis. This way, each node is informed of the load on the other nodes and the choice for the proxy node can be made locally based on the unicast routing information and the load information. The proxy strategy is a general solution to relocate a transcoding. The push upstream and downstream strategies are special cases of this general approach, where a node from the existing multicast tree is selected to function as proxy. Additionally, the transport of the stream to and from the proxy is optimised to reduce the bandwidth used.

D-16

D.5

Publicatie D

Performance evaluation and quality assessment

In this section, the performance of the service will be evaluated and an assessment of the resulting quality will be made. The performance of a service can be considered either from a service provider point of view or from a customer point of view. For a service provider, it is important to be able to introduce or to adjust the new service in a flexible way and to have an optimal usage of the resources in the network. A customer will seek a fast responding service, with an acceptable quality and providing an attractive and customisable functionality. Consequently, the performance metrics can be grouped accordingly. First, the performance of the transcoding processes in the nodes in terms of the required processing time will be discussed. These metrics are important to allow the optimal use of the computational resources in the network and to fine-tune the set-up procedures. Second, the different set-up procedures are evaluated in terms of the bandwidth and the number of transcodings used in the tree. This way, the service provider can observe and optimise the use of resources in his network. Third, the response times experienced by the users when joining a multicast session and the number of successive transcodings needed on the way from the server to the user are observed. These metrics indicate the quality of the service as seen by the customers. Finally, the service quality is also indicated by the Mean Opinion Score (MOS) which expresses the opinion of the users on the perceived quality of the stream. These metrics are discussed in the following subsections, detailing measurements of the transcoding performance, simulations assessing the tree set-up performance and observations of the perceived quality, respectively.

D.5.1

Transcoding performance

When transcodings are performed on the network nodes, a certain amount of CPU time will be required. It is important to know the required amount of CPU time for the different possible transcodings in order to determine the maximum number of transcodings that can be supported in parallel by the network nodes. The required CPU time will also indicate whether the transcoding can be done in real-time, i.e. the processing of a fragment does not take longer than the fragment itself. Below, the measurement procedures for the analysis of the different transcodings are described as well as the results for each of the available transcodings in the service.


D.5.1.1

D-17

Measurements

4 3 2

0.66 0.14 0.01

0.66 0.79

Transcoding time for 10ms fragment (ms)

5

3.64 3.65 3.77 4.07

1

0.15 0

CM

P bit

16

11

law

U-

G7

-7 26

it

4b

G7

Original codec

G7

28

G7

G7

28

26

G7

11

U-

law

G7

-7

29

4b

it

Resulting codec

Fig. D.6: CPU time (in ms) needed to perform a transcoding of a 10 ms voice fragment, for a processor speed of 1000MHz.

First, a remark is in place on the mechanism of the voice transcodings. To transform a voice fragment from one codec to another, the fragment is first transformed or decoded to the basic PCM 16bit encoded version. This version can then be encoded to the desired new codec. Knowing that encoding a voice fragment takes considerably more time than decoding it, it can be expected that the CPU time needed for the transcoding will mainly depend on the complexity of the destination codec. The software implementing the codecs available in the service and the transcodings between them is based on ANSI-C implementations of the respective ITU-T specifications [17–21]. These implementations are run on PC based Linux workstations. In order to measure the CPU time used to perform a certain transcoding, the standard UNIX tool time was used, counting the total amount of CPU time that was spent in user and kernel space by the transcoding process. The CPU time was measured for each of the available transcodings for a fragment of English speech, 28.14 seconds in length, sampled at 8kHz and with PCM16 encoding. The measurements were done for 4 different

D-18

Publicatie D

processor speeds: 500MHz (AMD-K6), 750MHz (AMD-Duron), 1000MHz and 1400MHz (both AMD-K7). During the measurements, the transcoding process is the only real process using the processor, apart from the Linux operating system, hence using approximately 100% of its capacity. Each measurement is repeated 20 times for each set of codecs and processor. The results are then averaged in order to compensate for the potential fluctuations due to the CPU time used by the operating system. The results for the 1000MHz processor are presented in Figure D.6. The results are normalised for a voice fragment of 10 milliseconds. D.5.1.2

Discussion

As was indicated above, it is clear that the processing time for the transcodings mainly depends on the desired new codec and that the original codec has little or no influence. Hence, the required CPU time is proportional to the complexity of the encoding algorithm of the desired codec. Because of their Pulse Code Modulation nature, the G.711 and the G.726-7 codecs perform far better than the more complex hybrid coders G.728 and G.729. Although the G.728 codec has a more complex algorithm than the G.729, it is performing better due to its backward adaptive nature. The same trends are found within the results for each of the four processor speeds used. It is also obvious that with increasing processor speed the required CPU time decreases. This reduction in processing time is roughly inversely proportional to the increase in processor speed. To be able to perform a transcoding in real-time, the processing time should be less than or equal to the length of the transcoded fragment. It can therefore be concluded that all transcodings on all processors are possible in real-time, as the transcoding of a 10 millisecond fragment does not take more than 8.18 milliseconds in the worst case (i.e. from G.728 to G.729 on the 500MHz processor). Moreover, the restriction for real-time transcoding also restricts the number of transcodings that can be done in parallel on one processor. The maximum number of parallel transcodings on the different processor speeds is roughly limited to 500-1000 for the G.711 codec and 34100 for the G.726-7 codec. This means a considerable amount of streams can be transcoded simultaneously on the same node. However, the maximum number for the G.728 codec is limited to 8-20 and for the G.729 codec to 1-3.

D.5.2

Tree set-up performance

First, a comparison is made of the different tree set-up strategies and of the procedures to overcome resource scarcity in the nodes. Therefore, the total


D-19

amount of bandwidth used in the network and the total number of transcodings done in the multicast tree are evaluated. Second, the response time when joining the tree and the number of successive transcodings between the server and the receiver are observed. D.5.2.1

Simulations

In order to evaluate these metrics, extensive simulations have been performed with the ns2 network simulator [22]. The ns2 network node was extended with an active networking agent, enabling the simulation of active networking capabilities. A network topology (240 nodes, 304 edges) generated with GT-ITM’s [23] transit-stub method was used to simulate the tree set-up procedure for the service. A topology with 3 transit domains (5 nodes per domain) and 3 stub domains per transit domain (5 edges per stub domain) was generated. In the simulations, the results obtained in Section 5.A were used, accounting for transcoding delays in the active nodes based on the values for a 1000MHz processor. For each run of the terminating simulation, a server node and a group of client nodes was randomly chosen, as well as the requested codec version of the voice stream for each client. Also a number of randomly chosen network nodes were marked as overloaded, meaning that they are unable to accommodate any extra transcodings. The simulations were conducted for a number of specific configurations, defined by the number of group members, and were repeated for a specific configuration until the relative statistical error on the observed parameters dropped below 1%. D.5.2.2

Results

The increasing amount of bandwidth and transcodings in the multicast tree with increasing number of group members is illustrated in Figures D.7 and D.8. For the push upstream strategy with 100% network load, all transcodings are pushed towards the server, resulting in separate trees being set up for each codec. This corresponds to the non-active solution for the problem. It can therefore be seen that the active solution without network load results in a reduction of bandwidth in the tree between 5% and 10%. The push upstream strategy clearly puts the least load on the network. When transcodings are pushed upstream, the bandwidth increases less than for the other strategies. In the push upstream strategy, extra bandwidth is only introduced on the upstream link and the lowest bitrate codecs are pushed first. On the contrary, in the push downstream strategy, transcodings are pushed down possibly along multiple links and the highest bitrate codecs

D-20

Publicatie D

4

3.5

x 10

Total Bandwidth in Tree (kbps)

3

2.5

unloaded loaded 20% push upstream loaded 60% push upstream loaded 100% push upstream loaded 20% push downstream loaded 60% push downstream loaded 100% push downstream loaded 20% push to proxy loaded 60% push to proxy loaded 100% push to proxy

2

1.5

1

0.5 40

60

80

100

120

140

160

Number of Group Members

Fig. D.7: Use of bandwidth in multicast tree for different fractions of overloaded nodes and different strategies.

are pushed first. The results for the push to proxy strategy lie between the results of the previous two. At the same time, when pushing transcodings upstream, ever more transcodings will coincide on the same upstream node, reducing the total number of transcodings. For the push downstream strategy, some of the transcodings may be pushed downstream along multiple links from the hosts, increasing the number of transcodings. Pushing transcodings to a proxy node will reduce the number of transcodings, while the transcodings will coincide on a small number of proxy nodes that are not overloaded. The results for the push upstream and push to proxy strategy are the same for a fully loaded network, where all transcodings are pushed to the server node. In Figure D.9, the average response times for joining the multicast session is shown for the different strategies. It is clear that the average response time is maximal for the downstream set-up strategy, since all JOIN messages have to travel up to the server before setting up a new branch. This is also independent of the number of members in the multicast group. With the number of group members increasing, the upstream strategy becomes faster since it becomes more probable that part of the multicast tree is already set up near the client sending the JOIN message. It can also be seen that response times in the traditional non-active solution, where multicast


D-21

140

Number of Transcodings in Tree

120

100

unloaded loaded 20% push upstream loaded 60% push upstream loaded 100% push upstream loaded 20% push downstream loaded 60% push downstream loaded 100% push downstream loaded 20% push to proxy loaded 60% push to proxy loaded 100% push to proxy

80

60

40

20

0 40

60

80

100

120

140

160


Fig. D.8: Number of transcodings in multicast tree for different fractions of overloaded nodes, for different strategy.

trees are set up for each version of the stream, are lying between the ones of the upstream and downstream strategy. Finally, in Figure D.10 the distribution of the average number of successive transcodings experienced by the stream on its way from the server to a client is shown. These results are averaged from approximately 40.000 simulation runs and from about 340.000 server-client pairs. About a quarter of all traffic in the tree does not undergo any transcoding, not even on the server, whereas about 60% will experience one transcoding. The probability that the stream undergoes two transcodings is about 16% and three or four successive transcodings occur in less than 1% of all cases. These results will be useful in the following subsection, where the quality resulting from successive transcodings is observed.

D.5.3

Perceived quality of transcoded voice streams

The multicasted voice streams may undergo one or more transformations to a lower bitrate codec. This way, the deterioration of the voice quality will increase with each new transcoding step. In order to get an idea of this accumulated deterioration of the quality, extensive measurements were conducted, showing the influence of the transcodings on the quality.

D-22

Publicatie D

400

350

Response Time (ms)

300

250

200

150

100 set−up upstream set−up downstream set−up upstream (non−active) 50 40

60

80

100

120

140

160


Fig. D.9: Response time as a function of the number of group members for upstream and downstream tree set-up procedure.

D.5.3.1

Measurements

To determine the perceived quality of transcoded voice streams, an objective speech quality assessment tool, called DSLA, is used. The operation of this Digital Speech Level Analyser is based on the Perceptual Analysis/Measurement System (PAMS) developed at British Telecom laboratories [24–26]. This algorithm evaluates the quality of a speech signal passing through a system under test by comparing the reference and the degraded signal. In this comparison, a psycho-acoustical model is used to take into account the human auditory system and error parameterisation to account for a variety of error classes. Based on the calculated difference, a prediction of the quality is made on the Absolute Category Rating scale [27], resulting in a Mean Opinion Score (MOS). This MOS expresses the opinion of an average public on the perceived quality, ranging from excellent (MOS=5), over good (4), fair (3) and poor (2) to bad (1). Optimal POTS quality or toll quality results in a MOS of about 4.0. The quality of speech signals is found to be acceptable for MOS values exceeding 3.0. The set-up used for the measurements is illustrated in Figure D.11. In the sender node, the reference speech signal generated by the DSLA is captured on the sound card, sampled at 8kHz, digitised to PCM16 format and encoded to the initial codec (CODEC1). The encoded speech is packetised into UDP/IP packets and sent to the receiver node. At the intermediate node, the speech fragment is transcoded to the resulting codec (CODEC2).


D-23

70

58.9%

Frequency Distribution (%)

60

50

40

30

24.1% 20

16.3%

10

0

0

1

2

0.7%

0.004%

3

4

Number of successive transcodings

Fig. D.10: Distribution of the number of successive transcodings between server and client. MOS value

reference signal Linux PC sound card conferencing software

sender node

DSLA Measurement Tool

transcoded signal

Linux PC router CODEC1

Transcoding Node

100BaseT ethernet

network interface card

Linux PC CODEC2 100BaseT ethernet

sound card conferencing software

receiver node

transcoding codec1 > codec2

Fig. D.11: Measurement set-up for perceived quality of transcoded voice.

At the receiver, the speech fragments are decoded and the resulting signal is captured by the DSLA. This measurement is repeated 25 times for each of the available transcodings, resulting in an averaged MOS value for each transcoding, shown in Figure D.12. D.5.3.2

Results

First, it can be seen that the best quality for voice streaming is achieved with the basic PCM16 encoding, resulting in a MOS of 4.04. When this signal is encoded with one of the four available codecs, the MOS degrades

D-24

Publicatie D

5

4.04 3.83 3.80 3.62 3.68 3.53 3.30 3.55 3.28 3.26

3

3.05

MOS

4

2

1 M

it PC

16b

0 tP bi

4bit

C

1

M

U -la

4b

w

7

9

it

72

8

G

72

6-

G

72

8

G72

Original codec

71

G

6-7

G72

G

G

16

-law

U 711

Resulting codec

Fig. D.12: MOS for transcoded voice streams.

to values of 3.8, 3.83, 3.62 and 3.3 for G.711, G.726-7, G.728 and G.729, respectively. It is clear that the bitrate reduction comes at the expense of signal quality degradation. When the signal is subsequently transcoded to another codec, the quality further degrades, depending on the resulting codec. From the measurements it can be seen that after one transcoding in the network, the resulting MOS values are still greater than 3.0. The total processing of the stream for this case includes the digitisation to PCM16, the encoding to the first codec and the transcoding to the second codec. On an extended set-up with multiple transcoding nodes, the influence of three and four successive transcodings was observed. In Figure D.13 it is shown that the speech quality resulting from three successive transcodings is still more or less acceptable with a MOS of 3.40 to 2.96. At the same time, the deterioration of a stream subject to four successive transcodings is shown to be too large to result in an acceptable quality, with a MOS of 2.83. However, the results from Figure D.10 learn that only 0.7% of all customer’s requests will result in three transcodings and only 0.004% of all requests will result in four transcodings.


D-25

4.5

PCM 16bit

4

G.711 u-law

MOS

G.726-7 4bit

G.726-7 4bit G.728

3.5

3

G.728

G.729 G.729 G.729

2.5

Fig. D.13: Degradation of MOS due to successive transcodings.

D.6

Conclusion

The design of an advanced multicast service providing media transcoding inside the network was presented. An active networking framework enabling flexible creation and introduction of advanced network services was discussed as well. This way, it was shown how attractive and advanced services can be built by enabling application functionality to be carried in packets or to reside in the network nodes. Both design and performance issues of the service were detailed. From the performance analysis it was seen that all required voice transcodings can be done in real-time in the network nodes. Furthermore, a substantial number of transcodings can be supported in parallel on a single node, except for the transcodings involving the G.729 codec. Additionally, the simulation results showed that the service based on active networking allows to have a reduction of the total bandwidth in the multicast tree between 5% and 10%. The number of transcodings in the multicast tree increases steadily with the number of group members. A number of different tree set-up strategies have been devised in order to support the advanced service. From the performance analysis for these strategies it is clear that setting up the tree in the upstream direction is the best option in terms of response time and complexity. From the three strategies to overcome resource scarcity in the nodes, the push upstream strategy performs best. When pushing transcodings upstream, the increase in used bandwidth in the tree is rather small in comparison with the other strategies. Furthermore, the number of transcodings in the tree decreases for the push upstream and push to proxy strategy, whereas it increases for the push downstream.

D-26

Publicatie D

It was also found that less than 20% of all traffic undergoes two or more transcodings. Moreover, chances are low (approximately 0.7%) that traffic will undergo three or four transformations. Finally, the degradation of the perceived quality of voice streams due to successive transcodings was demonstrated. When the number of successive transcodings performed on a voice stream is limited to three, the perceived quality stays acceptable. When four transcodings are performed, the MOS drops below 3.0 and quality becomes unacceptable. However, the probability that four successive transcodings occur is only 0.004%.

D.7

Acknowledgement

Part of this work has been funded by the Ghent University GOA project “PAN” (Programmable and Active Networks). The authors would also like to thank the reviewers for their valuable comments.

Referenties [1] D. Tennenhouse et al., A survey of active network research, IEEE Communications Mag., vol. 35, pp.80-86, Jan. 1997. [2] J.M. Smith, K.L. Calvert, S.L. Murphy, H.K. Orman , L.L. Peterson, L.L., Activating Networks: A Progress Report, IEEE Computer Mag., vol.32, pp.32-41, April 1999. [3] K.L. Calvert, S. Bhattacharjee, E. Zegura, J. Sterbenz, Directions in Active Networks, IEEE Communications Mag., vol. 36, pp.72-78, Oct. 1998. [4] K. Psounis, Active Networks: Applications, Security, Safety, and Architectures, IEEE Communications Surveys, http://www.comsoc.org/livepubs/surveys/public/1q99issue/psounis.html, First Quarter 1999. [5] A. Banchs, W. Effelsberg, C. Tschudin, V. Turau, Multicasting multimedia streams with active networks, IEEE Local Computer Networks Conference, LCN98, pp.150-159, Oct. 1998. [6] I. Kouvelas, V. Hardman, J. Crowcroft, Network adaptive continuousmedia applications through self organised transcoding, Proceedings of Network and Operating Systems Support for Digital Audio and Video (NOSSDAV), Jul. 1998.


D-27

[7] S. McCanne, V. Jacobson, M. Vetterli, Receiver-driven Layered Multicast, Proceedings of ACM SIGCOMM 1996, pp.117-130, Aug. 1996. [8] A. Nakao, L. Peterson, A. Bavier, Constructing End-to-End Paths for Playing Media Objects, IEEE OpenArch2001, Mar. 2001. [9] S. Wen, J. Griffioen, K.L. Calvert, Building Multicast Services from Unicast Forwarding and Ephemeral State, IEEE OpenArch2001, Mar. 2001. [10] I. Stoica, T.S. Eugene Ng, H. Zhang, REUNITE: A Recursive Unicast Approach to Multicast, IEEE Infocom2000, Mar. 2000. [11] D. Pendarakis, S. Shi, D. Verma, M. Waldvogel, ALMI: An Application Level Multicast Infrastructure, Proceedings of the 3rd USNIX Symposium on Internet Technologies and Systems (USITS01), pp.49-60, Mar. 2001. [12] S. Banerjee, B. Bhattacharjee, C. Kommareddy, Scalable Application Layer Multicast, Proceedings of ACM SIGCOMM 2002, Aug. 2002. [13] D. Wetherall, J. Guttag, D. Tennenhouse, ANTS: A toolkit for building and dynamically deploying network protocols, IEEE OpenArch98, Apr. 1998. [14] M.W. Hicks, P. Kakkar, J.T. Moore, C.A. Gunter, S. Nettles, PLAN: A Packet Language for Active Networks, Proceedings of International Conference on Functional Programming, pp.86-93, 1998. [15] M.W. Hicks, A.D. Keromytis, A Secure PLAN, Proceedings of the First International Working Conference on Active Networks (IWAN99), pp. 307-314, 1999. [16] S. Murphy, E. Lewis, R. Puga, R. Watson, R. Yee, Strong Security for Active Networks, Proceedings of IEEE OpenArch2001, 2001. [17] ITU-T, G.711: Pulse Code Modulation (PCM) of Voice Frequencies, ITU-T, 1972. [18] ITU-T, G.726: 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM), ITU-T, 1990. [19] ITU-T, G.727: 5-, 4-, 3-, and 2-bits Sample Embedded Adaptive Differential Pulse Code Modulation, ITU-T, 1990. [20] ITU-T, G.728: Coding of Speech at 16kbit/s Using Low-Delay Code Excited Linear Prediction, ITU-T, 1992.

D-28

Publicatie D

[21] ITU-T, G.729: Coding of Speech at 8kbit/s Using Conjugate Structure Algebraic-Code-Excited Linear-Prediction (CS-ACELP), ITU-T, 1996. [22] UCB/LBNL, Network Simulator, http://www.isi.edu/nsnam/ns.

ns,

[23] Georgia Tech Internetwork http://www.cc.gatech.edu/projects/gtitm/.

version

Topology

2,

1997.

Models,

[24] M.P. Hollier, M.O. Hawksford, D.R. Guard, Characterisation of Communications Systems Using a Speech-Like Test Stimulus, Journal of the Audio Engineering Society., Vol.41, No.12, 1993. [25] M.P. Hollier, M.O. Hawksford, D.R. Guard, Objective Perceptual Analysis: Comparing the audible performance of data reduction schemes, Presented to the 96th AES Convention in Amsterdam, Preprint No.3879, 1994. [26] ITU-T, P.56: Telephone transmission quality objective measuring apparatus, ITU-T, 1993. [27] ITU-T, P.800: Methods for subjective determination of transmission quality, ITU-T, 1996.

On the performance of Application Level Routing solutions Bart Duysburgh, Thijs Lambrecht, Filip De Turck, Bart Dhoedt, Piet Demeester

Elsevier Journal on Computer Communications, Submitted for publication

Abstract — Over the past years, the use of Overlay Networks and Application Level Routing (ALR) has been proposed. Overlay Networks consist of virtual node runtime environments executing on the application level of client nodes and interconnected by a virtual network. More specifically, for multicast services, content distribution networks, peer-to-peer networking and active networks, it provides a flexible and fast means to deploy new functionality or capabilities in the traditional network by adding an extra layer on top of the present infrastructure, without the need for changes in the underlying network infrastructure. However, traffic passing through the overlay nodes is copied between the user space and kernel space and is processed in the node runtime environment on the application level, giving rise to considerable processing overheads, and hence performance penalties. We investigate the performance of the Application Level Routing concept based on measurements and modeling of an experimental ALR node setup. The packet handling of this ALR node is representative for most hosts running an overlay based application. A general performance evaluation of the ALR node will be presented, based on the decomposition of the node architecture, the development and validation of mathematical models for the different components and measurements of the components and overall performance. Based on this approach generic conclusions on the performance of Application Level Routing are drawn, independent of the specific set-up used in the experiments.

E-2

Publicatie E

E.1

Introduction

The concept of Application Level Routing finds its origin in application level Overlay Networks which have been proposed in a multitude of situations over the past years. These overlay networks are realised through an extra layer of functionality on top of the traditional network infrastructure, providing a virtual network which interconnects a number of specific nodes with an alternative topology. In general, the overlay network consists of client hosts, running the virtual network’s node runtime environment, interconnected by tunnels based on either UDP or TCP connections. Traffic sent over such an overlay network is transported through the tunnels interconnecting the nodes and is processed in each of the runtime environments it traverses. More specifically, at the end of a tunnel the traffic is sent to the application level where routing decisions can be made in the node runtime environment. This concept is called Application Level Routing. An example of such an overlay network is shown in Figure E.1. The traffic that is sent between the overlay nodes A and C is transported through tunnels, which are set up between node A and B and node B and C. In node B, the traffic coming from the tunnel A-B is processed in the node runtime environment and forwarded along the tunnel B-C. Application

B Kernel

Overlay tunnel Overlay traffic Application

A Kernel Application Application

D

C

Kernel

Kernel

Overlay Node Runtime

Client Host

Fig. E.1: An example overlay network: the client hosts which are interconnected by the overlay network run an overlay node runtime environment at the application level. The virtual nodes of the overlay network are connected by overlay tunnels and traffic traversing an overlay node is processed and forwarded by the runtime environment. The overlay traffic between nodes A and C is processed in the node runtime environment of overlay node B.

On the performance of Application Level Routing solutions

E-3

The use of overlay networks has been suggested for various application areas, such as multicast, content distribution networks, peer-to-peer networking and active networks. In each of these fields, an overlay network provides a means for fast deployment of the envisaged service or application. Providing an additional layer hosting the application specific functionality avoids to change the underlying network infrastructure, since this additional ALR layer is typically installed in the user or application level of the infrastructure. End system or application level multicast [1–3] has been proposed in order to speed up the deployment of multicast services in the present network infrastructure. Multicast services have been a hot topic in network research for the past decade, but are still not available to a broad public and up till now multicast traffic is responsible for only three to five per cent of the total Internet traffic [4]. Using overlays, the session participants are connected via a virtual multicast tree, and the virtual tree is composed of unicast connections between the end hosts, which provide the packet replication functionality. This way, multicast functionality can be introduced in the network without changing the traditional infrastructure. In Content Distribution Networks (CDN) [5–7], the distribution of data is made more efficient by storing the content not only on a central server but also on a number of surrogate servers that each store a subset of the content. These surrogate servers provide the content closer to the potential clients, reducing latency when data is requested from the CDN. To facilitate the synchronisation of the replicas on the surrogate servers with the original content on the central server, an overlay network is used. This way, updates of the content can be multicast or broadcast to all surrogate servers through the overlay network. Peer-to-peer networking [8–10] is based on the large scale replication of content and sharing of resources over a large number of peering hosts. This distribution of content over a collection of peers offers a higher degree of resilience and availability, making services more reliable and robust. For the communication between the peer hosts and the distribution and transport of data over the peer-to-peer network, an overlay network is used. The Active Networking concept [11–14] allows to carry additional code or functionality in network packets and to execute that code in active nodes in the network. Therefore, active node runtime environments are provided on certain nodes where the code can be extracted from the packets to be executed. These active nodes may be placed either on client nodes or on network nodes. Apart from the fast way to introduce active capabilities in the traditional infrastructure, ALR also allows to gradually deploy active networking functionality in the network nodes and to have a restricted

E-4

Publicatie E

number of active nodes in the network. Due to the nonconventional handling of traffic in Application Level Routing, the concept gives rise to certain processing overheads, possibly leading to performance issues. In contrast to the normal network traffic, overlay traffic is processed at the application level not only in the endpoints of the connection but also in runtime environments of intermediate nodes. There, the traffic is sent to the virtual node runtime environment on the application level and after processing it is forwarded. In comparison with the traditional data path in a router, which is optimised to forward large numbers of packets as fast as possible and in the most efficient way, this new data path is not at all optimal. It is therefore clear that this alternative handling of the packets, which comprises the copy operations between user and kernel space and the additional processing at the application level, will put a considerable strain on the performance of an ALR node. Performance analyses in most of the ALR research efforts are restricted to the analysis of application performance. More specifically, routing heuristics, the optimal balance of traffic on the overlay network, the number of tunnels and the overhead created by the overlay are investigated. The node performance in an ALR overlay is only handled very briefly [15]. The performance of Linux packet handling and the problem of receive livelock has been discussed before [16]. As a solution for this problem the mechanism of polling has been proposed, which has been applied in the Click Modular Router [17]. Recently, the Linux kernel has been modified to support polling as well. However, for the time being most systems are still relying on the interrupt driven approach. The performance of the ANTS platform was briefly discussed based on some throughput measurements [18]. In this paper, the performance of an ALR node is analysed based on an experimental node set-up, which is representative for most client hosts running an ALR based application. The performance analysis is based on a detailed study of the packet handling process in an ALR node as well as on mathematical models to predict the behaviour of important components of the ALR node. A model predicting the throughput of the node is constructed, taking into account the packet handling process and the packet processing times. An additional model takes into account the effect of Java’s Garbage Collector and the UDP receive queue to predict packet loss in a complex ALR node set-up. Additionally, measurements on the experimental set-up allow to validate the constructed models and provide numerical data indicating the performance of the set-up. The use of mathematical models allows to have a generic approach, which is also applicable to different ALR node configurations, leading to general conclusions on the performance of ALR nodes.


E-5

The remainder of this paper is structured as follows. Section 2 introduces the general architecture of an ALR node. It also describes an experimental ALR node set-up, which is used for the performance measurements. This set-up is based on a Linux router extended with a Java based Active Networking node runtime environment. In Section 3, an analysis is made of the basic packet forwarding process in the Linux kernel and a model to calculate the throughput performance is constructed. This analysis is representative for the packet forwarding process in the majority of the client host operating systems. In Section 4, a Java based packet relay node is presented, allowing to analyse the performance of a basic ALR node. The influence of both the Linux packet handling and the Java platform are taken into account. Java is chosen because of its popularity and widespread use for the implementation of networking applications. In Section 5, the performance of an ALR node based on an Active Networking node runtime environment is detailed. In this relatively complex set-up, the complex runtime environment will influence the performance as well as the underlying Linux and Java technology. In Section 6, the performance of this node is also analysed in the case of multicast forwarding. Section 7 summarises the main results and conclusions.

E.2

General architecture of an Application Level Routing node

In this section, we discuss the architecture of a general ALR node and the main path followed by packets that traverse such node. Additionally, a brief introduction to the performance analysis of Sections 3 to 6 is given along with the main performance metrics and a description of the experimental set-up used for the performance measurements. In Figure E.2, the architecture of a general Application Level Routing node is illustrated. A virtual node runtime environment from the overlay network is running as an application. The communication between overlay nodes is based on overlay tunnels, which are terminated by dedicated sockets in the runtime environment. When packets arrive at an ALR node, they are first processed by the node’s operating system kernel, which analyses the packet headers and passes the packet through the protocol stack. The packet is then copied from kernel space to user space and is sent to the runtime via the listening socket for the tunnel. After the packet is processed, it is forwarded to its destination via one of the sockets. The packet is subsequently copied from user space to kernel space and the necessary headers are added while traversing the protocol stack. Finally, the kernel puts the packet on the network.

E-6

Publicatie E

Node Runtime Environment (Application process)

socket

socket

User space Kernel space

TCP

IN

UDP

TCP

UDP

IP

IP

Protocol stack

Protocol stack

OUT

Fig. E.2: General architecture of an Application Level Routing node: when a client host is part of an overlay network it runs an overlay node runtime environment for that overlay in the application level. Overlay traffic arrives through a tunnel, is processed by the protocol stack and is passed to the runtime environment via the corresponding socket of the tunnel. The traffic stream can either be terminated at a node or it can be forwarded to another destination.

It is obvious that this scheme, involving multiple packet copies between kernel space and user space, will strongly influence the performance of the ALR node. Consequently, ALR brings extra flexibility and extra functionality in the infrastructure at the expense of a reduced performance. In the next sections, the performance of an ALR node will be analysed based on the following characteristics. The main characteristic that will be observed is the throughput of the node, indicating the number of packets that can be forwarded per second as a function of the input packet rate. Closely related to the node throughput is the amount of packet loss in the node, which will increase dramatically when the load on the node reaches a certain threshold. When reaching this threshold, the node will not be able to handle all arriving packets and consequently some will be dropped. A third characteristic is the processing time per packet in the node. The performance of the ALR node is analysed through two approaches. On the one hand, a mathematical model is constructed based on an analysis of the packet handling process of the ALR node, allowing to calculate the throughput of the node as a function of the packet arrival rate and the packet processing times. On the other hand, the throughput is actually measured on an experimental ALR node set-up and also the time needed for different parts of the packet processing in the ALR node is characterised. These measurements allow to verify the model and additionally provide actual


E-7

values indicating the performance of the specific experimental set-up.

soft-state cache extension

Active Node Runtime (ANTS)

capsule execution sockets

JAVA User space Kernel space

UDP IN

UDP

IP

IP

OUT

Linux router

Fig. E.3: Experimental Application Level Routing node set-up based on a Linux router extended with a Java based implementation of an Active Node runtime (ANTS).

The experimental ALR node set-up used for the measurements is presented in Figure E.3. This set-up consists of a PC based Linux router, running Debian Linux with kernel version 2.2.18. The PC has a 450MHz AMD-K6 CPU, 192MB RAM and 5 DLINK DFE-530 network interface cards using the Via-Rhine network driver. On this system, the Java based ANTS 1.3 (Active Network Transport System [19]) active node runtime environment is running and the Blackdown Java HotSpot Client virtual machine from the Java 2 Standard Edition version 1.3.1 is used. The communication between the ANTS runtime environments is based on UDP tunnels. Therefore, the active packets carrying pieces of code in addition to the usual payload are encapsulated in UDP packets before being sent on the network. When they arrive at an Active Node, the packets are processed by the network protocol stack and are passed on to the application level through the network sockets in the ANTS runtime. When a packet is read from a socket, the embedded code is loaded into the runtime and executed. During this execution, a transformation of the payload can be performed, a decision can be made on the route to be taken, the packet can be replicated or it can just be sent on its way again. When the packet needs to be forwarded, it is encapsulated in a UDP packet again before it is sent to the next hop. The experimental set-up is composed of three distinctive parts - the Linux router, the Java virtual machine and the ANTS node runtime - and the analysis is split up accordingly over the following sections. In Section 3, the Linux packet handling process is analysed. Section 4 focuses on the performance of a Java based relay node and the ANTS based ALR node

E-8

Publicatie E

set-up is discussed in Sections 5 and 6.

E.3

Packet handling in a PC based Linux router

In this section, the basic packet handling in the Linux kernel is analysed. Based on the kernel code [20, 21] a description of the main packet handling procedures is given and the processing times for these procedures are measured on the experimental set-up. Furthermore, a mathematical model is created, allowing to predict the performance of this system, and the model is validated by means of additional measurements on the set-up.

E.3.1

Packet processing in the Linux 2.2.18 kernel

In general, packet processing can be divided into three main procedures: sending, receiving and forwarding packets. Sending a packet is the simplest procedure: when an application sends a new packet to a socket, the socket performs a number of checks and hands the packet to the protocol stack. The different headers are added to the payload, the packet is put in the output queue of the sending device and the device is notified that it has traffic to send. Finally, the network interface puts the packet on the wire. On the other hand, receiving and forwarding packets are more complex procedures. When a packet arrives on the network interface, the hardware takes it from the wire, puts it in a queue on the device and generates an Interrupt Request (IRQ) for the operating system, indicating that a new message has arrived. Triggered by this IRQ, the operating system interrupts the current process and starts handling the new message. Because an actual process is interrupted, handling this packet should take as little time as possible. Therefore, the interrupt handling is split into a top-half and a bottom-half part. When an interrupt is issued, the critical operations are taken care of in the top-half part. In this part, the packet’s header information is copied to the kernel memory, a reference to the new message is added to the backlog queue in the kernel memory and a flag is set to execute the bottom-half. The control is returned to the interrupted process and when judged appropriate by the scheduler, the bottom-half operations are executed. During this execution the packet is run through the network protocol stack up to application level or it is forwarded to the next hop. The kernel procedures corresponding to the different steps of the packet handling process are shown in Figure E.4. The netdev rx() procedure is part of the network interface driver and it is called from the packet arrival interrupt handler. This procedure performs the top-half handling of the newly


E-9

Application Process (node runtime) socket

User space Kernel space

net_bh_recv()

UDP IP IN

socket

udp_sendmsg()

UDP net_bh_fw()

IP OUT

netdev_rx()

Fig. E.4: Overview of kernel procedures for packet handling: the arrival of a new packet on an interface triggers an IRQ and subsequently the execution of the netdev rx() procedure. A packet that has not reached its destination yet is forwarded by the net bh fw() procedure. Otherwise, it is passed to the application level by the net bh recv() procedure. A new UDP packet can be sent by means of the udp sendmsg() procedure.

arrived packet. The bottom-half handling is done in the net bh() procedure, which will either deliver the packet to an application or forward it to the next hop. To distinguish between these two separate functionalities, we refer to this procedure as net bh recv() or net bh fw(), according to the receiving or forwarding functionality, respectively. Finally, when a new UDP packet is written to a socket by an application process, the udp sendmsg() procedure is called, adding the necessary headers and sending the packet to the next hop. The processing times of each of these procedures have been measured on the experimental set-up for streams with various packet lengths. For these measurements, the Time Stamp Counter Register is used, which is incremented every clock cycle. To read the content from the register a dedicated assembler instruction is called from a C-macro in the kernel code. This takes on average 15.8 clock cycles or 35 nanoseconds on the set-up. For different packet lengths, the processing times are measured ten times for a stream of 10000 packets. The averaged results are shown in Figure E.5. The time needed for the top-half processing of a packet (netdev rx()) appears to be independent of the packet length. The reason for this is the zero-copy scheme used in the Via-Rhine network device driver. In the tophalf handling, only the header info and a reference to the packet are copied to the kernel. The actual packet is stored in a memory location on the interface card. Only in the bottom-half processing of the packet, the complete

E-10

Publicatie E

Processing Times in Linux Kernel 50 netdev_rx() net_bh_fw() net_bh_recv() udp_sendmsg()

45

40

Processing Time [µs]

35

30

25

20

15

10

5

0

0

500

1000

1500

Packet Length [bytes]

Fig. E.5: Measured processing times for the Linux kernel packet handling procedures illustrated in Figure E.4.

packet is copied. When the packet is forwarded (net bh fw()), the packet and its headers are copied to a memory location on the outgoing interface card. When on the contrary the packet is delivered to a local application (net bh recv()), it is copied to a memory location in user space. In both cases, a single copy operation is performed and the processing time depends on the packet length. The procedure to send a UDP packet (udp sendmsg()) requires two copy operations, a first from user space to kernel space and a second from kernel space to the network interface card. Consequently, the processing time in this case is larger than for the other procedures and it also increases with the packet length.

E.3.2

Mathematical model

Based on the analysis above, the processing time for a newly arrived packet can be split into two parts: a time τIRQ is needed to handle the top-half handling after the interrupt and a time τ0 for the execution of the bottomhalf procedure. However, since each new arrival of a packet will cause the current process to be interrupted by the top-half execution, the bottom-half procedure may be interrupted as well. Therefore, the actual time spent on the bottom-half procedure execution will be larger than τ0 . When new packets are arriving during the minimal processing time τ0 , interrupts are generated by these packets and their top-half interrupt hand-

E-11


lers are executed. Assuming that k0 arrivals occur during the interval τ0 and that handling the top-half of the interrupt takes on average a time τIRQ , the packet that is being processed suffers an additional delay of k0 .τIRQ . When in turn new packets arrive during this additional time, again an extra delay is caused to the packet processing. This mechanism is illustrated in Figure E.6. τ τ0

τ1 = k0 .τIRQ

k0 packet arrivals

k1

τ2 = k1 .τIRQ τ3 = k2 .τIRQ

k2

Fig. E.6: A packet’s basic bottom-half processing time τ0 is interrupted by arriving packets and their subsequent top-half handling, which takes a time τIRQ . Consequently, the total time needed for a packet’s bottom-half handling depends on the number of packets arriving during its processing.

In the end, a packet experiences on average a total bottom-half processing time τ , depending on the number of packets arrived during the processing. An expression for this average actual processing time τ experienced by a packet can now be derived. The minimal processing time will be τ0 . With the assumption of a Poisson arrival process with an average packet arrival rate λ, the average number of new packets arriving during the total bottom-half handling is λ.τ . Then the following expression holds for the total bottom-half processing time. τ

=

∞

τk

(E.1)

k=0

= τ0 + (λ.τ ).τIRQ

(E.2)

Finally, an expression for τ and the packet service rate µ = τ −1 can be derived: τ=

1 τ0 = . 1 − λ.τIRQ µ

(E.3)

Based on the foregoing discussion, the Linux packet handling process can be modeled as follows. Each packet arriving on a network interface will trigger an IRQ and the subsequent execution of the top-half handling procedure. This procedure places the packet in the kernel’s backlog queue, where it will wait until the system has time to handle the bottom-half

E-12

Publicatie E

processing. In the bottom-half procedure, the packet is then either passed through the protocol stack and delivered to an application or it is forwarded towards the next hop. This procedure will take an average time τ . The packet handling process can then be modeled as a basic M/M/1/N queueing system, which is determined by a Poisson arrival process with average rate λ, exponential service times and an average service rate µ, and a finite input queue for N packets representing the backlog queue. The probabilities Pk that the queue contains k packets can then be written as Pk =

1 − λ/µ λ ( )k 1 − (λ/µ)N +1 µ

, k = 0, ..., N.

(E.4)

Consequently, the utilisation U indicating the average percentage of time the server is busy, can be determined as U = 1 − P0 =

(λ/µ)[1 − (λ/µ)N ] , 1 − (λ/µ)N +1

(E.5)

and the average throughput X is finally found by X = U.µ =

λ[1 − (λ/µ)N ] . 1 − (λ/µ)N +1

(E.6)

This expression for X, together with the one deduced for µ, allows to calculate the throughput as a function of the packet arrival rate λ and the processing times τ0 and τIRQ .

E.3.3

Validation of the model

To verify the model, throughput measurements were performed on the 450MHz Linux system using a SmartBits [22] network performance analysis system, which allows to inject specific network traffic and to analyse captured packet streams. For different packet length settings, the output packet rate of the node was measured as a function of the input packet rate. For each value of the input rate, the average output rate was determined during an interval of 60 seconds. These measurements were repeated 10 times for identical settings, allowing to calculate the average throughput values shown in the figures. This procedure was followed for all throughput measurements discussed in this document. In Figure E.7, the outgoing packet rate is shown as a function of the arrival packet rate for different packet lengths. It is clear that all packets are forwarded without loss until the arrival packet rate reaches a packet length dependent threshold. At this point, the interrupts generated by arriving packets and the subsequent top-half handling procedures are so


Throughput Linux Node

4

5.5

E-13

x 10

64 bytes→

5

Output Rate [pckts/s]

4.5 128 bytes→

4


3.5 330 bytes→ 3

2.5

2

2

2.5

3

3.5

4

4.5

Input Rate [pckts/s]

5

5.5

6

6.5 4

x 10

Fig. E.7: Throughput measurement on a 450MHz Debian Linux router.

numerous that the queue gets full and new packets have to be dropped. When the arrival rate increases further, the system spends ever more time handling the top-half procedures and less time is left to handle the bottomhalf processing. This way, a situation of receive livelock, as reported upon in [16], is reached, where all processing time is spent handling the tophalfs and no packets are actually popped from the queue and delivered or forwarded. To overcome this problem, the mechanism of polling has been proposed. In this new scheme, no interrupts are generated for new packets that arrive, but the kernel polls the network interface card at regular times to check for new packets. Polling functionality has been implemented in the Click Modular Router [17] as well as in the most recent versions of the Linux kernel. Based on the throughput measurements and the model from Section 3.2 (Equations (3) and (6)) values for the packet processing times τ0 and τIRQ can be derived. These parameters are here refered to as τ0lin and lin , indicating that the configuration under study is limited to the Linux τIRQ forwarding functionality. In addition, both parameters can also be measured separately and the results from both approaches can be compared, in order to validate the model. The throughput at the point that the first packets are dropped is called the maximum lossless throughput Xmax . At that point the processing unit is 100% loaded with the packet handling procedures and consequently λ.τ = 1.

E-14

Publicatie E

Since λ = Xmax at that point, it is obvious that 1 lin = τ0lin + τIRQ Xmax

(E.7)

which is consistent with Xmax .τ = Xmax .

τ0lin =1 lin 1 − Xmax .τIRQ

(E.8)

This approach gives an expression that allows to calculate the sum of the lin based on experimental data for Xmax . processing times τ0lin and τIRQ Estimation of processing time τlin+τlin 0

IRQ

35 net_bh_fw() netdev_rx() 1/Xmax 30

Processing times [µs]

25

20

15

10

5

0 64

128

192

256

320

384

448

512

Packet length [bytes]

Fig. E.8: Comparison of the results of two approaches to estimate the value of lin . Based on the measurements of Figure E.7 and the model τ0lin + τIRQ a first estimate is given by 1/Xmax . A second estimate is given by the sum of the measured values of netdev rx() and net bh fw(), shown in Figure E.5.

Alternatively, the measured values presented in Section 3.1 for the prolin cedures netdev rx() and net bh fw() correspond to the parameters τIRQ lin and τ0 , respectively. The sum of these measured values gives a second lin + τ0lin . estimation for τIRQ lin obtained from both approaches In Figure E.8, the values for τ0lin + τIRQ are compared. It is logical that the summed value of netdev rx() and −1 . The difference in slope of the net bh fw() is less than the value of Xmax two curves can be explained by the presence of concurrent kernel processes,


E-15

related to the general operation of the system, in the throughput measurements. These additional processes imply that the processor is not entirely devoted to processing packets, and hence λ.τ < 1.

E.4

Performance of packet handling in a Java based relay node

In this section, the model from Section 3.2 (Equations (3) and (6)) is used to analyse the performance of a basic ALR node. The simplest ALR node set-up consists of a relay node, for which the functionality is limited to receiving packets from a previous node and sending them towards the next node without any other processing. More specifically, the performance of a Java based relay node for UDP packets is analysed. For this specific set-up, the model parameters are refered to as τ0jav and jav τIRQ . In contrast to previous section, τ0jav represents the time needed to process a relay packet in the relay node. This includes popping the packet from the backlog queue, handling the bottom-half processing, passing the packet to the application level, processing it in the relay node runtime envijav represents ronment and sending it on to its destination. Additionally, τIRQ the time that the above mentioned packet handling procedure is interrupted by higher priority tasks. Since a considerable part of the packet processing takes place at the application level, it will not solely be interrupted by the IRQs from newly arrived packets, but also by other kernel processes and even application level processes with sufficient priority competing for the CPU. The set-up under study consists of two nodes with either a Java based sending or receiving application and a relay node in between. On this set-up, throughput measurements have been performed and the results for various packet lengths are shown in Figure E.9. In the analysis of this specific set-up, a dual approach is taken. At the jav can be estimated by fitting one hand, the processing times τ0jav and τIRQ the model from Equations (3) and (6) to the results of the throughput measurements in Figure E.9. The values obtained from this approach are shown in Table E.1 and the fitted curves of the model are shown by the dashed lines in Figure E.9. On the other hand, values for τ0jav can also be estimated from measurements on the relay node set-up. The processing time τ0jav can be split up in three components that can be measured separately. The first part is the time needed to pop a packet from the backlog queue, process it through the protocol stack and pass it on to the application level. This corresponds to the processing done in the net bh recv() procedure. The second part

E-16

Publicatie E

Throughput Java Relay node 12000 measured model

128 bytes→

10000 512 bytes→


1024 bytes→ 8000 1408 bytes→

6000

4000

2000

0

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8


2 4

x 10

Fig. E.9: Throughput measurement for Java relay node.

TABEL E.1: Fitted values from relay node model. Packet length τ0jav jav τIRQ

128 bytes 59.6 µs 29.4 µs

512 bytes 65.3 µs 34.4 µs

1024 bytes 81.6 µs 37.0 µs

1408 bytes 87.0 µs 40.0 µs

consists of the time spent in the relay node runtime environment. The third part is the time needed to process a new UDP packet through the protocol stack and to send it on the network, which corresponds to the processing of the udp sndmesg() procedure. The processing times for the net bh recv() and udp sndmesg() procedures have already been measured in Section 3.1 and are presented in Figure E.4. The processing time in the relay node has been measured separately by introducing additional timestamps. A linear fit was made for the measured values of these three components and in Figure E.10 the sum of these linear fits is shown. The estimated value for τ0jav based on the first approach is shown in Figure E.10 as well. jav clearly exceeds From the results in Table E.1, it can be seen that τIRQ lin τ0 . This is obvious since the packet processing in this case can be interrupted by other processes apart from the interrupts generated by newly arrive packets. Additionally, in contrast to the set-up of Section 3, the interrupts are not purely related to packet arrivals and may occur at any jav lin , τIRQ is moment during the packet processing. Consequently, unlike τIRQ


E-17

Decomposition and estimation of Java Relay node processing time τjav 0

100

90

send UDP [udp_sendmsg()] Java relay processing time receive UDP [net_bh_recv()]

jav τo

80


70

60

50

40

30

20

10

0 128

256

384

512

640

768

896

1024

1152

1280

1408


Fig. E.10: Estimation of the Java Relay packet processing time through two approaches. Fitting the model from Section 3.2 to the throughput measurement results of Figure E.9 gives a first estimate for the parameter τ0jav . Measuring the three components of the total processing time separately and summing the results gives a second estimate.

dependent on the packet length. From Figure E.10, it is clear that both approaches give similar values, indicating that the model is sufficiently accurate to yield a good approximation for the behaviour of this simple ALR node.

E.5

Packet handling in an ANTS based Application Level Routing node

The model from Section 3.2 has been evaluated for both Linux packet handling and packet forwarding in a basic Java based ALR node in the previous sections and it is now used for a more complex ALR node. This node consists of the Java based ANTS active networking node runtime environment on a Linux node. This set-up is very similar to the relay node, except for the amount of processing done in the active node runtime environment. The active packets carry their own forwarding routine, which is executed in the runtime environment of each active node that is traversed. For the throughput measurements, the forwarding routine only specifies to forward the packet to the next node without any additional processing. The me-

E-18

Publicatie E

asurements were done in a situation of steady state, implying that the additional code needed in the active nodes is already in place and that no overhead traffic from the active overlay occurs. In Figure E.11, the results of the throughput measurements on this node are shown. Throughput Java/ANTS node 4000 throughput 3500

3000



2500

1024 bytes→ 1408 bytes→ 2000

1500

1000

500

0

0

1000

2000

3000

4000

5000

6000


Fig. E.11: Throughput measurement for Java based ANTS node.

Although the basic functionality of the ALR node is again that of a relay node and therefore a good fit is expected with the proposed model, the results show that packet loss occurs already for relatively low input rates in the ascending part of the throughput curve. In addition, the amount of packet loss is found to be independent from the packet length in the ascending part and it grows with increasing input rates. From these observations, it seems that a considerable amount of processing time is consumed by another process apart from the already mentioned packet handling processes. This way, the total amount of time spent on the packet handling procedures is reduced and this reduction gradually grows with increasing input rates. Therefore, it can be concluded that the additional process is related to the packet handling process. This assumption is confirmed by an analysis of the ANTS code and a number of measurements, indicating that the Garbage Collector thread of the Java Virtual Machine is explicitely called from the code on a regular basis. The influence of the Garbage Collector processing is verified by repeating the throughput measurements of Figure E.11 with a modified ANTS node runtime environment. With the calls to the Garbage Collector removed from the ANTS code, the results shown in Figure E.12 are found.


E-19

This time, there is no packet loss for the lower input rates and the results correspond well to the model from Section 3.2. Throughput Java/ANTS node without Garbage Collector 4000 measured model 128 bytes→

3500

512 bytes→


3000


2500

2000

1500

1000

500

0

0

1000

2000

3000

4000

5000

6000


Fig. E.12: Throughput measurement for Java based ANTS node without Garbage Collector.

From additional measurements, it is observed that in the standard ANTS node the Garbage Collector thread is called about 1 to 4 times per second and that the procedures consume about 12% to 25% of the CPU time for input rates ranging from 850 to 4500 packets per second. It is clear that initially the Garbage Collector calls are the cause for the extra packet loss. However, the reduction of the processing time available for packet handling procedures due to the Garbage Collector will only result in a reduction of the maximum lossless throughput Xmax and will not in itself cause packets to be dropped. Consequently, another mechanism has to be at work in conjunction with the Garbage Collector calls. This other mechanism is described below, based on an analysis of the Linux kernel code. Firstly, a packet arriving on a node and destined for an application is not passed directly to that application process. Instead, after the packet is processed by the protocol stack, it is copied to the receive queue of the listening socket in the application. The packets in the receive queue are then processed sequentially by the ANTS node runtime environment. Secondly, the packet processing in the ANTS runtime environment is interrupted for some of the packets in the queue when the Garbage Collector thread is called. Consequently, the currently processed packet suffers an additional delay. Thirdly, the additional delay suffered by a minority of the processed

E-20

Publicatie E

packets is very large in comparison to the normal processing time of a packet. Consequently, for sufficiently high packet input rates the queue will run out of space and newly arriving packets have to be dropped. In order to show that this mechanism causes packet loss for relatively low input packet rates, this system is modeled and analysed using the queueing system illustrated in Figure E.13. service rate µ1 1−p

arrival rate λ

µ2 N

p

Fig. E.13: Model for packet handling in a socket receive queue with a fraction p of the packet processing times interrupted by the Garbage Collector.

In this model, the finite queue for N packets represents the socket receive queue. Due to the Garbage Collector’s interrupts, not all packets in the queue are experiencing the same processing time. The Garbage Collector calls are generated at a rate γ and with λ the average arrival rate of the packets, about a fraction p = γ/λ of the packets is interrupted and suffers an additional delay. With γ λ, this fraction p will be very small and the majority of the packets corresponding to the fraction 1 − p is processed without interrupts at the normal processing rate µ1 . Consequently, only a minority of the packets is processed at a rate µ2 µ1 . It is important to see that the packets are processed sequentially in order of arrival and that the system will process only one packet at a time. To analyse this model, the state transition diagram shown in Figure E.14 is used. The state of the system is determined by two parameters: the number of packets k in the queue and the type i of the packet that is at the head of the queue and will be processed next. If the next packet belongs to the fraction 1 − p, which is processed at a rate µ1 , it is of type 1. Otherwise, the next packet is of type 2 and is processed at a rate µ2 . The state of the system is then identified as ki . It is clear that when a new packet arrives in the system, a transition will be made from state ki to (k + 1)i , since the same packet remains at the head of the queue. These transitions occur at a rate λ. Packets are taken from the queue at a rate µi to be processed and a transition is made from state ki to (k − 1)j , with j the type of the new packet that comes at the

E-21


λ (1-p)λ µ1

0

λ

21

11 (1-p)µ1

...

(1-p)µ1

λ

λ

k1

(1-p)µ1

...

(1-p)µ1

λ

N1

(1-p)µ1

(1-p)µ2

(1-p)µ2

(1-p)µ2

(1-p)µ2

(1-p)µ2

pµ1

pµ1

pµ1

pµ1

pµ1

pλ µ2

λ

12

λ

22 pµ2

pµ2

...

λ

λ pµ2

k2

pµ2

...

λ pµ2

N2

Fig. E.14: State transition diagram for the socket receive queue packet handling model.

head of the queue. This packet will be of type 1 with a probability 1 − p and of type 2 with a probability p. In addition to the states ki there is also the state 0, where no packets are in the queue and consequently no packet is at the head of the queue. The packets arriving at a rate λ have probabilities 1 − p and p to become a packet of type 1 and 2, respectively. The probabilities P0 and Pk i that the system is in a state 0 or ki can be found by expressing the system’s flow equilibrium equations. More specifically, the flow-in = flow-out principle can be expressed for the different states. For the states 11 and 12 , following expressions are found. λ(1 − p)P0 − (µ1 + λ)P1 1 + µ1 (1 − p)P2 1 + µ2 (1 − p)P2 2 = 0 λpP0 − (µ2 + λ)P1 2 + µ1 pP2 1 + µ2 pP2 2 = 0

(E.9)

(E.10)

More general equations can be derived for the states k1 and k2 : λP(k−1) 1 − (µ1 + λ)Pk 1 + µ1 (1 − p)P(k+1) 1 + µ2 (1 − p)P(k+1) 2 = 0 (E.11) λP(k−1) 2 − (µ2 + λ)Pk 2 + µ1 pP(k+1) 1 + µ2 pP(k+1) 2 = 0

(E.12)

with 2 ≤ k ≤ N − 1. Finally, the expressions below hold for the states N1 and N2 . λP(N −1) 1 − µ1 PN 1 = 0

(E.13)

λP(N −1) 2 − µ2 PN 2 = 0

(E.14)

E-22

Publicatie E

Since the system has to be in one of the 2N + 1 states at any moment in time, also the following equality holds. P0 +

N

(Pk 1 + Pk 2 ) = 1

(E.15)

k=1

This gives 2N + 1 expressions for the 2N + 1 states, allowing to calculate the individual probabilities for each of the states, given the system parameters N , λ, µ1 , µ2 and p. Regarding the discussion above, the most interesting characteristic of the queueing system is the amount of packet loss, which can be determined by following expression: Ploss = PN 1 + PN 2 .

(E.16)

The MATLAB environment was used to solve the linear system for different values of the system parameters and to determine the packet loss. Packet Loss in UDP socket receive queue 22

20

18

Packet Loss [%]

16

14

12

10

8

6 derived from throughput measurements model [128 bytes] model [512 bytes] model [1024 bytes] model [1408 bytes]

4

2 500

1000

1500

2000

2500

3000

3500


Fig. E.15: Packet loss generated in a UDP socket receive queue. A comparison is made between the packet loss values obtained from the throughput measurements in Figure E.11 and the values calculated with the model from Equations (9)-(16).

In Figure E.15, the packet loss values calculated from the model are compared to the measured values. These measured values are deduced from the results shown in Figure E.11. As indicated before, the measured packet loss for low input rate values is independent from the packet length. For


E-23

the packet loss calculation from the model, following parameter values are used. In the Linux kernel, the UDP receive queue has a fixed length of 65536 bytes and since for each packet stored in the queue 1552 bytes are allocated regardless of the packet length, only 42 packets can be stored, so N = 42. The rate µ1 for packet processing that is not interrupted by the Garbage Collector is derived from the measured processing times in the ANTS node. In Figure E.16, the processing time needed to send a UDP packet and to process a packet in the ANTS runtime are shown. The former was already determined in Section 3.1 as udp sendmsg() and the latter has been measured on the ANTS based set-up. Inverting the sum of these two processing times gives the values for µ1 . Values of 5000 pckts/s, 4450 pckts/s, 4000 pckts/s and 3570 pckts/s are found for packet lengths of 128 bytes, 512 bytes, 1024 bytes and 1408 bytes, respectively. From measurements it is found that the Garbage Collector processing takes on average 0.1 seconds. Consequently, µ2 is set to 10 pckts/s. Finally, the fraction p of packet processings that are interrupted depends both on the rate at which Garbage Collector interrupts are generated and on the packet arrival rate. Based on the Garbage Collector measurements, a linear approximation is made for the relation between p and λ, which is given by: p = (1.975 − 0.00035λ)10−3

(E.17)

With these parameter values, Ploss is calculated for λ ranging from 500 to 3500 pckts/s. It is clear from Figure E.15 that for this range, where packet loss is only generated in the UDP receive queue, the calculated values are matching well with their measured counterparts. Consequently, it is clear that indeed the Garbage Collector calls in conjunction with the UDP receive queue system causes the packet loss for relatively low input rates. To conclude, the results of the throughput measurements without Garbage Collection shown in Figure E.12 are analysed with the same dual approach as in Section 4. This time the parameters of the model from Section ant . A first estimation for the values of 3.2 are refered to as τ0ant and τIRQ these parameters is found by fitting the model from Equations (3) and (6) to the results of the throughput measurements. These estimates are shown in Table E.2. TABEL E.2: Fitted values from ANTS node model. Packet length τ0ant ant τIRQ

128 bytes 232.0 µs 47.0 µs

512 bytes 253.0 µs 51.0 µs

1024 bytes 279.0 µs 59.0 µs

1408 bytes 288.0 µs 71.0 µs

E-24

Publicatie E

A second estimation for τ0ant can be found from measurements on the set-up. After all, the processing time τ0ant can be split up in three parts which can be measured separately. Analogous to Section 4, two of these parts are represented by the measured processing times for the procedures net bh recv() and udp sndmesg(). The third part is the time needed to process a packet in the ANTS node runtime environment, which was measured on the set-up using additional timestamps in the ANTS code. In Figure E.16 the linear fits of the measured values for the three components are summed and compared to the estimated values for τ0ant from the first approach.

Decomposition and estimation of ANTS node processing time τant 0

350 send UDP [udp_sendmsg()] ANTS processing time receive UDP [net_bh_recv()] 300

ant τo


250

200

150

100

50

0 128

256

384

512

640

768

896

1024

1152

1280

1408


Fig. E.16: Estimation of the ANTS node packet processing time through two approaches. Fitting the model from Section 3.2 to the throughput measurement results of Figure E.12 gives a first estimate for the parameter τ0ant . Measuring the three components of the total processing time separately and summing the results gives a second estimate.

From the results in Table E.2 and Figure E.16, the same conclusions can be drawn as in Section 4. For the same reasons discussed in Section 4, ant again are considerably larger than the values the estimated values of τIRQ lin ant for τIRQ . Additionally, both approaches to estimate the values for τIRQ give similar values, showing that the model from Section 3.2 also gives a good approximation for the behaviour of a more complex ANTS based ALR node.


E.6

E-25

Performance of an ANTS based multicast node

After the discussion of the ANTS based ALR node in previous section, the performance of this node is also analysed in case of multicast traffic. The set-up is extended with a number of additional receiving nodes which are connected to the forwarding node. For the throughput measurements, the forwarding routine of the active packets specifies that the packets received from the sending node have to be replicated and forwarded to multiple receiving nodes simultaneously. The measurements are done for 1, 2 and 3 receiving nodes. The results for a packet length of 128 bytes are shown in Figure E.17. Multicast Throughput Java/ANTS node without Garbage Collector 4000 1 receiving node 2 receiving nodes 3 receiving nodes 3500


3000

2500

2000

1500

1000

500

0

0

1000

2000

3000

4000

5000

6000


Fig. E.17: Throughput of a Java/ANTS based ALR multicast node with 1, 2 and 3 receiving nodes for 128 bytes packets.

It is clear that replicating a packet and forwarding it to multiple destinations takes more time than the basic processing and forwarding of a single packet. Consequently, the maximum lossless throughput will decrease with increasing number of destinations. The additional processing time needed for replication and forwarding to additional nodes can be deduced as follows. By fitting the model of Section 3.2 to the results, estimations for the mc processing time τ0mc are obtained. This gives the values τ0, 1 node = 232µs, mc mc τ0, 2 nodes = 295µs and τ0, 3 nodes = 362µs for a packet length of 128 bytes. The processing time increases with more or less constant steps of 63µs and 67µs when a second and a third destination are added. Obviously, these

E-26

Publicatie E

steps are larger for increasing packet lengths.

E.7

Conclusions

A performance analysis has been made for a general ALR node set-up, focusing on the throughput and the processing times. The influence of interruptdriven packet handling in the kernel was investigated based on a study of the Linux kernel. It was shown that large amounts of interrupts generated for high packet arrival rates will cause a fast degradation of performance. A performance analysis was made of a basic and a more complex ALR node, both based on Linux and Java technology. A general model was proposed, allowing to predict the performance in each of these cases. An analysis was made of the processing times in the ALR node based on estimations of the proposed model and measurements on the set-up. Also the influence of the Java Garbage Collector on the packet handling procedure was modeled and it was made clear that the interrupts generated by the Garbage Collector in conjunction with the socket receive queue are causing packet loss even for relatively low packet arrival rates. The throughput measurements show that for large packets (1024-1408 bytes) bitrates of 70Mb/s to 80Mb/s are attainable for the Java relay node. In case of the more complex ANTS based node, bitrates of 25Mb/s to 30Mb/s are achievable. Although the experiments were done on 450MHz processors, the results show that a considerable amount of traffic can be supported by the ALR nodes. When taking into account that Java is a slow technology in comparison to C or C++ based implementations and that the new polling based approach to packet handling considerably boosts performance, it is clear that there is still a large margin for improvement. Consequently, these results are very promising and can be considered as worst case indications of ALR node performance.

Acknowledgement Part of this work has been funded by the Ghent University GOA project “PAN” (Programmable and Active Networks).

Referenties [1] Pendarakis, D., Shi, S., Verma, D., Waldvogel, M., ALMI: An Application Level Multicast Infrastructure, Proceedings of the 3rd USNIX


E-27

Symposium on Internet Technologies and Systems (USITS01), Mar. 2001, pp.49-60. [2] Banerjee, S., Bhattacharjee, B., Kommareddy, C., Scalable Application Layer Multicast, Proceedings of ACM SIGCOMM 2002, Aug. 2002. [3] Chu, Y.-H., Rao, S.G., Zhang, H., A case for end system multicast, Proceedings of ACM SIGMETRICS 2000, Jun. 2000. pp.1-12. [4] Multicast Technologies, Multicast http://www.multicasttech.com/status/.

status

page,

[5] Akamai, http://www.akamai.com. [6] Exodus, http://www.exodus.com. [7] Speedera, http://www.speedera.com. [8] Gnutella, http://www.gnutella.com. [9] Freenet, http://freenet.sourceforge.net. [10] KaZaA, http://www.kazaa.com. [11] Tennenhouse D. et al., A survey of active network research, IEEE Commun. Mag., vol. 35,Jan. 1997, pp.80-86. [12] Smith, J.M., Calvert, K.L., Murphy, S.L., Orman , H.K., Peterson, L.L., Activating Networks: A Progress Report, IEEE Computer Mag., April 1999, pp.32-41. [13] Calvert, K.L., Bhattacharjee, S., Zegura, E., Sterbenz, J., Directions in Active Networks, IEEE Communications Mag., vol. 36, Oct. 1998, pp.72-78. [14] Psounis, K., Active Networks: Applications, Security, Safety, and Architectures, IEEE Communications Surveys, http://www.comsoc.org/livepubs/surveys/public/1q99issue/psounis.html, First Quarter 1999. [15] Ely, D., Savage, S., Wetherall, D.J., Alpine: A User-Level Infrastructure for Network Protocol Development, Proceedings of the 2001 USENIX Symposium on Internet Technologies and Systems, Mar. 2001, pp. 171-183. [16] Mogul, J.C., Ramakrishnan, K.K., Eliminating Receive Livelock in an Interrupt-Driven Kernel, ACM Transactions on Computer Systems, vol. 15, no. 3, Aug. 1997, pp.217-252.

E-28

Publicatie E

[17] Kohler, E., Morris, R., Chen, B., Jannotti, J., Kaashoek, M.F., The Click Modular Router Project, http://www.pdos.lcs.mit.edu/click/. [18] Wetherall, D.J., Service Introduction in an Active Network, PhD thesis, Feb. 1999. [19] Wetherall, D.J., Guttag, J., Tennenhouse, D., ANTS: A toolkit for building and dynamically deploying network protocols, IEEE OpenArch98, Apr. 1998. [20] Gleditsch, A.G., Gjermshus, P.K., Linux Cross-Referencing Project, http://lxr.linux.no/. [21] Herrin, G., Linux IP Networking: A Guide to the Implementation and Modification of the Linux Protocol Stack, http://www.cs.unh.edu/cnrg/gherrin/. [22] SmartBits Network Performance http://www.spirentcom.com.

Analysis

System,

Spirent,

Design and analysis of a stable set-up protocol for transcoding multicast trees in active networks Bart Duysburgh, Thijs Lambrecht, Filip De Turck, Bart Dhoedt, Piet Demeester Elsevier Journal of Network and Computer Applications, Submitted for publication Abstract — Based on Active Networking, an advanced streaming service was designed to offer different formats of the same stream using a single multicast tree. To that end, the initial format of the stream that is sent into the tree is transcoded to the other requested formats in the nodes of the tree, based on application level functionality residing in these network nodes. To set up such a multicast tree (including the necessary forwarding state in the nodes) and to install the necessary functionality in the nodes, a number of tree set-up procedures were designed. In this paper, performance aspects of these procedures are investigated: the stability and consistency of the forwarding state during the set-up procedures and the influence of dynamic user behaviour on the multicast tree. This performance assessment is based on a thorough analysis of the different set-up procedures and on simulations of the procedures. Based on the analysis, it is seen that great care must be taken during the set-up procedures in order to avoid interference with the existing streams. Therefore, extensions for the procedures are proposed. Furthermore, the influence of dynamic user behaviour on session state and performance attributes is analysed.

F.1

Introduction

The concept of Active Networking [1–4] provides an advanced networking infrastructure with increased flexibility and additional functionality, which is partly hosted by the network nodes. This way, the network can support

F-2

Publicatie F

advanced services with application level functionality residing in the network nodes. This is achieved by allowing each packet to carry its own forwarding routine that is executed on each node. This forwarding routine can specify a complex behaviour based on the Active Networking API provided by the nodes. This API allows to handle packets in the nodes, possibly including complex processing and modification of the payload, and to maintain application state in an information cache. Additionally, state information can be retrieved from the node environment and additional software modules can be called from node extensions. Consequently, each packet carries a program that defines its behaviour in the nodes and allows to provide advanced application functionality in the network. This infrastructure is used to implement an advanced media streaming service. Here, transcoding functionality is implemented in network nodes, allowing delivery of multimedia streams to terminals with heterogeneous capabilities (e.g. in terms of access bandwidth or processing power) while optimising bandwidth usage. Instead of building several multicast trees, each carrying a specific version of the same streaming content, only one version of the digital content is sent by the source. Transcodings performed at strategic locations in the network allow to deliver the content with a costumised quality to each client. The streamed data is sent through the network in DATA packets that find their way towards the users that joined the session based on the tree forwarding state that is set up in the network nodes. This tree forwarding state is maintained per session on each node in the information cache and contains information on the basic stream that is received and the different versions that are requested by the downstream users. More specifically, it is specified on which downstream link a specific version of the stream has to be sent and whether or not a transformation is needed from the basic stream. The set-up of the multicast tree is triggered by the JOIN messages from the users, indicating the streaming session of their interest (content selection) and the required version (bitrate, codec,...). While travelling through the network these messages will modify the forwarding state in some nodes, according to the carried request. In the same way, the state will be modified by LEAVE messages from users wanting to leave the session. Two particular problems have to be considered when applying this dynamic tree set-up procedure. First, when a streaming session has started, DATA packets are sent through the multicast tree, finding their way towards the joined users based on the forwarding information in the nodes. When during this session some users want to join or leave the session, JOIN or LEAVE messages will be sent in the network, triggering changes in the forwarding state. Since this state is used at the same time for routing the

Design and analysis of a stable set-up protocol for transcoding multicast trees in active networks

F-3

DATA packets, great care has to be taken. The set-up procedures have to be carefully designed to avoid interrupting the existing data streams by changes in the forwarding state. Second, in some cases the multicast group of the session may be characterised by a large degree of dynamic behaviour, with users leaving or joining frequently and unexpectedly. This way, the original multicast tree set up at the start of the session may gradually change to a totally different tree. Due to this gradual change, the tree topology is influenced by the existing state in the nodes and the resulting tree for the final multicast group will differ from the more optimal tree resulting from the same group joining the session at once. The differences between both multicast trees will not have a considerable influence on the users, but they are important for the performance of the network and the usage of resources in the network. Consequently, we investigate the following two aspects: the stability and consistency of the multicast forwarding state during the set-up procedures and the performance of the resulting multicast tree after a number of changes in the multicast group. The former is discussed in Section III, while the latter is discussed in Section IV. First of all, a description of the advanced multicast service and the set-up procedures are described in Section II.

F.2

An advanced multicast service with transcoding capabilities

Multicast technology has always been considered the preferred technique to support the distribution of media streams to a large group of users simultaneously. In the traditional application of media streaming one specific version, in terms of encoding or bitrate, is distributed to all users. This approach however lacks a lot of flexibility and does not allow any customisation of the service by the users. Therefore, it could be favourable to provide multiple versions of the streamed media. In this way, customers can choose a version according to the capabilities of their terminal and their network connection. They can customise the service according to their own needs and wishes, while considering the available support for different codecs on their terminal or the technology and bandwidth of their connection. In order to support this advanced feature of multicast streaming in the traditional network, separate multicast trees are needed for each version of the stream. This results in a significant increase of the load on both the server and the network. However, in an active network this advanced feature can be supported with a considerable reduction in network and server load. Only one multicast tree is used, sending only one version of the media stream and performing transformations of the original stream to

F-4

Publicatie F

the requested versions in intermediate nodes of the tree. In Figure F.1, a simple example is given of such a multicast session. For the discussions in the following sections, we focus on a general media distribution service providing five versions of the data with different bandwidths. These versions are referred to as codecs A, B, C, D and E, listed in descending order of used bandwidth. Transformations between these codecs are only performed from a higher to a lower bandwidth. After all, the requested codec with the highest bandwidth is initially sent in the tree, providing the data at the best quality, and lower bandwidth version can be deduced from it at the cost of a reduced quality. To distribute the appropriate versions of the streamed media to the different users of the session, a multicast tree has to be set up, incorporating the specific requests of all users. The state information for this multicast tree is maintained per session in the information cache of each active networking node. This state contains a reference to the corresponding session and consists of pointers to the next hops to which the stream has to be forwarded. For each pointer the requested version of the stream in that part of the tree is specified. When the pointer indicates the local node as the next hop, the specified version has to be delivered to the local user of that node. This way, a multicast tree as shown in Figure F.1 can be specified. In each node of the tree, a table with the according tree state information is set up, containing the pointers towards the next hops in the to-fields and the corresponding requested codec for each hop in the c-field. server to c 2 A 1 3B A to 4 5 6

c A A C

2

B

transcoding A>C

3

to c 3 B

user A

4 user

to c 4 A

A

5 user

C to c 5 A

6

to c 6 C

user

Fig. F.1: Example of the tree state information set up in the nodes for a simple tree with transcoding capabilities.


F-5

The media stream is transported in DATA capsules through the multicast tree. The forwarding routine carried in the DATA capsule specifies how the capsule and its payload travel through the network, based on the tree state information of the according session found on the nodes. In node 2 of Figure F.1, the arriving DATA capsules carry the codec with the highest bandwidth specified in that node’s tree state, which is called the upstream codec. This codec A version of the stream has to be forwarded to nodes 4 and 5, while codec C is required in node 6. Therefore, at the arrival of the DATA capsule carrying codec A, it is duplicated and forwarded towards node 4 and node 5. For a third instance of the same capsule, the payload is first transcoded to the requested codec C and the capsule is then forwarded to node 6. Further on, this basic example will be extended to more complex situations, where the processing load of the nodes is taken into account and the simple set-up is not sufficient. For these complex set-up procedures, additional tree state will be necessary.

F.2.1

Basic tree set-up procedures

The set-up of the tree forwarding state in the nodes is triggered by the JOIN messages from the users, carrying requests to join a session and to receive a specific version. These messages are transported in specific capsules, which in their dedicated forwarding routine also carry the intelligence to set up the node’s tree state. Consequently, the capsules will set up the tree state on their way through the network while their forwarding routine is executed on each node that is passed. With these capsules, a shortest path tree can be set up, based on the unicast routing information. Taking into account the possible asymmetric character of the network’s routes, different multicast trees may be set up depending on the direction of the set-up procedure: from users to server (upstream) or from server to users (downstream). In the first case, the tree state is set up in the nodes by the JOIN capsule travelling from the users to the server. In the second case, the JOIN capsule has to travel to the server and an acknowledgement in the form of a J-ACK capsule is sent back to the users, setting up the tree state along its way. The downstream set-up will result in a more optimal shortest path tree, with the streamed packets travelling along the shortest path from the server to the users. However, the upstream set-up will be faster and reduces the amount of signaling messages in the network since the JOIN messages only travel upstream until an existing part of the tree is reached, immediately setting up the tree state in the nodes that are passed. Figure F.2 illustrates the difference between both set-up procedures. It is assumed that the unicast routes between nodes 5 and 1 are different in

F-6

Publicatie F

Joi n

Joi n

ck -a (8 )J

Joi n A

in

(1)

(

3 Jo

B

4

5

4

5

user

user

user

user

(a)

B

2 (5)

A

k

ac

J4)

n Joi

(1) J

3

(3)

oin

(6)

(2)

(2) J

A>B

A

ck

2

A>B

J-a

A

1

k

-ac

J (3)

(7)

oin

1

B

(b)

Fig. F.2: Illustration of the difference between the tree set-up procedures in upstream (F.2(a)) and downstream (F.2(b)) direction.

both directions. The route from node 5 to 1 is via node 2, whereas the route in the opposite direction is via node 3. In this example the user in node 4 joins the session first with codec A and later the user in node 5 joins with codec B. In the upstream set-up of Figure F.2(a), the JOIN capsule from user 4 travels to node 1 setting up the tree state in nodes 4, 2 and 1 (step (1)-(2)), and the stream of DATA capsules with codec A starts when the JOIN capsule is processed in the server at node 1. The JOIN capsule from user 5 only travels to node 2 where the present tree state is inspected, finding that codec A is delivered to that node (step (3)). Consequently, additional state is added, specifying that a transcoding is needed from codec A to B and that the latter should be forwarded to node 5. At the next arrival of a DATA capsule with codec A, the stream towards node 5 will start. In the downstream set-up of Figure F.2(b), the JOIN capsules are travelling to the server where they trigger the set-up of tree state in the server node (step (1)-(2) and (5)-(6)). Next, the J-ACK capsule is sent, setting up the tree state in node 2 and 4 (step (3)-(4)) and in node 3 and 5 (step (7)-(8)). These capsules are immediately followed by the DATA capsules, starting the media stream. In this case, a transcoding from codec A to B is set up in node 1 and the codecs use seperate paths. From this discussion, it is clear that the two procedures result in different trees when asymmetric unicast routes are involved, while in the case of symmetric routes identical trees are set up. In [5], these set-up procedures are described more extensively and a performance analysis is made. Based on its much faster response times


F-7

and its reduced complexity of the set-up procedure the upstream procedure is preferred over the downstream procedure. Furthermore, the incidence rate of asymmetric routes is rather low in current networks, reducing the number of cases where the downstream procedure could have an advantage. Therefore, further discussions will focus on the upstream set-up procedure.

F.2.2

Set-up procedures in nodes with insufficient resources

This general and relatively simple set-up procedure discussed in the previous section can only be used when the network nodes are not overloaded and additional transcoding processes can still be installed. However, when a transcoding process is needed on a node with insufficient resources, more complex procedures are used to overcome the problem. The general approach to these procedures is to relocate the transcoding process to a node with sufficient resources and to forward the stream accordingly. Three different strategies have been proposed. The first two strategies attempt to maintain the session’s traffic on the existing tree by pushing the transcoding process along the currently used links of the tree in the upstream or downstream direction. The process is relocated to the nearest node of the tree in that specific direction capable of accommodating the requested transcoding. These strategies are called Push Upstream and Push Downstream, respectively. A third strategy tries to find the closest node in the entire network capable of accommodating the transcoding process. This node will then function as a proxy node for the transcoding and the strategy is called Push to proxy. A suitable proxy node is determined, based on the unicast routing table and the load information of the nodes, which is distributed over the network. First, the neighours of the overloaded node are examined whether they have sufficient means to support the relocated transcoding process. If so, the node with the most means available is selected. Otherwise, if no suitable node is found, the nodes that are 2 hops away are examined in the same way. In subsequent steps, groups of nodes that are even further away are examined and hence the closest node with sufficient resources is selected. The three strategies are illustrated in Figure F.3 with node 2 being overloaded. Consequently, the transcoding process from codec A to B, which is needed to deliver codec B to node 4, can not be installed on node 2. In the Push Upstream procedure, the transcoding is relocated to node 1 and codec A and B are streamed simultaneously from node 1 to node 2. In node 2, these streams are forwarded in the appropriate direction. In the case of Push Downstream, codec A is sent from node 2 to node 4, where it is

F-8

Publicatie F

A

A

1 A

B

3

1

A

2 A

A

1

A>B

2

load=100%

B

A

4

A

B push upstream

A

3 A

A

A

4 B

push downstream

A>B

A

2

load=100%

B

5

A>B

B

3

4

A

B push to proxy

Fig. F.3: Strategies to overcome processing power scarcity in nodes where transcodings are needed.

transcoded to codec B. In the Push to Proxy strategy, codec A is sent from node 2 to the transcoding proxy node 5. After transcoding the stream, it is returned from node 5 to node 2 and forwarded to node 4. To maintain these more complex transcoding trees in the network, additional tree state information has to be kept in the tree nodes. Therefore, two extra fields are introduced in the tree state entries in addition to those illustrated in Figure F.1: the tc-field and the psh-field. The tc-field indicates whether or not the requested codec in the entry should be transcoded from the upstream codec. When tc=no is specified for an entry, the codec may not be transcoded from the uplink codec. The stream is only forwarded over the link specified in the entry when the specified codec explicitly arrives at the node. The psh-field is used in the entries of a transcoded codec in the path between the proxy node or the upstream node where the transcoding was pushed to and the overloaded node. The entries of such a codec that is either transported in parallel with the actual upstream codec or on a specific branch between the proxy and the overloaded node are marked with psh=yes. This way, the psh-field indicates that these entries should not be modified since they are required to direct the transcoded stream to the originating node along a particular path. The use of this tree state is illustrated in Figure F.4. In Figure F.4(a), the transcoding from codec A to B needed on node 5 is pushed upstream to node 2. Consequently, node 2 and 3 contain tree state that forwards codec A and B simultaneously to node 5. The entries for codec B in these nodes are therefore marked with psh=yes, indicating that this is pushed traffic. In node 3 and 5, codec B should not be transcoded from codec A, so the


F-9

entries for codec B are marked with tc=no. In node 4, the regular tree state for a node with sufficient resources is shown, with one transcoding from codec B to C. In Figure F.4(b), a tree is shown with a transcoding process pushed to a proxy node. The transcoding from codec A to B, required to deliver codec B to node 6, is relocated to node 5. Codec A is forwarded to the proxy node as if node 5 were just one of the user nodes of the tree. The stream from node 5 to 2 carrying codec B is indicated as pushed traffic (psh=yes). In Figure F.4(c), it can be seen that in trees with transcodings pushed to downstream nodes, the tc- and psh-fields are not really needed to specify the tree.

to 3 3 4

tc y y y

3

B A B

2 c A B B

psh n y n

B

5

A

B

8

A B

4 to c tc psh 6 B y n 7 C y n

6

9

C

3

A A to 3 6 7

c A B A

B

B

2 tc y n y

B

psh n n n

to c tc psh 3 B y y

A

5 A>B

A



B>C

A>B


6

A

7

7

(a)

(b)

2

to c tc psh 3 A y n 4 A y n

A

A>B

3

A A

4

B

6

to c tc psh 6 B y n

(c)

Fig. F.4: Illustration of the tree state information in complex trees with pushed transcoding processes.

To set up the tree state in these Push procedures, additional capsules are used. In case of the Push Upstream or Downstream procedure, the Push capsule is simply sent in the respective direction, travelling until a node is found capable of accommodating the required transcoding and modifying the tree state on its way. For the Push to Proxy procedure, a PUSH and a P-ACK capsule are needed to set up the tree state in both directions between the overloaded node and the transcoding proxy node. Because the original codec should be delivered to the proxy node and the transcoded codec has to be sent back, this procedure is more complex than the other

F-10

Publicatie F

proxy node

B

3

(2) Push

A

Join

B

A

B

(3) P-ack

2

A>B

(5) P-ack

2

4 B

(2) Push

A C

(1)

5

6

5

6

5

6

user

user

user

user

user

user

(a)

C

B C

2

3

(4) Join

(2) Push

(3) Push

B

(6) P-ack

2

B>C

proxy node

(5) P-ack

3

B (2) Push

A B

B (3) Push

CA proxy node

4 C

D

(1)

(1)

C

Join

A

A

4

A>C

Join

(4) P-ack

4 proxy node

(c)

(5') P-repl (5) P-ack

A C (3) Push

A

(b)

A

(4) P-ack

3

C Join

4

(1)

B

A B (3) Push

(2) Push

A

A

(4) P-ack

3

A>B A>C A>D

A B

(1)

(5) P-ack

2

Join

A

5

6

5

6

user

user

user

user

(d)

(e)

Fig. F.5: Set-up of traffic between an overloaded node and a transcoding proxy node.

two. More specifically, four special cases can occur, which are illustrated in Figure F.5. In Figure F.5(a), the general set-up of traffic to and from the proxy node is shown. When the JOIN capsule requesting codec B arrives at node 2, it finds that codec A is delivered to the node but insufficient resources are present to perform a transcoding locally (step (1)). When node 4 is determined as a suitable proxy node, a PUSH capsule is sent to node 4, specifying that codec C should be transcoded from codec A and should be delivered to node 2 (steps (2)-(3)). When the capsule arrives in node 4, the necessary tree state is set up and a P-ACK capsule is sent back to node 2, setting up the necessary tree state for the traffic in both directions along its way (steps (4)-(5)). When the state is also configured in node 2, the media stream finds its way to and from the proxy node and to node 6. During the set-up procedure, the PUSH and P-ACK capsules both perform some checks on their way between the overloaded and the proxy node. The PUSH capsule determines whether the transcoded codec is available in the intermediate nodes. This is illustrated in Figure F.5(b), where the transcoded codec B is encountered in node 3 and it is simply forwarded to node 2. This way no transcoding process has to be set up on node 4. Consequently, the necessary state is installed on node 3 and a P-ACK capsule

Design and analysis of a stable set-up protocol for transcoding multicast trees in active networks F-11

is sent back to set up the tree state on its way to node 2. The P-ACK capsule checks if a codec with a higher bandwidth than required is present in the nodes on its way from the proxy node to the overloaded node. In both Figures F.5(c) and F.5(d), such codec is encountered in node 3, so it is not necessary to send the original codec A from the overloaded node 2 towards the proxy node 4. Instead the stream can simply be forwarded from node 3 to node 4. Since the P-ACK capsule by default sets up the state to forward the original codec A towards the proxy node, it is necessary for the case of Figure F.5(d) to replace this information with the correct state to forward codec B to the proxy node and to transcode it there to codec C. Therefore, a P-REPL capsule is sent back to the proxy node, replacing the default state with the correct one. In the situation of Figure F.5(c), the original codec is found in node 3, so the default state for codec A can be used. Further on, the P-ACK capsule proceeds its way from node 3 to the overloaded node, while setting up only the tree state necessary to deliver codec B to node 2. Another specific case for the P-ACK capsule is shown in Figure F.5(e). When on the proxy node a codec with a sufficiently high bandwidth is found, only the transcoding and the return path for the transcoded codec to the overloaded node has to be set up. However, when a codec with lower bandwidth is present in the proxy node, this upstream codec C should be replaced with the original codec A to allow the transcoding to codec B. Therefore, a JOIN capsule has to be sent upstream to replace codec C with codec A (step (4)) and afterwards the return path to the overloaded node is set up (steps (5)-(6)).

F.3

Stability and consistency of tree state during set-up procedures

An important aspect of the set-up procedures described in previous section is the stability and consistency of the tree state during the procedures. When for example new users join or leave an active session, the existing tree state in some nodes may be modified while it is at the same time used for routing DATA capsules in the tree and to deliver the media stream to the users. This way, existing streams may be interrupted for a short time during these procedures, degrading the service of the users that already joined the session. Consequently, great care must be taken during the procedures to preserve the existing streams. In Table F.1, an overview is given of the different capsules involved in the multicast service and their respective influence on the tree state in the nodes. It is clear that instability and inconsistency of the tree state for the existing streams can be caused by the JOIN and the PUSH capsules,

F-12

Publicatie F

TABEL F.1: Different types of capsules used in the multicast service.

to c tc psh 2 B y n

to c tc psh 2 B y n

1

Purpose Add branch Transport stream Relocate transcoding Relocate transcoding Clean up tree Remove branch

A

to c tc psh 3 B y n

to c tc psh 3 A y n

(2')

2

to c tc psh 3 B y n

(4)

(3)

B

to c tc psh 2 A y n

(3')

1

in J-c ln

LEAVE

Influence on tree state Adds new or overwrites existing entries Uses tree state to forward streamed data Adds new or overwrites existing entries Adds new entries Overwrites existing entries, which are not yet used Removes entries which are not needed anymore

Jo

Capsule JOIN DATA PUSH P-ACK P-REPL

(2')

2

to c tc psh 4 B y n

3

(1)

(a)

ln (1')

A>B

A

B

4

psh n n psh n


in

5

3

tc n y tc y

Jo

in

Jo

4

to c tc psh 4 B y n

(1)


(1')

(5) J-c

(2) Join

(2)

Jo

in

A

to c B A to c 3 A

* 33

(4')

5 (b)

Fig. F.6: Influence of the tree set-up procedure on the existing streams and their tree state. In Figure F.6(a), the existing stream with codec B from node 1 to node 4 is interrupted when in node 2 the entry for codec B is overwritten with codec A. In Figure F.6(b), this interruption is avoided by setting up state for codec A in parallel with the existing state for codec B. Afterwards, the state for codec B is cleaned up.

since they modify existing tree state in the nodes. In Figure F.6(a), a setup procedure is illustrated where no precautions are taken to preserve the existing streams. User 4 has joined the session and a stream with codec B is already set up, while user 5 issues a request for codec A. In node 3 a transcoding from codec A to B is installed (step (1’)) and a JOIN capsule is sent upstream to set up a path to deliver codec A to node 3. In node 2 the entry for codec B is overwritten with codec A (step (2’)), since codec B will be transcoded from codec A. However, at this moment DATA


capsules carrying codec B are still sent from node 1 to 2. These capsules are not forwarded to nodes 3 and 4 since only an entry for codec A exists. The stream towards node 4 is therefore interrupted and will only resume when the full path for codec A is set up. In Figure F.6(b), this problem is avoided by adding a new entry for codec A and modifying the codec B entry (tc=no). This ensures that codec B will still be forwarded during the set-up. However, when codec A is finally delivered in node 2, the state for codec B will not cause a transcoding from codec A to B and codec A will just be forwarded. The state for codec B then becomes useless and therefore J-CLN capsules are sent to clean up this state (step (4’)). These capsules are sent back along the path of the JOIN capsule, which was recorded on its way upstream. The J-CLN capsules are only sent after a certain delay in order to make sure that all capsules carrying codec B have reached the appropriate users and none are using the transient codec B state anymore. In order to avoid that other procedures take into account the information of the temporarily remaining entries for codec B, they are explicitly marked to be transient (by ∗ in Figure F.6(b)). In case of the Push procedures, similar mechanisms are used to avoid interrupting the existing streams. In Figure F.7(a), it is first shown that the Push Upstream procedure has no problems since it comes down to adding new entries for the pushed codec and modifying the attributes of the existing entries (tc=no). In Figures F.7(b) and F.7(c), the Push Downstream and Push to Proxy procedures are illustrated. In both cases, a transcoding from codec A to B is needed in the overloaded node 3, which has to be pushed to another node, and codec A has to be installed in the upstream links replacing codec B. To keep the procedure under control, first the path for the pushed codec is set up and second the new codec is installed in the upstream links. For the first step, a PUSH capsule is sent in the appropriate direction and a P-ACK capsule returns to the overloaded node to confirm that the relocation of the transcoding is completed. However, in the Push Downstream procedure, some transient state similar to the one in Figure F.6(b) is left in the downstream path, which is needed until the upstream path is also completely set up. The second part starts after the arrival of the P-ACK capsule and a JOIN capsule is sent upstream to set up the state for codec A. The transient state left in the nodes by the JOIN capsule is cleaned up by the J-CLN capsule (step (8’)). Only then the upstream set-up is completed and the J-CLN capsule will proceed from node 3 along the downstream path to clean up the other transient state left by the earlier Push procedure (steps (9’)-(10’)). From this discussion it is clear that the set-up of new streams can be made compatible with preserving existing streams at the expense of a more

F-14

Publicatie F

(7')

)J Pu cln sh

A

0 (1

4

*

n (9) J-cl

5

(10')

A

6

to c tc psh x B y n

A

(5) P

(2')

(4) P-ack

psh n psh n n psh n

( 2)

tc y tc n y tc y

ush

5

c B c B A c A

(11) J-cl n (3) P

to 6 to 6 6 to 6

tc n y tc y

psh n n psh n

to c B A A to c 4 A 5 A

tc n y y tc y y

psh n n n psh n n

* 445

(9')

oin

4

in Jo

A

(1')

3

)J

(1)

B

to c tc psh 4 B y n


(1')

3

(6) Join

Pu sh

A

to c B A to c 3 A

* 33

(1

to c tc psh 4 B y n

(6')

2

(8')

(2)

B A

to c tc psh 3 B y n


(2')

2

-cln

A

(3)

to c tc psh 3 B y n

to c tc psh 2 A y n

1

Pu sh

B A

to c tc psh 2 B y n

to c tc psh 2 B y y 2 A y n

A>B

-ack

1

(7) Join (8) J

(3')

to c tc psh 2 B y n

A

A>B

B

(a)

(b)

(5')

to c tc psh 2 B y n

to c tc psh 2 A y n

to c tc psh 3 B y n

-cln

A

(5) Join (6) J

1

(4')

2

tc y tc n y tc n y y

psh n (1') psh n B n (3') psh n n n B

4

n (7) J-cl

A

3

6

B

(3) P-ack

A

psh n n psh n

(2')

A>B

to c tc psh 3 B y y

oin

c B c B A c B A A

(1) J

to 4 to 4 5 to 4 5 6

(4) Join

A

to c tc B n A y to c tc 3 A y (2) Push

* 33

(6')

5 A

(c)

Fig. F.7: Influence of the push procedures on the existing streams and their tree state. The Push Upstream procedure (Figure F.7(a)) has no significant influence, whereas the Push Downstream (Figure F.7(b)) and the Push to Proxy procedure (Figure F.7(c)) will interfere with the existing streams. Therefore, specific measures are required to preserve the existing streams.

complex set-up procedure. This includes extra messages being sent in the network and a larger response time for the new users.


F.4

Stability of the multicast tree with changing multicast groups

In the preferred upstream set-up procedure, the JOIN capsules travel towards the server until an existing part of the multicast tree is encountered and then a new branch is attached. Consequently, the configuration of the new tree will depend on the configuration of the existing tree in the network. This way, when a multicast group is not static and users are joining and leaving the session regularly, the tree configuration will evolve with each user leaving or joining. Since each new tree configuration is based on the previous one, the resulting trees may be different from the optimal tree, which would result from the final multicast group joining the session at once. In this section, the final tree resulting after a number of changes in the multicast group is compared to the best possible tree that can be achieved for that specific set-up. This discussion is based on an analysis of the Leave procedures and on simulations. TABEL F.2: Codecs provided in the multicast service

A B C D E

Codec PCM 16 bit G.711 µ-law G.726-7 4 bit G.728 G.729

128 64 32 16 8

Bitrate kbit/s kbit/s kbit/s kbit/s kbit/s

[7] [8, 9] [10] [11]

The simulations were performed in the ns2 network simulator [6] for a voice streaming service offering the voice codecs listed in Table F.2. In the grid network depicted in Figure F.8(a), a server node and seven different zones are defined. These zones, which are used to determine the moving multicast groups, are shown in Figure F.8(b). In the simulations, an initial and a final multicast group are defined, with the initial group always located in zone 1 and the final group in one of the seven zones. During the simulation, the users of the initial group join the session first. Then, a number of users will join or leave the existing session in a random order. This will finally result in the final group having joined the session. In another run of the simulation, the users of the final group join the session at once. The resulting trees of both runs are compared to determine the performance of both approaches, thereby assessing the influence of dynamic user behaviour in the resulting multicast tree. Below, it is shown that the performance of the multicast tree is mainly determined by the way the existing tree state of an existing multicast tree

F-16

Publicatie F

1

Server

2

3

4

6

5

7

(a)

(b)

Fig. F.8: The grid network used for the simulations and its division into different zones.

is affected by users leaving the session. Therefore, the possible behaviour of the LEAVE capsules is described. In the simplest approach to the Leave procedure, the tree state that is no longer useful after a user has left, is removed. The LEAVE capsule travels upstream along the tree, removing the entries that were only used to deliver the stream to the leaving user. All other tree state information is left unchanged. However, a certain part of this remaining state may also be used to deliver the stream to the leaving user. The remaining tree will then partly be influenced by the previous users that have already left the session. In Figure F.9(a), a simple example shows how the remaining tree may have a reduced performance due to the influence on the tree state of the leaving user. When user 3 leaves the session, a LEAVE capsule is sent upstream, removing the state for codec A in node 2. The stream between the server and node 2 remains unchanged since it is needed to deliver codec B to node 4. The remaining tree is now suboptimal with codec A delivered to node 2 instead of codec B. Similar situations involving the three Push strategies are also shown in Figure F.9. In case of Push Upstream in Figure F.9(b), the parallel state for codec A can be removed in both node 2 and the server, resulting in an optimal tree. However, in case of Push Downstream or Push to Proxy (Figure F.9(c) and F.9(d)), the procedure results in a tree with reduced performance. Due to the fact that during the evolution between the initial and the final multicast group the tree configuration comprises a number of situations similar to Figure F.9, the resource usage in the tree is expected to increase as users join and leave the tree. The final tree could also exhibit reduced performance since each new tree builds on the state of the existing tree.


1

1

1

1

4 (a)

4 (b)

3

A A>B

(c)

4

B

3

av e

A

Le

A

(1)

ve

3

ea

B

(1) L

(1) Leave

ea (1) L

3

A

4 (d)

A

2

A>B

3

A

B

5

A>B

(3) Leave

ve Lea

B

5

(2)

A

A A B

2

2

2

A>B

ve

2

A

A

A B

Le av e

A

(1)

(2) L ea

ve

1

B

4

B

6

(e)

Fig. F.9: Illustration of the remaining tree state exhibiting reduced performance after a user leaves the session. In Figure F.9(a) it is shown that this can be the case in a normal situation without overloaded nodes. In Figures F.9(b), it is shown that the Push Upstream procedure exhibits no reduced performance. However, the Push Downstream and Push to Proxy procedure can exhibit reduced performance as shown in Figures F.9(c), F.9(d) and F.9(e).

To avoid this, a more complex Leave procedure is needed where a clean-up of the existing tree state is triggered each time a user leaves a session. In this case, each intermediate tree will still be the best possible solution for that situation, except for the Push to Proxy procedure. When in the Push to Proxy procedure a new branch is attached on a part of the tree that consists of pushed traffic, the path from the user to the server will not be the shortest path, which is illustrated in Figure F.9(e). When user 6 joins the session, codec B is directly delivered from the proxy node 5. When users 3 and 4 leave the session, node 6 now remains connected to the server via the suboptimal path over nodes 1, 2, 5 and 6 instead of the optimal path over nodes 1, 5 and 6. So, even when a clean-up of the tree state is triggered and only codec B is sent to node 6, this path will remain suboptimal. From this discussion, the following conclusions can be drawn considering the performance of the multicast tree with changing user groups. For the Push Upstream and Push Downstream procedure, the final multicast tree exhibits similar topology and performance as if the final group joins the session at once if the Leave procedure triggers a clean-up of the remaining tree state. For the Push to Proxy procedure, the final tree will differ significantly from this situation even after a clean-up of the tree state, resulting in additional bandwidth usage and extra transcodings in the tree. Compared to these cases, the simple approach to the Leave procedure, which was described first, can be considered as the worst case scenario, since no precautions are taken to avoid suboptimal trees. Consequently, an analysis

F-18

Publicatie F

of the differences between the final tree and the best possible tree in this approach gives a good idea of the worst case scenario. Furthermore, the measured values for the additional bandwidth usage and the number of extra transcodings in the tree can be considered as upper limits for all other practical cases. The values shown in Figure F.10 are obtained from simulations of the worst case approach, in which the bandwidth usage and the number of transcodings is observed, for both trees. The average increase of bandwidth usage and the number of transcodings in the tree is shown as a function of the network load, which is expressed as the fraction of overloaded nodes in the network. The simulations were done for seven pairs of an initial and a final zone, defining the part of the network where the initial and the final multicast group, containing 10 users, are located. For each of these seven pairs, the initial zone is zone one and the final zone is one of the seven zones, as indicated in the legend. First, it should be noticed that the three approaches give the same results for an unloaded network, since no transcodings are relocated and a simple shortest path tree with transcoding nodes is set up for each case. Second, for a completely loaded network, the final tree is identical to the best possible solution for the three approaches. After all, in this case transcodings are only relocated to the edge of the network, either to the server or the user nodes. Consequently, no suboptimal trees can arise when users leave the session. Third, the main conclusion should be that the differences in bandwidth usage and number of transcodings are limited to about 2.5%. Depending on the different locations of the initial and the final multicast group, this may be even less. This is mainly be determined by the overlap between the original and the final zone and the location of both with regard to the server node.

F.5

Conclusion

In this paper, we presented an advanced streaming service based on Active Networks and offering different formats of a stream via the same multicast tree. We made a detailed analysis of the performance of the different set-up procedures used to install the forwarding state for the service in the network nodes. In the analysis we focussed on two aspects of the performance. First, we investigated the stability and consistency of the forwarding state during the set-up procedures. It was shown that in some cases a set-up procedure may interfere with the existing streams, causing interrupts or bad performance during this set-up. Therefore, great care must be taken for the design of these set-up procedures. A number of solutions were presented

Design and analysis of a stable set-up protocol for transcoding multicast trees in active networks F-19 Push Upstream

Push Downstream

3

3 zone1 zone2 zone3 zone4 zone5 zone6 zone7

2.5

Increased bandwidth use [%]


2.5

2

1.5

1

0.5

0 0.0

zone1 zone2 zone3 zone4 zone5 zone6 zone7

2

1.5

1

0.5

0.2

0.4

0.6

0.8

0 0.0

1.0

0.2

Fraction of overloaded nodes

0.4

(a)

Push to Proxy

Push Upstream

1.5

1

Increased number of transcodings [%]


2


2.5

0.5

2

1.5

1

0.5

0.2

0.4

0.6

0.8

0 0.0

1.0

0.2


0.4

0.6

0.8

1.0


(c)

(d)

Push Downstream

Push to Proxy

3

3

2

1.5

1

0.5


2.5



2.5


1.0

3 zone1 zone2 zone3 zone4 zone5 zone6 zone7

2.5

0 0.0

0.8

(b)

3

0 0.0

0.6


2

1.5

1

0.5

0.2

0.4

0.6

0.8


(e)

1.0

0 0.0

0.2

0.4

0.6

0.8

1.0


(f )

Fig. F.10: Influence of a changing user group on the use of network resources in the tree.

to prevent the procedures from interfering with the streams. Second, the influence of dynamic user behaviour on the perfromance of the multicast tree

F-20

Publicatie F

was investigated. The procedures that are used to remove branches from the tree when a user leaves the session are for reasons of complexity and performance not optimised to remove all redundant state in the multicast tree. Hence, the resulting tree after a user left the session may exhibit reduced performance and over time this performance may be reduced even more. This was shown based on an analysis of the Leave-procedure and on simulations. From these simulations it was seen that the reduction of performance in terms of used bandwidth and number of transcodings in the tree is limited to 2.5%.

F.6

Acknowledgement

Part of this work has been funded by the Ghent University GOA project “PAN” (Programmable and Active Networks).

Referenties [1] Tennenhouse D. et al., A survey of active network research, IEEE Commun. Mag., vol. 35,Jan. 1997, pp.80-86. [2] Smith, J.M., Calvert, K.L., Murphy, S.L., Orman , H.K., Peterson, L.L., Activating Networks: A Progress Report, IEEE Computer Mag., April 1999, pp.32-41. [3] Calvert, K.L., Bhattacharjee, S., Zegura, E., Sterbenz, J., Directions in Active Networks, IEEE Communications Mag., vol. 36, Oct. 1998, pp.72-78. [4] Psounis, K., Active Networks: Applications, Security, Safety, and Architectures, IEEE Communications Surveys, http://www.comsoc.org/livepubs/surveys/, First Quarter 1999. [5] Duysburgh, B., Lambrecht, T., De Turck, F., Dhoedt, B., Demeester, P., An active networking based service for media transcoding in multicast sessions, Accepted for publication in IEEE Transactions on Systems, Man and Cybernetics, Part C, Special Issue on Computational Intelligence in Telecommunications Networks and Internet services, November 2003. [6] UCB/LBNL, Network Simulator, http://www.isi.edu/nsnam/ns.

ns,

version

2,

1997.


[7] ITU-T, G.711: Pulse Code Modulation (PCM) of Voice Frequencies, ITU-T, 1972. [8] ITU-T, G.726: 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM), ITU-T, 1990. [9] ITU-T, G.727: 5-, 4-, 3-, and 2-bits Sample Embedded Adaptive Differential Pulse Code Modulation, ITU-T, 1990. [10] ITU-T, G.728: Coding of Speech at 16kbit/s Using Low-Delay Code Excited Linear Prediction, ITU-T, 1992. [11] ITU-T, G.729: Coding of Speech at 8kbit/s Using Conjugate Structure Algebraic-Code-Excited Linear-Prediction (CS-ACELP), ITU-T, 1996.

Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie

Recommend Documents