Modelleren en analyseren van peer-to-peer verkeer in een HFC-netwerk

Vakgroep Informatietechnologie, Voorzitter: Prof. Dr. Ir. P. LAGASSE Onderzoeksgroep Wireless & Cable, Directeur: Prof. Dr. Ir. L. MARTENS

Modelleren en analyseren van peer-to-peer verkeer in een HFC-netwerk door Eli DE POORTER

Promotor: Prof. Dr. Ir. L. MARTENS Scriptiebegeleider: Ir. J. DE BRUYNE

Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen

Academiejaar 2005–2006

Modelleren en analyseren van peer-to-peer verkeer in een HFC-netwerk door Eli DE POORTER Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 2005–2006 Promotor: Prof. Dr. Ir. L. MARTENS Scriptiebegeleider: Ir. J. DE BRUYNE Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Onderzoeksgroep Wireless & Cable

Dankwoord Deze thesis werd geschreven als eindwerk van de ingenieursopleiding van Eli De Poorter. Het is de bekroning van de opleiding tot ingenieur en telt als dusdanig mee voor de eindbeslissing inzake het verkrijgen van het ingenieursdiploma. Deze thesis zou nooit tot stand gekomen zijn zonder de hulp van heel wat mensen. Graag zou ik daarom een woord van dank willen richten tot iedereen die hiertoe bijgedragen heeft. Allereerst gaat mijn dank uit naar mijn promotor Prof. Dr. Ir. L. Martens voor het aanbieden van dit thesisonderwerp en het ter beschikking stellen van het onderzoekslaboratorium. Verder wil ik mijn begeleider Ir. J. De Bruyne bedanken voor alle steun die hij mij geboden heeft. Ik ben hem dankbaar voor de vrijheid die ik heb gekregen bij dit onderzoek en de nauwgezetheid en ijver waarmee hij het onderzoek heeft gevolgd. Ook wil ik alle leden van de onderzoeksgroep ‘Wireless and Cable’ bedanken voor het ter beschikking stellen van hun materiaal en de aangename werkomgeving. Tenslotte wil ik mijn ouders, Christine Heymans en Erwin De Poorter, en vriendin Liesje Liagre bedanken voor hun steun en hulp.

Toelating tot bruikleen De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.

Eli De Poorter, mei 2006

Modelling and analysing peer-to-peer traffic on an HFC network Eli De Poorter Supervisor(s): Ir. Jeffrey De Bruyne, Prof. Dr. Ir. Luc Martens Abstract— This article examines the influence of peer-to-peer traffic on the performance of an Hybrid Fiber/Coax (HFC) network. Several characteristics of peer-to-peer traffic are examined, as well as the influence of the type of subscription. Information about the network load is gained by modelling the peer-to-peer traffic and simulating the network traffic on OPNET, a network simulator. Lastly, several (Euro-)DOCSIS Quality-ofService (QoS) facilities are investigated in order to reduce the influence of peer-to-peer traffic on the network. Keywords—Peer-to-peer, (Euro-)DOCSIS, traffic modelling

TABLE I M AXIMUM UP - AND DOWNLOAD SPEED OF THE SUBSCRIPTIONS

Subscription 128 kbps sub 192 kbps sub 512 kbps sub 512 kbps + sub

Max download 4 Mbps 5 Mbps 6.6 Mbps 10 Mbps

Max upload 128 kbps 192 kbps 512 kbps 512 kbps

I. I NTRODUCTION

T

RADITIONAL internet traffic is based on the client-server model where communication is usually to and from a central server. Client-server applications cause mainly downstream traffic. Recently there has been an increase in the traffic associated with peer-to-peer (p2p) networks. These networks are based on ad-hoc connections between participating nodes (‘peers’). The peers function both as a server and a client, thereby creating a large amount of both upstream and downstream traffic. This research focuses on HFC networks. HFC networks were developed for mainly client-server traffic. They have a limited upstream bandwidth, which is shared between multiple users. A good understanding of the influence of p2p traffic on the performance of an HFC-network is therefore important. Several characteristics of p2p traffic are studied and used to construct reliable distribution models of the p2p traffic. Based on the models, research is done, investigating the current occupation of the available bandwidth by p2p traffic. Finally, some solutions are examined in order to support QoS applications. II. M EASUREMENTS This study is based on traffic analysis on the backbone of a network provider, during a weekend in the holidays. The results of the used measurements were cumulated per minute. During the analysis of the measurements, a distinction is made between the hour of day, and the type of subscription. Both characteristics have a distinct influence on the amount of generated traffic. The up- and download speeds of the examined subscriptions are given in table I. III. P EER - TO - PEER ANALYSIS The proposed distribution models are simple but reliable. The model consist of 3 distributions: the upload size of the p2p traffic, the number of active users and the upload size of the backE. De Poorter is currently a last-year student with the Computer Science Engineering Department, Ghent University (UGent), Gent, Belgium. E-mail: [email protected] .

ground traffic. Together with these characteristics, also the connection duration is examined. A. Upload size of p2p traffic The data sent from all detected p2p protocols is modelled as one distribution. As demonstrated in table II, the average upload size varies depending on the type of subscription. TABLE II AVERAGE UPLOAD SIZE OF P 2 P TRAFFIC (S UNDAY BETWEEN 21 H - 22 H )

Subscription 128 kbps sub 192 kbps sub 512 kbps sub 512 kbps + sub

Average upload speed 130 kB/min (17.46 kbps) 173 kB/min (23.15 kbps) 197 kB/min (26.31 kbps) 307 kB/min (40.94 kbps)

In figure 1, the upload size of the 512 kbps subscription (between 14 and 15 o’clock) is fitted to two distributions. The lognormal distribution is most often used, but favors the large upload volumes. The Weibull distribution is a better alternative. Even though the average upload speed is 170 kB/min (about 23 kbps) per user, this number can increase up to 4000 kB/min (about 512 kbps). This demonstrates the need for distributions when modelling p2p traffic. In figure 1, one can observe a ‘nod’. This nod might indicate the percentage of heavy users and can also be found with all other subscriptions. B. Active users When modelling the number of active users on an upstream channel, a distinction can be made between the subscriptions. A large variation in the average number of active users is observed in the slower subscriptions: from 4 active users at night to 25 users during the evening. Fast subscriptions have less average users, and less variation: from 2 at night to 3 during the evening. The same can be said about the average percentage of

0

1

10

Cumulative probability

Survivor function

0.8 −1

10

−2

10

−3

upload data weibull lognormal

10

0

10

1

10

0.6

0.4

0.2 128 kbps sub 512 kbps + sub 2

0

3

10 Upload data (kB/min)

10

0

10

20

30 Minutes

40

50

60

Fig. 2. Distribution of the connection duration Fig. 1. Upload fitting of the p2p traffic of the 192 kbps sub (Sunday between 14h - 15h)

C. Connection duration During the analysis of the connection duration, one can make a distinction between the connection duration of the different protocols and the connection duration of the different subscriptions. In both cases, many of the connections are only 1 minute or shorter. Most of these connections can, in all likelihood, be classified as control connections. The average connection duration is given, both with control connection (‘all’) and without control connections (‘filtered’). The percentage of short connections is about 30%. TABLE III AVERAGE CONNECTION DURATION PER PROTOCOL

Protocol e-donkey KazaA Bittorrent Gnutella DC

all 29.1 min 11.1 min 59.4 min 12.0 min 21.7 min

filtered 36.9 min 16.3 min 88.5 min 16.4 min 28.3 min

IV. S IMULATIONS The previous distributions are used in a model to simulate the traffic on an HFC network. All simulations were done with the OPNET [1] modelling tool. Based on our simulations, the current occupation of the available bandwidth1 is about 16%. The peakbandwidth however, can be as much as 3 times higher. A. Extra p2p users When examining the influence of extra p2p users in the load, two different scenarios are constructed: an increase of 15 and an increase of 30 p2p users. The scenarios have been simulated twice: once with users of the fastest and once with users of the slowest subscription. The results can be found in figure 3. One can conclude that the influence of users of the fastest subscriptions is much larger than those of the slower subscriptions.

70 60 50

load (%)

active users, active on a p2p network. The percentage p2p users vary from 2% tot 5% by the slow subscriptions, whereas the percentage is almost constant at 30% by the fastest subscription. We found the Negative Binomial distribution to be the best fitting distribution for the number of active users.

The distribution of the connection duration is given in figure 2. The connection duration mounts up to more than 16 hours.

40 30

AVERAGE CONNECTION DURATION PER SUBSCRIPTION

10 0

Subscript. 128kbps sub 192kbps sub 512kbps sub 512kbps+sub

all 11.2 min 15.1 min 15.3 min 19.9 min

model 21h 128 kbps sub: 15 extra users 128 kbps sub: 30 extra users 512 kbps+ sub: 15 extra users 512 kbps+ sub: 30 extra users

20

TABLE IV

filtered 15.9 min 21.9 min 21.3 min 28.9 min

0

500

1000

1500

2000

2500

3000

3500

time (sec) Fig. 3. Influence of extra p2p users

1 When modelling the traffic on Sunday at 21h with an upstream bandwidth of 5.12 Mbps

B. Quality of Service in (Euro-)DOCSIS In order to reduce the influence of the p2p traffic on the performance of applications, several QoS facilities of the (Euro-)DOCSIS specifications [2] were examined. These specifications are integrated into most HFC networks, thus making the examined solutions generally applicable. The tested QoS classes are Unsolicited Grant Service (UGS), whereby users get a guaranteed upstream bandwidth, and real-time Polling Service (rtPS), whereby users are guaranteed to receive the opportunity to request upstream bandwidth. A bug in the implementation of the OPNET simulation software prevented us from testing the non-real-time Polling Service. 10

delay (sec)

9

Best effort priority 7 Best effort priority 0

8

Real−time Polling

7

Unsollicited Grant

6 5 4 3 2 1 10

20

30

40

50

60

70

80

load (%) Fig. 4. Quality of Service in (Euro-)DOCSIS

Figure 4 shows the results of the simulation. The delay of an upload application is shown in relation to the total network load. The difference between best effort priorities is negligible. UGS offers a guaranteed bandwidth, useful for real-time applications, at the cost of a potential waste of upstream bandwidth. The performance of rtPS is also satisfactory, offering an almost constant delay, until the load increases too much to give enough bandwidth to the service flow. As a result, UGS is recommended for well-defined real-time traffic and rtPS for more variable traffic. V. C ONCLUSIONS Several p2p characteristics have been examined and distribution models have been proposed, allowing the modelling of p2p traffic on an HFC network. The type of subscription is shown to have a large influence on the amount of traffic sent, the number of active users and the connection duration. Simulations indicate no immediate saturation of the upstream bandwidth. Furthermore, the QoS facilities of the (Euro-)DOCSIS protocol are shown to be sufficient to support QoS applications. ACKNOWLEDGMENTS The author would like to acknowledge the suggestions of ir. Jeffrey De Bruyne. R EFERENCES [1] OPNET - Optimized Network Engineering Tools, http://www.OPNET.com/. [2] DOCSIS specifications, http://www.cablemodem.com/.

Modelleren en analyseren van peer-to-peer verkeer in een HFC-netwerk door Eli DE POORTER Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 2005–2006 Promotor: Prof. Dr. Ir. L. MARTENS Scriptiebegeleider: Ir. J. DE BRUYNE Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie, Voorzitter: Prof. Dr. Ir. P. LAGASSE Onderzoeksgroep Wireless & Cable

Overzicht Daar waar bij traditioneel internetverkeer, zoals webverkeer, gebruikers vooral bestanden downloaden, stellen bij peer-to-peer (p2p) applicaties gebruikers zelf bestanden ter beschikking aan andere p2p-gebruikers. Dit veroorzaakt veel verkeer van de gebruiker naar de provider, zogenaamd ‘upstream’ verkeer. Bij Hybrid Fiber/Coax netwerken (ook bekend onder de naam HFC- of kabelnetwerken) wordt de beschikbare bandbreedte verdeeld over meerdere gebruikers. Dit impliceert dat het netwerkverkeer van p2p-gebruikers de kwaliteit van de verbindingen van andere gebruikers be¨ınvloedt. Het is belangrijk te weten wat de precieze invloed is van p2p-verkeer op de performantie van het netwerk. In deze thesis worden, in eerste instantie, op basis van metingen typische kenmerken van peer-to-peer verkeer afgeleid. Er wordt aangetoond dat het abonnementstype een belangrijke rol speelt. Vervolgens werden modellen opgesteld om het p2p-verkeer te simuleren. Met behulp van de modellen wordt onderzocht in welke mate peer-to-peer verkeer invloed uitoefent op een HFC-netwerk. Hoewel geen saturatie optreedt, blijkt p2p-verkeer een grote invloed te hebben op de belasting van het netwerk. Tenslotte worden een aantal oplossingen onderzocht om de invloed van p2p-verkeer tegen te gaan. Daarbij wordt aangetoond dat de QoS voorzieningen binnen het (Euro-)DOCSIS protocol tijdkritische toepassingen mogelijk te maken.

Trefwoorden Peer-to-peer, HFC-netwerk, (Euro-)DOCSIS, trafiek modellering, OPNET

INHOUDSOPGAVE

i

Inhoudsopgave Lijst met gebruikte afkortingen

vii

1 Inleiding

1

1.1 Situering van de thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.1.1

Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.1.2

Doelstellingen van de thesis . . . . . . . . . . . . . . . . . . . . . .

2

1.1.3

Innovativiteit van de thesis . . . . . . . . . . . . . . . . . . . . . . .

3

1.2 Opbouw van de thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2 Peer-to-peer netwerken

5

2.1 Wat zijn peer-to-peer netwerken? . . . . . . . . . . . . . . . . . . . . . . .

5

2.2 Toepassingen van peer-to-peer netwerken . . . . . . . . . . . . . . . . . . .

6

2.3 Peer-to-peer netwerkarchitectuur

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

7

2.3.1

Verschillende architecturen . . . . . . . . . . . . . . . . . . . . . . .

7

2.3.2

Bestaande file-sharing netwerken

. . . . . . . . . . . . . . . . . . . 10

2.4 Meetmethodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3 HFC-netwerken

14

3.1 Historisch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2 (Euro-)DOCSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.1

Referentie architectuur . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.2

Fysische laag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.3

Downstream MPEG-2 Transport Stream . . . . . . . . . . . . . . . 18

3.2.4

Upstream MAC specificatie . . . . . . . . . . . . . . . . . . . . . . 18

INHOUDSOPGAVE

ii

3.3 Piggybacking, Fragmentation en Concatenation in (Euro-)DOCSIS . . . . . 22 3.4 Quality of Service in (Euro-)DOCSIS . . . . . . . . . . . . . . . . . . . . . 23 4 Dataverwerking

25

4.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2 Situatieschets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2.1

Metingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.2

Types abonnementen . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3 Nodige gegevens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.4 Distributies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.4.1

Uploaddistributie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4.2

Actieve gebruikers per upstreamkanaal . . . . . . . . . . . . . . . . 35

4.4.3

Achtergrondverkeer . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4.4

Connectieduur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.5 Beperkingen van de distributies . . . . . . . . . . . . . . . . . . . . . . . . 48 4.6 Mogelijke oplossingen om de invloed van peer-to-peer verkeer te verkleinen

49

4.6.1

Traffic shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.6.2

Rate limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.6.3

Extra kosten aanrekenen . . . . . . . . . . . . . . . . . . . . . . . . 51

4.6.4

(Euro-)DOCSIS QoS . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.6.5

Peer-caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.6.6

Vergelijking van de oplossingen . . . . . . . . . . . . . . . . . . . . 52

5 Simulaties

54

5.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.2 OPNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.2.1

Implementatie van de peer-to-peer modellen . . . . . . . . . . . . . 57

5.2.2

Tekortkomingen van OPNET . . . . . . . . . . . . . . . . . . . . . 58

5.3 Opbouw van de simulaties . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.4 HFC-simulaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.4.1

Simulatie 1: Overhead door het (Euro-)DOCSIS protocol . . . . . . 61

INHOUDSOPGAVE

5.4.2

iii

Simulatie 2: Invloed van concatenation, piggybacking en fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.4.3

Simulatie 3: Prioriteiten in de DOCSIS module van OPNET . . . . 68

5.4.4

Simulatie 4: QoS in (Euro-)DOCSIS . . . . . . . . . . . . . . . . . 71

5.5 Peer-to-peer simulaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.5.1

Simulatie 5: Vergelijking van de belasting gedurende een piekuur en een daluur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.5.2

Simulatie 6: Invloed van de uploadsnelheid op piekverbruik . . . . . 77

5.5.3

Simulatie 7: Invloed van peer-to-peer op de QoS van ander verkeer

5.5.4

Simulatie 8: Invloed van extra peer-to-peer verkeer . . . . . . . . . 81

79

5.6 Beperkingen van de simulaties . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.7 Oplossingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 6 Verder onderzoek

85

7 Besluiten

88

A Overzicht van de door de netwerkanalyser onderscheidbare protocollen 90 B Instellingen bij de verschillende simulaties

92

B.1 Profielen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 B.2 Gebruikte profielen bij de simulaties . . . . . . . . . . . . . . . . . . . . . . 95

LIJST VAN FIGUREN

iv

Lijst van figuren 2.1 Gedecentraliseerde peer-to-peer architectuur . . . . . . . . . . . . . . . . .

8

2.2 Gecentraliseerde peer-to-peer architectuur . . . . . . . . . . . . . . . . . .

9

2.3 Hybride peer-to-peer architectuur . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 Oorspronkelijke CATV netwerkstructuur . . . . . . . . . . . . . . . . . . . 15 3.2 HFC netwerkstructuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3 Verdeling van het spectrum bij een HFC-netwerk . . . . . . . . . . . . . . 17 3.4 Structuur van een MAP PDU . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1 Structuur van het opgemeten netwerk . . . . . . . . . . . . . . . . . . . . . 26 4.2 Gemiddelde uploadsnelheid per klant van het 128 kbps abonnement op zondag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.3 Fitting van de distributie van de uploadhoeveelheid van het p2p-verkeer bij het 512 kbps abonnement . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4 Fitting van het aantal actieve gebruikers . . . . . . . . . . . . . . . . . . . 36 4.5 Gemiddeld aantal actieve gebruikers per uploadkanaal voor het 128 kpbs abonnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.6 Gemiddeld aantal actieve gebruikers per uploadkanaal voor het 192 kpbs abonnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.7 Gemiddeld aantal actieve gebruikers per uploadkanaal voor het 512 kpbs abonnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.8 Gemiddeld aantal actieve gebruikers per uploadkanaal voor het 512 kpbs abonnement Extra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

LIJST VAN FIGUREN

v

4.9 Percentage gebruikers dat actief is per uploadkanaal voor een 128 kbps abonnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.10 Percentage gebruikers dat actief is per uploadkanaal voor een 192 kbps abonnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.11 Percentage gebruikers dat actief is per uploadkanaal voor een 512 kbps abonnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.12 Percentage gebruikers dat actief is per uploadkanaal voor een 512 kbps abonnement Extra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.13 Fitting van de distributie van de uploadgrootte van het niet-p2p verkeer bij het 512 kbps abonnement . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.14 Connectieduur van een peer-to-peer gebruiker . . . . . . . . . . . . . . . . 47 4.15 Connectieduur van een peer-to-peer gebruiker (0 tot 60 minuten interval) . 47 4.16 Connectieduur van een peer-to-peer gebruiker (niet gefilterd) . . . . . . . . 48 5.1 Voorbeeld van een HFC-netwerk in OPNET . . . . . . . . . . . . . . . . . 56 5.2 Eenvoudig model van p2p gebruikers . . . . . . . . . . . . . . . . . . . . . 59 5.3 Upstream overhead bij het (Euro-)DOCSIS protocol . . . . . . . . . . . . . 62 5.4 Bezettingsgraad uitgedrukt als ‘reserved time slot/MAP duration’ . . . . . 62 5.5 Encapsulatie van data frames in DOCSIS frames . . . . . . . . . . . . . . . 65 5.6 Invloed van concatenation, piggybacking en fragmentation . . . . . . . . . 67 5.7 Effect van prioriteiten op korte termijn . . . . . . . . . . . . . . . . . . . . 70 5.8 Effect van prioriteiten op lange termijn . . . . . . . . . . . . . . . . . . . . 70 5.9 Effect van granting services op delay . . . . . . . . . . . . . . . . . . . . . 72 5.10 Bezettingsgraad van het kanaal om een piekmoment (tussen 21u en 22u) . 75 5.11 Bezettingsgraad zonder p2p- en met p2p-verkeer . . . . . . . . . . . . . . . 75 5.12 Vergelijking van de bezettingsgraad tussen een piekmoment (tussen 21u en 22u) en een daluur (tussen 6u en 7u) . . . . . . . . . . . . . . . . . . . . . 76 5.13 Invloed van de uploadsnelheid op piekverbruik . . . . . . . . . . . . . . . . 78 5.14 Invloed van extra p2p gebruikers . . . . . . . . . . . . . . . . . . . . . . . 82

LIJST VAN TABELLEN

vi

Lijst van tabellen 4.1 Verschillende uploaden downloadsnelheden bij de abonnementstypes . . . 28 4.2 Verschillende uploaden downloadlimieten per maand bij de abonnementstypes 28 4.3 Gemiddelde uploadsnelheid van het p2p-verkeer op zondag om 21 uur ’s avonds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.4 Gemiddelde uploadsnelheid van het achtergrondverkeer op zondag om 21 uur ’s avonds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.5 Gemiddelde connectieduur per protocol . . . . . . . . . . . . . . . . . . . . 45 4.6 Gemiddelde connectieduur per abonnement . . . . . . . . . . . . . . . . . . 46 4.7 Vergelijking van de effectiviteit van de verschillende voorgestelde oplossingen om de invloed van p2p-verkeer te beperken

. . . . . . . . . . . . . . . 53

5.1 MAP interarrival tijden voor verschillende uploadsnelheden . . . . . . . . . 60 5.2 Invloed van piggybacking op bursty en non-bursty verkeer . . . . . . . . . 68 5.3 Instellingen van de CM’s bij simulatie 3 . . . . . . . . . . . . . . . . . . . . 69 5.4 Aantal actieve gebruikers van de verschillende abonnementstypes bij simulatie 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.5 Delay bij de verschillende QoS mogelijkheden in een realistische situatie . . 80 5.6 Gemiddelde bezettingsgraad bij meer p2p-gebruikers

. . . . . . . . . . . . 82

A.1 Overzicht van de door de netwerkanalyser onderscheidbare protocollen . . . 91

LIJST MET GEBRUIKTE AFKORTINGEN

Lijst met gebruikte afkortingen p2p peer-to-peer VoIP Voice Over IP QoS Quality of Service MAC Media Access Control FEC Forward Error Correction CATV Community Antenna TeleVision HFC-netwerk Hybrid Fiber/Coax netwerk (Euro-)DOCSIS (European) Data-Over-Cable Service Interface Specification CM Cable Modem CMTS Cable Modem Termination System SID Service Identifier SFID Service Flow Identifier QAM Quadrature Amplitude Modulation QPSK Quadrature Phase-shift Keying TDMA Time Division Multiple Access BE Best Effort

vii

LIJST MET GEBRUIKTE AFKORTINGEN

rtPS real-time Polling Service nrtPS non-real-time Polling Service UGS Unsollicited Grant Service

viii

INLEIDING

1

Hoofdstuk 1 Inleiding 1.1 1.1.1

Situering van de thesis Probleemstelling

Het internet is een medium dat voortdurend aan verandering onderhevig is. Reeds lange tijd wordt zogenaamd peer-to-peer verkeer alsmaar populairder. Bij peer-to-peer verkeer (‘p2p-verkeer’) is er een rechtstreekse uitwisseling van informatie tussen twee klanten (ook wel ‘peers’ genoemd). Deze toepassingen werden vooral bekend onder de vorm van file-sharing. Bij deze toepassing wisselen klanten (meestal illegale) bestanden met elkaar uit. Een typisch kenmerk van peer-to-peer verkeer is dat het in principe symmetrisch verkeer is. Er wordt dus evenveel ge-upload als gedownload. Peer-to-peer netwerken zijn een relatief recentelijk fenomeen. Het eerste populaire file-sharing programma (Napster) ontstond pas in juni 1999. Bij het ontwerp van Hybrid Fiber/Coax netwerken (HFC-netwerken: breedbandtoegangsnetwerken waarbij in de last-mile gebruik gemaakt wordt van een coaxiale-kabel) werd uitgegaan van een intrinsiek asymmetrisch verkeerspatroon. Deze treden typisch op bij bijvoorbeeld web-verkeer waarbij webpaginas gedownload worden van een server. Aangezien asymmetrisch verkeer domineerde ten tijde van het ontwerp van HFC-netwerken, werd een veel grotere bandbreedte toegekend aan downstream verkeer dan aan upstream verkeer.

1.1 Situering van de thesis

2

Met de toename van het gebruik van symmetrische diensten (file-sharing, Voice-over-IP, etc.) ontstaat een reëel risico dat saturatie optreedt van de beschikbare upstreambandbreedte in een HFC-netwerk. Volgens sommige studies bedraagt het aandeel van peer-topeer verkeer reeds 60% tot 80% van de bandbreedte ([1],[2]). Zelfs indien hierdoor geen saturatie optreedt, kan dit verkeer een negatieve invloed uitoefenen op de prestatie van andere, bijvoorbeeld tijdskritische, toepassingen. De upload-bandbreedte van een HFCnetwerk is beperkt en wordt verdeeld over meerdere gebruikers. Dit impliceert dat het netwerkverkeer van p2p-gebruikers de kwaliteit van de verbindingen van andere gebruikers be¨ınvloedt. Er bestaat dus een grote behoefte aan onderzoek naar de invloed van p2p-toepassingen in een HFC-netwerk.

1.1.2

Doelstellingen van de thesis

De einddoelstelling van deze thesis is, om aan de hand van een realistisch netwerkmodel na te gaan wat de precieze invloed is van p2p-verkeer op de performantie van het HFCnetwerk en welke mogelijke oplossingen beschikbaar zijn voor de provider. Om dit doel te bereiken worden een aantal bijkomende onderzoeksdoelstellingen geformuleerd. • Dataverwerking Uitgevoerde metingen op het netwerk van een netwerkprovider, vormen het vertrekpunt van deze thesis. Op basis van deze meetdata wordt het p2p-verkeer onderzocht, waarbij een sterke nadruk wordt gelegd op de verschillende abonnementstypes. Aan de hand van de verkregen onderzoeksresultaten worden bruikbare distributies afgeleid, geschikt voor het modelleren van p2p-verkeer. • OPNET Vervolgens wordt onderzocht in welke mate de OPNET netwerksimulator voldoet om HFC-netwerken te simuleren. Er wordt vooral aandacht besteed aan de eventuele beperkingen van OPNET. • (Euro-)DOCSIS parameters Tenslotte wordt onderzocht wat de verschillende mogelijkheden zijn van (Euro-)-

1.1 Situering van de thesis

3

DOCSIS om de nadelige invloed van peer-to-peer verkeer af te zwakken. Daartoe worden, met behulp van OPNET, verschillende netwerksituaties gesimuleerd. Aangezien een HFC-netwerk vooral beperkt is wat betreft upstreambandbreedte, wordt enkel het upstreamverkeer bestudeerd.

1.1.3

Innovativiteit van de thesis

Rond p2p-verkeer is reeds heel wat onderzoek verricht. Toch is deze thesis relevant en vernieuwend. Zo wordt in 4.4.1 aangetoond dat de frequent gebruikte distributies niet optimaal zijn om p2p-verkeer te modelleren. De meeste p2p-modelleringsstudies ([1], [3], [4]) richten zich op het onderzoeken van verschillende statistieken als connectieduur, bestandsgrootte en het aantal connecties. Deze distributies zijn niet geschikt om simulaties uit te voeren, zowel vanwege hun complexiteit als vanwege de beperkingen van de simulatiesoftware. In deze thesis worden distributies afgeleid die geschikt zijn om simulaties uit te voeren. Gebruikersstatistieken kunnen op verschillende manieren afgeleid worden. Zo wordt dikwijls gebruik gemaakt van trackers waarbij individuele gebruikers nauwkeurig gevolgd kunnen worden [5]. Dit zorgt voor nauwkeurige metingen, maar slechts een beperkte hoeveelheid data. Een alternatief is het uitvoeren van metingen in de back-end van een provider. Deze methode werd voor deze thesis gebruikt. Dit resulteert in een veel grotere hoeveelheid meetdata, die meestal geaggregeerd wordt per uur [6]. Doordat de metingen van deze thesis het gebruik per minuut weergeven, is het mogelijk individuele gebruikersstatistieken te benaderen en toch te beschikken over een groot aantal metingen. Volgens onze gegevens is dit de eerste modelleringsstudie op basis van dergelijk fijne metingen in een head-end. In de literatuur wordt vooral aandacht geschonken aan algemene distributies zonder daarbij te beschikken over abonnementgegevens. Bij het afleiden van de distributies, wordt in deze thesis onderscheid gemaakt tussen verschillende abonnementtypes. Dit onderscheid laat toe verschillende gedragingen tussen abonnementen te onderzoeken.

1.2 Opbouw van de thesis

4

Tenslotte is het, naar wij weten, de eerste maal dat statistieken worden afgeleid over het aantal gebruikers dat actief is per kanaal in een HFC-netwerk.

1.2

Opbouw van de thesis

In deze paragraaf wordt kort omschreven welke onderwerpen in de verschillende hoofdstukken behandeld worden. De eerste 3 hoofdstukken bevatten vooral achtergrondinformatie nodig voor het onderzoek, alsook resultaten verkregen uit literatuurstudie. In de volgende hoofdstukken worden de onderzoeksresultaten overlopen. In het tweede hoofdstuk wordt een duidelijk beeld geschetst omtrent p2p-verkeer. De verschillende soorten p2p-netwerken worden besproken. Ook wordt dieper ingegaan op de verschillende meetmethodes van p2p-verkeer. Er wordt afgesloten met een aantal mogelijke oplossingen om de invloed van p2p-verkeer af te zwakken. Het derde hoofdstuk behandelt HFC-netwerken. De ontstaansgeschiedenis wordt kort toegelicht en de typische kenmerken worden weergegeven. De rol van (Euro-)DOCSIS wordt toegelicht. De verschillende mechanismen die het uploadverkeer regelen worden behandeld, alsook een aantal parameters die van belang zijn voor het onderzoek. In het vierde hoofdstuk wordt het verband gelegd tussen peer-to-peer verkeer en een HFC-netwerk. Er wordt verduidelijkt welke gegevens noodzakelijk zijn om simulaties uit te voeren. De beschikbare meetdata wordt besproken. Een aantal conclusies uit de verwerking van deze data worden opgesomd. Tenslotte worden algemene distributies afgeleid die geschikt zijn om simulaties uit te voeren. Het vijfde hoofdstuk behandelt de uitgevoerde simulaties. De gebruikte software om de simulaties uit te voeren wordt besproken met de bijhorende voor- en nadelen. Hierna volgen een aantal (Euro-)DOCSIS specifieke simulaties. In het volgende onderdeel worden simulaties uitgevoerd met p2p-gebruikers in een HFC-netwerk. In hoofdstuk 6 worden suggesties gedaan voor latere onderzoeken. Het zevende en laatste hoofdstuk herhaalt beknopt de belangrijkste besluiten van het onderzoek.

PEER-TO-PEER NETWERKEN

5

Hoofdstuk 2 Peer-to-peer netwerken 2.1

Wat zijn peer-to-peer netwerken?

Een peer-to-peer (dikwijls afgekort tot p2p) computernetwerk is een netwerk waarbij verschillende participanten in een netwerk samenwerken om een taak te verrichten. Dit in tegenstelling tot een traditioneel netwerk, waar klanten diensten aanvragen bij een centrale server. Peer-to-peer netwerken worden typisch opgebouwd uit klanten die op een ad hoc wijze verbonden worden. De klanten worden ‘peers’ genoemd, wat staat voor ‘gelijken’. Een puur peer-to-peer netwerk bestaat niet uit servers en clients. Alle gebruikers zijn gelijke nodes die tegelijk als ‘server ’ en als ‘client’ optreden. Dit type netwerk verschilt van het client-server model waar communicatie enkel van en naar een centrale server gebeurt. Een typisch voorbeeld van de client-server architectuur is een ftp-server waar het clienten serverprogramma niet gelijk zijn aan elkaar. De client initieert de download/upload en de servers reageren om aan de vraag te voldoen. Peer-to-peer networking bestaat reeds geruime tijd en neemt een steeds meer dominante plaats in bij het internetverkeer. Recente metingen duiden aan dat peer-to-peer verkeer een belangrijk aandeel vormt van het totale netwerkverkeer [2].

2.2 Toepassingen van peer-to-peer netwerken

2.2

6

Toepassingen van peer-to-peer netwerken

Peer-to-peer netwerken zijn bij het brede publiek vooral bekend onder de vorm van filesharing netwerken. Hierbij worden bestanden tussen gebruikers onderling uitgewisseld. Peer-to-peer verkeer kende vooral succes vanwege het ongereguleerde aspect ervan. Zo worden bij vele file-sharing netwerken allerhande content (zoals muziek, software en films) gratis ter beschikking gesteld van andere gebruikers, zonder rekening te houden met auteursrechten. Legale acties lieten niet lang op zich wachten. Maar telkens het RIAA (Recording Industry Association of American) met succes een p2p-netwerk probeert te blokkeren, duikt een ander moeilijker te blokkeren p2p-applicatie op [7]. De bekendste file-sharing toepassingen zijn Kazaa [3] en Napster [8]. Hoewel file-sharing vooral het uitwisselen van illegale bestanden betreft, worden peer-topeer netwerken ook voor heel wat legale toepassingen gebruikt. Zo zegt [9] over legale file-sharing: It is important for commercial p2p distribution systems to publicize and ” encourage their legal uses and applications. In this regard, applications such as those recently enabled by the BBC for distributing TV shows, the World of Warcraft ingame patching system, or the distribution of the independent film Star Wreck, can help improve perception over p2p networks.” Peer-to-peer toepassingen zijn vooral voordelig voor toepassingen die veel bandbreedte vereisen, en die door veel gebruikers op het zelfde moment opgevraagd worden. Het (volledig of suplementair) verdelen van patches of films via peer-to-peer netwerken vereist veel minder bandbreedte van de centrale servers en kan dus een groot financieel voordeel opleveren voor de providers. De uploadkost wordt als het ware verdeeld over de klanten, die dus niet enkel de gevraagde bestanden downloaden, maar deze ook helpen verspreiden. Een laatste toepassing waarbij p2p-netwerken gebruikt wordt is het uitwisselen van realtime data. Doordat gebruikers rechtstreeks met elkaar verbonden zijn treedt weinig overhead op bij de verbindingen tussen de gebruikers. Het meest bekende voorbeeld hiervan is internet telefonie. Bij dit type diensten wordt een verbinding met een beperkt aantal peers gemaakt, in tegenstelling tot file-sharing waar veel meer connecties gemaakt worden.


7

In de toekomst zulleb peer-to-peer protocollen ge¨ımplementeerd worden in heel wat meer applicaties. De toepassingen variëren van Voice-over-IP, spelletjes en virtuele kantoren [10] tot gedistribueerde rekencentra (distributed computing).

2.3

Peer-to-peer netwerkarchitectuur

Bij een peer-to-peer netwerk zijn de gebruikers rechtstreeks met elkaar verbonden. Toch is het nuttig een onderscheid te maken tussen controleverkeer en dataverkeer. Sommige peer-to-peer applicaties nemen immers een aantal voordelen over van de traditionele clientserver architectuur. In deze sectie wordt een overzicht gegeven van een aantal veel voorkomende architecturen voor file-sharing applicaties. De overdracht van de data gebeurt steeds op basis van peer-to-peer 1 . De architecturen worden onderscheiden op basis van de wijze waarop controleverkeer behandeld wordt. Op basis hiervan worden verschillende architecturen onderscheiden voor p2p-netwerken.

2.3.1

Verschillende architecturen

Gedecentraliseerd peer-to-peer netwerk Een eerste mogelijke architectuur is een gedecentraliseerde (of ‘pure’) p2p-architectuur (zie figuur 2.1). In een pure p2p architectuur wordt geen gebruik gemaakt van een centrale server. De gebruikers connecteren met andere gebruikers die reeds verbonden zijn met het netwerk. Het uitzenden van controleboodschappen (om verbonden te blijven, om bestanden te zoeken, ...) gebeurt door broadcasting. Enkele typische kenmerken: • Trage search/query antwoorden die veel netwerkverkeer genereren. • Netwerk performantie hangt af van de gebruikers • Geen centraal kwetsbaar punt 1

Op eventuele data-hubs na waarin data geaggregeerd wordt


8

Figuur 2.1: Gedecentraliseerde peer-to-peer architectuur • Geen centraal controle punt • Weinig schaalbaar Gecentraliseerd peer-to-peer network In een gecentraliseerde (of ‘mediated’) architectuur wordt een centrale server gebruikt voor het afhandelen van controleboodschappen (zie figuur 2.2). Elke gebruiker moet eerst deze server contacteren vooraleer dataverkeer verzonden kan worden. Enkele typische kenmerken: • Snelle search/query antwoorden • Eenvoudig protocol • Hoog performant • Kwetsbaar voor Denial-of-Service aanvallen


9

Figuur 2.2: Gecentraliseerde peer-to-peer architectuur • Kwetsbaar voor rechtszaken of andere legale acties • Mogelijkheid tot controle over de beschikbare data • Eenvoudig schaalbaar Hybride peer-to-peer netwerk Een hybride architectuur is opgebouwd uit een combinatie van een gecentraliseerde en een gedecentraliseerde architectuur (zie figuur 2.3). Hierbij treden sommige gebruikers (soms tijdelijk) op als servers waarmee andere gebruikers een verbinding maken. Deze tijdelijke servers worden soms gerefereerd als ‘superusers’ of ‘supernodes’. De gewone gebruikers verzenden hun controleboodschappen naar deze servers, en de servers versturen onderling controleboodschappen. Enkele typische kenmerken: • Goede search/query antwoorden waarbij minder verkeer wordt gegenereerd dan bij pure p2p-netwerken • Goede performantie en robuustheid dankzij het gebruik van supernodes


10

Figuur 2.3: Hybride peer-to-peer architectuur • Geen centraal kwetsbaar punt • Geen centraal controle punt • Goed schaalbaar

2.3.2

Bestaande file-sharing netwerken

Er bestaan veel peer-to-peer file-sharing applicaties en protocollen. Bij een bekende opensource community staan op dit moment (april 2006) 4 filesharing applicaties in de top 5 van ‘Most Downloaded’ programma’s2 . In deze sectie wordt een overzicht gegeven van een aantal populaire p2p-protocollen, en tot welke architectuur ze behoren. Van sommige protocollen bestaan meerdere implementaties, in dit geval worden enkele van de populaire implementaties weergegeven. Merk op dat de hybride architectuur veruit de meest gebruikte is. 2

Most Downloaded programs on http://sourceforge.net/: 1. eMule

2. Ares Galaxy

3. Azureus - BitTorrent Client

4. phpBB

5. Shareaza


11

Gecentraliseerde architectuur • Napster • Audiogalaxy Hybride architectuur • Gnutella Voorbeelden: Limewire, Bearshare, Gnotella, Xolox, Morpheus, Gnucleus • FastTrack Voorbeelden: Kazaa, Musiccity, Grokster, Early Morpheus • eDonkey • OpenNap Voorbeelden: WinMX, Napigator Gedecentraliseerde architectuur • Early Gnutella • Freenet Een alternatieve opdeling kan worden gemaakt op basis van de structuur inherent aan het betreffende protocol. Zo wordt in [11] een opdeling gegeven, gebaseerd op de mate waarin de positie van de bestanden controleerbaar is. Er wordt gesproken over een gestructureerd netwerk indien de netwerk topology strikt controleerbaar is en bestanden worden geplaatst op duidelijk specificeerbare plaatsen. Peer-to-peer netwerken met dit kenmerk zijn o.a. Chord, CAN, PAST en Tapestry. Er wordt over ‘loosely structured networks’ gesproken indien file-locaties be¨ınvloed worden door routeringshints, maar niet gedetailleerd gespecificeerd worden, waardoor niet alle zoekopdrachten succesvol zijn. Een voorbeeld van een ‘loosely structured network’ is Freenet. De overige, hoger weergegeven p2p-protocollen behoren tot de ongestructureerde netwerken.

2.4 Meetmethodes

2.4

12

Meetmethodes

Er bestaan verschillende methodes om informatie over peer-to-peer verkeer te verkrijgen. Wanneer gedetailleerde informatie onderzocht wordt, maakt men meestal gebruik van trackers. Bij deze worden specifieke kenmerken van het p2p-protocol aangewend om gegevens te vergaren. Zo maakt [5] gebruik van een server tracker: om bestanden te downloaden met behulp van het bittorrent protocol moet verbinding worden gemaakt met een centrale server. Deze houdt een logbestand bij dat veel gegevens bevat en waaruit informatie gehaald kan worden, zoals de duur van de connecties, de tijd nodig om een bestand te downloaden en het aantal downloadsessies per gebruiker. Een andere methode maakt eveneens gebruik van protocol-afhankelijke informatie. Hierbij doet de onderzoekende computer zich voor als een ‘gewone’ p2p-gebruiker [12]. Op deze wijze kunnen gegevens, zoals het aantal gedeelde bestanden, het aantal connecties met andere peers en de downloaden uploadsnelheid, worden afgeleid. Deze methode kan worden geoptimaliseerd [13] door met behulp van scripts wijzigingen aan te brengen aan het standaard protocol van de onderzoekende computer. Een derde methode om gegevens te vergaren, is gebruik makend van trafiekmetingen. Deze gebeuren meestal op een centrale plaats waar verkeer geaggregeerd wordt. Dit kan bijvoorbeeld een p2p-cache zijn [3], op een universiteitscampus [1], een ADSL edge-router [6], of een kopstation van een HFC-netwerk zoals in dit onderzoek. Dit type metingen levert meestal meer gegevens op, ten koste van de gedetailleerdheid ervan. Wanneer men gebruik maakt van trafiekmetingen, kan onderscheid gemaakt worden tussen actieve en passieve meetmethodes. Bij passieve meetmethodes wordt p2p-verkeer ge¨ıdentificeerd op basis van het poortnummer. Deze meetmethodes vereisen meestal geen kennis van de specifieke p2p-protocollen. In [2] en [14] wordt aangetoond dat deze aanpak niet heel effectief is: de meeste recente p2p-protocollen gebruiken dynamische of variabele poorten, of maskeren het verkeer door gebruikt te maken van poorten die typisch geassocieerd worden met ander verkeer zoals webverkeer (poort 80). Bij actieve meetmethodes wordt gebruik gemaakt van pakketinspectie. De ontvangen pakketten worden geanalyseerd waarbij gezocht wordt naar typische kenmerken van peer-to-peer protocollen. Het

2.4 Meetmethodes

13

gebruik van dynamische poorten en de toenemende trend om pakketten te encrypteren bemoeilijkt de analyse van peer-to-peer verkeer door middel van trafiekmetingen.

HFC-NETWERKEN

14

Hoofdstuk 3 HFC-netwerken 3.1

Historisch

Community Antenna TeleVision netwerken (CATV-netwerken, zie figuur 3.1) werden gedurende lange tijd gebruikt voor de distributie van televisieprogramma’s naar de klanten. Ze bestaan uit een tree-and-branch structuur waarbij coaxiale kabel wordt gebruikt voor de transmissie. De tv-signalen worden opgevangen in een kopstation (‘headend’) en verstuurd naar de klanten over de coaxiale kabel. Ze zijn dus vooral geoptimaliseerd voor unidirectionele transmissie van signalen. Het CATV-netwerk bestaat uit 5 belangrijke onderdelen. Het kopstation wordt gebruikt om analoge signalen op te vangen. De signalen worden met weinig verlies verdeeld via een dikke trunk kabel. Aan de bridge-versterker wordt het signaal verdeeld over verschillende distributiekabels. Het signaal wordt met behulp van taps via een drop-kabel met een klant verbonden. Typisch worden 4 klanten verbonden met één tap. Tenslotte bereiken de signalen de terminal equipment. CATV-netwerken beschikten over een grote bandbreedte en kenden een grote verspreiding (in België hadden meer dan 90% van de gezinnen de mogelijkheid tot verbinding met een CATV netwerk). Er was bijgevolg grote interesse om deze netwerken aan te passen tot volwaardige multimedianetwerken. Hiertoe werden de verschillende head-ends verbonden met een backbone van glasvezel. Een gedeelte van de trunk-kabels werden vervangen

3.2 (Euro-)DOCSIS

15

Figuur 3.1: Oorspronkelijke CATV netwerkstructuur door glasvezel. Enkel de ‘last mile’ bleef coax-kabel vanwege de hoge graafkosten om in stedelijke gebieden nieuwe kabels aan te leggen. Dit nieuwe type netwerken werden Hybrid Fiber/Coax netwerken (HFC-netwerken) genoemd. Enkele andere aanpassingen werden nog uitgevoerd om breedbandtoegang mogelijk te maken. Er werden bidirectionele versterkers toegevoegd, de modulatie ging van analoog naar digitaal en er werden geavanceerde modulatietechnieken toegepast.

3.2

(Euro-)DOCSIS

Data over Cable System Interface Specifications (DOCSIS) is een standaard die toelaat dat verscheidene gebruikers het HFC-kabel medium delen. Het werd ontwikkeld door CableLabs als algemene standaard voor bidirectionele communicatie over HFC-netwerken. DOCIS specificeert zowel de fysische laag als de Medium Acces Control (MAC) laag. Het MAC-protocol beschrijft de interactie tussen de Cable Modem (CM) van de klant en het Cable Modem Termination System (CMTS) aan de head-end zijde van het netwerk. Het oorspronkelijk protocol was versie 1.0 (v1.0) en liet best-effort data diensten toe.

3.2 (Euro-)DOCSIS

16

Een latere versie, DOCSIS v1.1, voegde onder andere Quality of Service, security en authenticatie voorzieningen toe. Tenslotte werd ook DOCSIS v2.0 ontwikkeld. Deze biedt ondersteuning voor een geavanceerdere fysische laag en een moduleerbaar aantal kanalen. In de volgende uiteenzetting wordt DOCSIS v2.0 niet behandeld. Aangezien DOCSIS een Amerikaanse standaard is, zijn aanpassingen nodig voor het gebruik in Europa. Deze aanpassingen werden gedefinieerd in een uitbreiding: EuroDOCSIS. De wijzigingen betreffen voornamelijk de verdeling van de frequenties.

3.2.1

Referentie architectuur

Figuur 3.2: HFC netwerkstructuur

Om de (Euro-)DOCSIS standaard te ondersteunen werden een aantal aanpassingen uitgevoerd in het HFC-netwerk. Deze werden vernoemd in deel 3.1 en resulteren in de huidige netwerkstructuur zoals weergegeven in figuur 3.2. Het HFC-netwerk is geschikt voor analoge tv-distributie en analoge telefonie. Het (Euro-)DOCSIS protocol werd ontwikkeld om ook digitale telefonie en internet toegang te ondersteunen. Het Cable Modem

3.2 (Euro-)DOCSIS

17

Termination System (CMTS) is verbonden met het publieke internet enerzijds (rechts van figuur 3.2) en het HFC-netwerk anderzijds (links van de figuur). Het netwerk bestaat uit een glasvezel gedeelte en een tree-and-branch coaxiaal gedeelte. Aan de gebruikerszijde worden de analoge tv-signalen verwijderd en de digitale signalen worden gedecodeerd in de Cable Modem (CM). De digitale signalen kunnen dan op meerdere manieren de gebruikerstoestellen bereiken, bijvoorbeeld via Ethernet, USB of WiFi.

3.2.2

Fysische laag

Het beschikbare spectrum over de coax-kabel is opgesplitst in een upstream en een downstream gedeelte. De scheiding tussen up- en downstream verkeer gebeurt door Frequency Division Duplex (FDD). Dit is weergegeven in figuur 3.3. De exacte verdeling van de frequenties hangt af van de operator en de wetgeving van het betreffende land. Algemeen

Figuur 3.3: Verdeling van het spectrum bij een HFC-netwerk worden de lagere frequenties (tussen 5 MHz en 65 MHz) toegekend aan het upstream verkeer . Het overgrote deel van de bandbreedte wordt gebruikt voor downstream verkeer (tussen 80 MHz en 860 MHz). De downstream bandbreedte wordt opgedeeld in kanalen van 8 Mhz. Een downstreamkanaal kan gebruikt worden voor een of meerdere toepassingen. In het downstream spectrum vinden we dus kanalen met analoge tv-signalen, FM radio, digitale tv of data-pakketten. De upstreamkanalen zijn smaller, gaande van 200 kHZ tot 3.2 MHz. Aangezien deze kanalen ook gevoeliger zijn voor ruis, blijkt reeds de intrinsiek asymmetrische veronderstelling dat downstream bandbreedte belangrijker is dan upstream bandbreedte. De downstream bandbreedte is gedefinieerd van 80 tot 862 MHz. Hierin worden kanalen gedefinieerd van elk 8 MHz. Over deze kanalen wordt een continue stroom van MPEG2

3.2 (Euro-)DOCSIS

18

pakketten verstuurd van elk 188 bytes. Er worden twee snelheden ondersteund: 41.4 Mbit/sec (modulatie 64-QAM) en 55 Mbit/sec (modulatie 256-QAM). De upstream bandbreedte is kleiner en gaat van 5 tot 65 MHz. De gebruikte kanalen hebben een variabele breedte van 200 kHz tot 3,2 MHz. Er is een grotere verscheidenheid aan mogelijke snelheden. Wanneer QPSK modulatie gebruikt wordt kan een bandbreedte van 0.32, 0.64, 1.28, 2.56 of 5.12 Mbit/sec ondersteund worden. Indien 16-QAM gebruikt wordt zijn de mogelijke snelheden 0.64, 1.28, 2.56, 5.12 of 10.24 Mbit/sec. Een CM is verbonden met één upstream kanaal en één downstream kanaal. Het upload kanaal ondersteunt ethernetframes van variabele lengte. Dit gebeurt door middel van een MAC protocol op basis van ‘contention’ en ‘granted acces’. In het volgende punt wordt hierop dieper ingegaan.

3.2.3

Downstream MPEG-2 Transport Stream

De beschikbare bandbreedte wordt gedeeld tussen de verschillende gebruikers. Aangezien de CMTS met verschillende gebruikers in verbinding staat betreft het hier een point-tomultipoint systeem. Over de downstream kanalen worden door de CMTS voortdurend MPEG-2 pakketten verstuurd. Dit zijn pakketten van 188 bytes waarvan 4 headerbytes. De MPEG-2 stroom kan verschillende soorten data bevatten, zo kan MPEG-2 video en data gemengd worden in één kanaal. De MPEG-2 payload kan (Euro-)DOCIS data pakketten bevatten, de pakketten voor de verschillende gebruikers worden door de CMTS na elkaar verstuurd.

3.2.4

Upstream MAC specificatie

De beschikbare bandbreedte wordt gedeeld tussen de verschillende gebruikers. Het systeem is ‘multipoint-to-point’: een CMTS is verbonden met meerdere CM’s. De kabel modems staan niet rechtstreeks met elkaar in verbinding. Er is dus behoefte aan een coördinatieprotocol dat aangeeft wanneer elke CM data mag verzenden. Dit protocol wordt een MAC-protocol genoemd (Medium Acces Control Protocol).

3.2 (Euro-)DOCSIS

19

Figuur 3.4: Structuur van een MAP PDU DOCSIS maakt gebruik van een gecentraliseerde aanpak op basis van reservatie om bandbreedte toe te wijzen op het upstream kanaal. De upstream stroom is opgebouwd uit een reeks minislots, met een dynamisch aantal contention (aanvraag) slots en gereserveerde slots voor upstream verkeer (Time Division Multiplexing Acces of TDMA). De contention slots kunnen gebruikt worden door CM’s om transmissiemogelijkheid aan te vragen aan de CMTS. De CMTS zendt regelmatig Bandwidth Allocation Map (MAP) boodschappen over het downstream kanaal om de CM’s te verwittigen welke upstream mini-slots aan hen toegewezen worden. De Allocation MAP is een MAC Management boodschap die beschrijft welke slots toegewezen zijn aan een specifieke CM om data te verzenden, welke slots beschikbaar zijn voor contention en welke slots voorzien zijn voor nieuwe CM’s die gebruik willen maken van dit kanaal. De Allocation MAP is een MAC boodschap van variabele lengte die de transmissiegelegenheden van het upstream kanaal beschrijft. Hij bestaat uit een header van vaste lengte, gevolgd door een variabel aantal Information Elements (IE’s). Een IE beschrijft het toegestane gebruik van een reeks minislots. Elke IE bestaat uit een 14 bit

3.2 (Euro-)DOCSIS

20

SID (Service Identifier), een 4 bit type code en een 14 bit starting offset. Het begrip SID wordt meer specifiek omschreven in deel 3.4, maar kan beschouwd worden als een actieve CM. De 4 types SID zijn broadcast (bedoeld voor alle CM’s), multicast (bedoeld voor een bepaalde groep van CM’s), unicast (bedoeld voor 1 CM) en een null adres (niet bedoeld voor een CM). De starting offset geeft de minislots aan, waarover de IE informatie bevat. De mogelijke IE’s die verzonden kunnen worden door een CMTS in een MAP zijn: Request IE beschrijft een interval waarin aanvragen voor upload datatransmissie verstuurd mogen worden. Request/Data IE beschrijft een interval waarin aanvragen voor upload datatransmissie of korte datapakketten verstuurd mogen worden. Initial Maintenance IE beschrijft een interval waarin een nieuwe CM het netwerk mag vervoegen. Station Maintenance IE beschrijft een interval waarin CM’s boodschappen kunnen versturen, nodig voor routine onderhoud. Null IE wordt gebruikt om het einde van de lijst met gealloceerde minislots aan te duiden. Short and Long Data Grant IE’s worden beiden gebruikt om minislots toe te wijzen aan een CM die een upload bandbreedte heeft aangevraagd. Short Data Grants worden gebruikt voor burst die korter zijn dan de maximal burst size die opgegeven wordt in de Upstream Channel Descriptor (UCD). Long Data Grants worden gebruikt voor data die deze lengte overschrijden. Een Data Grant IE mag een lengte van 0 minislots toewijzen, in welk geval het een Data Grant Pending IE is. Deze informeert de CM dat zijn aanvraag ontvangen is, maar er tijdelijk geen minislots (kunnen) worden toegewezen aan de CM. Deze Data Grant Pending IE’s worden steeds achter de Null IE geplaatst. Data Acknowledge IE duidt aan dat een specifieke data PDU van de CM werd ontvangen door de CMTS. Dit is meestal als reactie op een request for acknowledge die

3.2 (Euro-)DOCSIS

21

werd meegestuurd in een upstream pakket, verstuurd via contention minislots. Net zoals bij Data Grant Pending IE’s worden Data Acknowledge IE’s geplaatst na de Null IE. Expansion IE is voorzien voor eventuele uitbreidingen. Aangezien de CMTS de bandbreedte op een gecentraliseerde wijze verdeelt, krijgen de CM’s gegarandeerd botsingvrije slots voor data transmissie. Tijdens de contention periode daarentegen kunnen botsingen optreden. Dit wordt opgevangen door een Contention Resolution Algorithm (CRA). In (Euro-)DOCSIS wordt hiervoor het Truncated Binary Exponential Backoff algoritme gebruikt. Het CRA wordt gekenmerkt door twee waarden die geregeld worden door de CMTS: het initiële back-off window en het maximale back-off window. Beide waarden worden verzonden in de MAP en stellen een macht van twee voor. Wanneer een CM data wil verzenden, stelt het zijn interne back-off window gelijk aan de data back-off window, die gespecificeerd wordt in de momentele MAP. De CM kiest willekeurig een waarde tussen 0 en 2Backof f . Deze willekeurige waarde duidt het aantal contention mogelijkheden aan dat gewacht moet worden voor een upload gelegenheid kan worden aangevraagd door de CM1 . Na de contention transmissie wacht de CM op een Data Grant (Data Grant Pending) of een Data Ack in een volgende MAP. Eenmaal een van beiden ontvangen werd, is het Contention Resolution algoritme voltooid. Indien de CM geen MAP detecteert met een voor hem bestemde Data Grant (Data Grant Pending) of Data Ack, dan besluit de CM dat de upload aanvraag verloren is gegaan. De CM verhoogt zijn back-off window met een factor twee (indien dit het back-off window niet groter maakt dan het maximale back-off window). De CM selecteert opnieuw een willekeurig getal binnen zijn nieuw back-off window en herhaalt het hoger beschreven proces. Dit proces herhaalt zich tot het maximaal aantal herhalingspogingen, namelijk 16, is bereikt. 1

Enkel de voor de CM geschikte contention gelegenheden worden beschouwd. Dit zijn meestal Request

IE’s of Request/Data IE’s in de MAP.

3.3 Piggybacking, Fragmentation en Concatenation in (Euro-)DOCSIS

3.3

22

Piggybacking, Fragmentation en Concatenation in (Euro-)DOCSIS

Om het uploadproces efficiënter te implementeren ondersteunt (Euro-)DOCSIS een aantal extra mogelijkheden. Deze hebben als doel de ‘contention’ duur te verkleinen en dus het upload proces te versnellen. Het gebruik van onderstaande instellingen verbetert de algemene throughput en vereist minder upstream resources. Piggybacking geeft de CM de mogelijkheid om tegelijkertijd bij het verzenden van data een aanvraag te doen voor extra upstream bandbreedte. Hierdoor verbetert de efficiëntie van het uploadproces omdat het Contention Resolution Algorithm niet moet doorlopen worden om nieuwe data te verzenden. Deze instelling kan worden geactiveerd per individuele modem. Aangezien piggybacking pas ondersteund wordt in (Euro-)DOCSIS v1.1 is daardoor toch compatibiliteit mogelijk met CM’s die enkel (Euro-)DOCSIS v1.0 ondersteunen. Fragmentation laat toe een gedeelte van een packet frame te versturen tijdens een gereserveerd tijdslot. Deze eigenschap is instelbaar per CM, de CMTS moet fragmentation in- of uitschakelen per modem. Dit biedt compatibiliteit met (Euro-)DOCSIS v1.0 waarin deze mogelijkheid niet ondersteund wordt. Eenmaal een bepaalde Service Flow (zie 3.4) fragmentatie ondersteunt, is het mogelijk dat de CMTS bandbreedte toekent die kleiner is dan de aangevraagde bandbreedte. Dit staat bekend als een Partial Grant. Op deze manier is efficiënter upstream verkeer mogelijk doordat, door middel van een partial grant, reeds een gedeelte van de data verstuurd kan worden. Voor een toepassing zoals VoIP is dit heel voordelig: de CM kan kleine voice pakketten die erg tijdsgevoelig zijn tussen de andere data voegen, wat een positieve invloed heeft op de jitter en delay. Concatenation biedt de mogelijkheid om meer dan één frame te versturen tijdens een transmissie gelegenheid. De CM heeft de mogelijkheid om één request te doen voor meerdere pakketten en deze tegelijk te versturen in één grote upstream burst. Deze mogelijkheid bestond reeds in (Euro-)DOCSIS v1.0 maar was optioneel.

3.4 Quality of Service in (Euro-)DOCSIS

3.4

23

Quality of Service in (Euro-)DOCSIS

Elke CM heeft een uniek MAC adres. Om Quality of Service (QoS) te ondersteunen introduceert (Euro-)DOCSIS het begrip Service Flow ID (SFID), dat aangeeft hoe bandbreedte aangevraagd en toegekend wordt. Elke SFID is uniek en definieert een specifieke dienstklasse of afspraak tussen een CM en CMTS. Een SID kan beschouwd worden als een actieve SFID op het upstream kanaal. In (Euro-)DOCSIS v1.1 bestaan volgende Service Flows: • Unsollicited Grant Service (UGS) • Real-time Polling Service (rtPS) • Non-real-time Polling Service (nrtPS) • Best Effort (BE) • Unsolicited Grant Service with Activity Detection (UGS-AD) Verder ondersteunt (Euro-)DOCSIS v1.1 meerdere Service Flows per CM, waardoor een CM in staat is een combinatie te verzenden van video-, spraak- en data pakketten. Met behulp van Dynamic Service Establishment is het mogelijk op dynamische wijze service flows aan te maken, te wijzigen of te verwijderen. Er zijn verschillende scheduling algoritmes mogelijk om de QoS diensten te verwezenlijken. De specificaties verplichten geen specifiek algoritme, dit is één van de aspecten waarin verschillende verkopers zich van elkaar onderscheiden. De basisdiensten worden als volgt beschreven: Unsolicited Grant Service (UGS ) werd ontwikkeld om real-time diensten te ondersteunen die datapakketten van vaste lengte genereren op periodieke basis, zoals Voice-over-IP (VoIP). De dienst genereert grants van vaste lengte op vaste tijdstippen, zodat de overhead en traagheid van data requests wordt geëlimineerd. Dit garandeert dat de grants voldoen aan de real-time vereisten van de flow. De Service Flow kan geen contention requests uitvoeren en kan geen gebruik maken van

3.4 Quality of Service in (Euro-)DOCSIS

24

piggybacking. Dit duidt op het belang van het nauwkeurig specificeren van het te verwachten verkeer. Real-time Polling Service (rtPS ) is ontwikkeld om real-time diensten te ondersteunen die pakketten van variabele lengte genereren op periodieke basis, zoals MPEG video. De dienst genereert unicast request mogelijkheden die voldoen aan het te versturen verkeerspatroon. rtPS ondersteunt variabele lengte grants voor een optimale datatransport efficiëntie. De CM kan geen contention requests uitvoeren en kan geen gebruik maken van piggybacking. Er wordt enkel gebruik gemaakt van de unicast request mogelijkheden om upstream transmissie aan te vragen. Non-real-time Polling Service (nrtPS ) werd ontworpen om niet-real-time diensten te ondersteunen die pakketten van variabele lengte genereren op periodieke basis, zoals FTP overdrachten. De dienst genereert unicast polls op regelmatige basis, wat garandeert dat de flow request mogelijkheden ontvangt, ook wanneer er network congestion optreedt. De CM heeft nog steeds de mogelijkheid om contention aanvragen uit te voeren. Best Effort (BE ) diensten ondersteunen best effort verkeer. De CM kan gebruik maken van contention request mogelijkheden en van piggybacking. Er worden verschillende traffic priorities gedefinieerd, gaande van 0 tot 7 waarbij 0 de hoogste prioriteit krijgt. Unsolicited Grant Service with Activity Detection (UGS/AD) werd ontworpen om UGS diensten te ondersteunen die inactief worden voor een substantiële periode, zoals VoIP met stilte onderdrukking. De dienst voorziet unsollicited grants wanneer de flow actief is en unicast polls wanneer de flow niet actief is. Dit combineert de lage overhead en snelle data grants van UGS met de efficiëntie van rtPS. De CMTS is in staat de niet-actieve periodes te detecteren door ongebruikte grants op te volgen.

DATAVERWERKING

25

Hoofdstuk 4 Dataverwerking 4.1

Inleiding

HFC-netwerken werden ontwikkeld vanuit de veronderstelling dat netwerkverkeer typisch asymmetrisch verloopt. Aangezien dit niet het geval is bij o.a. peer-to-peer verkeer, is het interessant te onderzoeken wat de invloed is van dit verkeer op de prestaties van het netwerk. In dit hoofdstuk wordt eerst de situatie beschreven waarbinnen de gebruikte metingen werden uitgevoerd. Er wordt informatie gegeven over de verschillende abonnementen en over de beschikbare meetgegevens. Vervolgens wordt besproken welke distributies nodig zijn om simulaties uit te voeren. Deze distributies worden afgeleid en uitgebreid besproken. Tenslotte worden een aantal mogelijke oplossingen voor HFCproviders besproken, die de negatieve invloed van peer-to-peer verkeer kunnen beperken.

4.2 4.2.1

Situatieschets Metingen

Voor dit onderzoek werden metingen uitgevoerd op een HFC-netwerk. Hiertoe werd het upstream verkeer opgevangen in back-end switches. In deze switches worden verschillende upstream kanalen geaggregeerd. Dit resulteert in metingen van een honderdtal

4.2 Situatieschets

26

upstreamkanalen en een paar tienduizend abonnees.

Figuur 4.1: Structuur van het opgemeten netwerk In de switch werden metingen uitgevoerd met een gesofisticeerde network traffic analyser. Deze is in staat onderscheid te maken tussen verschillende applicaties, zoals webverkeer, e-mail, ftp en msn. Een lijst van alle detecteerbare netwerkprotocollen is bijgevoegd in appendix A. Belangrijk voor dit onderzoek is dat verschillende peer-to-peer protocollen kunnen worden onderscheiden. De network analyser kan metingen maken met een granulariteit van 1 minuut. Vanwege de grote hoeveelheid metingen is het momenteel niet mogelijk meer gedetailleerde metingen uit te voeren. Deze nauwkeurigheid is veel groter dan in de meeste onderzoeken, zoals in [5], wat toelaat een erg gedetailleerde analyse te maken van het upstream verkeer. Elke ontvangen meting bevat een timestamp, een connectienummer, de identificatie van het opgevangen protocol, het aantal geuploade en gedownloade kilobytes sinds de vorige

4.2 Situatieschets

27

timestamp, een abonnementstype, de naam van het upstream en downstream kanaal en de naam van de verantwoordelijke node. Deze gegevens stellen ons in staat interessante conclusies af te leiden over het netwerkverkeer. In deze scriptie worden enkel de gegevens verwerkt die betrekking hebben op het uploadverkeer. De sterkte van deze metingen ligt erin dat alle metingen in de back-end uitgevoerd worden, wat resulteert in een grote hoeveelheid data. Enkel kabelabonnementen worden opgemeten, dezen zijn permanent verbonden met het netwerk en zijn daardoor dominant aanwezig bij p2p-verkeer. Gebruikers worden onderscheiden op basis van een uniek connectie nummer, wat een nauwkeurigere analyse mogelijk maakt dan bij verwerking met IP-adressen. IP-adressen kunnen immers dynamisch gewijzigd worden. Tenslotte gebeurde de identificatie van de verschillende protocollen door inspectie van de pakketten en niet enkel op basis van poortnummer. In 2.4 hebben we aangetoond dat dit belangrijk is om een duidelijk beeld te krijgen van het p2p-verkeer. Bij het verwerken van de meetgegevens werd een groot belang gehecht aan de privacy van de gebruikers. De gebruikersgegevens werden aangepast, wat het associëren van de gegevens met een specifieke gebruiker onmogelijk maakt.

4.2.2

Types abonnementen

De betreffende kabeloperator biedt verschillende types abonnementen aan. Deze verschillen wat betreft de hoeveelheid webruimte die aangeboden wordt, het aantal e-mail adressen dat verkregen wordt, het aantal IP-adressen en een aantal andere opties. Het belangrijkste verschil voor dit onderzoek is de hoeveelheid data die per maand verzonden en ontvangen mag worden en de snelheid waaraan dit kan gebeuren. Dit bepaalt immers in grote mate het uploadgedrag van de gebruikers. In tabel 4.1 en tabel 4.2 wordt een overzicht gegeven van de verschillende datalimieten. Merk op dat gebruikers de mogelijkheid hebben tot het bijkopen van ‘volumeblokken’, maar niet van extra upload- of downloadsnelheid zonder van abonnementstype te veranderen. Het 128 kbps abonnement biedt de keuze tussen een maximale uploadsnelheid van 128 kbps of 192 kbps. Aangezien in de meetgegevens geen onderscheid kan gemaakt worden tussen beide mogelijkheden,

4.3 Nodige gegevens

28

wordt in deze thesis uitgegaan van een uploadsnelheid van 128 kbps. Type abonnement

maximale downloadsnelheid

maximale uploadsnelheid

128 kbps abonnement

4 Mbps

128 kbps

192 kbps abonnement

5 Mbps

192 kbps

512 kbps abonnement

6.6 Mbps

512 kbps

512 kbps abonnement Extra

10 Mbps

512 kbps

Tabel 4.1: Verschillende uploaden downloadsnelheden bij de abonnementstypes

Type abonnement

maximale downloadhoeveelheid

maximale uploadhoeveelheid

128 kbps abonnement

10 GB

1.5 GB

192 kbps abonnement

10 GB

1.5 GB

512 kbps abonnement

15 GB

5 GB


30 GB

10 GB

Tabel 4.2: Verschillende uploaden downloadlimieten per maand bij de abonnementstypes

Het is belangrijk een onderscheid te maken tussen de verschillende types abonnementen. Elk abonnement wordt gekenmerkt door een specifiek uploadpatroon, door verschillende uploadhoeveelheden en het aantal actieve gebruikers. Bij de verdere afleidingen van de distributies zal steeds een onderscheid gemaakt worden tussen de verschillende abonnementen. Dit zorgt voor een nauwkeurigere representatie van het netwerk en laat toe gedetailleerdere voorspellingen te doen.

4.3

Nodige gegevens

Om voorspellingen te doen zijn meetgegevens nodig over een lange periode. Voor dit onderzoek beschikken we enkel over de gegevens van een weekend uit een vakantieperiode. Dit impliceert dat de bekomen resultaten omtrent het peer-to-peer gedeelte van deze thesis enkel een momentopname beslaan. Uit onderzoeken blijkt dat de uploadhoeveelheid van een weekend ongeveer 3/5 bedraagt van de uploadhoeveelheid op een weekdag. Wanneer

4.3 Nodige gegevens

29

we dit in rekening brengen, kunnen we op basis van de resultaten een algemene indruk krijgen van de huidige situatie. 1.5 other webbrowsing p2p−verkeer

kbps per klant

1

0.5

0

0

5

10

15

20

Uur

Figuur 4.2: Gemiddelde uploadsnelheid per klant van het 128 kbps abonnement op zondag

Bij de metingen maken we een onderscheid tussen de abonnementstypes, de dag en het uur om de distributies af te leiden. Zoals in figuur 4.2 te zien is, varieert het uploadgedrag sterk gedurende het verloop van de dag. In de figuur wordt de gemiddelde uploadsnelheid weergegeven per klant. In deel 4.4.2 wordt aangetoond dat, voor modelleringsstudies, het nuttiger is om het aantal actieve gebruikers te beschouwen. Een peer-to-peer verbinding wordt gekenmerkt door verschillende factoren. Zo wordt een p2p-verbinding gekenmerkt door gegevens zoals uploadsize, aantal verbonden peers, connectieduratie, aantal gedeelde bestanden, etc. Deze gegevens kunnen niet allemaal afgeleid worden uit de meetgegevens, die enkel de geaggregeerde uploadhoeveelheid van een klant bijhouden per applicatie en per minuut. Voor dit onderzoek is dat geen beperking. We onderzoeken immers de invloed van peer-to-peer verkeer op het netwerk en deze invloed wordt vooral veroorzaakt door het extra netwerkverkeer. We hebben dus voldoende aan de distributie van de hoeveelheid p2p-verkeer dat wordt verstuurd door een gebruiker (‘uploaddistributie’, zie punt 4.4.1), de hoeveelheid niet-p2p-verkeer dat wordt verstuurd

4.4 Distributies

30

door een gebruiker (‘achtergrondverkeer ’, zie punt 4.4.3) en het aantal actieve gebruikers (zie punt 4.4.2). Met deze distributies wordt immers het hele upstream verkeerspatroon gespecificeerd1 . Deze benadering heeft het voordeel eenvoudig te zijn (slechts gekenmerkt door 3 distributies) terwijl toch de belangrijkste onderzoeken mogelijk zijn, zoals het verhogen van het aantal p2p-gebruikers en het onderzoeken wat de invloed is van het peer-to-peer verkeer op andere applicaties. Om een nauwkeuriger resultaat te bekomen, en extra onderzoek mogelijk te maken, werd ook een onderscheid gemaakt tussen de verschillende abonnementstypes. Dit is belangrijk voor de uiteindelijke modellering aangezien de verschillende abonnementen een andere maximale uploadsnelheid hebben. Dit brengt het totaal af te leiden distributies op 12. Er zijn reeds verscheidene andere studies uitgevoerd die peer-to-peer verkeer nauwkeurig beschrijven. Zo worden in [6] onder andere de distributies afgeleid van de bestandsgrootte die geshared wordt en de duur van de connecties. In [4] worden o.a. het aantal verbindingen per host afgeleid en de distributie van de verbindingsduratie. Dit zijn interessante conclusies, die minder relevant zijn voor dit onderzoek: we zijn enkel ge¨ınteresseerd in de hoeveelheid verkeer die veroorzaakt wordt. De grote hoeveelheid distributies zijn te complex om een uitgebreide netwerksimulatie uit te voeren met behulp van de netwerksimulator.

4.4

Distributies

Om de kenmerken van peer-to-peer verkeer af te leiden, is het noodzakelijk distributies af te leiden. Door middel van distributies worden de datasets van de gegevens vertaald in een formule die uitdrukt hoe de gegevens met elkaar verwant zijn. Belangrijke parameters daarbij zijn o.a. de gemiddelde waarde en de variantie. Distributies hebben het voordeel dat een grote dataset kan uitgedrukt worden door middel van enkele parameters, daarom ondersteunen de meeste simulatieprogramma’s een grote hoeveelheid distributies. In de figuren worden distributies uitgezet ten opzichte van de survivorfunctie. 1

Het betreft hier natuurlijk een benadering, zoals in iedere simulatie. Enkele tekorten worden bespro-

ken in punt 4.5

4.4 Distributies

31

De survivorfunctie wordt gedefinieerd als: S(y) = 1 − FY (y) = P (Y ≥ y) Daarbij staat FY (y) = P (Y ≤ y) voor de cumulatieve distributiefunctie. Eerst worden enkele distributies weergegeven die belangrijk zijn voor het verdere verloop van dit hoofdstuk. Een aantal van deze distributies keren regelmatig terug in de literatuur. Continue distributies: Lognormale verdeling:

y = f (x|µ, σ) =

1 √

xσ 2π

e

−(ln x−µ)2 2σ 2

(4.1)

Weibull verdeling: α β

y = f (x|α, β) =

!

x β

!α−1

x α

e−( β )

(4.2)

Discrete distributies: Neg Bin verdeling: 



r + x − 1

y = f (x|r, p) = 

p

x

r x

q

met   n  

r

=

n! r!(n − r)!

en

q =1−p

(4.3)

Poisson verdeling:

y = p(x|µ) = e−µ

µx x!

(4.4)

4.4 Distributies

4.4.1

32

Uploaddistributie

Een eerste distributie die noodzakelijk is om het peer-to-peer verkeer te modelleren, is de hoeveelheid data die door een actieve gebruiker verstuurd wordt. Aangezien de metingen geaggregeerd zijn per minuut, kan enkel de hoeveelheid data per minuut gemodelleerd worden. Hiertoe werd een script geschreven dat uit de meetgegevens de totale hoeveelheid verzonden peer-to-peer data per gebruiker berekent. De bekomen distributie is dus de totale hoeveelheid peer-to-peer data die verzonden wordt per minuut, samengenomen over alle peer-to-peer protocollen. In de literatuur worden meestal distributies afgeleid van de grootte van het bestand dat geupload wordt [4],[6]. Dit is echter geen bruikbare distributie om op eenvoudige wijze simulaties uit te voeren. Verder wordt meestal onderscheid gemaakt tussen verschillende peer-to-peer protocollen. Ook dit maakt de situatie hopeloos complex wat het simuleren van het netwerk betreft. Daarom werden voor deze studie alle protocollen samengenomen tot één dataset, en werd aldus de hoeveelheid data die door een gebruiker verzonden wordt gemodelleerd. De datasets werden per abonnementstype opgesteld, waarbij telkens de gegevens van één uur geanalyseerd werden. Dit laat toe een onderscheid te maken tussen verschillende abonnementstypes en het uur van de dag. Beide factoren hebben een grote invloed op de verstuurde hoeveelheid data. Abonnementstype

gemiddelde uploadsnelheid

128 kbps abonnement

130 kB/min (17.46 kbps)

192 kbps abonnement

173 kB/min (23.15 kbps)

512 kbps abonnement

197 kB/min (26.31 kbps)


307 kB/min (40.94 kbps)

Tabel 4.3: Gemiddelde uploadsnelheid van het p2p-verkeer op zondag om 21 uur ’s avonds In figuur 4.3 is de distributie van de dataset weergegeven op zondag van 14u tot 15u, voor het 512 kbps abonnement, alsook de benadering ervan door middel van enkele distributies.

4.4 Distributies

33

In de figuur wordt de survivorfunctie uitgezet ten opzicht van de hoeveelheid data die verstuurd wordt per minuut. 0

10

upload data weibull lognormal −1

Survivor function

10

−2

10

−3

10

0

10

1

10

2

10 Hoeveelheid data (kB/min)

3

10

Figuur 4.3: Fitting van de distributie van de uploadhoeveelheid van het p2p-verkeer bij het 512 kbps abonnement Uit de dataverwerking blijkt dat de gemiddelde grootteorde ongeveer 170 000 bytes/min of 22.6 kbps per actieve gebruiker bedraagt. Wat opvalt is dat de distributie een ‘lange staart’ heeft: hoewel er gemiddeld gezien slechts 170 kB/min wordt geupload kan tot 4000 kB/min (533 kbps) worden geupload door sommige gebruikers. Dit komt overeen met conclusies uit de literatuur die aanduiden dat bij peer-to-peer verkeer typisch een klein aantal gebruikers verantwoordelijk zijn voor het grootste deel van het netwerkverkeer (tot 70% volgens [4]). Verder is in figuur 4.3 een duidelijke ‘knik’ op te merken, wat erop wijst dat de dataset bestaat uit een mengsel van verschillende distributies. Deze ligt ongeveer op 5% van de datasets, wat kan wijzen op het aandeel van de ‘zware gebruikers’. Dit is een term die in verschillende onderzoeken terugkomt en aanduidt of een gebruiker significant meer bandbreedte verbruikt dan de gemiddelde gebruiker. De precieze grens die gebruikt wordt om dit onderscheid te maken varieert in de gebruikte papers van 1% van de gebruikers [4] tot 10% van de gebruikers [6].

4.4 Distributies

34

De figuren van de andere types abonnementen blijken gelijkaardig te zijn van vorm. De conclusies zijn analoog, behalve dat bij snellere abonnementen de ‘knik’ minder uitgesproken is. Dit kan veroorzaakt worden door de kleinere variatie tussen de gebruikers: iedereen is een ‘zware gebruiker’. Bij de snellere abonnementen zitten inderdaad gemiddeld zwaardere gebruikers: de gemiddelde uploadhoeveelheid bij het ‘512 kbps extra abonnement’ ligt bijna drie keer zo hoog als bij het ‘128 kbps abonnement’. Tenslotte blijkt, bij alle abonnementen, gedurende de nacht de gemiddelde uploadhoeveelheid 50% tot 100% hoger te liggen dan overdag. Een mogelijke verklaring is dat vooral zware gebruikers ’s nachts uploaden en het aandeel van de ‘gewone’ gebruiker dan afneemt. Dit lijkt bevestigd te worden in deel 4.4.2, waar blijkt dat het aandeel p2p-gebruikers ’s nachts sterk daalt bij de 128 kbps en 192 kbps abonnementen. Een andere mogelijkheid is dat ’s nachts hogere snelheden worden bereikt vanwege de afname van ander verkeer. Deze verklaring lijkt bevestigd te worden in deel 4.4.2, waaruit blijkt dat het aandeel actieve p2p-gebruikers ongeveer constant blijft gedurende de hele dag bij de snellere abonnementen. Vermoedelijk spelen beide factoren mee in de verklaring van dit fenomeen. Uit de datafitting blijkt dat de lognormale distributie minder goed de dataset modelleert dan de Weibull distributie. Vooral de staartverdeling blijkt niet goed overeen te komen met een lognormale distributie: de grote uploadhoeveelheden krijgen een te grote probabiliteit. De Weibull distributie sluit het nauwst aan bij de werkelijkheid. Nochtans worden in de meeste artikels eigenschappen zoals de bestandsgrootte en de uploadhoeveelheid per connectie gemodelleerd met behulp van een lognormale distributie. Enkel [6] duidt aan dat protocollen waarbij veel data verzonden wordt (zoals bij BitTorrent), niet goed gemodelleerd worden door een lognormale verdeling. Zij modelleren de transfer size van bestanden bij het FastTrack netwerk als een lognormale verdeling met Pareto staart, en deze van BitTorrent als een Weibull distributie. Het gebruik van de lognormale verdeling is dus minder nauwkeurig. Een mogelijke verklaring voor het veelvuldig voorkomen van deze distributie in de literatuur is de eenvoud ervan. Dit vereenvoudigt de implementatie ervan in simulatiesoftware waardoor de simulaties veel sneller uitgevoerd kunnen worden. Wanneer simulatietijd belangrijker is dan nauwkeurigheid, kan het aangewezen zijn om gebruik te maken van een lognormale

4.4 Distributies

35

distributie. Wanneer een ‘worst case’ situatie onderzocht wordt is de Weibull distributie aan te raden, aangezien bij ‘worst case’ situaties de staartdistributie een grote rol speelt.

4.4.2

Actieve gebruikers per upstreamkanaal

Om het verkeer te modelleren is, buiten de distributie van de uploadhoeveelheid, ook de distributie van het aantal gebruikers noodzakelijk. In deze sectie wordt de distributie opgesteld van het aantal gebruikers dat actief is in een uploadkanaal in het onderzocht HFC-netwerk. Er moet een onderscheid gemaakt worden tussen het totaal aantal gebruikers dat geabonneerd is (wat een constante is) en het aantal actieve gebruikers. Om het verkeer te simuleren is enkel deze laatste statistiek belangrijk. Zowel het totaal aantal actieve gebruikers wordt gemodelleerd, als het aandeel van deze gebruikers dat peer-to-peer verkeer genereert. Merk tenslotte op dat deze statistieken sterk provider afhankelijk zijn. Het aantal verbonden klanten wordt immers nergens gedefinieerd in de (Euro-)DOCSIS specificaties. Het totaal aantal mogelijke klanten hangt af van de kwaliteit van het netwerk (hoeveel verlies er optreedt), van het uploadgedrag van de klanten en van interne bedrijfsbeslissingen. Verder betreft het hier een momentopname: voor dit onderzoek zijn slechts tijdens twee dagen metingen uitgevoerd.

Distributies Bij het afleiden van de distributie van het aantal actieve gebruikers per kanaal, werd een onderscheid gemaakt tussen het totaal aantal gebruikers dat actief is (en dus data verzend), en het aandeel ervan dat p2p-verkeer genereert. Om de distributies te bekomen werd in de meetdata per uploadkanaal elke minuut gecontroleerd hoeveel gebruikers data-verkeer/p2p-verkeer verstuurden. Aldus krijgen we een algemene statistiek die niet afhangt van het gekozen kanaal. Hierbij gaan we ervan uit dat alle kanalen ‘identiek’ zijn: ze hebben dezelfde karakteristieken qua belasting, subscribers, enzovoort. Het uitmiddelen over de tijd (één distributie opstellen per uur) mag, indien er geen periodieke componenten aanwezig zijn. Met andere woorden: indien het systeem stationair is, en

4.4 Distributies

36

indien alle distributies ‘independent identically distributed ’ zijn. Dit is een redelijke veronderstelling bij dit type verkeer. Tenslotte wordt, zoals bij alle afleidingen, een onderscheid gemaakt tussen uur en type abonnement. Aangezien het aantal gebruikers steeds een geheel getal is, moet gebruik gemaakt worden van een discrete distributie. In figuur 4.4 wordt de distributie van het totaal aantal gebruikers gemodelleerd op zondag van 14u tot 15u. De optimale distributie blijkt Negatief Binomiaal verdeeld te zijn. De Poissonverdeling wordt veel gebruikt bij netwerkmodellering vanwege zijn eenvoudige eigenschappen. Uit [15] blijkt dat deze veronderstelling bij zowel locale als wide-area netwerken meestal niet opgaat, zoals bevestigd wordt door de modellering in figuur 4.4. Fitting van het aantal actieve users

0

10

−1

10

−2

Survivor function

10

−3

10

−4

10

−5

10

Distributie actieve gebruikers Fitting met Negatieve Binomiaal distributie Fitting met Poisson distributie

−6

10

0

1

10

10 aantal users

Figuur 4.4: Fitting van het aantal actieve gebruikers

4.4 Distributies

37

Algemene conclusies Uit de afgeleide distributies kunnen interessante eigenschappen worden afgeleid in verband met het uploadgedrag van gebruikers. In deze sectie wordt onderzocht hoe het uploadgedrag evolueert gedurende de dag, en wat de verschillen zijn tussen de abonnementstypes. Eerst wordt het dagverloop van het aantal actieve gebruikers uitgezet voor elk type abonnement. 25 Alle actieve gebruikers Aandeel p2p−gebruikers

Aantal gebruikers

20

15

10

5

0

2

4

6

8

10

12 14 Uur van de dag

16

18

20

22

24

Figuur 4.5: Gemiddeld aantal actieve gebruikers per uploadkanaal voor het 128 kpbs abonnement

4.4 Distributies

38

14 Alle actieve gebruikers Aandeel p2p−gebruikers

12

Aantal gebruikers

10 8 6 4 2 0

2

4

6

8

10


16

18

20

22

24



3.5

Aantal gebruikers

3 2.5 2 1.5 1 0.5 0

2

4

6

8

10


16

18

20

22

24


4.4 Distributies

39

3.5 Alle actieve gebruikers Aandeel p2p−gebruikers

3

Aantal gebruikers

2.5 2 1.5 1 0.5 0

2

4

6

8

10


16

18

20

22

24

Figuur 4.8: Gemiddeld aantal actieve gebruikers per uploadkanaal voor het 512 kpbs abonnement Extra Het aantal gebruikers dat gebruik maakt van snellere abonnementstypes is kleiner dan de tragere (en goedkopere) abonnementen. De twee goedkoopste abonnementstypes (128 kbps en 192 kbps) verschillen slechts weinig wat het dagverloop betreft. Rond 21u ’s avonds is het grootst aantal gebruikers actief. Enkel bij het 512 kbps abonnement ligt het piekmoment rond 18u ’s avonds, hoewel het piekmoment minder uitgesproken is. Het upstream verkeer daalt gedurende de nacht. Dit gaat van een heel uitgesproken daling (128 kbps abonnement, zie figuur 4.5), tot een kleinere (maar nog steeds duidelijk merkbare) daling bij het 512 kbps abonnement Extra (figuur 4.8). Het p2p-verbruik vertoont hetzelfde gedrag met minder uitgesproken effecten. Bij het ‘512 kbps abonnement Extra’ abonnement (figuur 4.8) is het aantal p2p gebruikers zelfs bijna een constante. Om simulaties uit te voeren is enkel het aantal actieve gebruikers belangrijk. Het is ook interessant om te kijken naar het procentueel aantal gebruikers dat actief is. Dit resulteert in onderstaande grafieken.

4.4 Distributies

40

25

Gemiddeld % actieve gebruikers

Alle actieve gebruikers Aandeel p2p−gebruikers 20

15

10

5

0

2

4

6

8

10


16

18

20

22

24

Figuur 4.9: Percentage gebruikers dat actief is per uploadkanaal voor een 128 kbps abonnement



18 16 14 12 10 8 6 4 2 0

2

4

6

8

10


16

18

20

22

24


4.4 Distributies

41



45 40 35 30 25 20 15 10 5 0

2

4

6

8

10


16

18

20

22

24




60 50 40 30 20 10 0

2

4

6

8

10


16

18

20

22

24

Figuur 4.12: Percentage gebruikers dat actief is per uploadkanaal voor een 512 kbps abonnement Extra De meest opvallende conclusie is dat, hoewel het totaal aantal actieve gebruikers kleiner

4.4 Distributies

42

is bij snellere abonnementen, het procentueel aantal actieve gebruikers veel hoger ligt. De gebruikers van snelle abonnementen zijn dus bijna voortdurend online. Daar waar bij het 128 kbps abonnement gemiddeld 4% tot 20% actieve gebruikers verbonden zijn, loopt dit op tot 35% à 65% bij het 512 kbps abonnement Extra. Een analoog besluit kan genomen worden in verband met het aandeel peer-to-peer gebruikers: bij het 128 kbps is slechts 1.5% tot 4% van de gebruikers actief in een p2p-netwerk, bij het 512 kbps Extra abonnement is dit gemiddeld 27%. Hieruit blijkt duidelijk dat het gebruik van p2p-netwerken een gegronde reden is voor klanten om te opteren voor een snel abonnement. Bij het 512 kbps en het 512 kbps Extra abonnement is de hoeveelheid data die verstuurd wordt groter dan bij de andere abonnementen én het aandeel peer-to-peer gebruikers is groter. In deel 5.5.4 wordt onderzocht wat het effect is van een groter klantenbestand van de verschillende abonnementstypes.

4.4.3

Achtergrondverkeer

Om het hele netwerk te kunnen simuleren moet ook het niet peer-to-peer verkeer gemodelleerd worden. Dit verkeer noemen we achtergrond verkeer en omvat onder andere het webverkeer, het ftp-verkeer en het e-mailverkeer. Dit is een grote hoeveelheid verkeer van verschillende oorsprong. Het is onmogelijk alle types verkeer afzonderlijk te modelleren, de simulaties worden veel te complex. Er wordt dus een aanvaardbare distributie gezocht die het andere verkeer benadert. Om de dataset te bekomen werd voor elk gebruiker opgeteld hoeveel data verstuurd werd per minuut. Peer-to-peer data werd daarbij niet meegerekend. Ook hier werd een opsplitsing gemaakt per uur en per abonnementtype. Abonnementstype

gemiddelde uploadsnelheid

128 kbps abonnement

56.7 kB/min (7.56 kbps)

192 kbps abonnement

60.0 kB/min (8.01 kbps)

512 kbps abonnement

78.3 kB/min (10.44 kbps)


78.9 kB/min (10.52 kbps)

Tabel 4.4: Gemiddelde uploadsnelheid van het achtergrondverkeer op zondag om 21 uur ’s avonds

4.4 Distributies

43

De gemiddelde uploadhoeveelheid wordt weergegeven in tabel 4.4. De waarden liggen veel lager dan de uploadsnelheid van het p2p-verkeer in tabel 4.3. Dit duidt er nogmaals op dat p2p-applicaties grote hoeveelheden p2p-verkeer genereren. Het 512 kbps abonnement en het 512 kbps abonnement Extra vertonen een groot verschil wat betreft de hoeveelheid gegenereerd p2p-verkeer, maar dit verschil is heel klein voor het achtergrondverkeer. Dit wijst erop dat de snellere abonnementen vooral aangevraagd worden om p2p-toepassingen te gebruiken. Ter illustratie is in figuur 4.13 de distributie van het achtergrondverkeer weergegeven van het 512 kbps abonnement op zondag 14 uur, met een gemiddelde uploadsnelheid van 9 kbps. Fitting van de uploaddistributie per minuut

0

10

upload data weibull lognormal

−1

10

−2

Survivor function

10

−3

10

−4

10

−5

10

−6

10

1

10

100 Hoeveelheid data (kB/min)

1000

Figuur 4.13: Fitting van de distributie van de uploadgrootte van het niet-p2p verkeer bij het 512 kbps abonnement De twee meest nauw aansluitende distributies zijn weer de lognormale en de Weibull

4.4 Distributies

44

distributie. De figuur heeft niet één duidelijke knik zoals het geval was bij peer-to-peer verkeer. Het modelleren met behulp van de lognormale distributie geeft een overschatting van de hoeveelheid verzonden data, de Weibull een onderschatting. Beide distributies modelleren het begin van de grafiek goed, dit is het gebied waarin 98.4% van de data valt. Aangezien dit deel het meest benaderd wordt door de lognormale verdeling, en vanwege de eenvoud van deze distributie, wordt in de simulaties de lognormale verdeling gebruikt voor het achtergrondverkeer.

4.4.4

Connectieduur

In dit deel wordt de connectieduur van de peer-to-peer gebruikers onderzocht. De connectieduur wordt niet gebruikt in de simulaties, maar gezien de grote hoeveelheid gegevens is het interessant deze toch te bestuderen. Er is weinig onderzoek verricht naar de upload connectieduur bij verschillende protocollen en, zover wij weten, nog nooit onderzoek verricht naar de connectieduur bij verschillende abonnementen. Op basis van de dataset wordt geanalyseerd wat de gemiddelde connectieduur is. Er moet een verschil gemaakt worden tussen de verbindings- en de verzendingsduur. De verbindingsduur wordt gedefinieerd als de tijd dat de gebruiker verbonden is met een filesharing programma. De verzendingsduur wordt gedefinieerd als de periode waar effectief data verzonden wordt. De hierna afgeleide ‘connectieduur’ betreft de verzendingsduur. Dit is, vanuit het standpunt van de provider, de meest belangrijke periode, aangezien dan dataverkeer gegenereerd wordt. Aangezien een verbinding langer kan duren dan 24 uur, werd voor de afleiding van de connectieduur gebruik gemaakt van gegevens van het hele weekend.

Connectieduur per protocol Eerst wordt een onderscheid gemaakt tussen enkele populaire protocollen. Uit de afleiding van de gemiddelde connectieduur, blijkt dat een groot aandeel van de verbindingen heel kort is. De reden hiervoor is niet onmiddellijk duidelijk, er zijn verschillende verklaringen mogelijk.

4.4 Distributies

45

• Mogelijks wordt het dataverkeer in het begin van het verzendingsproces niet geëncrypteerd. Nadat controle-informatie uitgewisseld is, wordt overgegaan op geëncrypteerd verkeer, dat niet herkend wordt. • De verbindingen kunnen korte, eenmalige, controleboodschappen betreffen, zoals het opvragen van een lijst met alle gedeelde bestanden van een gebruiker. • Recente p2p-netwerken bieden de mogelijkheid van verschillende gebruikers tegelijk te downloaden. De korte duur kan erop wijzen dat de gebruiker een stukje van een bestand upload, waarna de verbinding terug verbroken wordt. Op basis van de datagegevens kan geen verklaring gegeven worden voor de grote hoeveelheid korte verbindingen. Dit resultaat is wel in overeenstemming met metingen op kazaa [1], waaruit blijkt dat 32% van de connecties korter is dan 30 seconden. Het merendeel van de verbindingen zijn controleverbindingen [6], het precieze aandeel korte verbindingen hangt vooral af van het type protocol. Bij de afleiding van de gegevens werd uitgegaan van de veronderstelling dat verbindingen van 1 minuut of korter controleverbindingen zijn. In tabel 4.5 wordt de gemiddelde waarde van de connectieduur weergegeven, zowel met controleverbindingen (‘niet gefilterd ’) als zonder de controleverbindingen (‘gefilterd ’). Ook het aandeel korte verbindingen wordt weergegeven, en ook het aantal gemeten p2p-sessies als aanduiding van de relatieve populariteit. Protocol

niet gefilterd

gefilterd

korte verbindingen

sessies

e-donkey

29.1 min

36.9 min

23.6 %

762

KazaA

11.1 min

16.3 min

34.7 %

1077

Bittorrent

59.4 min

88.5 min

33.3 %

225

12 min

16.4 min

29.0 %

2083

21.7 min

28.3 min

24.3 %

630

Gnutella Direct connect

Tabel 4.5: Gemiddelde connectieduur per protocol De resultaten komen goed overeen met [1], [4] en [6], waar de connectieduur wordt afgeleid. Vooral bittorrent blijkt een langere gemiddelde connectieduur te hebben, doordat er meer

4.4 Distributies

46

grote bestanden gedeeld worden. Bij het afleiden van de connectieduur werden verbindingen die reeds actief waren op zaterdag om 1 uur, of die nog niet beëindigd waren op zondag om 24 uur, niet gebruikt in de berekeningen. Hierdoor is het mogelijk dat een gedeelte van de langere verbindingen weggefilterd werd. De resultaten zijn dus mogelijks een onderschatting van de realiteit.

Connectieduur per abonnement Bij de analyse werd ook een onderscheid gemaakt tussen de verschillende abonnementen. Er wordt weer gefilterd op connectietijden kleiner of gelijk aan 1 minuut, en het aandeel korte verbindingen wordt weergegeven. Uit tabel 4.5 blijkt dat het aandeel korte verbindingen weinig variabel is tussen de abonnementen. De verschillende abonnementen hebben wel een sterk verschillende gemiddelde connectieduur: het snelste abonnement blijft gemiddelde bijna dubbel zo lang verbonden met een p2p-netwerk. niet-gefilterd

gefilterd

korte verbindingen

128 kbps abonnement

11.2 min

15.9 min

31.1 %

192 kbps abonnement

15.1 min

21.9 min

32.6 %

512 kbps abonnement

15.3 min

21.3 min

33.6 %

512 kbps extra abonnement

19.9 min

28.9 min

32.4 %

Tabel 4.6: Gemiddelde connectieduur per abonnement

Om een beter beeld te geven van de verdeling van een connectieduur, werd ook de distributie ervan afgeleid. De distributie wordt weergegeven in figuur 4.14 en figuur 4.15, waarbij verbindingen van 1 minuut of korter niet in rekening gebracht zijn. In figuur 4.16 wordt de distributie van de ongefilterde connectieduur weergegeven. De connectieduur kan oplopen tot meer dan 16 uur.

4.4 Distributies

47

1 0.9


0.8 0.7 0.6 0.5 0.4 0.3 0.2 512 kbps abonnement Extra 128 kbps abonnement

0.1 0

0

100

200

300

400

500 600 Minuten

700

800

900

1000

Figuur 4.14: Connectieduur van een peer-to-peer gebruiker

1 0.9


0.8 0.7 0.6 0.5 0.4 0.3 0.2 512 kbps abonnement Extra 128 kbps abonnement

0.1 0

0

10

20

30 Minuten

40

50

60

Figuur 4.15: Connectieduur van een peer-to-peer gebruiker (0 tot 60 minuten interval)

4.5 Beperkingen van de distributies

48

1 0.9


0.8 0.7 0.6 0.5 0.4 0.3 0.2 128 kbps abonnement 512 kbps abonnement Extra

0.1 0

0

10

20

30 Minuten

40

50

60

Figuur 4.16: Connectieduur van een peer-to-peer gebruiker (niet gefilterd)

4.5

Beperkingen van de distributies

Bij het afleiden van de distributies treden twee types onnauwkeurigheden op. Onnauwkeurigheden van de metingen In de gebruikte dataset is een groot aandeel van de metingen geclassificeerd onder ‘generic TCP applications’, ‘generic UDP applications’ en ‘unknown’. Het betreft hier pakketten die niet kunnen worden geclassificeerd door de netwerkanalyser. Aangezien het een recente trend is om p2p-verkeer te encrypteren, kan een gedeelte ervan p2p-verkeer zijn. We hebben geen gegevens gevonden over het aandeel van het p2p-verkeer dat reeds gebruik maakt van encryptie. Mogelijks zijn de distributies van het aantal actieve p2p-gebruikers en van de p2p-uploadhoeveelheid dus een onderschatting van de werkelijkheid. Een verdere beperking is dat de netwerkanalyser elke minuut metingen samentelt en wegschrijft. Dit impliceert dat de meetgegevens beperkt zijn: ze bevatten geen informatie over de verdeling van de pakketgrootte, over het eventueel optreden van bursts, over de verdeling van de pakketten binnen deze minuut, enzovoorts. In deel 5.2.1 wordt

4.6 Mogelijke oplossingen om de invloed van peer-to-peer verkeer te verkleinen

49

vermeld hoe dit probleem aangepakt wordt in de simulaties. Doordat alle verkeer van een applicatie samengenomen wordt, is het niet mogelijk om distributies op te stellen van verschillende parameters, zoals de grootte van de verzonden bestanden. Tenslotte treden in netwerkanalyser soms synchronizatieproblemen op. Daardoor worden gegevens niet weggeschreven na 60 seconden, maar pas enige tijd later. Het gebeurt ook dat de meting een minuut overslaat en de metingen van twee minuten samen worden weggeschreven. Onnauwkeurigheden van de datafitting Er bestaan verschillende testen [16] om te verifiëren of een dataset voldoet aan een distributie. De meest bekende zijn de Chi-Square Goodness-of-Fit” test en de Kolmogorov” ” Smirnov ” test. Niet iedere dataset kan gemodelleerd worden als een eenvoudige basisdistributie. Uit de dataverwerking blijkt dat de hoger afgeleide distributies niet voldoen aan deze testen, wanneer bij de modellering eenvoudige distributies gebruikt worden, zoals de Weibull-distributie. Indien de dataset van figuur 4.3 wordt gemodelleerd als een mengsel van 3 à 4 Weibull-distributies, wordt wel voldaan aan de Chi-Square Goodness-of-Fit test en de Kolmogorov-Smirnov test. Aangezien mengsels complex zijn voor eenvoudige simulaties, lijkt deze aanpak niet interessant voor deze thesis.

4.6

Mogelijke oplossingen om de invloed van peerto-peer verkeer te verkleinen

Voor de provider is peer-to-peer verkeer weinig voordelig: er treedt extra verkeer op in het eigen toegangsnetwerk, alsook van en naar andere netwerken. Het toenemend verkeer op het toegangsnetwerk is nadelig voor HFC-netwerken omdat de bandbreedte gedeeld wordt over meerdere gebruikers, waardoor minder bandbreedte overblijft voor real-time applicaties zoals video-conferencing en Voice-over-IP. Het transit-verkeer van andere netwerken betekent een extra kost voor de provider.


4.6.1

50

Traffic shaping

Traffic shaping is het gebruik van een mechanisme om verkeer te controleren dat het netwerk binnenkomt of verlaat. Door artificieel bandbreedte te verlagen of burst uit te spreiden over de tijd, wordt een minder grillig verkeerspatroon bekomen. De meest gebruikte algoritmes zijn het ‘leaky bucket’ en het ‘token bucket’ algoritme. Meestal wordt een onderscheid gemaakt tussen verschillende verkeerssoorten of service flows. Het gebruik van traffic shaping kan resulteren in minder pakketverlies, een kleinere delay en minder jitter. Traffic shaping heeft een positieve invloed op de spreiding van het verkeer. Er zijn echter enkele praktische problemen bij het gebruik van traffic shaping in een HFC-netwerk. Het is niet mogelijk alle kabelmodems aan te passen met traffic shapers. De kost hiervan is te groot, en er bestaat geen eenvoudige manier om te controleren welk verkeer geshaped moet worden, of om klanten te verplichten gebruik te maken van traffic shaping. Dit impliceert dat het upstream verkeer pas kan aangepast worden voorbij de CMTS. Op dat moment is het verkeer reeds voorbij de bottleneck (de coaxiale kabel). Traffic shaping helpt dus, wat upstream verkeer betreft, enkel voor het backbone verkeer waar momenteel geen tekort is aan bandbreedte.

4.6.2

Rate limiting

Een alternatief om de hoeveelheid peer-to-peer verkeer te be¨ınvloeden maakt gebruik van de eigenschappen van het TCP-protocol. Het TCP-protocol maakt gebruik van een ‘congestion avoidance’ algoritme: indien datapakketten verloren gaan, wordt de snelheid waarmee de pakketten verstuurd worden verlaagd. Hiervan kan gebruik gemaakt worden door de provider: wanneer verzadiging dreigt op te treden, kunnen met behulp van een netwerkanalyser de pakketten ge¨ıdentificeerd worden die behoren tot p2p-verbindingen. Door op regelmatige tijdstippen een pakket te verwijderen uit het netwerk wordt het congestion avoidance algoritme geactiveerd, waardoor de p2p-verbindingen minder bandbreedte verbruiken. Deze oplossing kan ge¨ımplementeerd worden in een head-end, waardoor de extra kosten


51

relatief beperkt blijven.

4.6.3

Extra kosten aanrekenen

In verschillende sectoren wordt de kost reeds berekend per verbruik, denk bijvoorbeeld aan telefonie. Dit is vooral mogelijk vanwege de gewenning van de gebruiker, en zou waarschijnlijk niet aanvaardbaar zijn voor de klanten van internetproviders. Het lijkt dan ook weinig waarschijnlijk dat providers gebruikers van p2p-toepassingen extra kosten zullen aanrekenen. Merk toch op dat dit, in zekere zin, reeds toegepast wordt: afhankelijk van het type abonnement neemt de maandelijkse kost toe.

4.6.4

(Euro-)DOCSIS QoS

(Euro-)DOCSIS bevat verschillende mogelijkheden om types verkeer te bevoordelen ten opzichte van ander verkeer. Het voordeel van deze optie is dat QoS reeds mogelijk is binnen het (Euro-)DOCSIS protocol. Aan real-time toepassingen kan een hogere prioriteit toegekend worden. In hoofdstuk 5 wordt meer onderzoek gedaan naar de verschillende mogelijkheden.

4.6.5

Peer-caches

Het principe van peer-chaches is eenvoudig: data-files worden lokaal opgeslaan binnen het netwerk van de provider. Wanneer een p2p-gebruiker een bestand zoekt, wordt de query geanalyseerd. Indien het bestand reeds aangevraagd werd, bevindt het zich in de peer-cache en wordt het rechtstreeks, vanuit de cache, naar de gebruiker verstuurd. Zoniet, wordt de query doorgestuurd in het p2p-netwerk. Dit systeem biedt verschillende voordelen: • De gebruiker downloadt zijn bestanden sneller omdat ze uit een lokale cache komen. • De provider betaalt minder transitkosten, omdat bestanden niet meer opgehaald worden uit een ander netwerk.


52

• Het upstreamnetwerk wordt ontlast: indien een bestand opgevraagd wordt en het bevindt zich in de p2p-cache, dan moet het toegangsnetwerk niet aangesproken worden. Het caching-systeem werkt omdat p2p-netwerken vooral gebruikt worden om een beperkt aantal populaire bestanden uit te wisselen. In [3] is te vinden dat 65% van de downloads 20% van de bestanden betreft. Meer informatie over de precieze werking is te vinden in [2]. Dit is de enige oplossing die de totale hoeveelheid verkeer kan verminderen. Toch zijn bij deze oplossing enkele opmerkingen te maken. Zo wordt in [2] niet vermeld welke p2p-protocollen herkend worden. Evenmin wordt gezegd wat de peer-cache doet met geëncrypteerde protocollen. Ook moet een extra aankoop- en installatiekost in rekening gebracht worden.

4.6.6

Vergelijking van de oplossingen

De oplossingen moeten goed scoren op drie criteria: Effectiviteit van de oplossing - geeft aan in welke mate de oplossing invloed heeft op het peer-to-peer verkeer. Impact op infrastructuur - een goede oplossing heeft een minimale extra kost voor de provider en vereist een minimale technologische wijziging. Behoud van user experience - geeft de mate weer waarin de tevredenheid van de klant wordt be¨ınvloed.

Niet alle gevolgen van een oplossing behoren tot één van deze drie criteria. Zo kan het gebruik van een peer-cache ook de transitkosten verlagen. Het is mogelijk een algemene rangschikking te geven van de verschillende oplossingen. Deze is noodzakelijkerwijs subjectief: niet alle effecten zijn grondig onderzocht of voorspelbaar. Dit overzicht heeft vooral als doel aan te duiden wat de sterke en zwakke aspecten zijn van de overlopen oplossingen.


53

Effectiviteit

Impact op infrastructuur

Behoud van user experience

-

--

++

Rate limiting

++

+

--

Exra charges

+++

++

---

(Euro-)DOCSIS QoS

+++

++

+++

++

+

+++

Traffic shaping

p2p-caches

Tabel 4.7: Vergelijking van de effectiviteit van de verschillende voorgestelde oplossingen om de invloed van p2p-verkeer te beperken Uit de tabel blijkt dat vooral de ingebouwde (Euro-)DOCSIS QoS mogelijkheden en het gebruik van peercaches veelbelovend lijken. De eerste oplossing richt zich vooral op het garanderen van Quality-of-Service voor bepaalde diensten. De tweede oplossing richt zich op het verminderen van het p2p-verkeer en het verlagen van de transitkosten, zonder daarbij garanties te leveren over Quality-of-Service. Beide oplossingen zijn niet noodzakelijk exclusief. In het volgende hoofdstuk zullen enkel de (Euro-)DOCSIS mogelijkheden verder onderzocht worden.

SIMULATIES

54

Hoofdstuk 5 Simulaties 5.1

Inleiding

In dit hoofdstuk worden HFC-netwerken onderzocht met behulp van simulaties. Het hoofdstuk wordt opgedeeld in twee soorten onderzoeken. Het eerste type onderzoek gaat de invloed na van verschillende (Euro-)DOCSIS parameters. Het tweede deel van de onderzoeken gaat na welke invloed peer-to-peer verkeer heeft op het HFC-netwerk. Bij deze laatste simulaties wordt gebruik gemaakt van de in deel 4.4 afgeleide distributies. De simulaties geven vooral een kwalitatief beeld, eerder dan een kwantitief beeld. Het precieze verloop van de bekomen grafieken hangt af van het type verkeer dat verstuurd wordt en de instellingen van het fysisch kanaal. De resultaten zijn dus niet absoluut, maar geven een indicatie van het verloop van performantie.

5.2

OPNET

Alle simulaties werden uitgevoerd in de OPNET [17] netwerksimulator. De bibliotheken van OPNET (Optimized Network Engineering Tools) bevatten geavanceerde modellen van netwerkprotocollen, technologieën en applicaties. De netwerksimulator biedt de mogelijkheid virtuele voorstellingen te maken van netwerken om de capaciteit, Quality-of-Service

5.2 OPNET

55

(QoS) en andere karakteristieken te testen. De DOCSIS module van OPNET werd ontwikkeld door OPNET en CableLabs’ Bandwidth Modeling and Management Vendor ” Forum”. Het model is gebaseerd op de DOCSIS 1.1 specificaties, en kan dus gebruikt worden om DOCSIS v1.0 en v1.1 systemen te modelleren. Een voorbeeldnetwerk wordt weergegeven in figuur 5.1.

5.2 OPNET 56

Figuur 5.1: Voorbeeld van een HFC-netwerk in OPNET

5.2 OPNET

5.2.1

57

Implementatie van de peer-to-peer modellen

Om simulaties mogelijk te maken werden in deel 4.4 distributies afgeleid die het peerto-peer verkeer modelleren. Daar werd de ´totale hoeveelheid data verstuurd per minuut’ afgeleid. In dit deel wordt deze distributie gebruikt om individuele p2p-gebruikers te modelleren. Het model van één individuele p2p-gebruiker wordt gekenmerkt door opeenvolgende ‘p2pperiodes’ van 60 seconden. Eerst wordt de opbouw van een p2p-periode beschreven, daarna de wijze waarop p2p-periodes elkaar opvolgen.

Opbouw van een p2p-periode De nauwkeurigheid van de metingen bedraagt slechts 1 minuut. We beschikken bijgevolg niet over informatie omtrent de verdeling van de pakketgrootte en de pakketspreiding binnen een p2p-periode. We bespreken kort de gemaakte keuzes met betrekking tot de pakketgrootte en de pakketspreiding. • De belasting van het netwerk wordt vooral veroorzaakt door dataverkeer. Dataverkeer bestaat uit grotere pakketten dan controleverkeer. Aangezien we vooral de belasting op het netwerk willen onderzoeken werd gekozen voor pakketgroottes van 1000 bytes. • Er moet een keuze gemaakt worden wat betreft de pakketspreiding van een p2pgebruiker binnen de 60 seconden. Er werd gekozen om alle pakketten te genereren aan het begin van de p2p-periode. De p2p-periode bestaat dus uit een actief deel, gevolgd door een passief deel. Dit is een ‘worst case’ voorstelling, die resulteert in bursty verkeer van iedere gebruiker.

Opeenvolgende p2p-periodes Er moet vermeden worden dat iedere p2p-gebruiker op hetzelfde moment data verstuurt, dit zou niet resulteren in een realistische simulatie. Uit de dataverwerking blijkt dat de metingen door de netwerkanalyser worden weggeschreven volgens een normaalverdeling,

5.2 OPNET

58

met een gemiddelde van 60 seconden en een variantie van 12 seconden. We laten ook de opeenvolgende p2p-periodes van de gebruikers elkaar opvolgen met deze gemiddelde waarde en variantie. De eerste p2p-periode van elke gebruiker laten we uniform beginnen binnen de eerste minuut. Hierdoor vallen de piekmomenten van de gebruikers de eerste minuut niet samen. Wanneer meerdere gebruikers actief zijn, wordt door statistische uitmiddeling het bursty gedrag van de gebruikers gedeeltelijk weggewerkt.

Voorbeeld Wanneer de distributies in OPNET worden ge¨ımplementeerd, wordt een verloop van de upstream data bekomen zoals in figuur 5.2. De gebruikers zenden gemiddeld om de 60 seconden met een variantie van 12 seconden. In deze simulatie beginnen de gebruikers op hetzelfde moment met het verzenden van data, in latere simulaties beginnen de CM’s met het verzenden van de data volgens een uniforme verdeling binnen de eerste minuut. In figuur 5.2 worden 4 gebruikers weergegeven, één van elk abonnementstype en dus met een andere distributie voor de uploadhoeveelheid. Bij elk model is een andere maximale snelheid ingesteld. Dit uit zich door een uitvlakking van de uploadsnelheid: de CM kan niet sneller data verzenden dan de maximaal toegelaten snelheid.

5.2.2

Tekortkomingen van OPNET

OPNET is een geavanceerde netwerksimulator met uitgebreide mogelijkheden. Toch zijn tijdens de simulaties verscheidene bugs en tekortkomingen opgemerkt in de DOCSIS module van OPNET. Enkele studies konden hierdoor niet uitgevoerd worden, waardoor enkele simulaties moesten aangepast worden, ten koste van het realisme ervan. 1. Bugs • DOCSIS 1.1 non-real-time Polling Service (zie deel 3.4) biedt unicast request mogelijkheden om contention te vermijden wanneer er overbezetting optreedt op het netwerk. In de OPNET implementatie van nrtPS worden geen unicast request polls toegevoegd aan de MAP. Dit is het enige verschil tussen

5.2 OPNET

59

128 kbps abonnement 192 kbps abonnement 512 kbps abonnement 512 kbps abonnement Extra

700 600

IP bitrate (kbps)

500 400 300 200

100 0 100

150

200

250

300 tijd (sec)

350

400

450

500

Figuur 5.2: Eenvoudig model van p2p gebruikers nrtPS en Best Effort, waardoor nrtPS zich gedraagt als BE. Er konden dus geen studies worden uitgevoerd met nrtPS. 2. Beperkingen • In de specificaties van (Euro-)DOCSIS bestaat de mogelijkheid meerdere Service Flows in te stellen per CM. Dit gebeurt door middel van een configuratiebestand dat door de CM wordt gedownload. In OPNET is de Service Flow enkel instelbaar per CM, waardoor deze geldt voor alle verkeer van de CM. • In een praktische implementatie van een (Euro-)DOCSIS netwerk wordt de maximale uploadsnelheid per CM geregeld door een configuratiebestand. Er bestaat geen mogelijkheid de maximale snelheid te regelen per CM in OPNET. De enige manier waarop de uploadsnelheid te regelen is, is door het veranderen

5.3 Opbouw van de simulaties

60

van het MAP interarrival time van de CMTS. Dit impliceert dat de maximale uploadsnelheid een parameter is die enkel regelbaar is per kanaal. Deze tekortkoming treedt enkel op bij Best Effort diensten, aangezien bij rtPS en UGS het polling/grant interval wel individueel instelbaar is. In onderstaande tabel wordt een overzicht gegeven van de maximale best effort uploadsnelheid en de overeenkomstige instelling voor de MAP interarrival time. maximale uploadsnelheid

MAP interrarival time (sec)

96 kbps

0,02

128 kbps

0,015

192 kbps

0,01

512 kbps

0,00375

Tabel 5.1: MAP interarrival tijden voor verschillende uploadsnelheden • (Euro-)DOCSIS bevat heel wat ingebouwde beveiligingsfuncties, gaande van authenticatie van de CM tot encryptie van de verzonden data. Deze worden geen van allen ondersteund in OPNET. • De momentele DOCSIS module in OPNET ondersteunt maximaal (Euro-) DOCSIS v1.1. Extra upstream- en downstreammodulaties, worden niet ondersteund.

5.3

Opbouw van de simulaties

Voor de simulaties zijn telkens de volgende elementen opgegeven: 1. Beschrijving Beschrijft het doel van de simulaties. 2. Testopstelling Beschrijving van de gebruikte parameters en testscenario’s.

5.4 HFC-simulaties

61

3. Opmerking Eventuele extra commentaar bij de simulaties. 4. Conclusies De besluiten die kunnen genomen worden op basis van de simulaties. In OPNET is het mogelijk een ‘taak’ te definiëren: deze geeft aan welk type verkeer gegenereerd wordt in een node. Daarbij kan o.a. de pakketgrootte, de tijd tussen de pakketten en de tijd waarna de taak zichzelf herhaalt, gedefinieerd worden. Gedurende de simulaties wordt meermaals een ‘taak’ gebruikt om het verkeer te beschrijven dat gegenereerd wordt door de CM’s. In de simulaties wordt gebruik gemaakt van load als indicatie van de bezettingsgraad van het upstreamkanaal. Deze geeft aan welk percentage van de beschikbare bandbreedte (die het upstream kanaal aanbiedt) gebruikt wordt. Load = Reserved slot time in MAP/Total MAP duration De reserved minislots duiden het gedeelte van het upstreamkanaal aan dat niet beschikbaar is voor ander dataverkeer. Deze indicatie geeft ook correcte resultaten wanneer een CM meer slots toegewezen krijgt dan hij daadwerkelijk gebruikt. De extra toegewezen minislots kunnen immers niet door andere CM’s aangevraagd worden. Een uitgebreid overzicht van de instelling bij de verschillende simulaties vindt u terug in appendix B.

5.4

HFC-simulaties

5.4.1

Simulatie 1: Overhead door het (Euro-)DOCSIS protocol

• Beschrijving In deze simulatie wordt onderzocht hoeveel de overhead bedraagt bij het versturen van IP-data over een (Euro-)DOCSIS netwerk.

5.4 HFC-simulaties

62

• Testopstelling Er wordt gebruik gemaakt van 1 CM die verkeer genereert. Om dit verkeer te genereren werd een taak gedefinieerd, bestaande uit 100 pakketten van 1000 bytes. Deze pakketten worden direct na elkaar verzonden (dus met een interpakket tijd van 0 seconden). De taak wordt na een variabele periode herhaald. • Conclusies

bitrate (kbps)

250 Upstream traffic (IP) Upstream traffic ((Euro−)DOCSIS)

200 150 100 50 0

0

100

200

300

400 500 tijd (sec)

600

700

800

900

reserved time slot (sec)

Figuur 5.3: Upstream overhead bij het (Euro-)DOCSIS protocol

0.05 0.04 0.03 0.02 0.01 0

0

100

200

300

400 500 tijd (sec)

600

700

800

900

Figuur 5.4: Bezettingsgraad uitgedrukt als ‘reserved time slot/MAP duration’

Uit figuur 5.4 blijkt dat de gedefinieerde load, als functie van de Reserved slot time in MAP, een goede indicatie geeft van de procentuele bezettingsgraad. De totale beschikbare bandbreedte is 5.12 Mbps. De Total MAP duration is doorheen de hele simulatie 1 seconde. Op het piekmoment bereikt de Reserved slot time in MAP

5.4 HFC-simulaties

63

0.04 seconden, dus is de uploadsnelheid 4% van 5.12 Mbps, of 200 kbps. Dit komt overeenkomt met de load op MAC niveau in figuur 5.3. De load op MAC niveau blijkt bijna dubbel zo hoog te liggen als de load op IP niveau. Om dit fenomeen te verklaren wordt eerst de theoretische overhead berekend.

Overhead van de data Datapakket: 1000 bytes TCP header: 20 bytes IP header: 20 bytes Ethernet header: 18 bytes (14 bytes header en 4 bytes CRC)

DOCSIS Overhead DOCSIS MAC Header: 6 bytes DOCSIS extended header (BPI): 5 bytes CRC: 4 bytes Dit brengt de grootte van het totale MAC frame (Data + TCP-header + IP-header + ethernet-header + DOCSIS-header) op 1073 bytes. Deze MAC frames worden over het fysisch kanaal verstuurd, wat nog een extra overhead veroorzaakt.

Physical Media Overhead Aangezien Short Data Frames gelimiteerd zijn tot 100 bytes wordt er gebruik gemaakt van Long Data Frames die tot 10.000 bytes kunnen bevatten. Preamble length: 56 bits FEC (Forward Error Correction) pariteitsbytes: 16 bytes FEC Codeword length: 226 bytes Guard time: 40 bits Berekening van de uiteindelijke fysische pakketgrootte:

5.4 HFC-simulaties

64

Aantal codewoorden = (MAC frame)/(FEC Codeword length) = 1073/226 = 5 (afgerond naar het hoger gelegen geheel getal) Uiteindelijke message lengte = number of codewords x (FEC codeword length + 2 * FEC pariteitsbytes) = 5 x (226+2*16) = 1290 Totale frame lengte = message lengte + (Preamble + Guard Time)/8 = 1290 + (56 + 40)/8 = 1302 bytes.

Verdeling in minislots De CM moet een geheel aantal minislots aanvragen om de data te versturen. In de simulatie is de grootte van de minislots 32 bytes. Om de 1302 bytes te versturen moeten minstens 41 minislots aangevraagd worden. Uiteindelijk worden dus (41 minislots) * (32 bytes per minislot) = 1312 bytes aangevraagd. De overhead bedraagt bijna 30%. Deze wordt grotendeels veroorzaakt door de overhead op de fysische laag. Deze overhead kan verkleind worden door de FEC parameters te wijzigen. Bij kleine pakketten (zoals VoIP) loopt de overhead zelfs op tot 78% [18]. Een alternatief is het gebruik van Payload Header Suppression (PHS).

Overhead vs Load De bovenstaande berekening van de MAC- en fysische overhead verklaart niet de verdubbeling van load op (Euro-)DOCSIS niveau, in vergelijking met deze op IP niveau. De oorzaak daarvan is waarschijnlijk te zoeken bij de implementatie van het (Euro-)DOCSIS protocol in OPNET. Een CMTS kan meer slots toewijzen aan een CM dan deze heeft aangevraagd. Dit wordt onder andere gebruikt om synchronizatieproblemen te vermijden, of om concatenation toe te laten indien er geen gebrek is aan bandbreedte. De exacte details hangen af van de implementatie van de CMTS.

5.4 HFC-simulaties

Figuur 5.5: Encapsulatie van data frames in DOCSIS frames

65

5.4 HFC-simulaties

5.4.2

66

Simulatie 2: Invloed van concatenation, piggybacking en fragmentation

• Beschrijving Het (Euro-)DOCSIS protocol ondersteunt verschillende mogelijkheden om op een efficiëntere manier data te verzenden van CM naar CMTS. In deze simulatie wordt nagegaan in welke mate het gebruik van concatenation, piggybacking en fragmentation (zie deel 3.3) de performantie be¨ınvloedt. Hiertoe wordt de delay uitgezet ten opzichte van de load. • Testopstelling De verzonden data bestaat uit een taak van 15 pakketten, waarbij elk pakket 1000 bytes bevat. Deze pakketten worden bursty verstuurd (interpakket tijd is 0 seconden). De tijd tussen de opeenvolgende taken is exponentieel verdeeld en wordt gebruikt om de load te variëren gedurende de simulaties. Scenario 1: 7 CM’s verzenden data, piggybacking, fragmentation en concatenation disabled Scenario 2: 7 CM’s verzenden data, enkel piggybacking enabled Scenario 3: 7 CM’s verzenden data, enkel fragmentation en concatenation enabled Scenario 4: 7 CM’s verzenden data, piggybacking, fragmentation en concatenation enabled De uiteindelijke delay wordt berekend door uitmiddeling van de resultaten over de betreffende CM’s en over de simulatietijd van 2 uur. • Opmerking In alle gevallen wordt aan contention gedaan, aangezien het nog steeds om best effort verkeer gaat. De delay wordt berekend als het verschil tussen het tijdstip waarop het eerste pakket van de taak verzonden wordt en het tijdstip waarop het laatste pakket de CMTS bereikt. De gebruikte taak geeft vooral een kwalitatieve indicatie van het moment waarop

5.4 HFC-simulaties

67

de delay onaanvaardbaar groot wordt. De bezettingsgraad waarop de delay onaanvaardbaar wordt hangt af van de specifieke toepassing, maar zal wel van dezelfde grootte-orde zijn. Concatenation en fragmentation zijn beiden gespecificeerd in DOCSIS v1.1 en worden meestal in combinatie gebruikt. In de verdere simulaties wordt, tenzij anders vermeld, steeds gebruik gemaakt van concatenation, piggybacking en fragmentation. • Conclusies

15 Contention Piggybacking Concatanation and fragmentation All

delay (sec)

10

5

0

0

10

20

30

40 load (%)

50

60

70

80

Figuur 5.6: Invloed van concatenation, piggybacking en fragmentation Concatenation en fragmentation Uit de grafiek blijkt dat het gebruik van concatenation, piggybacking en fragmentation een gunstige invloed heeft op de performantie van het systeem. Vooral het inschakelen van concatenation en fragmentation verbetert de performantie van het systeem in hoge mate. De CM kan tegelijk meerdere pakketten, of delen van pakketten, versturen. Dit is vooral van belang bij VoIP, aangezien de delay en jitter sterk gereduceerd wordt [19].

5.4 HFC-simulaties

68

Piggybacking De invloed van piggybacking is relatief beperkt, dit blijkt ook uit [20]. Piggybacking heeft voornamelijk een grote invloed wanneer de buffer van de CMTS volzet blijft. Zoniet, kan een pakket geen aanvraag meesturen (‘piggybacken’) voor een volgend pakket. Indien het verkeerspatroon bursty is, zal de buffer gedurende geruime tijd volzet blijven. Om dit te illustreren is een nieuwe simulatie uitgevoerd. Hierbij zijn 7 CM’s verbonden met een CMTS. Er worden twee types verkeer verstuurd: bursty (40 pakketten van 1000 bytes gevolgd door 40 seconden pauze) en niet bursty (1 pakket per seconde gedurende 40 seconden). De resultaten hiervan (na uitmiddeling over de 7 CM’s) worden weergegeven in tabel 5.2. Daaruit blijkt duidelijk dat piggybacking vooral de prestaties van bursty verkeer positief be¨ınvloedt, en minder invloed uitoefent op non-bursty verkeer. Type verkeer

Piggybacking

Gemiddelde packet delay

niet-bursty

uitgeschakeld

0.103 sec

niet-bursty

ingeschakeld

0.078 sec

bursty

uitgeschakeld

10.1 sec

bursty

ingeschakeld

0.321 sec

Tabel 5.2: Invloed van piggybacking op bursty en non-bursty verkeer

5.4.3

Simulatie 3: Prioriteiten in de DOCSIS module van OPNET

• Beschrijving Het (Euro-)DOCSIS protocol ondersteunt verschillende prioriteiten binnen de best effort klasse. Er zijn in de specificaties 8 prioriteitsklassen gedefinieerd. Ze zijn genummerd van 0 tot 7, waarbij best effort 0 voorrang krijgt op alle andere prioriteiten. Best effort 7 is de standaard prioriteit. In deze simulatie wordt onderzocht welke invloed verschillende best effort prioriteiten hebben op het upstream verkeer. Hiertoe wordt de delay van een welgedefinieerde taak uitgezet ten opzichte van de load.

5.4 HFC-simulaties

69

• Testopstelling De testopstelling bevat CM’s van verschillende prioriteitsklassen om het effect ervan te kunnen onderscheiden. De testopstelling bestaat uit: 6 CM’s met prioriteit 7 6 CM’s met prioriteit 4 6 CM’s met prioriteit 0 1 CM met UGS (granting interval van 0.005 seconden) De verzonden data bestaat uit een taak van 15 pakketten die elk 1000 bytes bevatten. De pakketten worden verstuurd met een interpakket tijd van 0 seconden. De tijd tussen de verschillende taken is exponentieel verdeeld. De netwerkload wordt verhoogd door de tussentijd te verlagen van gemiddeld 120 seconden tot gemiddeld 4 seconden. De uiteindelijke waarde wordt bekomen door uitmiddeling van de delay over de CM’s van een bepaald type en over de tijd (de simulatietijd bedraagt 2 uur). Type

concatenation

fragmentation

piggybacking

best effort prioriteit

UGS

best effort 7

yes

yes

yes

7

-

best effort 4

yes

yes

yes

4

-

best effort 0

yes

yes

yes

0

-

UGS

yes

no

no

-

yes

Tabel 5.3: Instellingen van de CM’s bij simulatie 3

• Opmerking De delay wordt berekend als het verschil tussen het tijdstip waarop het eerste pakket van de taak verzonden wordt, en het tijdstip waarop het laatste pakket de CMTS bereikt. De gebruikte taak geeft vooral een kwalitatieve indicatie van het moment waarop de delay onaanvaardbaar groot wordt. De bezettingsgraad waarop de delay onaanvaardbaar wordt, hangt af van de specifieke toepassing, maar zal wel van dezelfde grootte-orde zijn.

5.4 HFC-simulaties

70

• Conclusies

7 Prioriteit 7 Prioriteit 4 Prioriteit 0 UGS

6

delay (sec)

5

4

3

2

1

35

40

45

50 55 Load (%)

60

65

70

75

70

75

Figuur 5.7: Effect van prioriteiten op korte termijn

7

6

Prioriteit 7 Prioriteit 4 Prioriteit 0 UGS

delay (sec)

5

4

3

2

1

35

40

45

50 55 Load (%)

60

65

Figuur 5.8: Effect van prioriteiten op lange termijn Best effort biedt geen Quality-of-Service garanties. Er zijn dus geen garanties dat

5.4 HFC-simulaties

71

best effort 0 beter is dan best effort 7. Dit blijkt duidelijk uit de vergelijking van figuur 5.7, met een simulatieduur van 8 minuten, met figuur 5.8, met simulatieduur van 2 uur. De verschillende best effort prioriteiten hebben vooral een lange-termijn effect. Uit de figuren blijkt dat dit effect slechts langzaam convergeert, wat twijfels oproept over het praktisch nut van de prioriteiten.

5.4.4

Simulatie 4: QoS in (Euro-)DOCSIS

• Beschrijving (Euro-)DOCSIS ondersteunt niet enkel best effort: er zijn verschillende andere QoS mogelijkheden gedefinieerd. Een meer uitgebreide beschrijving is terug te vinden in deel 3.4. In deze simulatie wordt de invloed van de verschillende QoS mogelijkheden onderzocht. Hiertoe wordt de delay van een welgedefinieerde taak uitgezet ten opzichte van de load. • Testopstelling De gebruikte taak bestaat uit een request van 15 pakketten, die elk 1000 bytes bevatten. De pakketten worden verstuurd met een interpakket tijd van 0 seconden. De tijd tussen de verschillende taken bedraagt 4 seconden. De testopstelling bestaat uit een netwerk dat een variabel aantal CM’s bevat, waaronder 1 CM met prioriteit 0, 1 CM met nrtPS, 1 CM met rtPS en 1 CM met UGS. De load wordt verhoogd door extra CM’s met best effort 7 toe te voegen aan het netwerk. Het UGS grant interval en het RTP polling interval worden ingesteld op 0,005 seconden. Om het beperkt aantal CM’s van elk type te compenseren, wordt de test meerdere keren uitgevoerd met andere randomwaarden. Het eindresultaat wordt bekomen door uitmiddeling van de resultaten over de verschillende simulaties. • Opmerkingen De delay wordt berekend als het verschil tussen het tijdstip waarop het eerste pakket

5.4 HFC-simulaties

72

van de taak verzonden wordt en het tijdstip waarop het laatste pakket de CMTS bereikt. De load wordt in deze simulatie verhoogd door het toevoegen van extra CM’s. Deze aanpak is eenvoudiger dan het wijzigen van het type verkeer: UGS en nrtPS moeten worden afgesteld op het type verkeer dat verzonden wordt. Anders kunnen, door het regelmatig wijzigen van de UGS parameters, de resultaten niet vergeleken worden met eerder gemeten resultaten bij lagere belasting. Het precieze verloop van de grafiek hangt af van het type verkeer dat verstuurd wordt en de instellingen van het fysisch kanaal. De resultaten geven dus vooral een kwalitatief beeld, eerder dan een kwantitatief beeld: bij andere instellingen zullen de grafieken gedeeltelijk verschuiven ten opzichte van elkaar. Enkele instellingen van deze simulatie (zie appendix B) zijn anders dan in de derde simulatie. Hierdoor is de performantie van het best effort verkeer niet gelijk aan deze uit de eerdere simulatie. • Conclusies

10 9 8

Best effort prioriteit 7 Best effort prioriteit 0 Non−real Time Polling Real−time Polling

delay (sec)

7

Unsollicited Grant

6 5 4 3 2 1 10

20

30

40

50

60

load (%)

Figuur 5.9: Effect van granting services op delay

70

80

5.5 Peer-to-peer simulaties

73

Non-real-time Polling Service Er is een fout aanwezig in de implementatie van nrtPS bij OPNET: de CMTS voegt geen unicast requests bij de MAP. Aangezien dit het enige verschil is dat nrtPS onderscheidt van best effort, kunnen geen performantiestudies uitgevoerd worden met nrtPS. Real-time Polling Service De prestaties van rtPS blijken zeer acceptabel te zijn: verzadiging van het kanaal treedt pas laat op, wanneer de CMTS niet kan voldoen aan de vraag naar vrije upstreamslots. Binnen het gebied zonder verzadiging blijft de performantie ongeveer constant. Voor tijdkritische, maar niet welomschreven toepassingen, blijkt RTP dus een optie die performantie garandeert. Unsollicited Grant Service UGS is de meest performante oplossing voor tijdskritische toepassingen. Er zijn echter enkele nadelen verbonden aan het gebruik van UGS. Zo is het gebruik van UGS enkel aan te raden voor duidelijk omschreven verkeer (bijvoorbeeld VoIP). Ook kan UGS heel vlug tot verspilling van uploadbandbreedte leiden.

5.5

Peer-to-peer simulaties

5.5.1

Simulatie 5: Vergelijking van de belasting gedurende een piekuur en een daluur

• Beschrijving In deze simulatie wordt een realistisch model opgebouwd van het HFC-netwerk, gebaseerd op de in hoofdstuk 4 afgeleide distributies. Om een beeld te krijgen van de invloed van het uur van de dag wordt zowel een piekmoment (tussen 21u en 22u) en een daluur (tussen 6u en 7u) gemodelleerd. • Testopstelling Het uploadverkeer wordt ingesteld zoals in 5.3. Hierbij wordt gebruik gemaakt van


74

de in hoofdstuk 4 afgeleide distributies van de uploadgrootte per peer-to-peer gebruiker, de distributie van de hoeveelheid achtergrondverkeer en het gemiddeld aantal gebruikers. Aangezien de maximale uploadsnelheid enkel kan ingesteld worden per kanaal (zoals vermeld in deel 5.2.2 ‘OPNET tekortkomingen’), wordt gekozen voor één algemene maximale uploadsnelheid van 128 kbps. De precieze invloed van de verschillende uploadsnelheden wordt onderzocht in simulatie 6. Type gebruikers

6u ’s ochtends

21u ’s avonds

128 kbps p2p

1

4

128 kbps achtergond

3

22

192 kbps p2p

1

3

192 kbps achtergond

2

12

512 kbps p2p

1

2

512 kbps achtergond

2

4

512 kbps Extra p2p

1

1

512 kbps Extra achtergond

2

3

Tabel 5.4: Aantal actieve gebruikers van de verschillende abonnementstypes bij simulatie 5 • Opmerking In deze simulatie kijken we enkel naar de verbruikte uploadbandbreedte. Dit is de load zoals gedefinieerd in 5.3. De peer-to-peer gebruikers worden in deze simulatie gescheiden van de CM’s die achtergrondverkeer genereren. Dit vereenvoudigt latere simulaties: het peer-topeer verkeer en het achtergrondverkeer kunnen afzonderlijk gewijzigd worden. In de praktijk genereren veel actieve CM’s zowel achtergrondverkeer als peer-to-peer verkeer. • Conclusies


75

45 Bezetting zonder uitmiddeling Gemiddelde bezetting

40 35

Load (%)

30 25 20 15 10 5 0

100

200

300

400

500 tijd (sec)

600

700

800

900

Figuur 5.10: Bezettingsgraad van het kanaal om een piekmoment (tussen 21u en 22u)

18 16 14

load (%)

12 10 8 6 4 2 0

Bezetting van model zonder p2p verkeer Bezetting van volledig model 100

200

300

400

500 tijd (sec)

600

700

800

Figuur 5.11: Bezettingsgraad zonder p2p- en met p2p-verkeer

900


76

25 Gemiddelde bezetting zondag 21h Gemiddelde bezetting zondag 6h Bezetting zondag 6h zonder uitmiddeling

load (%)

20

15

10

5

0

100

150

200

250

300

350 tijd (sec)

400

450

500

550

600

Figuur 5.12: Vergelijking van de bezettingsgraad tussen een piekmoment (tussen 21u en 22u) en een daluur (tussen 6u en 7u)

Uit figuur 5.10 blijkt dat zelfs op een piekmoment de maximale bezetting niet meer dan 45% bedraagt. Hoewel geen saturatie optreedt, ligt de piekbandbreedte een heel stuk hoger dan de gemiddelde bandbreedte die ongeveer 16% bedraagt. In figuur 5.11 wordt het 21 uur model weergegeven, met en zonder het peer-to-peer verkeer. Het p2p-verkeer neemt een belangrijk percentage van de bandbreedte in. Deze simulatie betreft zelfs een onderschatting van het p2p-verkeer, aangezien in deel 5.6 verduidelijkt wordt dat een gedeelte van het achtergrondverkeer mogelijks ook p2p verkeer omvat. Vervolgens wordt de invloed van het uur van de dag nagegaan: de twee modellen (6u ’s ochtends en 21u ’s avonds) worden met elkaar vergeleken in figuur 5.12. De gemiddelde bezetting om 6 uur ’s ochtends bedraagt slechts één derde van de bezettingsgraad om 21u. Het verkeer is erg grillig: doordat minder CM’s actief zijn worden de modellen weinig uitgemiddeld. Dit tekort van de modellering werd reeds aangehaald in punt 5.2.1. Merk tenslotte op dat het percentage p2p-verkeer niet noodzakelijkerwijs moet


77

overeenkomen met het percentage actieve p2p-gebruikers (zoals afgeleid in punt 4.4.2). De gemiddelde uploadhoeveelheid is immers groter bij p2p-gebruikers, waardoor een kleiner aandeel actieve p2p-gebruikers toch een groter aandeel van de bandbreedte kan verbruiken.

5.5.2

Simulatie 6: Invloed van de uploadsnelheid op piekverbruik

• Beschrijving Vanwege een beperking van OPNET (zie punt 5.2.2) is het niet mogelijk een uploadsnelheid in te stellen per CM. Dit impliceert dat de maximale uploadsnelheid een parameter is die enkel regelbaar is per kanaal. Dit is een ernstige beperking wanneer we de invloed van de verschillende abonnementen willen onderzoeken, aangezien in de praktijk grotere gebruikers ook sneller kunnen uploaden. Om simulatie 5 realistischer te maken, wordt in deze simulatie onderzocht welke invloed het wijzigen van de uploadsnelheid heeft. • Testopstelling De testopstelling is volledig identiek aan simulatie 5. De testopstelling wordt 3 maal uitgevoerd, eenmaal met uploadsnelheid 128 kbps, eenmaal met uploadsnelheid 192 kbps en tenslotte met uploadsnelheid 512 kbps. • Conclusies


78

45 512 kbps upload 128 kbps upload 192 kbps upload

40 35

load (%)

30 25 20 15 10 5 0

100

200

300

400

500 tijd (sec)

600

700

800

900

Figuur 5.13: Invloed van de uploadsnelheid op piekverbruik

Een wijziging van de uploadsnelheid wijzigt niets aan de gemiddelde bezettingsgraad, er moet nog steeds evenveel data verstuurd worden binnen dezelfde tijdsspanne. Een wijziging van uploadsnelheid be¨ınvloedt enkel het piekverbruik. Naarmate de maximale uploadsnelheid verlaagt, treden hogere pieken op bij de verbruikte bandbreedte. Dit wordt veroorzaakt doordat de bezettingsgraag vooral toeneemt wanneer meerdere gebruikers tegelijk data verzenden. Bij lagere uploadsnelheden is de kans groter dat de buffers van meerdere CM’s datapakketten bevatten. Hierdoor wordt in dezelfde MAP meer data verstuurd, wat zich uit in een hogere piek in de bezettingsgraad. In de simulatie gaf een uploadsnelheid van 512 kbps een piekverbruik van 35%, tegenover een piekverbruik van 45% bij een snelheid van 128 kbps. In simulatie 5 werd een ‘realistisch’ systeem gesimuleerd.

Deze situatie kwam

overeen met een uploadsnelheid van 128 kbps, een ‘worst case’ situatie. In de praktijk is een mengeling van CM’s aanwezig die elk een verschillende uploadsnelheid hebben. De 512 kbps situatie komt dan overeen met het meest optimale geval. De realiteit zal zich tussen deze ‘worst case’ en ‘best case’ bevinden.


79

Het is mogelijk dat, door het verhogen van de uploadsnelheid, het toekomstig uploadgedrag van de gebruikers wijzigt. Zo kan een hogere uploadsnelheid de klanten aanzetten het uploaden van meer data. Het verhogen van de maximale uploadsnelheid is dus enkel voordelig om hoge bezettingspieken af te zwakken, op voorwaarde dat het uploadgedrag hierdoor niet wijzigt. Uploadsnelheid in de praktijk In een realistische situatie wordt de uploadsnelheid per CM geregeld door een scheduling algoritme in de CMTS, terwijl de MAP interarrival tijd constant blijft. De effecten zijn gelijkaardig: een hogere uploadsnelheid impliceert dat buffers minder pakketten bevatten, waardoor minder hoge piekwaarden optreden. De meeste scheduling algoritmes veroorzaken een gemiddelde uploadsnelheid door uitmiddeling, eerder dan continu elk pakket te controleren. Het is dus mogelijk dat een CM tijdelijk aan een hogere snelheid verzendt dan zijn gemiddelde snelheid. Dit heeft een positief effect op de pieken, wat van onze simulatie een worst-case situatie maakt. Scheduling algoritmes worden niet door de (Euro-)DOCSIS specificaties opgelegd, de algoritmes zijn dus verkoperafhankelijk.

5.5.3

Simulatie 7: Invloed van peer-to-peer op de QoS van ander verkeer

1. Beschrijving In deze simulatie wordt nagegaan of de hoge load, veroorzaakt door p2p-verkeer, een nadelige invloed heeft op de delay en in welke mate de QoS-diensten van (Euro-)DOCSIS deze invloed ongedaan kunnen maken. 2. Testopstelling Er worden 2 CM’s aangemaakt met een profiel dat een constante hoeveelheid data verstuurt. De gebruikte taak bestaat uit een request van 15 pakketten die elk 1000 bytes bevatten. De pakketten worden verstuurd met een interpakket tijd van 0


80

seconden. De tijd tussen de verschillende taaks is exponentieel verdeeld met een gemiddelde van 4 seconden. De rest van het netwerk is gelijk aan de simulatie van zondag 21 uur, zoals in deel 5.5.1. Om de resultaten te bekomen wordt uitgemiddeld over de 2 CM’s en over de simulatietijd van 3 uur. 3. Opmerking Deze simulatie is erg analoog aan simulatie 4, waar de invloed van (Euro-)DOCSIS QoS werd nagegaan. De resultaten in verband met de verschillende granting mogelijkheden moeten dus analoog zijn, maar worden hier nagegaan op basis van een realistische situatie. De delay wordt bepaald als het moment waarop het laatste pakket van de hoger gedefinieerde taak de server bereikt. Afhankelijk van het type verkeer kunnen andere parameters (zoals jitter) belangrijk zijn. Voor deze parameters kunnen analoge conclusies gemaakt worden als over de delay. 4. Conclusies

Type QoS

delay

best effort 7 1.89 sec best effort 0 1.86 sec rtPS

1.54 sec

UGS

1.27 sec

Tabel 5.5: Delay bij de verschillende QoS mogelijkheden in een realistische situatie

De resultaten blijken erg analoog te zijn aan simulatie 4: UGS geeft de beste prestaties, gevolgd door nrtPS. Het verschil tussen best effort 0 en 7 is klein. Deze simulatie toont aan dat, hoewel de load slechts een klein aandeel bedraagt van de totale beschikbare bandbreedte (gemiddeld 16% op drukke momenten), het gebruik van de QoS diensten reeds een positieve invloed heeft op de performantie. Bij hogere belastingen van het netwerk maken de QoS diensten nog meer verschil.


5.5.4

81

Simulatie 8: Invloed van extra peer-to-peer verkeer

1. Beschrijving In deze simulatie wordt onderzocht wat de invloed is van extra peer-to-peer verkeer op het netwerk. Er wordt nagegaan of er grote verschillen zijn tussen de abonnementen. 2. Testopstelling Er wordt gebruik gemaakt van het in simulatie 5 opgestelde netwerk. Hierbij worden eerst 15 en daarna 30 extra p2p-gebruikers bijgevoegd van het 128 kbps abonnement. Dezelfde test wordt uitgevoerd met p2p-gebruikers van het 512 kbps abonnement Extra. 3. Opmerkingen De simulatieduur is groter dan bij simulatie 5, waardoor de pieken meer uitgemiddeld worden. 4. Conclusies Wanneer meer gebruikers data verzenden op het kanaal wordt het verkeer beter uitgespreid, wat resulteert in minder extreme pieken. Uit figuur 5.14 blijkt een groot verschil tussen de abonnementen. Extra p2p-gebruikers van het 128 kbps abonnement hebben een beperkte invloed, daartegenover vereisen 512 kbps Extra gebruikers veel meer bandbreedte. Dit toont aan dat er een zeer groot verschil is tussen gewone p2p-gebruikers en ‘zware’ p2p-gebruikers. Extra p2p-verkeer vormt geen onmiddellijk probleem behalve als het zware gebruikers betreft. De standaardafwijking van het aantal actieve p2p-gebruikers bij het ‘512 kbps abonnement Extra’ bedraagt slechts 0.5 gebruikers. De kans op een dergelijke hoeveelheid zware gebruikers is klein. De gemiddelde bezettingsgraad bij de simulaties wordt weergegeven in tabel 5.6.

5.6 Beperkingen van de simulaties

82

70

60

load (%)

50

40

30

20 model 21h 128 kbps abonnement: 15 extra gebruikers 128 kbps abonnement: 30 extra gebruikers 512 kbps abonnement Extra: 15 extra gebruikers 512 kbps abonnement Extra: 30 extra gebruikers

10

0

0

500

1000

1500

2000 tijd (sec)

2500

3000

3500

Figuur 5.14: Invloed van extra p2p gebruikers Simulatie

Gemiddelde bezettingsgraad

Model 21h

0.221359265 %

‘128 kbps abonnement’: 15 extra gebruikers

23.7794079 %

‘128 kbps abonnement’: 30 extra gebruikers

25.2743515 %

‘512 kbps abonnement Extra’: 15 extra gebruikers

41.2480732 %

‘512 kbps abonnement Extra’: 30 extra gebruikers

57.9088536 %

Tabel 5.6: Gemiddelde bezettingsgraad bij meer p2p-gebruikers

5.6

Beperkingen van de simulaties

De simulaties geven vooral een indicatie van een realistische situatie. Geen enkele simulatietool houdt rekening met alle aspecten van een HFC-systeem. De tekortkomingen gaan van kleine details, zoals geen rekening houden met de door ruis ge¨ıntroduceerde fouten, tot grotere tekorten, zoals het kunnen instellen van maximaal één SID per CM

5.7 Oplossingen

83

en het instellen van een maximale uploadsnelheid per kanaal i.p.v. per CM. Andere onnauwkeurigheden worden veroorzaakt doordat geen rekening gehouden kan worden met verkoperafhankelijke implementaties, zoals schedulingalgoritmes. Tenslotte worden in de meeste HFC-netwerken de verschillende (Euro-)DOCSIS parameters geoptimaliseerd voor het betreffende netwerk. Voor de simulatie moet noodgedwongen gebruik gemaakt worden van standaardwaarden. Een ander type beperkingen heeft te maken met de metingen. Zoals vermeld in deel 4.5 beslaan de metingen een korte tijdspanne (2 dagen) en hebben ze een beperkte resolutie (1 gecumuleerde meting per minuut). Dit maakt van de p2p-simulaties eerder een momentopname dan een algemeen geldig beeld. Verder staat niet vast dat alle p2p-verkeer werd opgemeten door de netwerkanalyser, aangezien sommige protocollen geëncrypteerd zijn. Een laatste beperking is de complexiteit van de ‘realistische’ simulaties. Wanneer gebruik gemaakt wordt van ongeveer 50 CM’s met elk andere instellingen en eventueel andere granting mogelijkheden, neemt de tijd om de simulaties uit te voeren sterk toe. Op de testcomputer (2Ghz CPU, 512 RAM) hadden verscheidene simulaties meer tijd nodig om te simuleren dan de tijd die gesimuleerd werd. Daarbij wordt een groot voordeel van simulaties teniet gedaan, namelijk de snelheid waarmee verschillende parameters en situaties getest kunnen worden. Dit is de hoofdreden waarom geen gebruik wordt gemaakt van de in de literatuur afgeleide distributies die veel complexer zijn.

5.7

Oplossingen

In dit deel wordt overlopen welke (Euro-)DOCSIS oplossingen een provider ter beschikking heeft om de invloed van p2p-verkeer af te zwakken. Eerst moet opgemerkt worden dat de momentele belastingssituatie geen probleem vormt wat saturatie betreft. Maar zelfs bij de lage bezettingsgraad die er momenteel is, kan het voordelig zijn om sommige oplossingen te implementeren. Onderzochte oplossingen

5.7 Oplossingen

84

• Een eerste oplossing is het verhogen van de beschikbare bandbreedte. Dit kan bijvoorbeeld door betere modulatietechnieken te gebruiken, een grotere uploadbandbreedte te gebruiken ((Euro-)DOCSIS v2.0) of meerdere kanalen aan te bieden aan één subscriber ((Euro-)DOCSIS v3.0). • Zoals aangetoond in simulatie 2 heeft het gebruik van concatenation, fragmentation en piggybacking een positieve invloed op de performantie van het systeem. • Verschillende (Euro-)DOCSIS parameters (zoals de foutcorrectie, het aantal minislots, enz.) hebben een grote invloed op de performantie van het systeem. Het vinden van de optimale waarden is belangrijk om een hoogperformant systeem te bekomen. • De ingebouwde (Euro-)DOCSIS granting mogelijkheden leveren degelijke QoS-garanties voor tijdskritische toepassingen. • Wanneer verondersteld wordt dat het verbruik niet gradueel mee zal stijgen, kan het verhogen van de maximale uploadsnelheid voordelig zijn om hoge bezettingspieken af te zwakken.

VERDER ONDERZOEK

85

Hoofdstuk 6 Verder onderzoek In deze thesis werden verschillende aspecten van p2p-verkeer en (Euro-)DOCSIS-netwerken onderzocht. Het is interessant deze onderwerpen verder uit te diepen. In dit deel worden een aantal mogelijke onderzoeksrichtingen voorgesteld, die dieper ingaan op de in deze thesis behandelde aspecten. Peer-to-peer onderzoek Enkele mogelijke onderzoeken in verband met p2p-netwerken worden voorgesteld. Vanwege de complexiteit van deze netwerken is deze lijst noodzakelijkerwijs onvolledig. Vele andere aspecten dan degene die aangehaald worden zijn interessant om te onderzoeken. • Verificatie van de modellen De correctheid van de modellen kan op verschillende manieren worden gecontroleerd. Het gemiddelde verbruik geeft reeds een aanduiding. Ook kan de kans dat een bepaalde uploadhoeveelheid wordt verstuurd in één minuut, afgeleid uit de simulaties, vergeleken worden met dezelfde kans, afgeleid uit meetgegevens. Tenslotte kan worden nagegaan of de verstuurde hoeveelheid data overeenkomt met theoretische modellen in de literatuur. • Uitgebreide dataverwerking Op basis van meer en gedetailleerdere meetgegevens kan een uitgebreider onderzoek gevoerd worden naar andere aspecten van p2p-verkeer. Zo kan nagegaan worden

VERDER ONDERZOEK

86

of gebruikers van bepaalde abonnementen een voorkeur vertonen voor specifieke p2p-netwerken. Er kan nagegaan worden hoeveel data gemiddeld verzonden wordt per connectie, waarbij een onderscheid kan worden gemaakt tussen de verschillende protocollen en abonnementen. Het is mogelijk een verband te zoeken tussen de uploadhoeveelheid en de downloadhoeveelheid. Er kan onderzocht worden of gebruikers verbonden zijn met meerdere p2p-netwerken, en welke p2p-protocollen dikwijls gecombineerd worden. • Lange termijn studies Het is interessant om te onderzoeken hoe de verschillenden abonnementen evolueren wat betreft connectieduur, uploadhoeveelheid, downloadhoeveelheid, populariteit van de p2p-protocollen, enzovoorts. Er kan een onderscheid gemaakt worden tussen de verschillende dagen van de week, en tussen vakantie- en werkdagen. • Sociologisch onderzoek De kabeloperator kan beslissen de maximale uploadsnelheid van een abonnement te verhogen. Het is interessant na te gaan of dit een invloed zou hebben op het toekomstig uploadgedrag van de gebruikers. Zo is het mogelijk dat een hogere uploadsnelheid de klanten aanzet tot het uploaden van meer data. Alternatieve oplossingen In deel 4.6 werden verschillende oplossingen voorgesteld die de invloed van p2p-verkeer kunnen beperken. Het is interessant een aantal van deze mogelijkheden verder te onderzoeken. Vooral rate limiting en peer-caches lijken veelbelovend. (Euro-)DOCSIS onderzoek Uit de simulaties blijkt dat de verschillende (Euro-)DOCSIS parameters een grote invloed hebben op de performantie van een HFC-netwerk. Het onderzoeken van de precieze invloed van parameters (zoals grootte van het minislot, instellingen van het backoff-window, de grootte van de FEC, PHS-instellingen, het aantal contention slots) is noodzakelijk om een optimaal netwerk te bekomen. (Euro-)DOCSIS v3.0 is momenteel in ontwikkeling en ondersteunt het gebruik van meerdere

VERDER ONDERZOEK

87

up- en downstream kanalen voor één gebruiker. Hieromtrent is heel wat onderzoek mogelijk. OPNET Hoewel OPNET heel geavanceerd is, bevat OPNET een aantal bugs en tekortkomingen (zie deel 5.2.2). Het verbeteren van de (Euro-)DOCSIS modellen is nuttig, om meer gedetailleerde simulaties te kunnen uitvoeren. De meest nuttige verbeteringen zijn de implementatie van nrtPS en het bieden van de mogelijkheid tot een maximale uploadsnelheid per CM. Verder kan een gedetailleerde OPNET studie meer duidelijkheid brengen over de ge¨ımplementeerde schedulingalgoritmes in OPNET.

BESLUITEN

88

Hoofdstuk 7 Besluiten In deze thesis werd onderzocht welke invloed p2p-verkeer heeft op de performantie binnen het Hybrid Fibre/Coax netwerk. Aangezien het HFC-netwerk vooral beperkt is wat betreft upstreambandbreedte, werd enkel het upstreamverkeer bestudeerd. In eerste instantie werden distributies afgeleid voor het uploadverbruik, het aantal gebruikers en de connectieduur. Vervolgens werden modellen opgesteld om het p2p-verkeer te simuleren. Deze moesten eenvoudig zijn om complexe netwerken binnen een redelijke tijd te kunnen simuleren. Tenslotte werden een aantal oplossingen onderzocht om de invloed van p2p-verkeer tegen te gaan. Dataverwerking De Weibull distributie blijkt de p2p-upload hoeveelheid beter te modelleren dan de lognormale distributie, die in verscheidene artikels gebruikt wordt. Uit de dataverwerking blijkt dat het belangrijk is een onderscheid te maken tussen de verschillende abonnementstypes. Dit wordt bevestigd door de simulaties, waaruit blijkt dat de invloed van extra p2p-gebruikers sterk afhangt van het type abonnement. Hoewel elk abonnementstype zware gebruikers bevat, kunnen sommige abonnementen ook als ‘zwaardere’ abonnementen beschouwd worden. Deze zware abonnementen omvatten een kleiner aantal klanten, maar een groter aandeel p2p-gebruikers, die ook meer p2p-verkeer versturen. Bij het afleiden van de gemiddelde connectieduur wordt een onderscheid gemaakt tussen

BESLUITEN

89

verschillende p2p-netwerken en verschillende abonnementen. Uit de analyse blijkt dat gebruikers bij sommige protocollen, zoals Bittorrent of e-donkey, typisch langer verbonden zijn met het netwerk dan bij andere protocollen, zoals Gnutella of Kazaa. Ook de zwaardere abonnementen hebben gemiddeld een langere connectieduur. Tenslotte blijkt dat een connectieduur gekenmerkt wordt door een groot aandeel (30 %) korte verbindingen. Modellen Er werden twee realistische netwerkmodellen opgesteld: één gedurende ‘dalperiode’ en één gedurende ‘piekperiode’. Uit het model blijkt dat de gemiddelde bezettingsgraad gedurende de dalperiode 25% bedraagt van de gemiddelde bezettingsgraad gedurende piekperiode. de bezettingspieken kunnen bij beide tot drie maal hoger liggen. Zelfs tijdens piekuren leiden de bezettingspieken niet tot saturatie, indien we de totale beschikbare capaciteit op het upstream kanaal op 5.12 Mbps instellen. Ook werd onderzocht wat de invloed is van extra p2p-gebruikers. Daarbij blijkt dat gebruikers van de zware abonnementen een veel grotere belasting veroorzaken dan gebruikers van de tragere abonnementen. Onderzochte oplossingen De invloed van verschillende (Euro-)DOCSIS parameters op de performantie van het HFCnetwerk werd onderzocht. Er werd aangetoond dat het gebruik van concatenation en fragmentation de performantie van het netwerk vergroot en het gebruik van piggybacking voordelig is voor bursty verkeer. Bij het onderzoek van de verschillende best effort prioriteitsklassen werd aangetoond dat hun nut beperkt is. De verschillende granting mogelijkheden (UGS en rtPS) bieden wel goede QoS-diensten aan en blijken zelfs bij lage belasting een duidelijke invloed te hebben op de delay. De ingebouwde QoS voorzieningen laten tijdskritische toepassingen mogelijk, zelfs bij een hoge bezettingsgraad van het netwerk. Wanneer verondersteld wordt dat het verbruik niet gradueel mee zal stijgen, kan het verhogen van de maximale uploadsnelheid voordelig zijn om hoge bezettingspieken af te zwakken.

OVERZICHT VAN DE DOOR DE NETWERKANALYSER ONDERSCHEIDBARE PROTOCOLLEN

Bijlage A Overzicht van de door de netwerkanalyser onderscheidbare protocollen

90

OVERZICHT VAN DE DOOR DE NETWERKANALYSER ONDERSCHEIDBARE PROTOCOLLEN

Identificatie

Protocol

Beschrijving

1

FTP

File Transfer Protocol

2

Browsing

Web Browsing

3

Streaming

Video and Audiostreaming

4

Mail

Email

5

Generic TCP

Other TCP toepassingen

6

Generic UDP

Other UDP toepassingen

7

Generic IP

Other IP toepassingen

8

News

Newsgroups

9

P2P

Msn

10

Vonage

VoIP

11

Kazaa

Populaire p2p toepassing

12

Skype

VoIP

13

Gnutella


14

WinMX


15

Winny


16

Direct Connect


17

Manolito


18

Bittorrent


19

Hotline

VoIP

20

E-Donkey


21

Gaming

Gaming

22

Soulseek


23

SIP

Session Initiation Protocol

24

PC-TV

TV op PC

25

Game zone

Gaming via server

26-31

Niet belangrijk

Niet belangrijk

Tabel A.1: Overzicht van de door de netwerkanalyser onderscheidbare protocollen

91

INSTELLINGEN BIJ DE VERSCHILLENDE SIMULATIES

92

Bijlage B Instellingen bij de verschillende simulaties Bij de simulaties wordt zo veel mogelijk gebruik gemaakt van de standaardinstellingen. Eerst worden een aantal profielen gedefinieerd. Daarna wordt vermeld welke profielen gebruikt werden in de simulaties.

B.1

Profielen

MAP profielen: • 128 kbps upload profiel: Time covered by map Time covered by map: Constant Map interarrival time: 0,015 sec Grant interval: as requested by CM Request/Data IE Data backoff Start: 0 Data Backoff End: 4 Number of contention slots: 32 Short Grant IE

B.1 Profielen

93

Short Grant Limit (bytes): 128 Long Grant IE Maximum Payload Size (bytes): 10000 Initial Maintenance IE Initial Maintenance Area (slots/sec): 4 Station Maintenance IE Station Maintenace (slots/sec): 2

• 192 kbps upload profiel: Identiek aan 128 kbps profiel, met MAP interarrival time 0,01 sec

• 512 kbps upload profiel: Identiek aan 128 kbps profiel, met MAP interarrival time: 0,00375

• Speciaal map profiel: Dit profiel werd aangemaakt om eenvoudiger de load te kunnen verhogen. De instellingen komen overeen met [20], waardoor de resultaten eenvoudig vergeleken kunnen worden. Time covered by map Time covered by map: Constant Map interarrival time: 0,02 sec Grant interval: as requested by CM Request/Data IE Data backoff Start: 7 Data Backoff End: 16 Number of contention slots: 32 Short Grant IE Short Grant Limit (bytes): 128 Long Grant IE

B.1 Profielen

94

Maximum Payload Size (bytes): 10000 Initial Maintenance IE Initial Maintenance Area (slots/sec): 4 Station Maintenance IE Station Maintenace (slots/sec): 2

Physical media Overhead Request Frames Overhead: Preamble length: 56 bits FEC Error Correction: 0 bytes FEC codeword Length: 6 bytes Guard time: 32 bits Short Data Frames Overhead: Preamble length: 48 bits FEC Error Correction: 10 bytes FEC codeword Length: 75 bytes Guard time: 40 bits Long Data Frames Overhead: Preamble length: 56 bits FEC Error Correction: 16 bytes FEC codeword Length: 226 bytes Guard time: 40 bits Upstream Physical QPSK (640kbps) Modulation: QPSK Channel width: 800kHz Center Frequency: 8MHz Bytes per minislot: 4 Minimum Fragment Size: 64 bytes

B.2 Gebruikte profielen bij de simulaties

95

16 QAM (5,12Mbps) Modulation: QPSK Channel width: 800kHz Center Frequency: 15MHz Bytes per minislot: 32 Minimum Fragment Size: 64 bytes

B.2

Gebruikte profielen bij de simulaties

Simulatie 1: overhead • Physical media Parameters Upstream channel MAP profile: 192 kbps MAP Upstream physical Profile: 16 QAM (5,12Mbps) Modulatie profiel: default Associated Downstream: default Downstream channel 64QAM • Management Message intervals End of ranging: 1 sec SYNC Interarrival Time: 0,01 sec

Simulatie 2: Concatenation, piggybacking en fragmentation Er wordt gekozen voor een klein uploadkanaal. Zoniet, wordt bij hoge loads de simulatietijd erg groot. • Physical media Parameters Upstream channel


96

MAP profile: Speciaal map profiel Upstream physical Profile: QPSK (640kbps) Modulatie profiel: default Associated Downstream: default Downstream channel 64QAM • Management Message intervals End of ranging: 1 sec SYNC Interarrival Time: 0,01 sec

Simulatie 3: Prioriteiten Er wordt gekozen voor een klein uploadkanaal. Zoniet, wordt bij hoge loads de simulatietijd erg groot. • Physical media Parameters Upstream channel MAP profile: Speciaal map profiel Upstream physical Profile: QPSK (640kbps) Modulatie profiel: default Associated Downstream: default Downstream channel 64QAM • Management Message intervals End of ranging: 1 sec SYNC Interarrival Time: 0,01 sec

Simulatie 4: QoS


• Physical media Parameters Upstream channel MAP profile: 192 kbps upload Upstream physical Profile: 16 QAM (5,12Mbps) Modulatie profiel: default Associated Downstream: default Downstream channel 64QAM • Management Message intervals End of ranging: 1 sec SYNC Interarrival Time: 0,01 sec

Simulatie 5: Volledig model • Physical media Parameters Upstream channel MAP profile: 192 kbps upload Upstream physical Profile: 16 QAM (5,12Mbps) Modulatie profiel: default Associated Downstream: default Downstream channel 64QAM • Management Message intervals End of ranging: 1 sec SYNC Interarrival Time: 0,01 sec

Simulatie 6: Invloed van uploadsnelheid Analoog aan simulatie 5, met telkens andere MAP intervallen.

97


Simulatie 7: Invloed van p2p-verkeer Analoog aan simulatie 5, met het 192 kbps upload profiel.

Simulatie 8: Extra p2p-verkeer Analoog aan simulatie 5, met het 192 kbps upload profiel.

98

BIBLIOGRAFIE

99

Bibliografie [1] Jian Liang, Rakesh Kumar, and Keith W. Ross. The kazaa overlay: A measurement study. Proceedings of the 19th IEEE Annual Computer Communications Workshop, 2004. [2] Andrew Parker.

Cachelogic - advanced solutions for peer-to-peer networks.

www.cachelogic.com. [3] N. Leibowitz, M. Ripeanu, and A. Wierzbicki. Deconstructing the kazaa network. 3rd IEEE Workshop on Internet Applications (WIAPP’03). Santa Clara, CA, 2003. [4] Subhabrata Sen and Jia Wang. Analyzing peer-to-peer traffic across large networks. Second Annual ACM Internet Measurement Workshop, November 2002. [5] M. Izal, G. Urvoy-Keller, E. Biersack, P. Felber, A. Hamra, and L. Garces-Erice. Dissecting bittorrent: Five months in a torrent’s lifetime. Proceedings of the 5th Passive and Active Measurement Workshop, April 2004. [6] Louis Plissoneau, Jean-Laurent Costeux, and Patrick Brown. Analysis of peer-topeer traffic on ADSL. In C. Dovrolis, editor, PAM, volume 3431 of LNCS, pages 6982. Springer, 2005. [7] Electronic Frontier Foundation. http://www.eff.org. [8] Napster. http://www.napster.com.

RIAA v. the people:

Two years later.

BIBLIOGRAFIE

100

[9] Pablo Rodriguez, See-Mong Tan, and Christos Gkantsidis. On the feasibility of commercial, legal p2p content distribution. ACM SIGCOMM Computer Communication Review, 36(3):75–78, January 2006. [10] Groove. http://www.groove.net. [11] Stephanos Androutsellis-Theotokis and Diomidis Spinellis. to-peer content distribution technologies.

A survey of peer-

acmcs, 36(4):335–371, dec 2004.

http://www.spinellis.gr/pubs/jrnl/2004-ACMCS-p2p/html/AS04.html. [12] Peter Backx, Tim Wauters, Bart Dhoedt, and Piet Demeester. A comparison of peer-to-peer architectures. Eurescom Summit, Heidelberg, Germany, 2002. [13] J.A Pouwelse, P. Garbacki, D.H.J. Epema, and H.J Sips. The bittorrent p2p filesharing system: Measurements and analysis. 4th International Workshop on Peerto-Peer Systems (IPTPS’05), Februari 2005. [14] Thomas Karagiannis, Andre Broido, Nevil Brownlee, kc claffy, and Michalis Faloutsos. Is p2p dying or just hiding? Proceedings of the GLOBECOM 2004 Conference, IEEE Computer Society Press, Dallas, Texas, November 2004. [15] Vern Paxson and Sally Floyd. Wide area traffic: the failure of Poisson modeling. IEEE/ACM Transactions on Networking, 3(3):226–244, 1995. [16] Engineering statistics handbook. http://www.itl.nist.gov/div898/handbook/eda/eda.htm. [17] OPNET - Optimized Network Engineering Tools. http://www.opnet.com/. [18] Jay Strater and Steve Nikola.

Engineering CMTS and HFC for VoIP with

Capital and Operating Expenses in Mind.

Motorola - White Paper, 2004.

http://broadband.motorola.com/ips/pdf/MTA-VoIP.pdf. [19] John J. Downey. Understanding VoIP packet sizing and traffic engineering. Society of Cable Telecommunications Engineers Cable-Tec Expo, 2005. [20] Gayathri Chandrasekaran, Mohammed Hawa, and David W. Petr. Preliminary performance evaluation of QoS in DOCSIS 1.1. Januari 2003.

BIBLIOGRAFIE

101

[21] Mario T. Schlosser, Tyson E. Condie, and Sepandar D. Kamvar. Simulating a filesharing p2p network. First Workshop on Semantics in P2P and Grid Computing, December 2002. [22] M. Ripeanu and I. Foster. Mapping the gnutella network: Macroscopic properties of large-scale peer-to-peer systems. Proceedings of the 1st International Workshop on Peer-to-Peer Systems, March 2002. [23] J. Lambert, Benny Van Houdt, and Chris Blondia. Dimensioning the contention channel of DOCSIS cable modem networks. In NETWORKING, pages 342–357, 2005. [24] K. Gummadi, R. Dunn, S. Saroiu, S. Gribble, H. Levy, and J. Zahorjan. Measurement, modeling, and analysis of a peer-to-peer file-sharing workload. Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP-19), October 2003. [25] Luc Martens. HFC toegangsnetwerken: case study. Lecture notes, 2004–2005. [26] DOCSIS specifications. http://www.cablemodem.com/. [27] Distribution fitting. http://www.statsoft.com/textbook/stdisfit.html.

Modelleren en analyseren van peer-to-peer verkeer in een HFC-netwerk

Recommend Documents