Universiteit Gent Faculteit Toegepaste Wetenschappen. Vakgroep Informatietechnologie (INTEC) Voorzitter : Prof. Dr. Ir. P. Lagasse

Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie (INTEC) Voorzitter : Prof. Dr. Ir. P. Lagasse

“Dimensionering van ATM/IP netwerken op basis van trafiekgegevens” door Adelbert Groebbens

Promotor: Prof. Dr. Ir. P. Demeester Co-promotor: Prof. Dr. Ir. M. Pickavet Thesisbegeleiders: Ir. F. De Turck en Ir. M. Gryseels

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

Academiejaar 1999-2000

Voorwoord De auteur houdt eraan op deze plaats zijn dank te betuigen aan zijn promotor, Prof. Dr. Ir. P. Demeester, aan zijn co-promotor Prof. Dr. Ir. M. Pickavet en aan zijn thesisbegeleiders, Ir. F. De Turck en Ir. M. Gryseels voor de verstrekte hulp en leiding. We verontschuldigen ons voor eventuele spellingsfouten, tijpfouten en typografische fouten, het tijdsbestek liet ons niet toe deze voldoende weg te werken. Qua benamingen en termen is er zowal gekozen voor het Nederlands als het Engels : door elkaar gebruikt ! Dit levert het voordeel dat (meestal) zowel de Engelse als de Nederlandse term aan bod komt en bovendien dat er bovendien niet moet gelet worden op consistentie. Wat betreft de notaties, hebben we de meeste termen wanneer ze voor het eerst verschijnen en concepten die aandacht vragen in cursief gezet of tussen “aanhalingstekens” geplaatst. Afkortingen worden in de volgende stijl genoteerd : mbt, tem, ivm, etc,...

Toelating tot bruikleen "De auteur geeft de toelating deze SCRIP TIE 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."

Overzicht “Dimensionering van ATM/IP netwerken op basis van door Adelbert Groebbens SCRIPTIE ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 1999-2000 Promotor: Prof. Dr. Ir. P. Demeester Co-promotor: Prof. Dr. Ir. M. Pickavet Thesisbegeleiders: Ir. F. De Turck en Ir. M. Gryseels Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie (INTEC) Voorzitter : Prof. Dr. Ir. P. Lagasse

Samenvatting : Concreet gaat deze scriptie over : “Planning van capaciteitsexpansie van een internet access provider met behulp van trafiekmetingen en voorspellingstechnieken.” We houden ons bezig met planning (dimensionering), meerbepaald met capaciteitsexpansie (=uitbreiden van de resources van het netwerk). Bovendien hebben we ons geconcentreerd op internet access netwerken. Het was de bedoeling deze dimensionering te doen aan de hand van trafiekmetingen. Vermits planning steeds een vorm van anticiperen op de toekomst is, bestuderen en gebruiken we ook voorspellingstechnieken. Het uitgangspunt van deze thesis was immers dat de planning van internet (access) netwerken totaal iets anders is dan deze van telefonienetwerken. De demand (of maw het internetverkeer) is onzeker, grillig en zelfs chaotisch. Dit maak de planning zeker niet eenvoudig. Er is een studie gedaan van internet access netwerken, een studie gedaan van zaken ivm capacity planning, een studie gedaan over forecasting technieken. Met behulp van ANALOG en MATLAB werden access logs verwerkt. Er werd een eenvoudige trafiekgenerator gebouwd en een eenvoudige beslisser voor capaciteitsexpansie geïmplementeerd. De figuren, berekeningen en implementatie van de algoritmen en technieken werden gedaan met MATLAB 5.3.1.29215a (R11.1). Als besluit kunnen we stellen dat capacity planning een complex domein is, we hebben slechts de basis gelegd voor verder onderzoek. “Real-world” conclusies zijn er weinig of niet, dit is te wijten aan het feit dat echte trafiekmetingen niet vlot en/of openbaar beschikbaar waren, aan het feit dat er geen beschrijvingen van access netwerken van commerciële providers voorhanden waren, aan het feit dat de (vrijwel vereiste) ervaring “in the field” niet mogelijk was, aan het feit dat we in een breed toepassingsgebied zitten mede door het aansnijden van statistische methodes en tenslotte aan het feit dat de resultaten sterk afhangen af van de juistheid van de parameters in de modellen, een praktisch bruikbare toepassing vereist dus voldoende en correcte kennis en modellering van de effecten die zich in de realiteit in internet access netwerken kunnen afspelen.

Trefwoorden : capacity planning, forecasting, ADSL, dial-up, internet access, access logs

Inhoud 1

2

3

4

5

Inleiding, probleemstelling en overzicht......................................................................................................1 1.1 Algemeen overzicht ................................................................................................................................1 1.2 Inleiding en probleemstelling : access netwerken, Dial-up en ADSL ...........................................1 Capacity planning ............................................................................................................................................4 2.1 Betekenis en belang van capacity planning :......................................................................................4 2.2 Definitie van adequate capaciteit..........................................................................................................4 2.3 “A capacity planning methodology”....................................................................................................4 2.3.1 “understanding the environment”................................................................................................4 2.3.2 “workload characterization, workload model validation ...........................4 2.3.3 “workload forecasting” .................................................................................................................5 2.3.4 “perfomance model development, validation, calibration and prediction”..........................5 2.3.5 “cost model development, cost prediction”...............................................................................5 2.3.6 “cost versus performance analysis”............................................................................................6 Internet accesnetwerken..................................................................................................................................7 3.1 Typisch Dial-up Access netwerk..........................................................................................................7 3.1.1 Structuur van een POP (en het netwerk er rond)......................................................................7 3.1.2 Uitleg bij Dial-up access...............................................................................................................7 3.2 Tussendoor : informatie ivm planningsaspecten................................................................................9 3.3 Typisch ADSL Access netwerk..........................................................................................................12 3.3.1 Structuur van een POP (en het netwerk er rond)....................................................................12 3.3.2 Uitleg bij ADSL access...............................................................................................................13 3.3.3 Verder informatie ivm planning en vergelijking van Dial-up en ADSL ............................14 3.4 Configuraties..........................................................................................................................................14 3.4.1 Zestal verschillende Dial access architecturen op een rijtje .................................................14 3.4.2 Meer details over locale architecturen in de POP zelf ...........................................................18 3.4.3 Viertal verschillende ADSL access architecturen op een rijtje ............................................19 3.4.4 Besluit over de architecturen......................................................................................................21 3.5 Apparatuur..............................................................................................................................................22 3.5.1 Terminologie en algemene informatie ......................................................................................22 3.5.2 Dial equipment .............................................................................................................................23 3.5.3 ADSL equipment..........................................................................................................................26 Trafiek en trafiekgenerator(en)....................................................................................................................29 4.1 Netwerktrafiek.......................................................................................................................................29 4.2 Trafiekmetingen bekomen...................................................................................................................30 4.3 Access logs.............................................................................................................................................30 4.3.1 Wat zijn access logs ?..................................................................................................................31 4.3.2 Waarvoor kunnen access logs gebruikt worden ?...................................................................31 4.3.3 Generatie van grafieken : logfile analyzer...............................................................................32 4.4 Voorbeelden access logs......................................................................................................................34 4.4.1 Atlantis WWW server.................................................................................................................35 4.4.2 ClarkNet WWW server...............................................................................................................39 4.4.3 Nasa WWW server ......................................................................................................................43 4.4.4 Speciaal : Atlantis firewall .........................................................................................................46 4.4.5 WWW server van de University of Calgary (CS Department)............................................51 4.4.6 WWW server van de University of Saskatchewan.................................................................52 4.5 Implementatie van de trafiekgenerator..............................................................................................53 4.5.1 Elementen in onze trafiek generator.........................................................................................53 4.5.2 Voorbeeld, statistieken en vergelijking met access logs.......................................................54 Forecasting technieken..................................................................................................................................57 5.1 Achtergrond informatie ........................................................................................................................57 5.1.1 Basisconcepten.............................................................................................................................57 5.1.2 Stappen en strategieën bij forecasting ......................................................................................58 5.2 Technieken en modellen ......................................................................................................................59 5.2.1 “stationary forecasting models”.................................................................................................59 5.2.2 “forecasting time series that exhibit ..................................................................61 5.2.3 “time series with trend, seasonal and cyclical variation : multiplicatief model” ..............62 5.2.4 “time series with trend, seasonal and cyclical variation : additief model” .........................65 5.2.5 Andere voorspellingstechnieken en verdere informatie ........................................................65

5.2.6 Time series forecasting in een breder kader geplaatst...........................................................65 5.3 Performantie-evaluatie methoden.......................................................................................................66 5.3.1 Evaluatie van de performantie van forecasting technieken : ................................................66 5.3.2 Optimalisatie van de parameters : .............................................................................................67 5.4 Implementatie van de technieken en performantie-evaluatie methoden, toepassing op een voorbeeld..............................................................................................................................................................67 5.4.1 “exponential smoothing” ............................................................................................................68 5.4.2 “moving average”.........................................................................................................................69 5.4.3 “exponential smoothing with linear trend”..............................................................................70 5.4.4 “exponential smoothing with linear trend and seasonal factors (Holt Winter’s multiplicative method)” ................................................................................................................................71 6 Capacity planning : capaciteitsexpansie ....................................................................................................75 6.1 Capaciteitsexpansiemodel....................................................................................................................75 6.1.1 Berekening van overbelasting....................................................................................................75 6.1.2 Gekozen upgrade-regel ...............................................................................................................76 6.1.3 Gekozen kost model ....................................................................................................................77 6.1.4 Files met implementatie ..............................................................................................................78 6.1.5 Mogelijke andere modellen/uitbreidingen...............................................................................79 6.2 Resultaten op de logfiles ......................................................................................................................79 6.2.1 Berekening van “aantal minuten per dag boven een aanvaardbare belasting”..................79 6.2.2 Toepassen van capaciteitsexpansie model...............................................................................85 6.2.3 Bepalen van optimale parameters in model.............................................................................94 6.2.4 Andere logfiles .............................................................................................................................96 6.3 Resultaten op eigen gemaakte trafiek generator..............................................................................96 6.3.1 Berekening van “aantal minuten per dag boven aanvaardbare belas .........................96 6.3.2 Toepassen van capaciteitsexpansie model...............................................................................97 6.3.3 Bepalen van optimale parameters in model...........................................................................106 7 Conclusies, verder werk en uitbreidingen ...............................................................................................109 7.1 Conclusies ............................................................................................................................................109 7.2 Verder werk en uitbreidingen............................................................................................................110 8 Appendix A : andere formules ivm forecasting......................................................................................111 9 Appendix B : extra uitleg bij CD-ROM ...................................................................................................112 10 Appendix C : bandbreedtes/link-types .................................................................................................113 11 Appendix D : details en specificaties van internet access equipment ............................................114 11.1 Cisco AS5x00 Series ..........................................................................................................................114 11.1.1 Cisco AS5800 Universal Access Server................................................................................114 11.1.2 Cis co AS5300 Universal Access Server................................................................................115 11.1.3 Cisco AS5200 Universal Access Server................................................................................116 11.2 Nortel CVX 1800................................................................................................................................116 11.3 Ascend MAX TNT .............................................................................................................................117 11.4 Cisco 36x0 Series ................................................................................................................................119 11.4.1 Cisco 3620 router.......................................................................................................................119 11.4.2 Cisco 3640 router.......................................................................................................................119 11.4.3 Cisco 3660 router.......................................................................................................................119 11.4.4 NETWERK MODULES/WAN INTERFACE CARDS :...................................................119 11.5 Cisco 75xx Series ................................................................................................................................121 11.5.1 Cisco 7513 ...................................................................................................................................122 11.5.2 Cisco 7507 ...................................................................................................................................122 11.5.3 Cisco 7505 ...................................................................................................................................122 11.5.4 Cisco 7576 (àuitbreiding van de 7513)................................................................................122 11.5.5 Opsomming van de “Interface Processors” in deze routers...............................................122 11.5.6 Mogelijke “route switch processors” in deze routers...........................................................123 11.5.7 Verdere componenten in deze routers ....................................................................................123 12 Referenties ................................................................................................................................................124 12.1 Boeken ..................................................................................................................................................124 12.2 Artikelen,documenten en papers ......................................................................................................124 12.3 Tutorials en documentatie..................................................................................................................124 12.4 Online webpages .................................................................................................................................124 12.4.1 Webpage artikelen van Datacomm Magazine (http://www.data.com) .............................124 12.4.2 Telecom-equipment ...................................................................................................................125

1 Inleiding, probleemstelling en overzicht 1.1 Algemeen overzicht De titel van de thesis was oorspronkelijk vrij algemeen gehouden en omvat een nog veel groter domein dan wat er werkelijk in deze thesis behandeld is. De titel had misschien preciezer als volgt kunnen gekozen worden : “Planning van capaciteitsexpansie van een internet access provider met behulp van trafiekmetingen en voorspellingstechnieken.” Dit houdt dus in dat we ons bezig houden met planning (dimensionering), meerbepaald met capaciteitsexpansie (=uitbreiden van de resources van het netwerk). Bovendien hebben we ons geconcentreerd op internet access netwerken. Het was de bedoeling deze dimensionering te doen aan de hand van trafiekmetingen. Vermits planning steeds een vorm van anticiperen op de toekomst is, bestuderen en gebruiken we ook voorspellingstechnieken. Het uitgangspunt van deze thesis was immers dat de planning van internet (access) netwerken totaal iets anders dan deze van telefonienetwerken. De vraag (of maw het internetverkeer) is onzeker, grillig en zelfs chaotisch. Dit maak de planning zeker niet eenvoudig. Wat wordt er behandeld in de volgende hoofdstukken ? De probleemstelling wordt verder geconcretiseerd in 1.2. Nadien gaan we dieper in op het begip capacity planning. Vervolgens geven we informatie over internet access netwerken. Daarna bespreken we onze (noodgedwongen) aanpak ivm trafiek(metingen). Nadien komen de voorspellingstechnieken aan bod. Om uiteindelijk alles toe te passen in ons model voor capaciteitsexpansie. We ronden af met conclusies, verder werk en uitbreidingen. Ook in de appendices staat nog informatie die niet uit het oog verloren mag worden. De figuren, berekeningen en implementatie van de algoritmen en technieken werden gedaan met MATLAB 5.3.1.29215a (R11.1). We vermelden alvast dat er een CD-ROM voorhanden is met de gemaakte implementaties (.m files) (hiervoor is MATLAB vereist) en met bijkomende informatie (zie Appendix B : extra uitleg bij CD-ROM).

1.2 Inleiding en probleemstelling : access netwerken, Dial-up en ADSL Access netwerken zijn de eerste delen van netwerken die de “gewone” gebruikers tegenkomen. Deze gebruikers zijn mensen thuis of zijn werknemers in een remote office. De plaats waar zij zich bevinden wordt meestal met de term suscriber premise aangeduid. Deze netwerken leveren toegang tot services, aangeboden door apparatuur (en/of software) die we servers noemen. Deze services zijn bijvoorbeeld internet services zoals e-mail, webspace,… geleverd door de Internet Service Provider (ISP) maar ook bijvoorbeeld toegang tot het private netwerk van een bedrijf, … waarbij het bedrijf zelf meestal voor een deel van de access infrastructuur zorgt (=corporate LAN). Hieronder volgt een figuur (Figuur 1.1) die een eerste beeld geeft van wat access netwerken zijn. We zien dat de suscriber premise verbonden wordt met een netwerkwolkje dat een soort concentratorfunctie uitoefent. Deze verbinding gaat meestal via een publiek netwerk zoals het PSTN of het ISDN netwerk (tegenwoordig zijn deze samengesmolten). Van de concentrator gaan we via een reeks data netwerken (routers, layer 2 netwerken zoals ATM, …) naar de ISP of naar de corporate LAN. De details van het concentratorwolkje en de mogelijkheden binnen het edge/backbone-wolkje worden later uitgelegd. Welke instantie de verschillende delen (zichtbare en niet zichtbare op de figuur) van dit netwerk uitbaat ligt tegenwoordig niet zo duidelijk meer. We kunnen stellen dat de trend is dat de conctratorfunctie en de verbinding naar de servers door een soort Network Service Provider (NSP) wordt verzorgd. Dit is bvb. een grote ISP van vroeger, een telecom of carrier operator (vb. Belgacom), … De services zelf

© Adelbert Groebbens

1

worden dan eventueel door kleinere ISP’s verzorgd. En de bedrijven kopen van de NSP dan toegang tot hun eigen netwerk af (dit wordt wel eens outsourcing van access genoemd). INTERNET Suscriber Premise : Ÿ PC Ÿ small LAN Ÿ ... Concentrator : Ÿ Dial Gateway Ÿ ISDN Gateway Ÿ ADSL rack Ÿ ...

Internet Service Provider (ISP)

SERVERS

Ÿ Ÿ Ÿ

edge, backbone

SERVER

Suscriber Premise : Ÿ PC Ÿ small LAN Ÿ ...

Ÿ Ÿ Ÿ Concentrator : Ÿ Dial Gateway Ÿ ISDN Gateway Ÿ ADSL rack Ÿ ...

Corporate LAN

Ÿ Ÿ Ÿ

Suscriber Premise : Ÿ PC Ÿ small LAN Ÿ ...

INTERNET

Figuur 1.1 : access netwerk Wanneer we in het standpunt van zo’n operator die access levert gaan staan, dan zien we dat hij verschillende soorten apparatuur installeert. Deze hebben elk een eindige capaciteit hebben (bvb. maximaal aantal gebruikers, maximale throughput van bandbreedte, maximale CPU snelheid of geheugenruimte). Het komt er voor hem dus op aan de gepaste apparatuur op het gepaste tijdstip (en zelfs op de gepaste plaats) te installeren. Hij kan bijvoorbeeld uitbreiden met nieuwe apparatuur (bvb. interfacekaarten van een router) omdat de capaciteit ervan overbelast is. Hij kan bijvoorbeeld oudere en minder performante apparatuur vervangen door nieuwe. Dit vereist een zekere planning. De operator moet er in ieder geval voor zorgen dat zijn klanten (gebruikers) service krijgen voor hun geld (de soort service dat ze krijgen staat bijvoorbeeld beschreven in Service Level Agreements (SLA’s)). Wanneer we de gebruikersgroep (subscribers) bekijken, dan zien we dat de karakteristieken van door hun gegenereerd datatrafiek (PC met 56k modem of zelfs al een ADSL connectie (1 Mbit/s nu in praktijk)) zodanig is dat de traditionele (voice) capacity planning die gebruikelijk zijn bij telefonieoperatoren niet meer gelden. (Traditioneel werd bvb. verondersteld dat gebruikers enkele keren per dag bellen voor een korte periode.) De klanten benutten immers steeds meer de beschikbare bandbreedte ten volle en dit voor langere tijden. Bovendien is het “datagedrag” van deze gebruikers nogal chaotisch : welke websites ze bezoeken is onvoorspelbaar, de hoeveelheid informatie die ze downloaden per tijdseenheid is bursty (bvb. lange tijd e-mails lezen betekent weinig transfer, een mp3 bestand downloaden vergt dan weer veel meer capaciteit gedurende een korte periode). Ook is het voor operatoren die verschillende ISP’s bedienen (wholesalers van access, modem wholesaling) niet eenvoudig om te dimensioneren op de grootte van de connecties die zij met de verschillende ISP’s voorzien : op elk tijdstip hebben ze immers een niet te voorspellen mengeling van

opmerking : wholesale : meerdere ISP’s en bedrijven kopen een deel van de “wholesale” access server (deze wordt uitgebaat door een network service provider) © Adelbert Groebbens

2

Het gevolg is dat de capacity planning van internet access netwerken niet zo eenvoudig is en het misschien interessant is om op basis van trafiekmetingen (en stochastische technieken) eens te gaan kijken welke nuttige planningsmethoden er kunnen toegepast worden. Trafiek of “workload” metingen zijn hierbij metingen van de belasting van de verschillende resources : zoals de hoeveelheid bandbreedte op één van links die de verschillende netwerkelementen verbinden, zoals het aantal hits op een webpagina van een webserver, zoals het aantal pakketten dat door een router of een switch moet passeren, … Er kunnen immens veel metingen zijn zodat er nood is aan datareductie en stochastische technieken. Bovendien vergt capacity planning steeds dat we vooruitkijken op de toekomst. Zodat het de bedoeling is uit de metingen (die bvb. op regelmatige tijdstippen gebeuren) voorspellingen te maken. Hierop zit er steeds een zekere fout en kunnen statistische technieken nuttig zijn om deze in te schatten.


3

2 Capacity planning Het domein van deze thesis is dus capacity planning (als een onderdeel van dimensionering). We geven wat commentaar rond het begrip capacity planning. Deze is gebaseerd op het boek [1].

2.1 Betekenis en belang van capacity planning : Capacity planning heeft tot doel de aanwezige capaciteit (resources, dwz apparatuur,...) zo goed mogelijk te gebruiken of nieuwe capaciteit optimaal aan te schaffen. Het essentieel nuttig element van capacity planning is voorspellen (forecasting, prediction, planning ahead !). De redenen hiervoor zijn : • bvb. omdat capaciteitsproblemen niet onmiddellijk opgelost kunnen worden wegens tijd nodig voor bvb. de installatie of aanschaf van apparatuur • bvb. om te kijken wat de voor- en nadelen zijn van alternatieven vooraleer er één in werkelijkheid uit te proberen • ...

2.2 Definitie van adequate capaciteit Wanneer is de capaciteit nu voldoende of optimaal gebruikt ? We nemen daarvoor volgende formulering (uit [1]) : een systeem heeft “ADEQUATE CAPACITY” indien de “service level agreements” tussen user en managers steeds voldaan zijn, eventueel met bepaalde gespecifieerde (om bvb. andere redenen dan performantie en dus niet te kiezen) technologie (vb. Win NT) en standaarden (vb. TCP/IP), en dit allemaal onder gegeven kost beperkingen (vb. startup cost, operating cost, amortization cost (=afschrijvingen)) Hierbij zijn “service level agreements” (SLA’s) overeenkomsten tussen de gebruiker en de aanbieder van de dienst (service) : bvb. Turboline ADSL levert verschillende internet access diensten, elk met verschillen qua minimum gegarandeerde bandbreedte, download limiet per maand, ...

2.3 “A capacity planning methodology” We sommen de verschillende stappen op die een mogelijke methode voor capacity planning vormen :

2.3.1

“understanding the environment”

We citeren : “The initial phase of methodology consists of learning what kind of hardware, software, network connectivity and protocols, are present in the environment. It also involves the identification of peak usage periods, management structures, and service-level agreements.” Opmerking : management structures = aankoopproces, uitgave limieten, … We zullen ons in hoofdstuk 3 richten op internet access netwerken als een van de vele concrete toepassingdomeinen van capacity planning.

2.3.2 “workload characterization, workload model validation and calibration” Een systeem staat onder een zekere belasting : vb. er zijn per seconde zoveel gebruikers van een webserver van een bedrijf, vb. er worden per seconde zoveel modems bezet in een modemgateway van een internet access provider. Daarentegen heeft een systeem een zekere performantie : vb. de gebruikers moeten een bepaalde tijd wachten vooraleer hun HTTP requests door de web server wordt beantwoord, vb. de gebruikers stellen een bepaalde (gemiddelde) effectieve bandbreedte vast op hun modemlijn. De belasting heeft uiteraard invloed op de performantie : hoe meer belast, hoe minder het systeem zal presteren en hoe meer de SLA’s met de gebruikers in het gedrang komen. Het is dus zeker nodig de belasting (workload) te begrijpen, te karakteriseren (met validatie). © Adelbert Groebbens

4

Het is aanbevolen de globale belasting te verdelen in componenten en deze verder weer op te splitsen in subcomponenten. Deze laatste kunnen zijn dan meestal volledig door de workloadintensiteit : de mate waarin er werk van het systeem wordt gevraagd (wanneer, hoe frequent) (= vb. arrival rates) de service demand : het hoeveelheid werk er wordt gevraagd (wat) (= vb. document size, CPU time, ..) Beide voorgaande parameters kunnen gemeten of berekend worden). Voorbeelden van workloadintensiteit : • aantal “transacties” per seconde per user • aantal users Voorbeelden van service demand : • CPU utilization • grootte van “transactie” Deze parameters worden gebruik om een model voor de belasting van het systeem op te stellen : in het algemeen zijn “factors that have a direct influence on the performance” de aangewezen parameters om een workload model op te stellen. Het doel workload model is een compactere, representatieve, reproduceerbare voorstelling geven van de echte workload van een systeem (vgl. benchmark van enkele programma’s ipv miljoenen lopen). Workload model is accuraat ó metingen van de reële performantie bij een gegeven workload gelijk zijn aan de performantiemetingen berekend aan de hand van een performantiemodel (zie later) op basis van het workloadmodel bij diezelfde workload (en dit voor alle workloads).

2.3.3 “workload forecasting” Workload forecasting mag uiteraard niet ontbreken , namelijk we herhalen wat we hierboven gezegd hebben : het essentieel nut van capacity planning is voorspellen en op voorhand plannen. In dit eindwerk wordt hieraan de meeste aandacht besteed.

2.3.4 “perfomance model development, validation, calibration and prediction” We proberen een model (met parameters) voor de performantie van een systeem te bepalen en daaruit het performantieresultaat (=vb. response time, throughput, resource utilization,…) af te leiden : • systeem parameters (vb. mirror, protocol, aantal connecties, aantal threads, …) • resource parameters (vb. seek time, cpu speed, latency, transfer rate, bandwidth,…) • workload parameters : • workloadintensiteit (vb. hits per day, requests per sec, number of clients, …) • service demand (= totale hoeveelheid van service time nodig voor een gegeven basis component in een gegeven resource) Mogelijkheden voor een performance prediction model zijn simulatie modellen and analytische modellen. Bij het opstellen van het model komen we volgende afweging tegen : model met grote correctheid impliceert veel data verzamelen, dit kan soms lastig zijn en niet de moeite lonen en daarom wordt er meestal gesteld dat een correctheid van binnen de 10% à 30% aanvaardbaar is. Uit het performantiemodel kan dan de performantie bepaald worden bij een gegeven workload.

2.3.5 “cost model development, cost prediction” Uiteraard mag een cost model niet ontbreken in capacity planning, het is namelijk een restrictie op de mogelijkheden. Er zijn 2 types van kost : • startup cost (hardware, software, infrastructure, installation) • operating costs (per tijdseenheid) (maintenance, upgrade, personeel, training, telco,…) © Adelbert Groebbens

5

2.3.6 “cost versus performance analysis” Uiteindelijk kan je al de bekomen resultaten combineren en afwegen : cost versus performantie. Hieruit volgt dan de verdere planning (configuratie, investeringen, personeelsbeleid, …)


6

3 Internet accesnetwerken Dit deel heeft als bedoeling inzicht en achtergrondinformatie te geven in internet accessnetwerken : één van de (mogelijke) toepassingsdomein voor “dimensionering op basis van trafiekmetingen” en meerbepaald “dimensionering met gebruik van voorspellingstechnieken”. In het vorige deel werd immers vermeld dat het belangrijk is de we de omgeving begrijpen, meerbepaald de apparatuur, architectuur, configuraties, ...

3.1 Typisch Dial-up Access netwerk Dial-up access betekent dat de gebruikers inbellen via een modem of via een ISDN kaart.

3.1.1

Structuur van een POP (en het netwerk er rond)

We noemen een Point of Presence (POP) de plaats waar de binnenkomende oproepen van de gebruikers getermineerd worden en waar de routering of switching gebeurt naar de achterliggende core data netwerken (het internet). Zie Figuur 3.1.

...

Core data network 2

Core data network 1

SERVER

Core data network N

4 4 1

1

1

SERVER

Access Router

3

3 PSTN Dial Gateway

2

ISDN DIal Gateway

2

PSTN V.x modem

...

V.x modem

ISDN

ISDN modem/ card

...

POP

ISDN modem/ card

Figuur 3.1 : typisch dial access netwerk

3.1.2

Uitleg bij Dial-up access

We bespreken Figuur 3.1. De gebruikers bereiken via een V.x modem of via ISDN modem het telco netwerk (=PSTN of ISDN). De access provider huurt van de telco operator één of meerdere (access) lijnen (zie (2) op de figuur) die aangesloten worden op de interface kaart(en) in de PSTN dial of ISDN gateways, merk op dat op zo één lijn er verschillende calls (oproepen) kunnen gemultiplexeerd (TDM) zijn, (deze laten dus toe om bvb. 30 gebruikers access te geven via slechts 1 access lijn), voorbeeld van zulke interfaces (die meestal WAN interfaces genoemd worden) is bvb. ‘channelized E1/PRI’, dwz. dertig 64 kbit/s calls die elke afzonderlijk demultiplexeerbaar (“channelized”). © Adelbert Groebbens

7

De PSTN dial gateway is een soort modembank die uit de WAN lijnen de afzonderlijke calls filtert, hij biedt niet mogelijkheid om twee calls met elkaar door te verbinden, dit kan pas gebeuren in de access router. We beschrijven kort de weg die deze afzonderlijke calls doorliepen om tot aan de gateway te geraken : • digitale data wordt gemoduleerd via een PC modem bij de gebruiker voor transmissie via de analoge telefoonlijn naar de centrale • in de centrale wordt deze analoge data naar een 64 kbit/s digitale stream omgezet vanaf dan gebeurt de switching en transmissie over het publieke netwerk naar de WAN lijnen van de POP volledig digitaal en via gemultiplexeerde lijnen (vb. E1 trunks) • in de PSTN dial gateway zijn er dan twee mogelijkheden : o vroeger : werd de digitale stream naar analoge signalen omgezet, deze analoge signalen werden dan gedemoduleerd naar digitale data o nu : wordt de omzetting naar analoog overgeslaan en haalt men direct de oorspronkelijke digitale data eruit en spreken we van digitale modems in de gateway (“all digital”) Merk het volgende voordeel van digitale modems op : de technologie zit volledig in software en kan dus geupgrade worden naar nieuwere modem technologieën (vb. door het downloaden van softwarepatches naar de gateway). Voor een “carrier-class” gateway zitten we momenteel in de orde van 300 à 400 modempoorten per shelf. De oorspronkelijke digitale data van de gebruiker bevat meestal IP pakketten geëncapsuleerd in PPP pakketten, deze worden door de concentrator-gateway naar de access router gestuurd (zie (3) op figuur), dit wordt meestal gerealiseerd door een LAN verbinding (Ethernet) maar kan eventueel een (andere) layer 2 technologie (ATM, FR, PPP) zijn (of zelfs een layer 1 technologie) waarover dan (eventueel) Ethernet gestuurd wordt De access router is mogelijks ver verwijderd van de gateway, zodat een WAN verbinding en/of een layer 2 switching network nodig is om de connectie tussen de gateway en de access router te verwezenlijken In de access router wordt de payload van de PPP pakketten (=IP pakketten) afgesplitst en deze IP pakketten kunnen dan verder gerouteerd worden langs heen de achterliggende core data netwerken (dit gebeurt via de links genummerd met (1) op figuur) (merk bovendien op dat 1 lijn op de figuur eventueel staat voor meerdere links) Waarom zijn er meerdere core data netwerken ? Een mogelijke reden is dat de POP kan uitgebaat kan worden door een “modem wholesaler” die access diensten levert aan verschillende ISP’s met elk hun eigen data netwerk, afhankelijk van de gebruiker die inbelt zullen zijn IP pakketten naar de gepaste core data netwerken moeten gerouteerd worden. Een andere mogelijke reden is dat de access provider onderscheid wil gaan maken tussen verschillende types klanten bvb. “premium users” en gewone gebruikers, de “premium users” zullen dan gerouteerd worden naar een “sneller” core data netwerk. Nog een andere mogelijke reden is dat de access provider access levert aan bedrijven die extra security wensen, in dit geval zouden sommige core data netwerken met extra firewalls beschermd kunnen worden, deze core data netwerken zijn dan bvb. enkel toegankelijk voor de werknemers van een bedrijf. De overige gebruikers gaan dan via de goedkopere maar “onveiligere” core data netwerken. Noteer dat er in de dial gateway nagekeken wordt welke identiteit de gebruiker heeft en tot welk netwerk hij toegang moet of mag krijgen, deze gegevens worden bijvoorbeeld bijgehouden in een server (security server). De gateway maakt dus eerst nog een connectie met deze security server (via de access router) om de gegevens van de gebruiker op te halen (vb. ook gegevens ivm met accouting (=billing)) vooraleer hij de gebruiker verder doorgang verleent. Zo belanden we bij (4) op de figuur : de servers zijn afkomstig van de individuele ISP’s of van bedrijven, maar eventueel ook van de access provider (=eigenaar van POP), ze leveren o.a. de volgende functies : • “AAA” (triple A functies) :


8

Accounting : de tijdsduur van een connectie of de hoeveelheid verzonden data tijdens een connectie per gebruiker bijhouden om hem hierop te kunnen factureren o Authenticatie : de identiteit van de gebruiker bepalen en verifiëren o Authorisatie : de toegang tot bepaalde services verbieden afhankelijk de identiteit van de gebruiker (bvb. enkel toegang tot extranet van een bedrijf voor onbekenden, toegang tot mainframe van een bedrijf voor werknemers, …) CACHING : o door bvb. nabij de access router een proxyserver te installeren kan er bespaard worden op de vereiste bandbreedte van de links naar de core data netwerken (zie later bij de bespreking van enkele types van architecturen) o verdere voordelen caching : gebruikers krijgen sneller antwoord, netwerktraffiek wordt beperkt, de belasting van de echte server wordt beperkt, de availability wordt verbeterd wegens verspreid zijn over verschillende caches MIRRORING : o door een webserver te verdubbelen en de belasting over beiden te verdelen (bvb. minst belaste krijgt nieuwe aanvraag te verwerken) kan je de capaciteit van je webservices uitbreiden o concreter : andere hosts bewaren een replicaat van de site en er wordt regelmatig vanuit die hosts geupdate, bovendien vertalen DNS servers de URL naar het IP adres van de minst druk bezette of de dichtst bijzijnde mirror SERVICES : zoals de webserver van de ISP, zoals portaalsites, e-mailservices, … o

•

•

•

3.2 Tussendoor : informatie ivm planningsaspecten Belangrijke doelstellingen voor een uitbater van een POP zijn (ISP of NSP) : • scalability van de POP’s, dwz we moeten eenvoudig (en vlug !) de volledige capaciteit van onze POP bvb. kunnen verdubbelen • consolidating (van equipment of van inkomende WAN lijnen), dwz we proberen zoveel mogelijk bijeen te stoppen zodat we een beter centraal beheer, een compactere opstelling en beter gebruik van de infrastructuur krijgen Een andere belangrijke vraag is : waar plaatsen we onze POP tov het PSTN en/of ISDN network ? en ook : voor hoeveel gebruikers voorzien we capaciteit in onze POP ? In Figuur 3.2 : staat de POP in voor alle gebruikers (nationaal). De POP moet dus qua capaciteit groot zijn en moet ook zeer betrouwbaar zijn. Deze plaatsing heeft als voordeel dat er maar één of enkele locaties met apparatuur te beheren zijn. Het kan toegepast worden indien er nog niet zoveel gebruikers zijn of verwacht worden. Het heeft als nadeel dat voor alle gebruikers het volledige publieke netwerk doorkruist moet worden en dit zelfs ook voor connecties tussen twee gebruikers A en B die naburig zijn (eventueel zou B ook een server kunnen zijn en dan moet er een WAN link van de pop access router naar de server van B geïnstalleerd worden) National Exchange

POP

Regional Exchange

Local Exchange

...

...

...

... A

B

Figuur 3.2 : POP op bovenste niveau telefonienetwerk


9

Bij Figuur 3.3 en Figuur 3.4 : wanneer het gebruikersaantal van de provider stijgt migreren we de POP dichter tot bij de gebruikers, we zullen dan uiteraard meer POP’s moeten voorzien.

National Exchange

Regional Exchange

POP

POP

...

Local Exchange POP

...

...

POP

...

Figuur 3.3 : POP op regionaal niveau in het telefonienetwerk National Exchange

Regional Exchange POP

POP

Local Exchange

...

...

...

...

Figuur 3.4 : POP op lokaal niveau in het telefonienetwerk

Figuur 3.5 geeft aan dat als we de POP’s dichter bij de gebruikers plaatsen er meer flexibiliteit mogelijk is qua dimensionering op het aantal gebruikers.

connectie capaciteit voor 30 gebruikers

POP

connectie capaciteit voor 30 gebruikers

Local Exchange

10 gebruikers willen inbellen

Local Exchange

overloop van 30 gebruikers via interconnectie van Local Exchanges

...

50 gebruikers willen inbellen

...

Figuur 3.5 : flexibiliteit in het geval van POPs op lager niveau in het voice-netwerk


10

Eveneens is het belangrijk te weten wat de capaciteit van het equipment moet zijn : • hoeveel en welke type kaarten (vb. Ethernet of Fast Ethernet voor de verbinding van de gateway met de access router) ? • de huidige mentaliteit is : “select a large chassis and upgrade it with cards as you grow” • hoeveel poorten (vb. Ethernet poorten) nodig in een chassis (=rack) nodig ? • welke bandbreedte en hoeveel links hebben we nodig (zie (1), (2) en (3) op Figuur 3.1) ? • hoeveel vrije slots moeten we in onze stukken equipment voorzien voor latere uitbreiding ? • hoe moet een server gedimensioneerd zijn ? o aantal en snelheid processors o aantal en snelheid en capaciteit van de opslagmedia (disks) o type van het operating system (OS) o de hoeveelheid geheugen o de netwerkbandbreedte naar de server (!) o … De antwoorden hierop hangen ook af van management issues : bvb. “hoeveel modems installeren we als we wensen dat de kans dat een klant niet bediend kan worden (=busy modem pool) < 5% ?”. Deze kans is afhankelijk van : het aantal modems, het aantal gebruikers, de tijd dat een gebruiker geconnecteerd is tijdens een sessie, het aantal sessie per dag bij een gebruiker, … Elementen en onbekende parameters die capacity planning niet triviaal maken zijn : • het aantal actieve gebruikers die inbellen of wensen in te bellen op een bepaald tijdstip • naar welk netwerk de gebruikers bellen (vb. core data network 1 = Belgacom, core data network 2 = Online, ...) en dus welke bandbreedte er op de links naar het core data network verbruikt wordt • bij welke server de gebruikers zoal informatie opvragen en hoe groot de hoeveelheid opgevraagde informatie is (vb. e-mail versus videofilmpje) per tijdseenheid • in welke mate de gebruikers migreren van klassieke V.x modems naar ISDN modems • ...


11

3.3 Typisch ADSL Access netwerk ADSL access betekent dat de gebruikers thuis een ADSL modem hebben en een rechtstreekse verbinding naar de ADSL Access Multiplexer (DSLAM), waar hun lijn getermineerd wordt op een ADSL kaart (hierin zit eveneens een ADSL modem). Zie hiervoor naar Figuur 3.6. Het gewone telefonieverkeer van de gebruiker wordt zowel thuis als in de DSLAM afgesplitst (POTS splitter) en wordt verder getransporteerd via het klassieke telefonienetwerk. Het dataverkeer van de gebruiker wordt (langsheen de ADSL Access Multiplexer) naar de ATM switch getransporteerd in de vorm van ATM cellen. Merk op dat er in de DSLAM dus totaal geen intelligentie zit : het hoofddoel is het concentreren van trafiek naar 1 lijn. Deze lijn gaat dan naar de switch. In de omgekeerde richting is de functie van de DSLAM : het verdelen en uitsorteren van de trafiek die van de switch komt naar de verschillende gebruikers toe.

Figuur 3.6 : een mogelijk ADSL access netwerk

3.3.1

Structuur van een POP (en het netwerk er rond)

De Point of Presence (POP) is hier de plaats waar de binnenkomende ADSL lijnen van de gebruikers getermineerd worden en waar de concentratie gebeurt naar de switch (ATM). Deze zorgt voor de layer 2 connectie naar de backbone router (die zowat dezelfde functie vervult als de access router in het geval van dial access). Zie hiervoor naar Figuur 3.7.


12

Core data network 1

SERVER

Core data network 2

... Core data network N

BACKBONE ROUTER

POP

ATM netwerk

ATM switch

ATM switch

ADSL rack

ADSL RACK

... Telephone

ADSL suscriber

splitter

ANT (adsl modem)

Terminal

ADSL suscriber

ADSL netwerk

...

ADSL suscriber

ADSL suscriber

...

...

PSTN

ADSL netwerk

ADSL suscriber

Figuur 3.7 : de POP in een ADSL access netwerk

3.3.2

Uitleg bij ADSL access

We bespreken Figuur 3.7. De ADSL suscriber heeft ATM network termination equipment (ANT) zoals bvb. een ADSL modem, het telefonie verkeer wordt afsgeplitst (zowel thuis als in ADSL rack in de POP) en verloopt via het klassieke PSTN (=public switched telefony network) en kan in feite als volledig gescheiden worden beschouwd, de lijn die dus van de gebruiker naar het rack in de POP loopt is dus twisted pair. Het ADSL netwerk is in feite gewoon een reeks remote DSLAM’s verbonden met bvb. DS-3‘s (zie 3.5.3.1) De lijnen van de gebruikers komen tesamen in het ADSL rack, deze wordt ook Digital Suscriber Line Access Multiplexer (DSLAM) genoemd. In de DSLAM (= “ADSL rack”) staan de splitters en de ADSL line termination boards (ADSL LT’s), in dit rack wordt het verkeer van alle ADSL LT’s gemultiplexeerd naar een interface, deze interface is meestal STM-1 (=OC-3c) of DS-3 (of E3) (in ieder geval van de orde 34 of 44 of 155 Mbit/s), en deze interface leidt naar een ATM switch. Het ATM netwerk bestaat uit ATM switches. Merk op dat pas in de switches de mogelijjkheid bestaat om connecties tussen verschillende gebruikers te verwezenlijken. De connectie tussen het ATM netwerk en de backbone router gebeurt bvb. over STM-1 links (155 Mbit/s). Uiteindelijk bereiken we dus de backbone router. Noteer dat pas hier authenticatie,... kan geïmplementeerd worden. Dee router stuurt bijvoorbeeld eerst boodschap (vb. CHAP ivm PPP protocol) naar een authenticatie server (vb. RADIUS). Over de ganse lijn we dus een ATM connectie tussen de ADSL modem van de gebruiker en de backbone router, en passeren we een DSLAM en ATM switches. Vanaf die plek geldt dezelfde uitleg als in het geval van dial access netwerken.


13

3.3.3

Verder informatie ivm planning en vergelijking van Dial-up en ADSL

Ivm dimensionering van de ATM switch in een ADSL access netwerk hebben kunnen we bvb. rekening houden met : “typically 20% of the access customers will be active at the same time”. We sommen enkele verschilpunten op tussen Dial-up en ADSL access : • bij ADSL heeft elke gebruiker een “dedicated” lijn van bij hem tot aan het rack, bij Dial gebeurt de connectie van de gebruiker naar de dial gateway via het PSTN of ISDN netwerk • de connectie tussen gebruiker en ADSL rack is min of meer permanent (enkel bij aan- en afschakelen ADSL modem wordt de connectie onderbroken), de connectie tussen gebruiker en dial gateway wordt slechts opgezet voor korte tijd en dit meerdere keren per dag bvb. • het gevolg is dat de planning van het ADSL rack versus de dial gateway duidelijk verschillend is : het aantal modempoorten kan statistisch gezien minder zijn, het aantal gebruikers die verbonden zijn op een bepaald tijdstip is immers lager • qua service bieden ATM netwerken verschillende soorten verkeer aan en verschillende soorten quality of service (QOS), dit is nog niet zo bij IP netwerken (maar wordt wel in de toekomst verwacht), het gevolg is dat ADSL access meer dan louter access tot data netwerken kan aanbieden (bvb. er zijn plannen om via ADSL een zestal telefoonlijnen aan te bieden), dit is mogelijk dankzij het feit dat ADSL via ATM werkt • …

3.4 Configuraties 3.4.1 Zestal verschillende Dial access architecturen op een rijtje 3.4.1.1 architectuur 1 Deze is de architectuur hierboven reeds gegeven in Figuur 3.1 en werd reeds besproken.

3.4.1.2 architectuur 2 Ipv één of meerder centrale severs te gebruiker, is het eveneens mogelijk een server te installeren lokaal nabij de access router. Een “server” betekent concreet : webserver, proxy, mirror,

Dit is bijvoorbeeld het geval indien een ISP in plaats van één centrale server, nu in elke POP die access tot hem levert een eigen server laat installeren. Zie Figuur 3.8. Zulke lokale servers kunnen de moeite lonen indien het aantal gebruikers dat normaal van de oorspronkelijke server gebruik maakte toeneemt. Core data network 1

Core data network 2

...

Core data network N

POP Access Router LOCAL SERVER

PSTN Dial Gateway

ISDN DIal Gateway

PSTN

...

V.x modem

...

V.x modem

ISDN ISDN modem/ card

ISDN modem/ card

Figuur 3.8 : 2e architectuur voor dial access

•

voordelen

De links naar de verschillende ISP’s (naar de core data netwerken dus) worden minder belast indien we bijvoorbeeld lokaal een cache inhouden. © Adelbert Groebbens

14

De server kan de security aspecten regelen of bvb. de AAA functies, de access operator kan hiermee dus de geleverde dienst uitbreiden en nieuwe bronnen van inkomsten creëren.

•

nadelen

Het aantal servers dat beheerd moet worden stijgt indien er in elke POP zo’n lokale server komt te staan.

3.4.1.3 architectuur 3 Recente gateway devices (zie later in overzicht van equipment) voorzien nu zowel kaarten voor modem dial-up als kaarten voor ISDN dial-up. Dan bekomen we de architectuur zoals in Figuur 3.9.

Core data network 1

CENTRAL SERVER

Core data network 2

...

Core data network N

POP

CENTRAL SERVER

Access Router

PSTN Dial & ISDN Gateway

PSTN

...

V.x modem

ISDN modem/ card

...

V.x modem

ISDN ISDN modem/ card


•

voordelen

Er is één type equipment minder. In vergelijking met het vorige geval, h te zijn naar de access router. Het kan wel zijn dat er meerdere gateways in één POP staan (zie later). cabling maintenance” en met de configuratie, en is dus goedkoper. De bandbreedte capaciteit van de gateway(s) naar de access router kan bovendien minder zijn omdat er nu nog meer (statistisch) gemultiplexeerd wordt. Bovendien wordt de migratie van modem dial-up naar ISDN hierdoor vereenvoudigd, het volstaat geleidelijk aan de interfacekaarten in de gateway te vervangen, waarbij dan de link naar de access router weinig verandering behoeft !

3.4.1.4 architectuur 4 Men kan ook de inkomende WAN lijnen aan de gateway consolideren naar één lijn toe. Dit is vooral gedreven door het feit dat men evolueert naar een volledig digitaal netwerk ook tot bij de gebruiker : het telefonietransportnetwerk is reeds digitaal (SDH, PDH, …), het ISDN netwerk zorgt ervoor dat de gebruiker ook reeds volledig digitaal doorzendt, modem is nog analoog maar wordt in de centrale direkt omgezet naar 64 kbit/s (PCM) streams. Het is dan ook logisch om enkel nog zulke 64 kbit/s “calls” op de lijn naar de gateway te nemen.


15

Core data network 2

Core data network 1

CENTRAL SERVER

...

Core data network N

POP

Access Router


"all digital"

ISDN

...

PSTN

...


•

voordelen

Het voordeel is dat men enkel nog in de gateway kiest of de call al dan niet naar een modem-controller of naar een ISDN-controller (vaak HDLC controller) moet gestuurd worden, men kan weerom dus de inkomende lijnen beter benutten. Ze dienen nu zowel voor analoge calls als voor ISDN calls. Dit leidt uiteraard tot een goedkopere situatie voor dezelfde capaciteit of geleverde service. Voorbeeld : geval 3e architectuur) 1 lijn voor modem-calls nodig (met dus 30 calls mogelijk in het geval van een E1/PRI lijn) maar slechts gemiddeld 10 ervan gebruikt en daarnaast een 2e lijn in gebruik met capaciteit voor 30 ISDN calls (weerom PRI of E1 interface is dit) waarvan slechts gemiddeld 20 in gebruik geval 4e architectuur) 1 E1 lijn waarop zowel modem dial-up als ISDN gebruikt kunnen worden en dus gemiddeld gezien voldoet aan de nodig vraag In het algemeen kan men stellen dat hoe meer men consolideert op 1 lijn, hoe beter deze benut wordt en hoe beter er ook gebruik gemaakt worden van statistische multiplexering. Bovendien hebben we steeds dat als het aantal grillige inputs die statistisch gemultiplexed worden toeneemt, de grilligheid afneemt en men veel beter in staat is te plannen.

3.4.1.5 architectuur 5 In plaats van in elke POP een router te plaatsen is het ook mogelijk om slechts 1 router voor verschillende POP’s te voorzien. Dit is geïllustreerd in Figuur 3.11.


16

...

Core data network 2

Core data network 1

Core data network N

CENTRAL SERVER

POP 1


"all digital"

Access Router

...

POP N PSTN Dial & ISDN Gateway

"all digital"


•

voordelen

Deze architectuur is nuttig wanneer we bijvoorbeeld verschillende kleinere POP’s hebben. Het voordeel is weerom dat er beter “gemultiplexed” wordt en dat er veel minder verbindingen van access routers naar de core data netwerken nodig zijn. Bovendien vallen er minder routers te configureren en te beheren.

•

nadelen

Een mogelijk nadeel is dat er (duurdere) WAN verbindingen nodig zijn tussen de POP’s en de access router (of routers), dit komt uiteraard doordat de POP’s geografisch verspreid zijn. In het algemeen : hebben we als nadeel van het samenvoegen (“consolideren”) van apparatuur dat het falen ervan steeds meer catastrofaal wordt. De eisen aan reliability van de apparatuur worden dus hoger (vb. power redundancy om falen van voeding op te vangen).

3.4.1.6 architectuur 6 Nog meer recenter gateway equipment incorporeert ook routeermogelijkheden. We hebben dan een stuk apparatuur waarin we als kaarten onder andere E1-interfaces, modem-controllers, ISDNcontrollers, Ethernet-interfaces, routing-controllers, … kunnen steken. Uiteraard vergt de configuratie van zo’n stuk apparatuur veel meer inspanning. Zelfs authenticatie kan reeds met deze apparatuur gebeuren. Zie Figuur 3.12. Merk op dat we ook aangeven dat er uiteraard meerdere POP’s zijn in het internet access netwerk en al deze POP’s leiden naar het core data netwerk. Bovendien zijn er verschillende mogelijkheden voor de links van de gateways naar de core data netwerken zowel LAN technologieën als WAN technologieën zijn mogelijk.


17

Core data network 1

Core data network 2

...

Core data network N

POP N POP 1

PSTN Dial & ISDN Gateway + routing

...

...

PSTN Dial & ISDN Gateway + routing

...


•

voordelen

Er is geen aparte access router meer nodig, dus zijn eveneens de links ernaartoe overbodig. Het aantal (remote) te beheren en te onderhouden (“Operating and Maintenace” (OAM)) stukken apparatuur wordt eveneens kleiner

3.4.2 Meer details over locale architecturen in de POP zelf Dikwijls heeft men meerdere gateways en access routers in de POP’s. De redenen hiervoor zijn : uitbreiden van capaciteit omdat het aantal gebruikers stijgt reliability (vb. reserve gateways en routers) aparte access router afhankelijk van het type klant (vb. met en zonder firewall, vb. snel/duur tov minder snel/goedkoop) aparte access router per achterliggend core data netwerk (levert een meer eenvoudige administratie en configuratie op, …) … Deze gateways en access routers moeten op een bepaalde manier geconnecteerd worden. Hiervoor bestaan weerom verschillende manieren. Een eerst mogelijkheid is een mesh (vermaasd netwerk) op te zetten, dit vergt uiteraard veel links en niet in het minst veel interfaces ! (à Figuur 3.13). Wordt het aantal concentratorgateways en/of routers te groot, dan kunnen de meerdere concentrators worden geaggregeerd via shared/switched Ethernet (of een ander layer 2 netwerk) naar één of meerdere routers die dan leiden naar het achterliggend core data netwerk (à Figuur 3.14) Merk op dat het in dit geval interessant wordt om eventueel een cache in de POP te installeren (wegens het groot aantal gebruikers, “de grote densiteit”). Access Router


Access Router


Access Router


Figuur 3.13 : full mesh interconnectie in POP


18

Access Router

Access Router

Access Router

layer 2 technology (e.g. Ethernet)


CACHE



Figuur 3.14 : layer 2 technologie lokaal in de POP

3.4.3 Viertal verschillende ADSL access architecturen op een rijtje 3.4.3.1 architectuur 1 Deze is de archictectuur reeds hierboven besproken in Figuur 3.7. Samengevat hebben we een layer 2 ATM connectie van de gebruiker naar de backbone router die dan naar de achterliggende core data netwerken leidt. Merk op : dat het ADSL rack in feite kan bestaan uit een reeks aparte racks, die dan allen leiden naar het ATM netwerk.

3.4.3.2 architectuur 2 Het is ook mogelijk om de backbone router naar de POP’s te verschuiven. Dit is getoond in Figuur 3.15. Merk op dat we daardoor een IP netwerk nodig hebben tussen de POP’s en de randen (“edge”) van de core data netwerken. Het IP netwerk (layer 3) zal daardoor bijvoorbeeld over een ATM netwerk (layer 2) gelegd worden. SERVER

Core data network 1

Core data network 2

Core data network N

...

IP netwerk (over ATM)

POP

POP

...

ROUTER

ROUTER

ADSL rack

ADSL rack

ADSL suscriber

...

ADSL suscriber

ADSL suscriber

...

ADSL suscriber

Figuur 3.15 : 2e architectuur voor ADSL access

•

nadelen

Er is vereist dat het verkeer komende van het ADSL rack dus getermineerd wordt naar een IP netwerklaag, het gevolg is dat enkel IP verkeer mogelijk is, wat een beperking vormt in het geval van ATM omdat ATM speciaal ontwikkeld is om ook bijvoorbeeld real-time informatie te verzenden, terwijl IP dit (nog) niet aankan in dezelfde mate. Het aantal te configureren routers neemt bovendien toe.

•

voordelen

De routers zijn gestegen in aantal en gedistribueerd, dit zorgt voor een betere reliability en availability. Deze architectuur laat ook toe om lokaal in de POP’s servers te installeren (zie ook architectuur 3).


19

3.4.3.3 architectuur 3 Zoals gezegd, indien we lokaal in de POP’s een server wensen is het (meestal) nodig, om er eveneens een router te installeren . Dit geeft dan de 3e architectuur, zie Figuur 3.16. De opmerkingen hierbij zijn dezelfde als bij de analoge architectuur in het geval van dial-up access. Core data network 2

Core data network 1

...

Core data network N


POP

POP

ROUTER ROUTER SERVER

...

ADSL rack

SERVER

ADSL rack

SERVER

ADSL suscriber

...

ADSL suscriber

ADSL suscriber

...

ADSL suscriber


3.4.3.4 architectuur 4 Zoals vroeger kunnen we één router gebruiker voor meerdere POP’s. Merk op : dat de verbindingslijnen tussen de racks en de routers dan waarschijnlijk ook over ATM zullen verlopen. Zie Figuur 3.17.

Core data network 2

Core data network 1

Core data network N


ROUTER

ADSL rack

ADSL suscriber

...

connectie via bvb. layer 2 netwerk (bvb. ATM)

POP

...

POP's

ADSL rack

...

POP

ROUTER

ADSL rack

ADSL rack

... ADSL suscriber

ADSL suscriber

ADSL suscriber



20

3.4.4 Besluit over de architecturen De keuze van welke architectuur of architecturen we gebruiken, is niet zo eenvoudig. Een aspect die de architectuur bepaald is de totale kost, deze omvat o.a. : 1. kost van de basisversies van equipment 2. kost van de (additionele) modules en interfaces nodig in het equipment 3. kost van reserveonderdelen (spares) 4. kost van de links (LAN,WAN, fibre, leased lines, …) 5. kost om het equipment te configureren en operationeel te houden 6. … Merk op dat de besproken architecturen duidelijk verschillen zullen vertonen wat betreft deze onderdelen in de totale kost.


21

3.5 Apparatuur 3.5.1

Terminologie en algemene informatie

In de volgende hoofdstukken worden enkele producten in detail behandeld. We geven eerst nog wat voorbereidende uitleg. Informatie werd gehaald op het web (zie 12.4) en uit [5],[6],[7] en [8]. We geven later productbeschrijvingen van de volgende types apparatuur : • “concentrator + router” : dit staat voor de DIAL-UP & ISDN gateway met geïntegreerde routeermogelijkheden • “access router” : dit is een gewone (layer 3) IP router • “servers” : dit zijn webservers, security servers, firewalls, … • “rack” : dit staat voor de ADSL concentrator die de ATM connecties op de verschillende telefoonlijnen multiplexeert naar één lijn • “ATM switch” : dit is een gewone (layer 2) ATM switch • “backbone router” : eveneens een router (merk op dat er verschillende “groottes“ (lees : aantal interfaces, totale throughput,…) bestaan in routers en dat afhankelijk van de architectuur van het netwerk een kleinere of een grotere router vereist is op een bepaalde plaats) Zie Figuur 3.18 voor een voorbeeld van interfacekaarten die in de slots van een chassis van een stuk equipment kunnen gestoken worden.

Figuur 3.18 : interfacekaarten die passen in een slot van een stuk equipment (vb. router) Voor de bandbreedtes op deze links Appendix C : bandbreedtes/link-types . Typische naamgeving die we tegenkomen (alhoewel deze totaal niet strikt is) : • “WAN interfaces” : dit zijn interfaces voor de lijnen die van de telco operator komen, ze gaan over een grote afstand • “LAN interfaces” : dit zijn interfaces voor de lijnen die lokaal apparatuur verbinden (bvb. in de POP) • “uplink interfaces” : dit zijn interfaces voor de lijnen die van de concentrator naar de backbone netwerken (“erachter”) lopen, kunnen WAN of LAN interfaces zijn De term “channelized” (à bijvoorbeeld channelized E1 (vaak gewoon E1 genoemd !) ) betekent dat we 64 kbit/s calls (64 kbit/s =DS0) multiplexeren naar een E1 bitrate (2 Mbit/s), normaal hebben we dus plaats voor 32*64 kbit/s maar vermits één kanaal gebruikt wordt voor signalisatie en een ander kanaal voor framing, hebben we dus uiteindelijk 30 beschikbare 64 kbit/s voice calls. Opmerking : • opsomming LAN protocols : bvb. IP, IPX en APPLETALK • opsomming WAN protocols : bvb. FR, X.25, proprietary HDLC, PPP (MLPPP) © Adelbert Groebbens

22

Qua prijsinformatie is er zeer weinig openbaar op de sites van de leveranciers te vinden. Prijzen komen immers tot stand na onderhandelingen tussen de operatoren en de leveranciers zelf. Ter informatie : • 1996 : prijs voor • 1 chassis • + 1 Ethernet interface • + 23 modems (64 kbit/s) • + 1 T1 (USA) of PRI poort • + IP routing en management software • = orde1 M Bfr • 1996 : prijs van • 1 Ethernet • + 1 T1 of PRI • + 1 modem card • = varieert van 15000 Bfr tot 100000 Bfr à bvb. gemiddeld rond de 35000 Bfr De beschrijving van equipment is bijvoorbeeld nuttig om een concreter beeld te krijgen over de apparatuur die te vinden is over een access netwerk. Uit de resem aan interfaces kan je o.a. afleiden : welke connecties er tussen de apparaten mogelijk zijn over welke afstand deze connecties kunnen lopen wat de capaciteit (bandbreedte) van deze connecties is … Bovendien krijg je een overzicht van de modulaire opbouw van deze apparaten en welke modules en kaarten nodig zijn om een bepaald systeem uit te bouwen. De gedetailleerde uitleg in de volgende hoofdstukken werd naar een appendix verschoven omwille van het feit dat de specificaties nogal langdradig zijn : zie Appendix D : details en specificaties van internet access equipment

3.5.2

Dial equipment

3.5.2.1 “concentrator + router” We hebben de volgende apparatuur bekeken.

•

Cisco AS5x00 Series

Zie Appendix D : details en specificaties van internet access equipment en zie [25].

•

Nortel CVX 1800


•

Ascend MAX TNT


•

Cisco 36x0 Series



23

•

extra : PSTN Dia l & ISDN gateway + routing

We geven hier een figuurtje die een schets van een mogelijke interne opbouw van een gateway met routeermogelijkheden toont. De bedoeling is kort de structuur en werking van dit soort apparatuur te geven. Zie Figuur 3.19. De informatie is gebaseerd op [8]. controller card router

CPU

Cell Bus

modem card router modem modem

modem card router modem modem

uplink card CPU Ethernet Ethernet

TDM bus T1 card

T1 card

T1 framer

T1 framer

line interface unit

line interface unit

Figuur 3.19 : een structuurschets van een dial-up/ISDN gateway met routeermogelijkheden

We geven kort wat uitleg bij deze figuur : • T1 card en TDM bus : zorgt voor de interface met de T1 lijn en stuurt DS0 streams (= 64 kbit/s calls) naar de modem card • modem card : terminatie van PPP sessie, stuurt login informatie naar controller card • controller card : stuurt login informatie naar (external) RADIUS server • modem card : indien login geslaagd, dan stuurt deze kaart de PPP data pakketten naar de controller card via de cell bus • controller card : assembleert de in cellen gesneden PPP data tot hun oorspronkelijke vorm, neemt de payload eruit (meestal zijn dit IP pakketten) en encapsuleert deze weer in een gepast formaat (LAN,WAN,…), daarna zorgt de router (deze zit eventueel ook op aparte kaart) ervoor dat er naar de gepaste uplink (vb. Ethernet interface) gerouteerd wordt • enkele eigenschappen van dit soort equipment die ervoor zorgen dat aan de noden van de ISP’s kan voldaan worden (zoals bvb. ISP heeft zeer veel modems nodig (dwz “hoge

•

alles wordt in een enkel stuk hardware samengebracht we hebben multi-card systemen verbonden via een bus interface er is gezorgd voor een flexibel chassis en we hebben een “modular card design” de nodige processing kan over verschillende kaarten verdeeld worden de “next generation” van dit soort systemen beoogt o.a. : van de orde 2000 calls per shelf, 10000 call per rack (cf. wholesaling) (à vereist hardware aanpassingen in huidige systemen) reliability (hot swappable, redundancy) (à vereist hardware aanpassingen in huidige systemen) multiple services (dial-up, xDSL) (à vereist vooral software aanpassingen in huidige systemen)

3.5.2.2 “access router”

•

Cisco 75xx Series

Zie Appendix D : details en specificaties van internet access equipment en zie [26]. © Adelbert Groebbens

24

3.5.2.3 “servers” Servers zijn bijvoorbeeld “high-end towers” met meerdere CPU’s, harde schijven en netwerkkaarten (op bvb. PCI interface). De software die erop draait varieert van Windows NT, alle UNIX varianten (HP UX, Sun Solaris, Linux, …) tot eigen besturingsystemen van de fabrikanten zelf (zij leveren dan een “box” met alles erop en eraan qua hardware en software). We kunnen servers indelen in de volgende 3 groepen : • Thin servers : deze hebben geen WAN interfaces, meestal geen firewall en meestal geen routing. Ze ondersteunen 6 à 200 gebruikers. Ze zijn “proprietary products” (=patent van fabrikant) voor één welbepaald doel, dus niet zelf configureerbaar of uitbreidbaar door de klanten. Hun toepassing is bvb. intranet workgroups. • Multiservice Internet access servers : deze hebben wel een WAN interface, wel firewall en wel routing. Ze ondersteunen 100 gebruikers. Hun toepassing is : “all in one products”. Het nadeel hiervan is dat ze een single point of failure vormen. • Core servers : hebben soms WAN interface, soms wel firewall (à maar aangeraden om gescheiden te houden), meestal wel routing (à maar aparte routers bieden betere performantie). Hun toepassing is : public internet services (1000 hits per second). Ze zijn gemaakt voor : extensibility, scalability. Ze hebben als besturingssystemen : “own flavor of UNIX”, Windows NT, Novell Netware. Ze ondersteunen 100,1000 tot 10000 end users. Allen hebben ze SNMP agents en meeestal meerdere CPU’s (zie Tabel 3.1). De methode om deze meerdere CPU’s te gebruiken is clustering, dwz elke CPU krijgt zijn eigen operating system en de CPU’s communiceren via een high-speed connection en ook : “an external device, like a router, is used to load balance the users accessing the cluster”. Het nadeel hiervan is dat elke CPU een soort eigen server, die apart geconfigureerd moet worden. Het biedt wel de mogelijkheid tot werken met verschillende groepen van end-users. • We zien in dat meerdere CPU’s hebben in een web server nuttig is als we de antwoorden op “hoe behandelen HTTP servers meerdere requests tegelijkertijd ?” bekijken : • forking a copy of the server for each request • multithreading • using a pool of processes • gevolg : wanneer er zeer veel request “tegelijkertijd” zijn vergt dit veel CPU time slots voor al die processen Tabel 3.1 : enkele core server producten en hun maximaal aantal CPU’s Webserver producent IBM DEC Silicon Graphics

Product RS6000 Alphaserver Webfore Origin

# CPU’s up to 512 up to 14 up to 128

Iets omtrent de orde van grootte van servers : high end hebben 500 hits per seconde en low end : 10 hits per seconde. Mogelijke applicaties op een server zijn : • web publishing • web hosting • e-commerce • “collaborative software” • basic internet services (e-mail, DHCP, DNS, FTP, …) • … Verder : load balancing is een techniek met als doel het distribueren van het werk over verschillende web servers. Er zijn twee opties : load balancing server, load balancing software on network servers. • methode hardware load balancers : • staan gepositioneerd tussen router en webservers • van inkomend request van remote webbrowser worden het source en destination IP adres en de source en destination port bijgehouden • nadien wordt het destination IP adres in de request vervangen door lokaal adres van één van de webservers © Adelbert Groebbens

25

•

•

bij het ontvangen (passeren) van een antwoord van de webserver in de balancer, wordt dan het gepaste destination IP adres op de plaast van het lokale adres geschreven • het ontvangen van berichten van de webbrowser en het antwoorden van berichten ernaar gebeurt dus enkel door de load balancer methode software load balancers : • deze vangen enkel maar het eerste request op en sturen door naar de minst belaste server, waarna alle verdere uitwisseling tussen browser en server gebeurt • voordeel : de verdere antwoorden hoeven niet noodzakelijk langsheen de load balancing server te passeren (meerbepaald langsheen zijn netwerksegment)

Voor meer uitleg en details ivm producten zie o.a. [29] en [30].

3.5.3

ADSL equipment

3.5.3.1 “rack”

•

Alcatel ASAM

De Alcatel ASAM (= ATM Suscriber Access Multiplexer) is het “ADSL rack” dat in de POP staat. Hieronder geven we een figuur die duidelijk de componenten in de ASAM beschrijft : zie Figuur 3.20. De figuur zou op zich duidelijk genoeg moeten zijn.


26

PSTN ATM

Alarm control unit

PORT 1

POTS splitter 1

PORT 2

POTS splitter 2

PORT 3

POTS splitter 3

PORT 4

POTS splitter 4

ADLT

POTS splitter 1

PORT 2

POTS splitter 2

PORT 3

POTS splitter 3

PORT 4

POTS splitter 4

SHELF 1

twisted pair ADSL suscriber

1 SHELF

...

bus

ADSL suscriber

2

...

ADLT

Customer Premise Equipment

ADSL suscriber

1

PORT 1

ADSL Network Termination

POTS splitter

...

network termination Ÿ STM-1 Ÿ OC3c Ÿ DS3 Ÿ E3

12 Extender POTS splitter 1

PORT 2

POTS splitter 2

PORT 3

POTS splitter 3

PORT 4

POTS splitter 4

...

ADLT

ASAM

ADSL suscriber

...

SHELF 2

PORT 1

network termination Ÿ DS3 Ÿ ...

1

...

Extender duplicate

Alarm control unit

12

R-ASAM

PORT 1

POTS splitter 1

PORT 2

POTS splitter 2

PORT 3

POTS splitter 3

PORT 4

POTS splitter 4

ADLT

1 PORT 1

POTS splitter 1

PORT 2

POTS splitter 2

PORT 3

POTS splitter 3

SHELF 12

POTS splitter 4

PORT 4

ADLT

2

...

...

line termination (to remote ASAM) Ÿ DS3

Figuur 3.20 : ADSL ASAM, systeem architectuur •

Enkele eigenschappen van de ASAM : • de toepassing ervan is het concentreren van trafiek • de ASAM is volledig ATM gebaseerd, dit wil zeggen : • AAL 5 framing en fragmenting into ATM cells reeds van bij de suscriber (=gebruiker) • ADSL à physical layer • mogelijke links tussen ASAM en ATM switch : STM1/OC3c of DS3 of E3 links • 12 ADSL-LT’s (line termination boards) per shelf • shelves zijn verbonden via ADSE • 3 shelves per rack mogelijk • in totaal zijn er maximaal 12 shelves per network interface mogelijk • dus 12 shelves/network interface*12 LT’s/shelve * 4 lines/LT = 576 ADSL lines per network interface à 500 à 600 gebruikers per ASAM • 10 VP/VC connections per ADSL line • mogelijke ATM network interfaces : • 1x STM-1 interface • 4x E1 of DS1 interface


27

•

• 1x E3 of DS3 interface er bestaan ook kleinere remote access multiplexers (R-ASAM) met minder ADSL-LT’s per shelf, kleinere afmetingen (verbinding met ASAM via 4x E1 of DS1 interface)

3.5.3.2 “ATM switch” (eventueel ook geval bij dial up als layer 2 (L2) verbinding met access router)

•

ForeRunner ATM switches

De gevonden informatie geven we in de volgende tabel : Tabel 3.2 : informatie over de Forerunner ATM switches throughput aantal poorten aantal connecties opzetbaar per seconde maximum poortsnelheid

• •

ASX-200WG 2.5 Gbps, nonblocking 12 tot 32 100

ASX-200BX 2.5 Gbps, nonblocking 2 tot 24 450

ASX-1000 10 Gbps, nonblocking 2 tot 128 450

ASX-1200 10 Gbps, nonblocking 2 tot 128 525

STM-4c,OC12 (=622 Mbit/s)




IBM Nways 8265 switches van Newbridge

Voor meer informatie verwijzen we naar de internet sites van deze fabrikanten.

3.5.3.3

•

à idem als de access router bij dial-up

3.5.3.4

•

“backbone router” “server”

à idem als bij dial-up


28

4 Trafiek en trafiekgenerator(en) Zoals gezegd is het uitgangspunt van deze thesis dat we ons baseren we ons op metingen (vooral dan van trafiek). Deze zijn nodig omdat we niet meer mogelijk is (i.t.t. telefonie) de capaciteit van een internet access netwerk te plannen op basis van trafiekmodellen. Trafiekmetingen laten ons toe besluiten te trekken omtrent het verbruik van de resources in ons accessnetwerk en wanneer deze resources dus best uitgebreid worden. Voorbeelden van (trafiek)metingen zijn : • het totaal aantal getransfereerde bytes die aan een uitgang van een router of een switch verstuurd worden (maw het bandbreedte verbruik van een link) • het totaal aantal requests die behandeld worden in een (web) server • het totaal aantal requests van een bepaald soort type die behandeld worden in een (web) server (waarbij type : het filetype, de grootte van de request, ... kan zijn) • het totaal aantal getransfereerde bytes door een (web) server • het totaal aantal getransfereerde bytes van een bepaald soort type door een (web) server • het aantal bezette modems in een modempool (modemgateway) op een bepaald tijdstip • het totaal aantal requests die binnenkomen op het netwerk voor een server (maar eventueel niet behandeld kunnen worden) • het totaal aantal gebruikers die inbellen op een modemgateway maar eventueel geen vrije modem in gebruik kunnen nemen • het aantal paketten die weggeworpen worden in een router of switch tengevolge van congestion (het vol lopen van de buffer) • ... We geven eerst wat algemene informatie over netwerktrafiek. Daarna bespreken we hoe we de gepaste data kunnen bekomen.

4.1 Netwerktrafiek Internet (of netwerk) trafiek heeft de volgende eigenschappen (voor verdere informatie zie [1]) : 1. BURSTINESS • netwerktrafiek is bursty : dwz de peak rate is 8 à 10 keer de average rate • “metrics at peak time” zijn sterk verschillend van “average metrics”, maar met beiden moet rekening gehouden worden bij capaciteitsplanning • karakterisatie van burstiness in een model kan bijvoorbeeld via : • a = de verhouding tussen de maximum peak rate en de average rate (bij een meting over een bepaalde tijdsperiode) • b = de fractie van de tijd waarbij de rate > de average rate • opmerking : met rate wordt bedoeld hoe snel de data pakketjes met requests arriveren 2. HEAVY TAIL DISTRIBUTIE • de metingen kunnen extreme variaties vertonen • extreme variaties kunnen niet zo uitzonderlijk zijn, we hebben te maken met heavy tail distributie (maw Prob[X groot] = niet zeer klein, met X een positieve toevalsgrootheid) • gevolg : estimaties (bvb. van gemiddelde) vertonen grote variantie 3. SELF-SIMILARITY • netwerktrafiek vertoont self-similarity, dit wil zeggen correlatie die behouden wordt over verschillende tijdsschalen • meer concreet : als je de totale hoeveelheid trafiek gedurende een tijdsinterval met lengte x uitzet voor een hele reeks opeenvolgende tijdsintervallen (een zekere periode in de tijd dus), dan bemerk je bursts ongeacht de lengte x (dus ook voor lengte a*x met a willekeurige schaalfactor (vb. 10,0.1,100,0.01,…)) • gevolg : burstiness van netwerk trafiek (vb. ook web trafiek) voor praktisch alle tijdschalen ! 4. CHAOTISCH • “it is difficult to know in advance how many people will access a website, at what times, and what their usage patterns will be” • maw het is moeilijk om een model achter de metingen te zoeken om deze metingen dan te verklaren © Adelbert Groebbens

29

4.2 Trafiekmetingen bekomen Het meten van trafiek voor capaciteitsdoeleinden gebeurt best gedurende een peak workload moment en dan nog voor een voldoende lang tijdsinterval. Vaak zijn er heel veel datasamples en dan zijn representatieve parameterwaarden nodig. Methoden hiervoor zijn bijvoorbeeld : • typische waarde (=”average over all”) • werken met klassen (small, medium, large) en dan een typische waarde per klasse nemen De verschillende stappen in “measuring” zijn : • referentie punten specifiëren • variabelen die gemeten moeten worden specifiëren • instrumentatie (vb. monitortools installeren) en data collectie • analyseren en transformeren van de data naar de gewenste vorm Er bestaan 2 modes van measurement : • EVENT MODE : tijdstippen van data collectie zijn bepaald door events (=iets wat de toestand (=set van variabelen) van een syteem verandert) (vb. interrupt, transactie, …) à nadeel : geven een zekere overhead die meestal onvoorspelbaar is (bvb. groot) en deze kan ervoor zorgen dat measurements waardeloos worden • SAMPLING MODE : tijdstippen van data collectie zijn regelmatige tijdstippen à de overhead is bepaald door de duur van het sampling interval (de overhead hangt bvb. af van de hoeveelheid informatievariabelen die gesampled moeten worden) à voordeel : dit interval kan wel gespecifieerd worden en dus de overhead kan meestal wel bepaald en in rekening gebracht worden Steeds heeft men de afweging : accuracy versus overhead. De event mode is accurater dan de sampling mode. Er zijn 3 types van measurement : • hardware monitor : dwz gebruik van hardware, met als eigenschappen weinig overhead, weinig resource verbruik, portabel, meestal geen metingen van software-gerelateerde zaken • software monitor : dwz gebruik van software • hybrid monitor (= hardware + software monitor)

Een van de problemen in deze thesis was het bekomen van geschikte metingen. Internet access providers maken deze gegevens liever niet publiek (concurrentie). We hadden slechts volgende mogelijkheden : • log files : we hebben gelukkig op het internet enkele web server access logs kunnen vinden, ook hebben we de access logs van de vakgroep IBCN (Atlantis web server en firewall) bekeken • trafiekgenerator : zoals reeds vermeld is eigen generatie van de metingen zeker niet eenvoudig wegens de complexe aard van gepaste modellen voor internet traffiek, we hebben ons dan ook beperkt tot een eenvoudige (puur artificiële) generator Er weze dus opgemerkt dat de gebruikt data niet (echt) geschikt is voor capaciteitsplanning. En dat praktisch bruikbare resultaten en of conclusies zullen uitblijven. Mogelijke uitbreiding is dus het zoeken naar of het verkrijgen van betere metingen. We bespreken in de volgende delen : de gevonden access logs en de eigen trafiekgenerator.

4.3 Access logs In dit deel bespreken we enkele web server (of firewall) access logs. De bedoeling is : • kwantitatieve en/of kwalitatieve eigenschappen te identificeren • inzicht te krijgen nodig voor de bouw van een eigen trafiek generator • manier bekomen om onze eigen trafiek generator te vergelijken © Adelbert Groebbens

30

4.3.1

Wat zijn access logs ?

Access log is een logfile (=textfiles die acties reporteren) die een HTTP server bijhoudt met informatie omtrent elke request die binnenkomt. Access logs, bevatten meestal per request volgende zaken : • de host (=IP address of host name van de client die de request uitvoerde) • identificatie, login name (=ivm authenticatiemogelijkheden van de server) • datum, tijd en tijdzone van de request • type HTTP request (vb. GET/HTTP/1.0) • status (vb. succes, unauth, nonexist) (opm. 200 = succes) • file size van de request (= grootte van de gevraagde file) • welke pagina of file werd gevraagd • soort van browser • het operating system van de host die de aanvraag deed Voorbeeld : 3 lijntjes uit een access log : ram0.huji.ac.il - - [01/Jun/1995:00:05:44 -0600] "GET /~scottp/publish.html" 200 271 eagle40.sasknet.sk.ca - - [01/Jun/1995:00:08:06 -0600] "GET /~lowey/" 200 1116 eagle40.sasknet.sk.ca - - [01/Jun/1995:00:08:19 -0600] "GET /~lowey/kevin.gif" 200 49649 …

Hieruit kunnen we bvb. berekenen : het totaal aantal requests per 5 min het totaal aantal getransfereerde bytes per seconde door de server ...

4.3.2

Waarvoor kunnen access logs gebruikt worden ?

Zoals verteld in de strategie is het de bedoeling om via access logs iets te weten te komen over de belasting van de WWW server. Meer nog : we wensen te voorspellen hoe deze belasting zal evolueren. We hebben dan ook eerst nagegaan in welke mate dit mogelijk is. De volgende informatie is gebaseerd op [12], [10] en [11]. Enkele punten : • neveneffecten die ervoor zorgen dat access logs niet de echte “b beschrijven : o browsercache : zorgt ervoor dat niet alle requests voor een pagina ook de server bereiken o caches van ISP, etc : zorgen ervoor dat niet alle requests voor een pagina ook de server bereiken, zorgen er bovendien voor dat het internet adres van de client host dikwijls die van de cache is ipv de host die daadwerkelijk het initiatief nam om de pagina op te vragen o soms ontvangt de web server leugens i.v.m. het soort van browser, de referrer pagina (=de pagina die de link naar de request bevatte) o spiders en agents : zorgen er ook voor dat we niet weten of we met een echte gebruiker te maken hebben die de request uitvoert o accelerator = cache voor uitgaande pagina’s van een server (slaat namelijk de opgevraagde documenten (tijdelijk) op in een snelle structuur op schijf (of in geheugen) (deze structuur is sneller dan de directory structuur van de harde schijf) à staat bijgevolg los van de server (en dus ook van de log files) • zeker niet te halen uit access logfiles (alhoewel vaak gepoogd) : o identiteit van de bezoekers (vb. wegens caches) o aantal bezoekers (vb. wegens caches, wegens geen bijectie host ⇔ gebruiker) o aantal bezoeken (=visit = “user session”) (vb. wegens geen bijectie host ⇔ gebruiker, wegens geen goeie definitie voor “visit”) o sequentie van de pagina’s van uw webserver die een gebruiker bekijkt (vb. wegens cache o o

de referrer van de eerste pagina’s van uw webserver die een gebruiker bekijkt (vb. wegens cache) hoe lang bezoekers een pagina bekijken


31

de minst gebruikte pagina’s, reden (!) : de ongebruikte pagina’s worden nooit in log opgenomen o ... samengevat : o er is enkel geweten wat er gebeurt bij de server zelf o voornaamste reden : HTTP is een “stateless protocol” o gebruik web statistieken dus enkel voor wat ze gebruikt kunnen worden o

•

Merk dus op dat voor planning een access log waarschijnlijk geen goeie beschrijving van de belasting vormt : bvb. het wegvallen van één of andere cache (vb. landelijke cache in UK voor trafiek naar VS) kan een enorme stijging van het aantal requests tot gevolg hebben. Dit is nog een benadrukt door : “Web traffic volatility: Short-term Web traffic is extremely volatile, so that one week's figures may be double, or half, the previous week's (Nielsen). Such fluctuations mean that trends in site traffic emerge only with long-term data analysis.” In de toekomst zal er dus eventueel nood zijn aan andere middelen om greep te krijgen op WWW trafiek en om via log file analysis een beter beeld te krijgen over gebruikers en gebruik (commercieel belangrijk vb. reklame,...) : bvb. andere protocols, benutten van cookies, … Bovendien staan in een access log enkel de requests die effectief bediend zijn geworden en is een access log bij overbelasting dus onbetrouwbaar. Dit is nog een van de tekortkomingen van access logs voor capacity planning. Volgende citaat uit de FAQ van [12] toont aan dat voorzichtigheid zeker nodig is : “Can stats be used to assess changes over time?” No. The number of individuals and sites using caches is rising all the time, as is the amount of disk space and memory used for caching. When the Cranfield Accelerator goes live (early November, 1995), there should be an actual drop of our server stats, while an increase in accesses, due to increased speed and reliability of the server. Caching has been on the rise for more than a year now. Even so, loads on systems (including ours) have gone up dramatically.”

4.3.3

Generatie van grafieken : logfile analyzer

De access logs werden geanalyseerd met ANALOG 4.03 (zie [12]). Instellen van ANALOG gebeurt via configuratiefiles (zie Tabel 4.1 en Tabel 4.2 ) en de uitvoer na analyse is een soort data-textfile formaat (computerformaat). ANALOG staat ook op de CD-ROM, zie Appendix B : extra uitleg bij CDROM. Eens in computerformaat (vb. zie ) en na preprocessing (automatisch wegknippen bepaalde velden en blanco lijnen) (computerformaat .comp file en na preprocessing .comp_pp file) konden zij ingelezen en bewerkt worden door MATLAB. Tabel 4.1 : voorbeeld van een configuratiefile (analog_uofs_five_all_comp.cfg) in Analog 4.03 # ANALOG 4.03 # configuration file by Adelbert Groebbens (c) 04/2000

# # # # # # #

ABSTRACT : this file configures report generating, for : -http_logs of the university of Saskatchewan WWW server -aggregates results for each five minutes -and this is done for all days (that are present in the logs) -in "computer format" (see documentation readme)

CONFIGFILE five_conf.cfg ## Specifies the logfiles to be analyzed: LOGFILE d:\logs\uofs_logs\*


32

## Specifies the output file (computer format) : OUTFILE ..\uofs_logs\uofs_five_all.comp

Tabel 4.2 : voorbeeld van een configuratiefile (five_conf.cfg) in Analog 4.03 # ANALOG 4.03 # configuration file by Adelbert Groebbens (c) 03/2000

# ABSTRACT : # this file configures basic options for report generating # and can be included as : CONFIGFILE five_conf.cfg

############### # nodig om geheugenproblemen in Win98 op te lossen : hostnames en filenames zijn toch niet nodig ! HOSTLOWMEM 3 FILELOWMEM 3 HOSTNAME "(c) 2000 by Adelbert Groebbens" # Use this if you want to unzip the files automatically (using gzip) # UNCOMPRESS *.gz,*.Z "gzip -cd" ############### # Possibility to specify time : # FROM yyMMdd:hhmm # TO yyMMdd:hhmm ALL OFF # -> later, we turn on what we like GENERAL OFF GOTOS OFF RUNTIME OFF FIVE ON FIVECOLS RBP

# aggregate for each day # the number of requests, bytes, # request only for pages (=.html,.htm,directories) FIVEROWS 0 # no restriction on the total number of hours that are reported OUTPUT COMPUTER LOGO none COMPSEP , # nog input logfile en output computerfile nodig : in file waarin dit bestand geincludeerd wordt

Tabel 4.3 : output computerformaat Analog 4.03 (voor preprocessing) x,VE,analog4.03/Win32 x,HN,(c) 2000 by Adelbert Groebbens x,PS,2000,05,15,20,21 x,FR,1995,06,01,00,00 x,LR,1995,12,31,23,59 © Adelbert Groebbens

33

H,RBP,65,547137,37,1995,06,01,00 H,RBP,16,55192,13,1995,06,01,01 H,RBP,37,522659,22,1995,06,01,02 H,RBP,76,259214,52,1995,06,01,03 H,RBP,57,237106,44,1995,06,01,04 H,RBP,70,749102,42,1995,06,01,05 H,RBP,94,296703,61,1995,06,01,06 H,RBP,70,663858,42,1995,06,01,07 H,RBP,144,1072714,104,1995,06,01,08 H,RBP,400,13693764,263,1995,06,01,09 H,RBP,455,2490690,235,1995,06,01,10 H,RBP,501,2779461,233,1995,06,01,11 H,RBP,283,1088348,116,1995,06,01,12 H,RBP,421,1659283,198,1995,06,01,13 ... Opmerking : ANALOG telt bij bvb. het tellen van het aantal requests enkel de succesvolle requests dwz status code 2xx en status code 304 (dit laatste in het bvb. het geval van “browser vraagt document op voorwaarde dat het na een bepaalde datum is veranderd (zoniet kan de browser zijn cache gebruiken)”), server antwoordt met status 304, maar in het aantal bytes getransfereerd staat er steeds bij status 340 : “- bytes”, deze worden dus niet meegeteld (wat logisch is). Volgende .m files (MATLAB functies of scripts) werden gebruikt : • plot_rbp.m • plot_rbp_u.m • dispstats.m • ag_read_in.m • ag_read_in_g.m • pa_atlantis_http_d.m • pa_atlantis_http_f.m • pa_atlantis_http_h.m • pa_clarknet_d.m • pa_clarknet_f.m • pa_clarknet_h.m • pa_firewall_d.m • pa_firewall_f.m • pa_firewall_h.m • pa_nasa_d.m • pa_nasa_f.m • pa_nasa_h.m • pa_uofcal_d.m • pa_uofcal_f.m • pa_uofcal_h.m • pa_uofs_d.m • pa_uofs_f.m • pa_uofs_h.m Wat betreft de MATLAB files wordt best voor uitleg gekeken naar (in volgorde) : de online help documentatie bij MATLAB (zie [14],[15],[16],[17] en [18]), de hulpcommentaar in de code (=de 1e lijntjes commentaar van een functie of script, op te roepen via help <script of functie .m file>), de commentaar die naast de code staat. De code is te vinden op de CD-ROM (zie Appendix B : extra uitleg bij CD-ROM).

4.4 Voorbeelden access logs In dit deel beschrijven we de (op het internet) gevonden access logs. De logfiles zijn gecomprimeerd te vinden op de CD-ROM (zie Appendix B : extra uitleg bij CD-ROM). Zonder compressie zouden zij ongeveer 2 Gigabyte in beslag nemen, compressie reduceert dit met een factor 10. © Adelbert Groebbens

34

4.4.1

Atlantis WWW server

We behandelen hier de beschikbare access logs (ook traces genoemd) van de Atlantis WWW server. De Altantis WWW server is de webserver van de vakgroep Breedbandcommunicatie van de faculteit FTWE (aan de RUG). De traces starten op 20/05/1999 11:45 en gaan tot 24/02/2000 11:36. M.a.w. ruwweg een 280-tal dagen, 7000-tal uren, 80000-tal blokken van vijf minuten. Tijdens deze periode waren er in totaal 37219 aantal requests.

4.4.1.1 dagverloop

Figuur 4.1 : dagverloop accesslog van de Atlantis WWW server We merken op dat : • de uitschieters bij de drie grafieken niet samenvallen, dit is te wijten aan het feit dat een gemiddelde webpagina (.html) tussen de 0-10 Kbyte groot is, terwijl andere filetypes die van een web server gehaald kunnen worden wel enkele Mbytes groot kunnen zijn • het patroon zeer grillig is, quasi onvoorspelbaar (vb. stel je probeert op dag 140 het verloop van de volgende 10 dagen te bepalen) • deze grilligheid/onvoorspelbaarheid is hier vooral te wijten is aan “content”-gebaseerde gebeurtenissen (m.a.w. zaken die meer te maken hebben met de inhoud, context in de realiteit,... van de web server dan met netwerktrafiek op zich) : o vb. dag 90-150 : vakantieperiode à rustig o vb. dag 150 : start van het nieuwe academiejaar o vb. dagen 200-240 : periode rond de kerstvakantie, afhalen op de server beschikbare slides ivm cursussen (blokperiode,...) Enkele statistieken van de 1e grafiek van de figuur : Tabel 4.4 : statistieken van het aantal requests per dag bij de Atlantis WWW server STATISTIEKEN van het aantal requests per dag : LOCATIEMATEN :


35

Gewoon gemiddelde : 552.694 Geometrisch gemiddelde : 0 Mediaan : 239 Gemiddelde met uitsluiting van de 12.5% outliers (aan beide uiteinden) : 413.7204 DISPERSIEMATEN : Standaardafwijking : 694.4125 Bereik (=max-min): 5261 IQR (=interquartile range) (25%...75%): 878.75

4.4.1.2 uurverloop

Figuur 4.2 : uurverloop accesslog van de Atlantis WWW server We merken op dat als we op de deze figuur inzoomen we vaak uren tegenkomen waarbij er geen enkele request is ! De Atlantisch WWW server kan dus als een sporadische bezochte web server doorgaan. Enkele statistieken van de 1e grafiek van de figuur : Tabel 4.5 : statistieken van het aantal requests per uur bij de Atlantis WWW server STATISTIEKEN van het aantal requests per uur : LOCATIEMATEN : Gewoon gemiddelde : 23.1077 Geometrisch gemiddelde : 0 Mediaan : 1 Gemiddelde met uitsluiting van de 12.5% outliers (aan beide uiteinden) : 6.6802 DISPERSIEMATEN : Standaardafwijking : 72.2413 Bereik (=max-min): 3233 IQR (=interquartile range) (25%...75%): 18


36

Uiteraard ligt het gemiddelde hier lager, maar merk op dat de de standaardafwijking hier veel groter is tov van het gemiddelde. Zelfs de robuuste gemiddelde met uitsluiting (“trimmed mean”) en de IQR (afstand tussen de 25% fractiel en de 75% fractiel) tonen aan dat de er veel variatie is. Het feit dat het geometrisch gemiddelde 0 is en dat de mediaan 1 is, toont nogmaals aan dat de Atlantisch WWW server maar sporadisch (per uur bekeken) bezoekt wordt. In de volgende figuur (Figuur 4.3) zien we duidelijk de “outliers” (=uitzonderlijk grote waarden) (worden gemerkt met een kruisje) en kunnen we besluiten dat we een sterk scheve distributie hebben. We kunen dus al denken aan de lognormale verdeling of iets dergelijks. Ook het histogram kan nuttig zijn om inzicht te krijgen in “het aantal request per uur” (Figuur 4.4). Bij dit histogram zijn de meest extreme “outliers” wel verwijderd.

Figuur 4.3 : boxplot van het aantal requests per uur op de Atlantisch WWW server

Figuur 4.4 : histogram (na verwijdering van de meest extreme outliers) van het aantal requests per uur op de Atlantisch WWW server

4.4.1.3 verloop per blokje van vijf minuten We bekijken enkel de maand december :


37

Figuur 4.5 : dag 10 van de maand december van de access log van de Atlantis WWW server

Figuur 4.6 : dag 11 van de maand december van de access log van de Atlantis WWW server Bespreking : • de burstiness van de trafiek is overduidelijk, zelfs op een tijdschaal van 5 minuten • er is geen verband tussen 2 opeenvolgende dagen We bekijken ook nog eens het verloop van het gemiddelde aantal requests per 5 min over een dag na verwijdering van de “outliers” (hier de 12.5 % kleinste en 12.5 % grootse waarden) : Figuur 4.7. Vermenigvuldigen van deze waarden met 12*24 geeft ons het gemiddeld aantal requests per dag. We zien geen duidelijke trendlijn, hoogstens een rustige deel en een daaropvolgende deel met zwaardere belasting (dwz meer requests per tijdseenheid).


38

nr of requests

Figuur 4.7 : verloop van het daggemiddelde (van het aantal requests per 5 min) over de maand december

4.4.2

ClarkNet WWW server

We behandelen hier de traces van de ClarkNet WWW server. De ClarkNet WWW server is de webserver van de fulltime Internet access provider ClarkNet, voor de Metro Baltimore-Washington DC. De traces starten op 28/08/1995 00:00 en gaan tot 4/09/1995 23:59. M.a.w. een 14-tal dagen, 350tal uren, 4000-tal blokken van vijf minuten. Tijdens deze periode waren er in totaal 3328587 aantal requests. Merk op een factor 100 groter dan bij de Atlantis access log en dat terwijl het over een period gaat die 20 keer zo kort was, dus in totaal iets van de orde van een 1000x grotere belasting !

4.4.2.1 dagverloop

Figuur 4.8 : dagverloop accesslog van de ClarkNet WWW server We merken op dat : • deze keer de uitschieters (voor zover ze bestaan) van de drie grafieken min of meer samenvallen, dit is waarschijnlijk te wijten aan het grote aandeel van de gewone webpagina (.html, tussen de 010 Kbyte groot) in de totale trafiek, wat op zijn beurt te verklaren is door het feit dat we met zeer veel (en dus de meeste gewone) gebruikers (“surfers”) zitten is • het patroon vrij regelmatig en vertoont typische wekelijkse schommelingen (weekends zijn rustiger) en kan voor de rest min of meer als constant worden beschouwd (na verwijderen van de schommelingen (“deseasonalizing”, 5.2.3)


39

Enkele statistieken van de 1e grafiek van de figuur : we hebben omwille van het lage aantal samples deze keer geen “verwijdering van outli Tabel 4.6 : statistieken van het aantal requests per dag bij de ClarkNet WWW server STATISTIEKEN van het aantal requests per dag : LOCATIEMATEN : Gewoon gemiddelde : 230296.2143 Geometrisch gemiddelde : 226770.0629 Mediaan : 247513.5 DISPERSIEMATEN : Standaardafwijking : 39954.717 Bereik (=max-min): 114106

4.4.2.2 uurverloop

Figuur 4.9 : uurverloop accesslog van de ClarkNet WWW server We zien : • een regelmatig weekpatroon • een regelmatig dagpatroon • (de witte kloof komt overeen met het down zijn van de server) De ClarkNet WWW server kan dus als een druk bezochte web server doorgaan. Tabel 4.7 : statistieken van het aantal requests per uur bij de ClarkNet WWW server STATISTIEKEN van het aantal requests per uur : LOCATIEMATEN : Gewoon gemiddelde : 9595.6756 Mediaan : 9229 Gemiddelde met uitsluiting van de 12.5% outliers (aan beide uiteinden) : 9406.5079 DISPERSIEMATEN :


40

Standaardafwijking : 3849.732 Bereik (=max-min): 18435 IQR (=interquartile range) (25%...75%): 5676 De lezer wordt verder aangeraden om zelf de statistieken te vergelijken met de vorige statistieken betreffende de zelfde accesslog, alsmede met de overeenkomstige statistieken bij andere accesslogs ! Vervolgens waren we geinteresseerd in verandering van dag tot dag in de statistiek van de trafiek per uur. Volgende figuur van (bekend veronderstelde, zoniet zie cursus [2]) “box and whisker” plots toont volgende zaken aan : • de statistiek van de trafiek per uur verandert niet spectaculair (we zouden kunnen zeggen dat we weerom een stationair weekpatroon bemerken) • er is steeds een minimum dat bereikt wordt (=betekenis bolletje onderaan bij de box-whisker figuurtjes) • er zijn geen outliers (geen kruisjes) • de distributies zijn niet echt scheef, bovendien zowel links- als rechtsscheef komt voor, uitgemiddeld over alle dagen bekomen we een uurdistributie die praktische symmetrisch is

Figuur 4.10 : box-and-whisker plots van de statistiek van de trafiek per uur (en dit voor een veertiental dagen) bij de ClarkNet WWW server

4.4.2.3 verloop per blokje van vijf minuten We tonen weerom niet het ganse verloop, maar zoomen in op het trafiekverloop tijdens een drietal dagen. We zien : • in Figuur 4.11 : het patroon is weerom regelmatig • in Figuur 4.12 : toch kunnen aantal request tijdens nabijgelegen periodes van 5 minuten een vrij grote sprong maken (30% verschil is mogelijk)


41

Figuur 4.11 : verloop van de trafiek (in blokjes van 5 minuten) over een drietal dagen van de ClarkNet WWW server

Figuur 4.12 : detailweergave van het aantal requests (tijdens blokjes van 5 minuten) over een drietal dagen van de ClarkNet WWW server © Adelbert Groebbens

42

We geven hier ook even nog de statistieken : Tabel 4.8 : statistieken van het aantal requests per min bij de ClarkNet WWW server STATISTIEKEN van het aantal requests per 5 min : LOCATIEMATEN : Gewoon gemiddelde : 799.6396 Mediaan : 760 Gemiddelde met uitsluiting van de 25% outliers (aan beide uiteinden) : 769.0842 DISPERSIEMATEN : Standaardafwijking : 345.7428 Bereik (=max-min): 2068 IQR (=interquartile range) (25%...75%): 490.5

4.4.3

Nasa WWW server

We bekijken nu de traces van de NASA Kennedy Space Center WWW server in Florida. De traces starten op 1/07/1995 00:00 en gaan tot 31/08/1995 23:59. M.a.w. een 60-tal dagen, 1500-tal uren of 18000-tal blokken van vijf minuten. Tijdens deze periode waren er in totaal 3367294 aantal requests. Merk op dit is een vierde van de belasting van de ClarkNet traces.

4.4.3.1 dagverloop

Figuur 4.13 : dagverloop accesslog van de NASA WWW server We zien : • de vorm van de drie grafieken valt min of meer samen • het patroon vertoont wekelijkse schommelingen (weekends zijn rustiger) • er zit geen echte trend in het verloop, het enige wat op te merken valt is dat de 1e maand (juli) ietwat drukker is (vooral dan in het begin) dan de 2e maand (augustus) Enkele statistieken van de 1e grafiek van de figuur :


43

Tabel 4.9 : statistieken van het aantal requests per dag bij de NASA WWW server STATISTIEKEN van het aantal requests per dag : LOCATIEMATEN : Gewoon gemiddelde : 54311.1935 Mediaan : 57575.5 Gemiddelde met uitsluiting van de 12.5% outliers (aan beide uiteinden) : 54383.5217 DISPERSIEMATEN : Standaardafwijking : 24050.078 Bereik (=max-min): 129233 IQR (=interquartile range) (25%...75%): 27978

4.4.3.2 uurverloop

Figuur 4.14 : uurverloop accesslog van de NASA WWW server We zien : • een regelmatig weekpatroon, alhoewel in vergelijking met de ClarNet WWW server er (zeker in de 1e maand = blokken 0 tot 750) toch wat uitschieters zijn • de 2e maand is dan weer rustiger en regelmatiger dan de 1e • (de witte kloof komt overeen met het down zijn van de server) Tabel 4.10 : statistieken van het aantal requests per uur bij de NASA WWW server STATISTIEKEN van het aantal requests per uur : LOCATIEMATEN : Gewoon gemiddelde : 2263.3602 Mediaan : 1949.5 Gemiddelde met uitsluiting van de 12.5% outliers (aan beide uiteinden) : 2129.1022 DISPERSIEMATEN : Standaardafwijking : 1542.1054 Bereik (=max-min): 14388 IQR (=interquartile range) (25%...75%): 2016.5 © Adelbert Groebbens

44

Hieronder volgt (zie Figuur 4.15) een histogram en een boxplot van het aantal requests per uur. Hieruit kunnen we besluiten dat we toch met een licht scheve distributies zitten (merk ook de “outliers” op). Bovendien geven we ook nog eens het verloop van de box-whiser plots tijdens de 2 maanden.

Figuur 4.15 : boxplot en histogram van het aantal requests per uur van de accesslog NASA WWW server

4.4.3.3 verloop per blokje van vijf minuten We bekijken enkel de eerste 3 dagen :

Figuur 4.16 : verloop (met resolutie van 5 min per sample) van de 1 e drie dagen van de accesslog van de NASA WWW server We geven ook het histogram (distributie van het aantal requests per 5 min), aangevuld van de statistische gegevens. Zie Figuur 4.17 en Tabel 4.11. Hieruit blijk dat we met een sterk rechtsscheve


45

(dwz uitgesmeerd naar hogere waarden toe) distributie zitten . Het hoge aantal keer “0 requests per 5 min” is te wijten aan het down zijn van de server (zie daarvoor bvb. naar Figuur 4.14)

Figuur 4.17 : histogram van het aantal requests per 5 min van de NASA WWW server

Tabel 4.11 : verdere statistieken van het aantal requests per 5 min van de NASA WWW server STATISTIEKEN van het aantal requests per 5 min : LOCATIEMATEN : Gewoon gemiddelde : 188.5805 Geometrisch gemiddelde : 0 Mediaan : 162 Gemiddelde met uitsluiting van de 25% outliers (aan beide uiteinden) : 167.0798 DISPERSIEMATEN : Standaardafwijking : 135.9677 Bereik (=max-min): 1449 IQR (=interquartile range) (25%...75%): 172

4.4.4

Speciaal : Atlantis firewall

De Atlantis firewall (de firewall van de vakgroep Breedbandcommunicatie van de faculteit FTWE (aan de RUG)) houdt ook access logs bij : voor elke uitgaande request van het lokaal gebruikersnetwerk wordt er een regel in deze log file geschreven. Deze logfile is dus verschillend tov van de vorige in de zin dat het meer model staat voor de trafiek gegenereerd door een gebruikersgroep, dan door de trafiek die behandeld wordt door een server. De traces starten op 10/08/1999 12:19 en gaan tot 11/03/2000 23:22. M.a.w. ruwweg een 225-tal dagen, 5400-tal uren, 64000-tal blokken van vijf minuten. Tijdens deze periode waren er in totaal 2091770 aantal requests.


46

4.4.4.1 dagverloop

Figuur 4.18 : dagverloop accesslog van de Atlantis firewall We merken op dat : • de grafiek veel regelmatiger is dan ivm de Atlantis web server • de drie grafieken komen vrij goed overeen, ook de middelste grafiek (merk op dat de figuur herschaald werd wegens het optreden van 1 enkele uitschieter en dat deze daarom op het eerste zicht totaal anders lijkt) • dit patroon is zeer grillig en bevat geen trend, wel zit er een cyclische component in (dit is een patroon dat opvalt maar niet eenvoudig te verklaren is (vb. weekpatroon is wel eenvoudig te verklaren, maar een economisch conjunctuur patroon is dat niet)) Enkele statistieken van de 1e grafiek van de figuur : Tabel 4.12 : statistieken van het aantal requests per dag bij de Atlantis firewall STATISTIEKEN van het aantal requests per dag : LOCATIEMATEN : Gewoon gemiddelde : 9296.7556 Geometrisch gemiddelde : 7731.3766 Mediaan : 9548 Gemiddelde met uitsluiting van de 12.5% outliers (aan beide uiteinden) : 9180.0473 DISPERSIEMATEN : Standaardafwijking : 4782.1246 Bereik (=max-min): 20870 IQR (=interquartile range) (25%...75%): 7642.5

4.4.4.2 uurverloop Hieronder nog eens analoge figuren :


47

Figuur 4.19 : uurverloop accesslog van de Atlantis firewall

Figuur 4.20 : boxplot en histogram van het aantal requests per uur van de Altantis firewall accesslog


48

Figuur 4.21 : verloop van het gemiddelde van het aantal requests per uur van de Altantis firewall accesslog over de alle dagen

Tabel 4.13 : statistieken van het aantal requests per uur bij de Atlantis firewall STATISTIEKEN van het aantal requests per uur : LOCATIEMATEN : Gewoon gemiddelde : 388.8048 Mediaan : 135 Gemiddelde met uitsluiting van de 12.5% outliers (aan beide uiteinden) : 230.2423 DISPERSIEMATEN : Standaardafwijking : 525.3176 Bereik (=max-min): 5260 IQR (=interquartile range) (25%...75%): 605

4.4.4.3 verloop per blokje van vijf minuten Tabel 4.14 : statistieken van het aantal requests per 5 min bij de Atlantis firewall STATISTIEKEN van het aantal requests per 5 min : LOCATIEMATEN : Gewoon gemiddelde : 32.4054 Geometrisch gemiddelde : 0 Mediaan : 3 Gemiddelde met uitsluiting van de 25% outliers (aan beide uiteinden) : 5.0788 DISPERSIEMATEN : Standaardafwijking : 61.3294 Bereik (=max-min): 1865 IQR (=interquartile range) (25%...75%): 40


49

Figuur 4.22 : verloop met een resolutie van 5 min over een 3-tal dagen van de access log van de Atlantis firewall

Figuur 4.23 : meer gedetailleerde weergave van het verloop met een resolutie van 5 min over een 3-tal dagen van de access log van de Atlantis firewall


50

Figuur 4.24 : histogram van het aantal requests per 5 min van de access log van de Atlantis firewall

4.4.5

WWW server van de University of Calgary (CS Department)

We voegen hier ook nog de traces van de University of Calgary Department of Computer Science WWW server in Canada. De traces starten op 24/10/1994 en gaan tot 11/10/1995. M.a.w. een 353-tal dagen, 8000-tal uren of 100000-tal blokken van vijf minuten. Tijdens deze periode waren er in totaal 726739 aantal requests.

4.4.5.1 dagverloop

Figuur 4.25 : dagverloop accesslog van de WWW server van de University of Calgary

Tabel 4.15 : statistieken van het aantal requests per dag bij de WWW server van de University of Calgary STATISTIEKEN van het aantal requests per dag : © Adelbert Groebbens

51

LOCATIEMATEN : Gewoon gemiddelde : 1887.0737 Geometrisch gemiddelde : 1615.4582 Mediaan : 1728 Gemiddelde met uitsluiting van de 12.5% outliers (aan beide uiteinden) : 1774.2528 DISPERSIEMATEN : Standaardafwijking : 1012.6645 Bereik (=max-min): 6185 IQR (=interquartile range) (25%...75%): 1105.25

4.4.6

WWW server van de University of Saskatchewan

Tenslotte ook nog de traces van de University of Saskatchewan WWW server in Saskatoon (Canada). De traces starten op 1/6/1995 23:59 en gaan tot 31/12/1995. M.a.w. een 200-tal dagen, 5000-tal uren of 50000-tal blokken van vijf minuten. Tijdens deze periode waren er in totaal 2408625 aantal requests.

4.4.6.1 dagverloop

Figuur 4.26 : dagverloop accesslog van de WWW server van de University of Saskatchewan Merk op dit is de eerste figuur waarop er trend te merken is over de periode van een 200-tal dagen. Tabel 4.16 : statistieken van het aantal requests per dag bij de WWW server van de University of Saskatchewan STATISTIEKEN van het aantal requests per dag : LOCATIEMATEN : Gewoon gemiddelde : 10958.6262 Geometrisch gemiddelde : 10138.6727 Mediaan : 9899.5 Gemiddelde met uitsluiting van de 12.5% outliers (aan beide uiteinden) : 10844.4562 DISPERSIEMATEN : Standaardafwijking : 4170.4067 Bereik (=max-min): 16765 © Adelbert Groebbens

52

IQR (=interquartile range) (25%...75%): 6711

4.5 Implementatie van de trafiekgenerator Logfiles hebben het voordeel dat ze realistische representatie van de belasting van een webserver vormen (want in realiteit gemeten), maar het nadeel dat eens ze gemeten zijn geworden, ze niet meer veranderen. Bovendien waren logfiles van webservers zoals reeds vermeld niet ideaal om de belasting voor te stellen : bvb. enkel de requests die bediend zijn geworden, worden bijgehouden in zo’n logfile. (zie ook 6.1.1) Omwille daarvan hebben we er ook voor gekozen om zelf een trafiek generator te bouwen. Deze simuleert het totale aantal requests dat in een webserver behandeld worden per tijdsblokje (van bvb. 5 minuten).

4.5.1

Elementen in onze trafiek generator

We hebben ons geïnspireerd op de figuren hierboven (deel 0), meerbepaald : • Figuur 4.16 : dagverloop bevat typsiche dag-nacht schommeling, we nemen voor de eenvoud iets sinusoïdaal • Figuur 4.9 : het uurverloop van de trafiek over een 2-tal weken blijkt tijdens de weekends globaal minder druk te zijn, we nemen een factor 1+e voor elke dag van de week (met e=e(dag)) als model • Figuur 4.17 : het totale aantal requests tijdens een blokje van 5 minuten blijk een sterk rechtsscheve distributie te zijn, we nemen de lognormale verdeling als model Aldus zijn de volgende parameters instelbaar in onze generator : • weekpattern : weekpatroon waarvan enkel de relatieve verschillen tellen • een dagpatroon dat sinusoïdaal is met gemiddelde 1, hiervan kan scale ingesteld worden, dwz hoeveel keer piek meer is dan dal en het peakhour, dit geeft het uur van de dag aan dat met de piek overeenkomt (behoort dus tot 0,1,..,23) • een globale lineaire stijging over de ganse periode, bepaald door lin_inc_per_month die de totale relatieve lineaire toename (eindwaarde tov startwaarde) per maand (30 dagen) voorstelt en het startniveau, dit is het aantal requests per 5 min waar we op de 1e dag rond schommelen • frac_rand geeft aan hoeveel percent van de trafiekwaarde het gevolg is van een random component (meerbepaald wordt een fractie van de oorspronkelijk trafiekwaarde vervangen door een lognormaal verdeelde waarde met gemiddelde de absolute grootte van die fractie) • mu_vs_sigma geeft aan hoe groot het gemiddelde van de lognormale verdeling tov standaardafwijking is à maw hoe groter deze waarde, hoe minder variatie de distributie vertoont Dit alles is geïmplementeerd in de volgende Matlab functie : • tgen.m Deze eenvoudige random generator is slechts een eerste stap in het maken van een parametercontroleerbare, betekenisvolle generator die het verloop van de belasting van een webserver over de tijd weergeeft. Mogelijke uitbreidingen zijn : • random effecten in weekpatroon creëren • random effecten in dagpatroon creëren


53

• • • • •

onderzoeken in welke mate en hoe er correlatie in het model wordt gestopt (bvb. als er 100 gebruikers zijn die een of andere (video of audio) stream afhalen zijn er dat 5 minuten later meestal ook nog een 100-tal) onderzoeken hoe en waarom self-similarity eigenschappen (etc.) best toegevoegd worden andere soorten patronen en trends incorporeren gebruik maken van een de principes achter echte “web workload generator” of benchmarks zoals SPECweb96 ...

Het liefst zouden we een sterk parametriseerbare generator wensen te hebben, die indien de juiste parameters ingegeven worden (zoals bvb. filesizedistributie op web server, filesizedistributie van de requests, verloop van aantal gebruikers over de tijd, inkomende en uitgaande bandbreedtemogelijkheden, aantal CPU’s en “performantie” van CPU’s, aantal harde schijven en performantie van opslagsysteem,....) een realistisch belastingsverloop (vb. aantal requests die per seconden bediend worden) geeft van de webserver (wat eventueel getoetst zou kunnen worden aan de hand van metingen van de echte workload (belasting) van de webserver). Andere uitbreidingen zijn : het effect van meerdere webservers, caches, mirrors,... en hun samenwerking (load balancing, netwerktopologie,...) bekijken. Bovendien hoeft het geheel niet beperkt te blijven tot WWW servers, maar kan het uitgebreid worden naar de bezetting van modemgateways (of andere resources), naar mailservers, naar proxyservers en mirrors, ...

4.5.2

Voorbeeld, statistieken en vergelijking met access logs

We geven enkele outputs van onze generator plus analoge statistieken zoals bij de acces logs om te kunnen vergelijken. Deze werden gegeneerd door : pa_tgen_f.m De in onze generator ingestelde parameterwaarden zijn : • weekpattern = [1 1 1 0.9 1 0.8 0.65]; • scale = 4; • peakhour = 15; • lin_inc_per_month = 0.3; • startniveau = 100; • frac_rand = 60; • mu_vs_sigma = 2; We geven hier eerst het verloop over 1 dag, zowel als een gewone plot (zie Figuur 4.27), als in een barplot, omdat deze laatste een ander beeld oproept. De figuren hebben in de abscis het nummer van het blokje van 5 minuten en in de ordinaat bvb. het totaal aantal requests tijdens deze 5 minuten.

Figuur 4.27 : verloop over 1 dag (288 samples van 5 min) van de eigen trafiekgenerator


54

Figuur 4.28 : barplot van het verloop over 1 dag (288 samples van 5 min) van de eigen trafiekgenerator Vervolgens werd een verloop over een 60 dagen gegenereerd. We bekwamen de volgende statistieken : Tabel 4.17 : statistieken van het aantal requests per 5 min bij de eigen generator STATISTIEKEN van het aantal requests per 5 min : LOCATIEMATEN : Gewoon gemiddelde : 118.2855 Geometrisch gemiddelde : 103.4489 Mediaan : 111.1879 Gemiddelde met uitsluiting van de 25% outliers (aan beide uiteinden) : 111.5325 DISPERSIEMATEN : Standaardafwijking : 58.7013 Bereik (=max-min): 347.629 IQR (=interquartile range) (25%...75%): 94.2229

Hieronder het verloop van een 3-tal dagen uit deze 60 dagen, dan het histogram van het aantal requests per 5 min. We merken hier dat de verdeling toch wel anders is dan we gehoopt hadden : de distributie is niet zodanig uitgesmeerd, een van de redenen is dat we een lineair stijgend verloop hebben en dat we dus een som van verschillende lognormale verdelingen bekomen met een stijgend gemiddelde. Desalnietemin zullen we de trafiekgenerator later in het deel over capaciteitsexpansie (zie 6.3) toch gebruiken


55

Figuur 4.29 : verloop over over een 3-tal dagen van de eigen trafiekgenerator

Figuur 4.30 : histogram van het aantal requests per 5 min van de eigen trafiekgenerator In de volgende figuur (Figuur 4.31) tonen we het verloop van het gemiddelde aantal request per 5 minuten (na verwijdering van de outliers). We herkennen de lineaire trend en het weekpatroon.

Figuur 4.31 : verloop van het gemiddelde aantal request per 5 min na verwijdering van de outliers over een 60 tal dagen (eigen trafiekgenerator) Besluit : de generator is verre van ideaal, maar kan als een aanvulling dienen om te kijken wat de effecten zijn in onze latere modellen.


56

5 Forecasting technieken In dit deel bespreken we “forecasting” : het voorspellen van bepaalde grootheden. We geven eerst wat algemene uitleg en achtergrondinformatie. Nadien bekijken we verschillende forecasting technieken voor tijdsreeksen en de tijdsreeksmodellen waarop ze toegepast worden. Vervolgens gaan we na hoe de performantie (met betrekking tot de correctheid van de voorspellingen) van zo’n techniek kan bepaald worden. In een laaste onderdeel vergelijken we de technieken die we geïmplementeerd hebben en passen deze toe op eenzelfde voorbeeld. De meeste informatie in dit deel is afkomstig van [1] en [2].

5.1 Achtergrond informatie 5.1.1

Basisconcepten

Forecasting is het voorspellen van bepaalde grootheden (bvb. e-mail-trafiek kan groeien in 3 dimensies : aantal gebruikers, aantal berichten, grootte van de berichten). Workload forecasting is het voorspellen van de belasting van een systeem (bvb. het aantal requests dat een web server te verkrijgen krijgen per tijdseenheid, bvb. het bandbreedteverbruik van een link,...) Er zijn verschillende invalshoeken mogelijk om een grootheid te voorspellen : • ernaar raden op een weloverwogen manier • forecasting op basis van vroegere waarden (“historical data”) • forecasting op basis van veranderingen in “business processes” in als gevolg van externe factoren (bvb. workload groeit of krimpt, afhankelijk van de toekomst van een bedrijf, van de evolutie van de technologie, ...) We kunnen de invalshoeken eigenlijk verdelen in 2 methoden : • KWANTITATIEF : • dwz de voorspellingen zijn gebaseerd op data uit het verleden • nadeel : wat indien de technologie/situatie snel verandert zodat waarden uit het verleden in feite verouderd zijn ? à een oplossing hiervoor is kwalitatieve forecasting • KWALITATIEF : • bvb. gebaseerd op intuïtie, meningen van experten, analogieën of andere relevante informatie • vb. Delphi technique : dit is in feite niets anders dan een groep van experten een consensus laten uitdenken Wij baseren ons natuurlijk op kwantitatieve methoden. De kwantitatieve methoden zouden we eventueel ook in 2 modes kunnen onderverdelen : • CAUSAL MODE : voorspellend verband opzetten tussen een afhankelijke (vb. moeilijk te bepalen) en een onafhankelijke variabele (vb. eenvoudig te verkijgen), om dan in geval van een nieuwe waarde van de onafhankelijke variabele de afhankelijke variabele te kunnen bepalen (=voorspelling ervan) • TREND MODE : voorspelling in de tijd gebaseerd op de evolutie van de historische (=voorbije) data We maken enkel gebruik van de historische data, we noemen dit ook voorspellen van time series (tijdsverloop van een grootheid). Het is belangrijk in te zien dat een time serie in feite als een samenstelling van componenten moet bekeken worden. De meest gebruikte componenten van een TIME SERIE zijn : • (long-term) trend : dwz de grove lijn die het tijdsverloop volgt, meestal gemodelleerd als linear, kwadratisch of exponentieel • stationary : in het geval er geen trend is, noemen we de tijdsreeks “stationary”


57

• • •

seasonal variations : dwz stijgen of dalen gebaseerd op kalender, uur van de dag, klimaat, … dus met een regelmatig patroon, meestal gemodelleerd als een multiplicatieve factoren of additieve constanten bovenop de trend cyclical variation : tijdelijk stijgen of dalen op basis van een niet eenvoudig te verklaren (of voorspellen) patroon, moeilijk te modelleren of te voorspellen random effecten (random errors) : rest van de verdere variaties die we als onverklaarbaar of onbeduidend modelleren

Voor voorbeelden of meer duidelijkheid verwijzen we naar 5.4. Nu kunnen we het doel van “time series forecasting” begrijpen : zo nauwkeurig als mogelijk de componenten van de time serie te identificeren. Mogelijke technieken : linear regression, moving average, exponential smoothing,... (zie verder)

5.1.2

Stappen en strategieën bij forecasting

Forecasting vereist een aantal te nemen acties en keuzen. Een algemeen schema van te volgen stappen in “forecasting process” zijn : 1. bepalen van de forecasting objectieven, bvb. : • over welke periode moet de forecasting gebeuren ? • wat wordt er met de forecasting gedaan ? • hoe kritisch zijn de beslissingen die op basis van deze forecast gedaan worden ? 2. definitie van kwalitatieve forecasting , bvb. : • de kwalitatieve informatie die invloed kan hebben (vb. gebruik van Java in de volgende 5 jaar kan trafiek op website beïnvloeden) 3. analyse van historische data • bepalen van de bronnen die de data zullen verschaffen • reeds inschatten van de toekomst 4. selectie van een forecasting techniek, op basis van bvb. : • de periode waarover voorspeld moet worden • de beschikbaarheid van de historische data • het pattern in de historische data, oa : TREND, STATIONARY, CYCLICAL, SEASONAL • betrouwbaarheid en beschikbaarheid van de data • de gewenste nauwkeurigheid 5. workload forecasting • eerst de geselecteerde kwantitatieve techniek toepassen • analyse en validatie van de resultaten (en van de techniek) • combinatie met de resultaten van kwalitatieve forecasting Het grote probleem ivm workload forecasting is unpredictable demand = workload die op random tijdstippen verschijnt en de volledige systeem capaciteit in beslag neemt (vb. bij beurs crash gaat iedereen de stock market web site overrompelen, …) We tonen nog een figuur (Figuur 5.1) die de tot nog toe aangehaalde zaken schematisch herhaalt.


58

media, experts, consultants, etc

systems

collecting information

Ÿ Ÿ Ÿ

historical data

quantitative forecasting techniques

expert opinions judgement technological forecasting

qualitative forecasting methods

forecast workloads

Figuur 5.1 : schema van een mogelijke forecasting strategie

5.2 Technieken en modellen We bekijken nu enkele modellen voor tijdsreeksen en de forecasting technieken die daarbij het best passen. De te volgen procedure is : 1. verzamel data 2. maak een grafiek 3. beslis op basis hiervan welk model te gebruiken 4. test met statistische methoden of het model OK is 5. keuze van een bij het model passende forecasting methode (ook keuze van de parameters hierbij) 6. pas de methode toe In de volgende paragrafen wordt steeds het model gegeven, manieren om te testen of het model ok is en mogelijke forecasting technieken die passen bij het model.

5.2.1 • • •

“stationary forecasting models” model voor een stationaire tijdreeks : y (t ) := β0 + ε(t ) met de ε(t)' s : onafhankelijk verdeelde toevalsgrootheden met gemiddelde nul waarbij β0 in feite ook mag veranderen, maar wel op een tijdschaal die veel groter is dan die van de opeenvolgende ε(t)' s

5.2.1.1 testen of model wel voldoet : We moeten nagaan of er in de gegeven data geen trend, geen seasonality en geen cyclische componenten aanwezig zijn. 1.

test of er geen trend aanwezig is : • via een hypothesetest

o

y (t ) := β0 + β1 ⋅ t + ε(t ) hypothese : H 0: : β1 = 0 we verwerpen H0 met significantie α als p < α met p = p-value van de test (=

o

standaardwaarde die in de meeste pakketten (MS Excel,...) teruggegeven wordt als deel van het resultaat) betekenis : α is de kans dat we H0 verkeerdelijk verwerpen

o o

stel linear model :


59

o

•

nadeel : deze werkwijze veronderstelt wel dat de

ε(t)' s onafhankelijk verdeelde

toevalsgrootheden met gemiddelde nul en allen met ZELFDE variantie (zoniet zouden we het model kunnen verwerpen ook al is het correct) via Daniel’s test (zie voor volledige informatie [2]) o rangschik de data van klein naar groot : dit zorgt ervoor dat y(10) bvb. op rang 1 (ipv 10) komt te staan (newrang(y(10)) is dus 1) o

bereken

rs = 1 −

6 ⋅ ∑ d t2

n ⋅ (n 2 −1)

met

d t = t − newrang ( y( t )) en n=aantal

datasamples rs ligt in [-1,1] principe : |rs | groot duidt op de aanwezigheid van trend (rs > 0 : stijgende trend , rs < 0 : dalende trend) o statistische aanpak : er bestaan testtabellen, etc.. o vanaf n groot : andere formule (zie [2]) via autocorrelatie (zie ook bij 2. hieronder) : o autocorrelatie tussen opeenvolgende tijdstippen (dit wordt lag=1 genoemd), geeft trend aan (vb. stijgende trend) o o

•

2.

test of geen er seasonality aanwezig is : • via berekening van de autocorrelatie tussen tijdstippen met k eenheden tijdsverschil : we noemen ρk = autocorrelation coefficient of lag k vb. k=1 : autocorrelatie tussen opeenvolgende tijdstippen vb. k=7 en tijdsresolutie van de reeks = 1 dag : autocorrelatie tussen dezelfde weekdagen (dwz vast herhalend patroon per week, en dus overeenkomst tussen dezelfde dagen in een week) o vb. k=12 en tijdsresolutie van de reeks = 1 maand: autocorrelatie tussen zelfde maanden is te schatten uit de data via : rk = sample autocorrelation coefficient of lag k (voor o o

3.

•

ρk

•

formules zie [2]) rk in functie van k noemen we de the sample autocorrelation function

test of er cyclical components aanwezig zijn : • meestal enkel door de grafiek te onderzoeken, moeilijk om automatisch te detecteren

5.2.1.2 forecasting technieken voor “stationary models” : •

weighted moving average method : n

o

yˆ t +1 = ∑ wi ⋅ y t −i +1 met i =1

n

∑w

i

= 1 en w1 ≥ w2 ≥ ... ≥ wn

i =1

wi ’s (=de gewichten) zijn gekozen parameters

o

de n (=aantal perioden) en

o

let op : kijkend naar het model, beseffen we dat in het geval we enkel tot en met tijdstip t data voorhanden hebben, de voorspelling voor het tijdstip t+1 ( yˆ t +1 ), ook de meest zinvolle voorspelling voor t+2,t+3, etc. is, als we dan nieuwe data binnenkrijgen (bvb. yt +1 ) (dan kan voorspelling herzien worden)

•

deze methode blijkt ook geschikt voor stationary time series die lichtjes autocorrelatie vertonen speciaal geval : the last period technique : yˆ t +1 = yt

•

speciaal geval : moving average methode :

o

o o •

wi =1/n

maw de voorspelde waarde voor de volgende periode is het gemiddelde van vorige observaties eigenschap : moving average met weinig perioden (kleine n) reageert sneller op de data dan indien n groter zou zijn

speciaal geval : exponential smoothing


60

o o

doel : rekening houden met alle voorbije waarden en deze toch niet allemaal hoeven bij te houden (opslag) of ermee te rekenen yˆ t +1 = α⋅ yt + (1 − α) ⋅ yˆ t = α⋅ ( y t − yˆ t ) + yˆ t met α tussen 0 en 1 gelegen o

expliciet uitschrijven van deze formule komt overeen met

yˆ t +1 is een geometrisch

gewogen som van de vorige yi ’s (dus n wordt ∞ in de formule voor de weighted moving average method), meerbepaald zijn de coefficiëten α , o

α⋅ (1 − α) , α⋅ (1 − α) 2 , … keuze van initiële schatting (= yˆ1 ) : dit kan bvb. het gemiddelde van de eerste i waarden

zijn (maar speelt weinig rol) (en dan vanaf yi +1 proberen te voorspellen) interpretatie α : § indien groot : veel belang hechten aan de huidig waarde à snelle verandering worden goed opgevolgd § indien klein : juist andersom o deze methode is eveneens geschikt voor stationary time series die lichtjes autocorrelatie vertonen opmerking : verband moving average en exponential smoothing : stel in beide methoden de gewogen som (met coefficienten net zoals in reeks van de forecast formule) van de leeftijd (dwz 1 voor vorige de periode, 2 voor de periode daarvoor etc) gelijk, dan geldt n = 2/ α –1 , dit kan een richtlijn zijn voor keuze van α (vb. α =0.1 bij exponential smoothing komt overeen met n = 19 bij weighted moving average) opsomming van enkele aspecten waarmee rekening te houden is bij statonary time series : o de mate van autocorrelatie o de mate van verschuivingen in de andere gemiddelde waarde β0 o

•

•

o o

de mate waarin we wensen dat de voorspelling de data volgt (responsiveness, tracking) de hoeveelheid data die nodig is om de voorspelling te doen (cf. exponentiële smoothing versus moving average methode)

5.2.2 “forecasting time series that exhibit linear trend” • model voor een tijdreeks die lineaire trend vertoont : y (t ) := β0 + β1 ⋅ t + ε(t ) • met de ε(t)' s : random errors, dit zijn onafhankelijk verdeelde toevalsgrootheden met •

gemiddelde nul waarbij β0 en

β1 in feite ook nog mogen veranderen, maar wel op een tijdschaal die veel groter is dan die van de ε(t)' s

5.2.2.1 testen of model wel voldoet : Test of er lineaire trend aanwezig is : • via een hypothesetest o o o •

y (t ) := β0 + β1 ⋅ t + ε(t ) hypothese : H 0: : β1 = 0 we verwerpen weerom H0 met significantie α als p < α met p = p-value van de test ( α is de kans dat we H0 verkeerdelijk verwerpen) stel linear model :

verdere informatie over al dan niet lineaire trend is te halen uit de ANOVA -tabel en R-squarewaarde (dit zijn weerom standaard begrippen in de statistiek, cf. MS Excel Summary Output bij lineaire regressie)

5.2.2.2 forecasting technieken voor lineaire trend modellen : •

lineaire regressie (voor gedetailleerdere uitleg zie [3]): o we kunnen regressie methoden toepassen om de waarde van de dependent variabele (=bvb. hit count) te voorspellen aan de hand van de waarden van de independent variabelen (=bvb. tijd). De meeste regressiemodellen stellen een lineair verband (omdat dit eenvoudig is). o de coefficienten van de lineaire vergelijking bepalen via de lineaire regressie formules


61

o o •

daarna het te voorspellen tijdstip invullen in de independent variabelen eigenschap van lineaire regressie : minimaliseert MSE (= mean square error, zie later)

single exponential smoothing with linear trend : (ook wel Holt’s linear exponential smoothing technique genoemd) : o de voorspelling op basis van yt , yt −1 ,... voor yt + k met k > 1 wordt bepaald via volgende formules :

o

yˆ t +k = Lˆ t + k ⋅ Tˆt met Lˆt = α⋅ yt + (1 − α) ⋅ ( Lˆt −1 + Tˆt −1 )

o

en

o

o

Tˆt = γ ⋅ ( Lˆ t − Lˆ t −1 ) + (1 − γ ) ⋅ Tˆt −1

interpretatie : herschrijven we de 2e formule als :

Lˆt = α⋅ yt + (1 − α) ⋅ yˆ t dan zien we

Lˆt in feite overeenkomt met de exponential smoothing techniek (en te bekijken valt als een schatting voor het niveau (level) van de datawaarden, dat Tˆt een indicatie is voor de mate van verandering van level, maw de helling (slope), en dat α en γ de mate bepalen waarin belang gehecht wordt aan nieuwe informatie en bepaalt of we Lˆt en Tˆt dat

o

wensen te behouden of eerder wensen te veranderen voordeel van deze methode ivm lineaire regressie : het vergt minder data om bij te houden (opslag)

o

initiële keuzen :

o

α , γ parameters (0<...<1) en bvb. voor Lˆ 2 = y 2 , Tˆ2 = y2 − y1 (ter herinnering uit 1e formule volgt immers yˆ 3 = Lˆ2 + Tˆ2 ) opmerking ivm α en γ : er geldt algemeen hoe groter deze parameters (0<...<1), hoe groter de “tracking speed for changes in value”

•

er bestaat ook nog een variant waar 2 keer exponential smoothing wordt gebruikt : double exponential smoothing (with linear trend), zie hiervoor naar Appendix A : andere formules ivm forecasting.

5.2.3 “time series with trend, seasonal and cyclical variation : multiplicatief model” • • •

model : y(t) = T(t)*C(t)*S(t)*e(t) met E[e(t)]=1 met de e(t)’s : random errors met gemiddelde 1 met T(t) de trend component, C(t) de cyclische component en S(t) de seizoenscomponent (ze worden de “seasonal factors” genoemd)

5.2.3.1 testen of model wel voldoet : •

dit model is geschikt (ivm additief model, zie later) indien de seasonal en cyclical variations proportioneel zijn met de trend waarde (verderde interpretatie wordt later nog verduidelijkt)

5.2.3.2 forecasting technieken : •

methode CLASSICAL DECOMPOSITION : o het doel is de verschillende componenten stapsgewijze te isoleren o stap 1 : isoleren van T(t)*C(t) uit y(t) = T(t)*C(t)*S(t)*e(t) § dit gebeurt door middel van een moving average over het geschikt aantal perioden (nl. de duur van een “season”) : vb. stel season = 1 jaar = 12 maanden (periode = 1 maand) : gebruik de moving average waarde van bvb. periode 1 tem 12, als waarde van T(t)*C(t) voor de (1+12)/2 = 6.5’e maand (en dit procédé dus laten lopen (moving) over alle data)


62

§ § § §

maak daarna uit waarde (bvb.) voor de 6.5’e maand en voor 7.5’e maand, de waarde voor de 6e maand, namelijk als het gemiddelde (=”gecentreerde moving averages”) van beiden, herhaal dit uiteraard over alle data deze waarde vormt een schatting voor T(t)*C(t) merk op dat zowel S(t) als e(t), een gemiddelde 1 hebben (S(t) in feite bij definitie ervan, namelijk S(t) zorgt voor schommelingen rond de trend) S(t) en e(t) zijn dus te schrijven als “1 + een kleine rest”, deze kleine rest valt weg door de sommatie (gebruikt bij het uitmiddelen) (ook al werden ze vermenigvuldigd met de trend waarde) (zie Figuur 5.2)

y(t)

... trend

uitmiddelen over een season-lengte elimineert min of meer S(t)*e(t)

t Figuur 5.2 : eliminatie van seasonal en random components o

o

o

o

o

o

stap 2 : bepalen van S(t)*e(t) § deel de in de vorige stap bekomen schattingen weg uit y(t), zo wordt S(t)*e(t) overgehouden stap 3 : isoleren van seasonal factors uit S(t)*e(t) § neem het gemiddelde van alle S(t)*e(t) die bij een bepaalde periode van een “season“ behoren (vb. alle S(t)*e(t) behorende bij de maand januari), dit elimineert e(t) § opmerking : soms kan geometrische gemiddelde hierbij beter zijn (< rekenkundige gemiddelde) § deze waarde worden nadien nog eens genormeerd zodat zij gemiddeld 1 zijn (cf. Figuur 5.2) § zo bekomen we voor elke periode van een season : een seasonal factor (bvb. we bekomen dus 12 seasonal factors in geval we met maanden als periode werken (en een seizoen dus in feite een jaar duurt)) stap 4 : “deseasonalize” § deel y(t) door de passende seasonal factor § eventueel kan na deze stap reeds een grafiek gemaakt worden om te zien of de gemaakte veronderstellingen kloppen en het model min of meer in orde is stap 5 : in deze laatste grafiek : identificeren van de trend component § vb. lineaire trend à dmv van regressieanalyse, ... § dit geeft dan T(t) § zelfs in geval van geen trend aanwezig (dit valt ook na te gaan (zie vroeger)), is het hier mogelijk om een methode voor stationary data toe te passen § we weten hier dus reeds : hoe we T(t) moeten voorspellen stap 6 : cyclische component identificeren § deel gedeseasonaliseerde waarden (dit zijn C(t)*T(t)*e(t) (=deze van de gemaakte grafiek) : door T(t), dit geeft C(t)*e(t) § filter e(t) weg, door bvb. uitmiddelen (moving average), dit geeft dan C(t) (merk op C(t) = 1 (of althans toch ongeveer een constante) in geval van geen echte cyclische variaties) stap 7 : forecasting uitvoeren


63

§ § § •

we hebben nu achtereenvolgens bepaald : S(t) (als een periodieke herhalen van seasonal factors in feite), T(t) en C(t) we voorspellen T(t+1) (met de gepaste methode afhankelijk van de trend zie hierboven en zie vroeger) we passen T(t+1) aan met de gepaste seasonal factor en nadien ook met C(t)

Holt-Winters Multiplicative Algorithm : • dit is het algoritme dat we later zullen gebruiken omdat het meest geavanceerde van de hier besproken eenvoudige methoden is en bovendien eenvoudiger te implementeren ivm de classical decomposition methode • vergelijkingen : o de voorspelling op basis van yt , yt −1 ,... voor yt + k met k > 1 wordt bepaald via volgende formules :

o o o

o

yˆ t +k = ( Lˆt + k ⋅ Tˆt ) ⋅ Sˆ t + k −c voor k=1,2,...,c yˆ t +k = ( Lˆt + k ⋅ Tˆt ) ⋅ Sˆ t + k − 2⋅c voor k=c+1,c+2,...,2c etc. met c = de lengte van een seizoen (in aantal datawaarden) met Lˆt

= α⋅

yt + (1 − α) ⋅ ( Lˆ t −1 + Tˆt −1 ) ˆ S t −c

o o

Tˆt = β ⋅ ( Lˆt − Lˆt −1 ) + (1 − β) ⋅ Tˆt −1 yt en Sˆt = γ ⋅ + (1 − γ ) ⋅ Sˆt −c Lˆt en

α , β en γ tussen 0 en 1

o

weerom liggen de “smoothing parameters”

o

interpretatie : herschrijven we de formule voor

y yˆ Lˆt als Lˆt = α⋅ t + (1 − α) ⋅ t : Sˆ Sˆ t −c

t −c

Lˆt in feite overeenkomt met de exponential smoothing techniek maar waarbij de reeks reeds “gedeseasonaliseerd” is. De formule voor Tˆt is zoals vroeger en we hebben eveneens een “update”-vergelijking voor Sˆ , waarbij speciaal op te merken dan zien we dat

t

yt en dus zeker niet gebruikt mag worden om yt te voorspellen, daarom wordt er in de voorspellingsformules voor yˆ t + k , gebruik gemaakt de seasonal factor Sˆt −c , dus die van de overeenkomstige periode maar een seizoen valt dat deze steunt op de waarde van

o

eerder. initiële keuzen : § de constanten § §

α , β en γ (die moeten liggen tussen 0 en 1) de seizoensfactoren : Sˆ −( c−1), Sˆ − (c −2 ),..., Sˆ 0 (als we aanemen dat in de data de tijdsindex loopt van 1,2,3,…) vermits we meestal toch in het begin over een reeks datawaarden beschikken kunnen we deze schatten uit de eerste c datawaarden : bvb. deel de eerste c samples door hun gemiddelde en neem de bekomen waarden als de seasonal factors


64

Lˆ 0 kan je ook gelijk aan dit gemiddelde nemen en Tˆ0 kan je nul nemen (speelt

§

niet zoveel rol, na een beginvoorwaarden toch uit)

voldoend

aantal

datawaarden

sterven

deze

5.2.4 “time series with trend, seasonal and cyclical variation : additief model” • • •

model : y(t) = T(t)+C(t)+S(t)+e(t) met de e(t)’s : random errors met gemiddelde 0 met T(t) de trend component, C(t) de cyclische component en S(t) de seizoenscomponent

5.2.4.1 testen of model wel voldoet : •

dit model is geschikt indien de seasonal en cyclical variations onafhankelijk zijn van de trend waarde

5.2.4.2 forecasting technieken : Er bestaan analoge methodes, ze worden verder niet gebruikt (vermits we (meestal) met een proportioneel model zitten in realiteit) en worden dus ook niet uitgebreid besproken : • een analoge CLASSICAL DECOMPOSITION methode • een multiple regression methode : • manier om seasonal factors te implementeren : dummy variabeles o vb. 4 perioden in een seizoen, lineare trend als model : § y (t ) := β0 + β1 ⋅ t + S1 ⋅ x1 + S 2 ⋅ x2 + S 3 ⋅ x3 + ε(t )

•

§ onafhankelijk variabelen t,x1 ,x2 ,x3 § aanduiding van de seizoenen : x1 ,x2 ,x3 : (0,0,0),(0,0,1),(0,1,0),(1,0,0) o de data wordt in een tabel opgeslaan in de vorm van y(t),t,x1 ,x2 ,x3 • hierop kan je dan multiple regressie toepassen, dan bekom je de schattingen b0,b1,S1,S2,S3 voor de parameters uit de formule • validatie van model kan vlot gebeuren uit regressietabel etc. (zie bvb. MS Excel) • forecasting via : vul in de formule t+1 in en de gepaste t,x1 ,x2 ,x3 in er bestaan ook een variant van het Holt-Winters algoritme, zie daarvoor Appendix A : andere formules ivm forecasting.

5.2.5 Andere voorspellingstechnieken en verdere informatie We geven hier nog enkele aanvullingen, andere technieken en we bespreken een kader ivm forecasting technieken (gebaseerd op [9]), om aan te geven dat er talrijke en meer geavanceerde technieken bestaan (oa gebaseerd op expertsystemen).

5.2.5.1 transformeren van modellen (vb. naar modellen met lineaire trend) : Modellen voor lineaire trend zijn niet zo beperkend zoals op het eerste zicht zou lijken. We kunnen er ook andere trends mee modelleren : •

vb. kwadratisch model :

y (t ) := β0 + β1 ⋅ t + β2 ⋅ t 2 + ε(t ) via u(t) = y(t+1) – y(t) naar een

linear model à nadeel e_new(t) is dan niet meer een onafhankelijke reeks van random errors ! •

vb. exponentieel model :

y (t ) := β0 ⋅ β1t ⋅ ε(t ) via u(t) = log(y(t))

Zelfs een stationair model kan meer dan op het eerste zicht mogelijk : • vb. transformeren van een lineair model naar een stationair model : weerom door verschillen te maken à opnieuw : nadeel e_new(t) is dan niet meer een onafhankelijke reeks van random errors

5.2.6

Time series forecasting in een breder kader geplaatst

We geven hier een mogelijke klassering van de verschillende forecastmethodes. Deze klassering is “ The THCMS Methodology” genaamd.


65

Klassering van de FORECASTING ENGINE (=techniek om te voorspellen) : • T = TYPE : o subjective : dwz niet data-gedreven, de gebruikers schatten op basis van de aangeboden informatie (vb. grafiek) de toekomst o objectief : dwz wel data-gedreven, de voorspelling (“baseline forecast”, nl. uitgangspunt dat eventueel verder gecorrigeerd wordt) wordt aangepast als er nieuwe data beschikbaar is à BETER • binnen het type objectief : H = HORSEPOWER (--> mechanisme) o niet-statistische methode : vb. uitmiddelingsformules, focus-formules : eenvoudige rekenformules en regeltjes toegepast op de data o statistische methode : analyseert de data en onderscheidt : overgangsverschijnselen, trends, seasonal components, ... à BETER (zeker nu de rekenkracht ervoor bestaat) • binnen de statistische methoden : C = CLASS o causale methoden : dwz parameters uit het relatie-model tussen onafhankelijke variabelen en de data trachten te vinden (vb. lineaire regressie) § toepassing : • lange termijn voorspelling (“strategic”) • explicatie van het verleden o extrapolatieve methoden (=time series) : volledige gebaseerd op de data à MEESTAL BETER (tenzij onafhankelijke variabelen sterke invloed hebben) • binnen de extrapolatieve methoden : M = number of METHODS o enkelvoudig : dwz slechts één methode gebruiken, dit blijkt enkel geschikt voor zeer korte termijn voorspelling (“operational”) o meervoudig : dwz meerdere methodes gebruiken, deze zijn beter vanaf het moment dat we middellange termijn voorspelling maken (“tactical”) • binnen de meervoudige methoden : S = SELECTION (van één van de methodes) o best-fit : dwz keuze van dat model dat de laagste “forecast error” (= bvb. MAD, MAPE, MSE of (R)MSE, zie later) geeft (en tevens de hoogste “coefficient of determination” (=R^2=R-square, cf. lineaire regressie)), namelijk per model worden de parameters zo gekozen zodat ze de laagste “forecaste error” produceren (optimisatie van de parameters) o expert-system : à BETER § keuze van de methode net zoals een expert (=hier : persoon met grote kennis en vaardigheid in statische forecasting) § bvb. experten doen vaak : • filteren van data • identificeren welke data we gebruiken • bepalen van een groepje methoden, op basis van de trends en cycli in de data à patroonherkenning (!), visuele perceptie van de data • keuze van de beste methode uit dit groepje § samengevat : experten baseren zich op wat de data eigenlijk aan het doen is • als besluit kunnen we stellen : o operational forecasting (dwz korte termijn): statistische, extrapolatieve, eventueel enkelvoudige forecasting toelaatbaar o tactical forecasting (dwz middellange termijn) : statistische, extrapolatieve, meervoudige forecasting, liefst expert system o strategical forecasting (dwz lange termijn) : statistische, causale forecasting

5.3 Performantie-evaluatie methoden Niet elke forecasting techniek scoort even goed. Het is daarom belangrijk maten te hebben die de performantie van een techniek weergeven, wanneer deze toegepast wordt op een reeks datasamples. We bekijken eerst enkele maten en nadien behandelen we optimalisatie van de parameters bij een forecasting techniek.

5.3.1 Evaluatie van de performantie van forecasting technieken : Op basis van de forecast error (=verschil tussen voorspelde waarde en werkelijk bekomen waarde in realiteit) kunnen we de prestatie van een forecasting techniek meten. De werkelijk bekomen waarden © Adelbert Groebbens

66

kunnen we pas gebruiken als de gepaste tijd verstreken is en deze waarden opgemeten zijn. Soms is dit niet mogelijk of niet geschikt. Een alternatief is dat we van de tijdsreeks die we reeds in ons bezit hebben, slechts een eerste fractie ervan gebruiken in onze voorspeller en dat we doen alsof we de volgende fractie nog moeten voorspellen. (maw een gedeelte van de historische data zelf nog eens voorspellen (op basis van nog eerdere historische data) en dan te kijken wat de afwijkingen zijn, om hieruit te oordelen of de forecasting techniek een goeie is) We kunnen zo de voorspelde waarden en de echte waarde van de tijdreeks vergelijken. Hiervoor bestaan er bvb. volgende maten, die we ze zo klein mogelijk wensen : o de MSE = mean squared error = gemiddelde kwadratische fout o de MAD = mean absolute deviation = gemiddelde absolutie fout § de MAD geeft in vergelijking met de MSE minder penalty aan grote afwijkingen o de MAPE = mean absolute percent error = gemiddelde relatieve fout (eventueel in % uitgedrukt) § de MAPE wordt ivm de MSE en de MAD vooral gebruikt indien absolute verschillen minder betekenis hebben, bvb. geval van een sterk dynamisch bereik in de data o de LAD = largest absolute deviation = grootste fout die we tegenkomen § de LAD is nuttig in de gevallen dat we een zekere maximale afwijking vooropstellen (tolereren) Voor formules verwijzen we naar de implementatie in Matlab of naar [2]. De MATLAB files : • lad.m • mad.m • mape.m • mse.m

5.3.2 Optimalisatie van de parameters : De prestatie van een forecasting techniek hangt af van zijn geschiktheid tov van de data , maar ook van de gekozen waarde voor de parameters. (Daarentegen hangt de prestatie weinig af van de beginvoorwaarden (initialisatiewaarden) als de tijdsreeks voldoende lang is.) Het is bvb. mogelijk om de parameters van een forecasting techniek te bepalen die een gegeven “forecast error measure“ minimalizeren, maar deze keuze van parameters hoeft niet noodzakelijk de beste te zijn, bvb. de volgzaamheid (responsiveness, tracking zie vroeger) van de voorspellingen kan ook belangrijk zijn. Voorbeeld : bij single exponential smoothing with l inear trend kan je optimaliseren onder een bepaald criterium (MSE,MAD,...) naar α en γ .

5.4 Implementatie van de technieken en performantieevaluatie methoden, toepassing op een voorbeeld In dit deel bekijken we de prestaties en implementaties van de voorspellingstechnieken. We gebruiken eenzelfde voorbeeld, een fictieve sequentie over een aantal dagen, die gegenereerd werd door het MATLAB script : • fict_dayseq.m Dit scriptje genereert een tijdsreeks met per dag 1 sample en bevat de volgende elementen : • lineaire stijging (trend) • seasonal factors (weekpatroon) • uniforme ruis (random) Deze sequentie werd dan bewaard voor meermaals gebruik in : • ag_dagverloop_thresholdoverschrijding.mat


67

We passen nu enkele van de bekeken forecast technieken toe op deze tijdsreeks en bespreken hun prestatie. Meerbepaald bekijken we : moving average, exponential smoothing, exponential smoothing met lineaire trend en Holt-Winter’s multiplicatieve methode. Normaal gezien zou de Holt-Winter’s multiplicatieve methode het best moeten scoren vermits deze rekening houdt met alle elementen die in de fictieve dagsequentie zitten.

5.4.1 “exponential smoothing” Zie hiervoor naar Figuur 5.3. Als initiële schatting kozen we yˆ1 = 0, deze speelt na een 10-tal dagen nog weinig rol. Voor de waarde van α hebben 0.5 genomen omdat deze juist het midden is tussen de twee uitersten. Zoals reeds gezegd kan α naar een bepaalde criterium geoptimiseerd worden. In de eerste grafiek staat de originele reeks (bvb. betekenis # requests tijdens die dag), in de tweede grafiek staat de originele naast de voorspelde reeks. In de derde grafiek is de relatieve fout uitgezet. Deze is op de plaatsten waarde originele reeks nul was, zeer groot (in feite oneindig groot tenzij voorspelde waarde ook nul, maar we hebben op die plaatsten de originele reeks door een kleine waarde vervangen om zodoende de numerieke problemen te vermijden) . (Bij de HW methode hadden we ook numerieke problemen (nl.delen door nul ivm seasonal factors) moeten wegwerken dmv er een kleine waarde bij te tellen.)

Figuur 5.3 : toepassing van exponential smoothing Om een eerlijke vergelijking te bekomen laten we de eerste 7 dagen (à weekpatroon nodig voor HW multiplicatieve forecasting) buiten beschouwing. We vergelijken dan de originele reeks met de voorspelde reeks. De performantieresultaten worden steeds door volgende MATLAB file berekend : • disp_errors.m MSE, sqrt(MSE) : 14800.0543 , 121.6555 MAD : 111.8181 MAPE, MAPE(%) : 78.7358 , 7874 LAD : 193.2284 © Adelbert Groebbens

68

Deze resultaten werden bekomen door : • expsm.m : algoritme • test_expsm_pres.m : genereren van de figuur

5.4.2 “moving average” Als initiële waarden hebben we in feite de reeks vooraan aangevuld met nullen. We laten het gemiddelde lopen over 3 opeenvolgende waarden (n=3). De eigenschappen blijken goed op die van exponential smoothing te trekken.

Figuur 5.4 : toepassing van moving average De performantieresultaten zijn evenwel overal wat slechter dan bij exponential smoothing : MSE, sqrt(MSE) : 15621.6065 , 124.9864 MAD : 115.7898 MAPE, MAPE(%) : 79.2397 , 7924 LAD : 230.7531 Merk op dat deze performantieresultaten geen algemene betekenis hebben. Het hangt af van de tijdsreeks zelf en van de gekozen parameters. In realiteit kan je dus (aan de hand van een reeds gekend fragment van de tijdsreeks) best volgende strategie gebruiken : neem verschillende voorspellingsmethoden, pas ze allemaal toe en dit ook voor verschillende parameterwaarden (bvb. α in stappen van 0.1) en kies dan diegene die het beste scoort voor een gekozen criterium, neem dan deze techniek inclusief parameterwaarden om de verdere voorspellingen te maken. Dit komt overeen met de “multiple methods” karakterisatie van 5.2.6. De resultaten werden bekomen door : • ma.m : algoritme • test_ma_pres.m : genereren van de figuur


69

5.4.3 “exponential smoothing with linear trend” Volgende figuur werd bekomen dmv : • expsm_lin.m : algoritme • test_expsm_lin_pres.m : genereren van de figuur

Figuur 5.5 : toepassing van exponential smoothing met lineaire trend Merk op dat ondanks het feit dat we ivm exponential smoothing een bijkomende parameter in het model opnemen (namelijk de “smoothing” van de trend) we op alle criteria slechtere performantieresultaten bekomen : MSE, sqrt(MSE) : 21004.2102 , 144.9283 MAD : 127.5705 MAPE, MAPE(%) : 80.0607 , 8006 LAD : 248.3127 Noteer ook dat we in feite bij alle 3 vorige voorbeelden duidelijk een soort naijling van de voorspellingsreeks tov de originele reeks kunnen bemerken. Bij exponentiële smoothing met lineaire trend hebben we eigenlijk nog wel andere keuzemogelijkheden voor de initiële voorwaarden. Deze kunnen soms wel belangrijk zijn omdat een nieuwe voorspelling steeds nog wat afhangt van alle vorige voorspellingen bij smoothing methoden. Voor details van deze voorwaarden wordt naar de (volgende) MATLAB files verwezen. Een variant is : • expsm_lin_ii.m : algoritme • test_expsm_lin_ii_pres.m : genereren van de figuur Met als resultaten : MSE, sqrt(MSE) : 21206.1503 , 145.6233 © Adelbert Groebbens

70

MAD : 128.2248 MAPE, MAPE(%) : 80.604 , 8060 LAD : 247.7387 Nog een variant is : • expsm_lin_iii.m : algoritme • test_expsm_lin_iii_pres.m : genereren van de figuur Met als resultaten : MSE, sqrt(MSE) : 21206.1503 , 145.6233 MAD : 128.2248 MAPE, MAPE(%) : 80.604 , 8060 LAD : 247.7387 Dus dezelfde als bij expsm_lin_ii.m (alhoewel andere beginvoorwaarden !) Nog een variant is : • expsm_lin_iv.m : algoritme • test_expsm_lin_iv_pres.m : genereren van de figuur Met als resultaten : MSE, sqrt(MSE) : 21206.3722 , 145.6241 MAD : 128.2141 MAPE, MAPE(%) : 80.562 , 8056 LAD : 247.8531

5.4.4 “exponential smoothing with linear trend and seasonal factors (Holt De meest geavanceerd methode in de reeks is de HW multiplicatieve methode. De parameters a,b en g werden allen gelijk aan 0.5 gekozen, dit ligt juist tussen de twee uitersten. Dit zijn niet noodzakelijk goeie parameters. Mogelijke uitbreiding is optimale a,b en g bepalen (bvb. op 0.05 na). De parameter c is bepaald door de periode van het kleinste seizoen, hiermee is bedoeld : bvb. dagverloop, periodiek per week, periodiek per maand à c=7 : wekelijks (om de 7 dagen herhaling van het patroon). Voor details ivm de beginvoorwaarden verwijzen naar de implementatie in de .m files. Deze implementatie staat in : • HW_mult.m : voor de formules • HW_fcast.m : HW voorspelling op basis van alle dagen ervoor • test_HW_pres.m : genereren van de figuur


71

Figuur 5.6 : toepassingsvoorbeeld HW multiplicative method Ter herinnering : door de 1e grafiek met de 2e te vergelijken weet je welke de originele reeks is en welke de reeks die uit de voorspelling bestaat. De performantiematen zijn duidelijk beter : MSE, sqrt(MSE) : 2485.625 , 49.856 MAD : 36.062 MAPE, MAPE(%) : 0.42266 , 42 LAD : 117.404 De Holt-Winter’s methode heeft nu als eigenschap dat we ook kunnen voorspellen voor meerdere dagen in de toekomst. In feite is dit een lineaire extrapolatie (op basis van het voorspelde niveau en de voorspelde slope (of trend)) gecompenseerd met de seasonal factor. (We kunnen in feite steeds meerdere toekomstige dagen voorspellen maar bij de vorige andere methoden nemen we dan steeds dezelfde voorspelling ! (zie 5.2.1)) Hieronder volgt daarvan een voorbeeld (zie ), dat gegenereerd werd door : • HW_mult.m : voor de formules • HW_fcast_many.m : HW voorspelling op basis 1,2,...,m dagen ervoor (met m instelbaar) • test_HW_many_pres.m : genereren van de figuur


72

# requests (origineel) # requests (voorspeld) # requests (voorspeld) # requests (voorspeld)

HOLT WINTERS MULTIPLICATIVE METHOD (a=0.5) (b=0.5) (g=0.5) (c='lag'=7) 400

200

0 0

5

10

15 20 # voorspelde requests op basis van 1 dag(en) tevoren

25

30

35

0

5

10


25

30

35

0

5

10


25

30

35

0

5

10

25

30

35

400 300 200 100 0 400 300 200 100 0

400 300 200 100 0 15

20

Figuur 5.7 : meerdere voorspellingen met de HW multiplicatieve methode In deze figuur staat dus voor elke dag : de originele waarde, de voorspelling op basis van de reeks tem 1 dag ervoor, de voorspelling op basis van de reeks tem 2 dagen ervoor en de voorspelling op basis va n de reeks tem 3 dagen ervoor. Merk op als je deze 4 figuren van boven naar beneden schuin diagonaal overloopt, dan krijg je in volgorde : de originele reeks, de voorspelling van de dag daarop, de voorspelling van de 2e daaropvolgende dag, de voorspelling van 3e daaropvolgende dag. Dit is dan ook de aanpak die in de capaciteitsplanner zal gebruik worden. De performanties : 1 dag(en) tevoren : MSE, sqrt(MSE) : 2485.625 , 49.856 MAD : 36.062 MAPE, MAPE(%) : 0.42266 , 42 LAD : 117.404 2 dag(en) tevoren : MSE, sqrt(MSE) : 6225.1975 , 78.8999 MAD : 51.2542 MAPE, MAPE(%) : 0.45165 , 45 LAD : 261.585 3 dag(en) tevoren : MSE, sqrt(MSE) : 8067.3094 , 89.8182 MAD : 54.4457 MAPE, MAPE(%) : 0.42737 , 43 LAD : 294.0343 Merk op : we bij alle forecast error measures monotoon minder presteren, behalve qua MAPE ! Figuur 5.8 illustreert de origanisatie van de data van dit geval. Het is nuttig om nu al te vermelden dat we in onze capaciteitsexpansieplanner voor een variant in organisatie gekozen hebben.


73

originele time serie forecasting gebaseerd op alle data t.e.m 2 tijdsstippen ervoor

...

etc ...

forecasting gebaseerd op alle data ervoor

Figuur 5.8 : meerdere voorspellingen maken met de HW multiplicatieve methode (HW_fcast_many.m)


74

6 Capacity planning : capaciteitsexpansie In de volgende delen bespreken we ons model voor capciteitsexpansie. Het model vertrekt van een ‘overbelasting’ die weggewerkt zal worden door capaciteitsexpansie. Dit model is generiek toepasbaar (of uitbreidbaar). Het doel is te beslissen wanneer we uitbreiden in capaciteit (omdat bepaalde resources uitgeput zijn). We leggen eerst dit model uit en vermelden details ivm de implementatie. Nadien geven we voorbeelden van de berekening van de overbelasting. Daarna passen we hierop ons capaciteitsexpansie model toe. We gebruiken hiervoor een capaciteitsexpansieregel. Uiteindelijk berekenen de optimale (parameters van de) regel aan de hand van het kost model in ons capaciteitsexpansiemodel. Alle voorgaande zaken worden zowel op de access logs als op de output van detrafiekgenerator toegepast.

6.1 Capaciteitsexpansiemodel 6.1.1

Berekening van overbelasting

Het doel is capacity planning : dwz zorgen dat er op het juiste moment voldoende resources (vb. bandbreedte) zijn, zodanig dat aan de gebruikers hun wensen voldaan is (vb. ivm delays, response time,...). Vermits we capaciteitsexpansie bekijken, is het uitgangspunt het volgende : we meten en/of berekenen hoeveel een resource (vb. CPU webserver, link tussen 2 routers,...) “belast” wordt (waarbij de metingen en/of berekeningen afhangen van het geval). We zullen dit in de voorbeelden doen aan de hand van de access logs maar in feite stelt dit niet de echte belasting van het systeem voor, maar wel de belasting die bediend is geworden (vb. requests die beantwoord zijn geworden door webserver)), bij de trafiekgenerator (of in feite “belastingsgenerator”) zou je dit eventueel in het model ervan kunnen op nemen . De nodige inputgegevens zijn dus : het verloop van de belasting met gepaste (dwz voldoende fijne) granulariteit in de tijd . Belangrijke keuze hierbij is de vereiste granulariteit in de tijd (zodat we bij verdere stappen nog steeds voor capacity planning zinvolle gegevens bekomen). Wegens rekentijd (en wegens het feit dat Analog 4.03 slechts totale trafiek kan aggregeren vanaf 5 min of meer (zie [12])), hebben we ons beperkt tot een granulariteit van 5 minuten. De nadelen hiervan zouden eventueel onderzocht kunnen worden als uitbreiding. We hebben gebruikt gemaakt (wegens het gebrek aan andere gegevens) voor het aantal requests die door een web server behandeld worden per 5 min. Een belangrijk volgende stap is de transformatie naar “overbelasting” : we berekenen hoe vaak (op basis van zelfde granulariteit als die van de inputgegevens !) de belasting boven een (door “management” of door andere performantiemodellen bepaalde (zie voorbeeld 1)) opgegeven threshold T zit (=“overschrijding in tijd”) en dit tijdens een bepaalde periode en zetten dit uit per periode en dit voor een hele reeks perioden (zie voorbeeld 2). Het is belangrijk in te zien hoe deze threshold in de praktijk tot stand komt en hoe ze hier berekend is geworden. In de praktijk wordt de threshold bepaald door de eigenschappen van de apparatuur en architectuur : bvb. we weten hoeveel requests onze webserver aankan, of wat de maximale throughput is van een bepaalde link, of wat het maximaal aantal modems is in onze modemgateway,... Anderzijds wordt de threshold ook bepaald door management beslissingen maw zaken zoals : we wensen zoveel percent risico dat gebruikers een bezette modemgateway tegenkomen, we wensen een gemiddelde bandbreedte van 5 Kbyte/s per modemgebruiker, we wensen dat aanvragen naar onze proxy server binnen de zoveel msec beantwoordt worden,... Hier : wordt de threshold artificieel gehaald uit de access logs (of trafiekgenerator output). De redenering is dat we de access logs in feite beschouwen als metingen van de werkelijk optredende belasting moest deze niet gestoord worden door capiciteitsbeperkingen. We hebben dan bvb. per seconde x(t) requests in onze metingen. Uit externe berekeningen en factoren (niet verder beschouwd, maar kunnen als belangrijke, niet eenvoudige en omvangrijke uitbreiding gelden) menen we dan te kunnen halen wat het maximaal aantal requests per seconde is dat ons systeem (zoals het op dat © Adelbert Groebbens

75

moment is) aankan. Dit vormt dan de de threshold. Wij hebben als threshold meestal iets van de vorm “gemiddeld aantal requests + een aantal keer de standaardafwijking” genomen, om toch een redelijke waarde te bekomen die bruikbaar is om voorbeelden in onze figuren te geven. We vermelden later de concrete keuze van de threshold T bij de door ons geimplementeerde methode en de door ons bekeken voorbeelden (zie 6.1.2). Voorbeeld 1 : -

het aantal requests op de web server moet bvb. beperkt blijven tot 75% van de capaciteit (die vast staat en gekend is als C requests per seconde) namelijk : performantiemo dellen tonen aan dat onze web server niet meer dan C requests mag te verwerken krijgen zoniet krijgen de gebruikers niet hun gevraagde service

Voorbeeld 2 : -

we zetten per dag uit hoeveel keer (als een veelvoud van 5 minuten) gedurende die dag er 5 minuten waren tijdens dewelke het totaal aantal requests 300*C of meer was

We zullen dit “het verloop van de overbelasting” noemen. (voorbeeld : 300 seconden (5 minuten dus) op dag 1, 600 seconden op dag 2 (10 minuten dus),...). Merk op : ook hier is een belangrijke keuze, namelijk de vereiste granulariteit in de tijd van de periode (hier dag).

6.1.2

Gekozen upgrade-regel

De gekozen regel voor capaciteitsexpansie is : indien er gedurende x opeenvolgende perioden telkens meer dan y tijdseenheden (eenheid bepaald uit die inputgegevens !) per periode de threshold T wordt overschreden, dan kunnen we spreken van een blijvende trend en voegen we dus best capaciteit toe Meer concreet hebben wij : indien er gedurende x opeenvolgende dagen meer dan y minuten (eenheid is hier minuut) per dag de threshold T wordt overschreden, dan voegen we capaciteit toe. Verdere nodige uitleg hierbij is : • herhaling : is R = het aantal requests tijdens een periode van 5 minuten dan hebben we in onze implementatie de threshold T als volgt genomen T = E[R]+k*stdev[R] of soms alternatief T = trimmean[R]+k*iqr[R] (voor meer uitleg zie de .m files), maw T staat voor een buitensporig aantal requests tijdens 5 minuten observatie • we kunnen dus berekenen hoeveel keer er 5 minuten waren tijdens dewelke we boven T zaten • capaciteitstoevoeging betekent dat het systeem een grotere threshold aan kan en zal dus als gevolg hebben dat T wordt verhoogd In onze implementatie hebben we de volgende parameters : • voor y : TH_grens = aantal minuten per dag dat we niet boven de threshold wensen te blijven zoniet brengen we die dag in rekening als een "slechte dag" (bad day) • bovendien hebben we 3 varianten : • geval : op basis van verleden (dwz geen forecasting) o voor x : nr_bad = het aantal opeenvolgende voorbije dagen waarna we als deze dagen steeds "slecht" waren, beslissen tot capaciteitsexpansie, de capacity upgrade treedt dus in werking direct daarop (de “ochtend” van de eerste daaropvolgende dag als het ware) • geval : ideale forecasting o voor x : nr_bad = het aantal opeenvolgende toekomstige dagen waarvoor we als deze dagen steeds "slecht" zouden zijn, beslissen tot capaciteitsexpansie, de capacity upgrade treedt dus in werking direct ervoor (de “ochtend” van de eerste dag als het ware) • geval : forecasting dmv bekende forecastingstechnieken o hetzelfde als bij ideale forecasting maar nu maken we elke dag (gesteld is we kijken elke “ochtend”) enkel gebruik van de tot dan toe opgedane kennis, dwz van het verloop van de overschrijding van de threshold (=verloop van de overbelasting) van de dagen tot dan toe (die aanwezig waren in onze logfile of trafiektrace) © Adelbert Groebbens

76

•

merk op dat we hier in deze regel reeds veronderstellen dat er geen vertraging is tussen beslissing capaciteitsuitbreiding en operationeel worden van de capaciteitsuitbreiding

Noteer dat we hier nog veraf staan van : “als ... plaats dan een nieuwe interface van type ... en capaciteit ... in router ...” of “als ... zorg dan dat de CPU capaciteit verdubbelt”.

6.1.3

Gekozen kost model

De laatste vraag die we wensen te beantwoorden is dan : welke parameterwaarden nemen we in onze regel ? Dit kan bepaald worden aan de hand van een of andere criterium die we dan wensen te optimaliseren. Het criterium dat we hier hanteren is : de kost zo laag mogelijk. De kost wordt bepaald aan de hand van een kost model. Het door ons gekozen kost model : • enerzijds : de kost van uitbreiding capaciteit daalt als de tijd vordert § vb. in de implemtatie : exponentiele afname, dwz elke nieuwe tijdseenheid wordt de kost met een cte tussen 0 en 1 vermenigvuldigd • anderzijds : de penalty kost indien het aantal minuten per dag dat we boven de threshold T zitten niet beneden een bepaalde grens is § vb. in de implementatie : we rekenen het volle aantal minuten per dag aan dat we boven de threshold T zitten en de penalty is evenredig met het aantal minuten dat we erboven zitten Ter herinnering : capaciteitsuitbreiding heeft als gevolg dat de vanaf dan geldende threshold T groter is en dus ook dat het aantal minuten per dag dat we boven een threshold zitten Ons model zegt ook : we kunnen enkel capaciteit in constante discrete pakjes toevoegen : dwz C,C+a,C+2*a,... (met C de originele capaciteit) de threshold zal als gevolg daarvan met constante hoeveelheden toenemen : dwz T,T+b,T+2*b, ... (met T de originele threshold) Merk op dat bovenstaande twee factoren in kost model elkaar tegenwerken (in het vinden van een optimum) : de daling van de uitbreidingskost stelt upgrades uit, de penalty bij het niet wegwerken wil dan weer wel capaciteit toevoegen. Er is dus een trade-off. In onze implementatie hebben we de volgende parameters en verdere modellering : • • • • • • •

cap_unit_cost : de kost van het maken van een capaciteitsuitbreiding (op t = het begin van de tijdsreeks) upg_step : de hoeveelheid waarmee de threshold verhoogd wordt ten gevolge van een capaciteitsuitbreiding halveringstijd : de dag waarop de kost van een capaciteitsuitbreiding is teruggevallen tot de helft van haar oorspronkelijke kost (als onze reeks begint op dag 1) penalty_factor : de kost die we toekennen als we geen capaciteit zouden toevoegen en dan op het einde van de tijdsreeks de toestand evalueren het model is dat deze penalty_factor evenredig afneemt met de reductie van het totale aantal minuten dat we overbelasting hebben (in de reeks) na het toepassen van de capaciteitsuitbreidingen bvb. zonder upgrades : 760 minuten overbelasting over de gehele tijdsreeks (vb. 60 dagen), na upgrades : 76 minuten overbelasting over de gehele tijdsreeks, zou betekenen dat de penalty_factor met een factor 10 vermindert upg_step wordt gelijk gesteld aan een fractie van de oorspronkelijke threshold T (deze wordt TH_load genoemd)

De totale kost is de totale kost te wijten aan capaciteitsuitbreidingen en de kost die nog overgebleven is van de originele penalty, dit is de penalty die moet betaald worden in het geval er geen capaciteitsuitbreidingen zouden plaats grijpen (maw als de overgebleven overbelasting gelijk zou zijn aan de totale originele overbelasting).


77

Het optimum hangt af van : hoeveel is de kost van een capaciteitsuitbreiding (deze staat in feite sterk in verband met de grootte van upg_step) tov de kost te wijten aan penalty. In de voorbeelden zullen we die waarden voor de parameters nemen die een “gunstige” uitslag/figuur als gevolg hebben , vermits we ons toch niet precies kunnen baseren op externe gegevens om al deze parameters te bepalen. Al een eerste vaststelling : verwacht wordt dat het geval met ideale forecasting beter presteert dan het geval op basis van het verleden (zie Figuur 6.1), omdat de penalty vermeden wordt (weliswaar iets vroegere toevoeging van capaciteit)

op basis van verleden beslissen tot expansie originele reeks x dagen y minuten per dag overbelasting

op basis van toekomst ideale voorspelling beslissen tot expansie

voorspelde reeks dag

FORECASTER BESLIST NIET TOT EXPANSIE Figuur 6.1 : vergelijking van de 3 mogelijke gevallen -

6.1.4

merkwaardiger is dat het geval forecasting dmv gekende forecastingstechnieken eventueel wel beter zou kunnen presteren, en dit vermits onze regel niet optimaal is (merk op : een optimale regel vinden is onbegonnen werk want het hangt af van teveel factoren (oa de ganse situatie van het netwerk, het systeem, het bedrijf,...)) en de niet-ideale forecasting zou kunnen verhinderen dat de regel teveel of te weinig wordt toegepast vermits deze forecasting niet perfect is (zie ook Figuur 6.1)

Files met implementatie

De implementatie staat in volgende Matlab files : • compute_dayseq.m : basisfunctie berekening van overbelasting • berekening van de overbelasting (per logfile) : o deel1_deel2_*.m met * = de naam van de logfile • model toegepast op trafiekgenerator : o cap_exp.m : model op basis van verleden o cap_exp_ideal_fcast.m : model op basis van ideale voorspeller o cap_exp_HWmult_fcast.m : model op basis van HW voorspeller à gebruikt HW_fcast_many_var_impro.m o HW_demo.m : overloopt stap voor stap capaciteitsplanning • model toegepast op logfiles : o cap_exp_log.m : model op basis van verleden o cap_exp_ideal_fcast_log.m : model op basis van ideale voorspeller


78

o

•

cap_exp_HWmult_fcast_log.m : model op basis van HW voorspeller berekenig van cost (gebruik tijdsreeks als directe input) : o cap_exp_cost.m o cap_exp_cost_ideal_fcast.m o cap_exp_cost_HWmult_fcast.m o cap_exp_cost_matfunc.m o kost.m

Opmerking : mogelijke verbetering aan de .m files zijn : • meer encapsulatie, betere functionele decompositie : bvb. functie die default parameterswaarden retourneert in een structuur bestaande uit een variabele voor elke parameter, eventueel aanpasbaar dmv de functie waarden mee te geven die default waarden aanroepen (bvb. params(‘perc_random’,40,’nrdays’,60)), dit is vooral nodig als het aantal parameters groot wordt (> 15 bvb.) (voor een voorbeeld van deze aanpak : zie optimset.m uit de Matlab Optimisation toolbox) • de kwaliteit en bruikbaarheid van de code verbeteren (de gegeven code was het resultaat van “rapid prototyping”) • ...

6.1.5

Mogelijke andere modellen/uitbreidingen

6.1.5.1 andere upgrade-regels De gekozen regel is maar één van de vele mogelijkheden, andere mogelijkheden : • als de toekomende x dagen er z (<=x) dagen zijn waar bij het aantal minuten per dag dat de threshold werd overschreden meer dan y minuten per dag is • rekening houden met vorige upgrades (bvb. niet te vlug na mekaar of niet te lang na mekaar capaciteit toevoegen) • ...

6.1.5.2 andere kostmodellen Het kostmodel moet zeker nog verfijnd worden, mogelijkheden zijn : • het in rekening brengen dat capaciteitstoevoeging niet onmiddellijk kan gebeuren • uitbreiden naar de apparatuur en architectuur van internet access netwerken en bvb. gebruik maken van de echte kost van alle apparatuur • ...

6.1.5.3 andere berekeningen van overbelasting (ipv threshold) Zoals gezegd is de threshold artificieel bepaald en moet er dus nog onderzocht wat deze threshold moet zijn in realiteit (geval per geval) of hoe men een model opbouwt om deze threshold eventueel automatisch te bepalen.

6.2 Resultaten op de logfiles We gaan eerst na in 6.2.1 welke logfiles een interessant verloop vertonen qua “overbelasting”. We passen nadien ons capaciteitsexpansiemodel en kostmodel toe. We vermelden steeds welke parameterwaarden we gebruikt hebben.

6.2.1

Berekening van “aantal minuten per dag boven een aanvaardbare

Ter herhaling : we bekijken hier steeds het aantal requests we bepalen een zekere threshold (=maximum toegelaten aantal requests per 5 minuten) en we bepalen hoeveel minuten per dag we boven deze threshold zitten (dus steeds een veelvoud van 5 minuten) De volgende voorbeelden kunnen vergeleken worden met de oorspronkelijke data gegeven in 4.4.


79

6.2.1.1 Nasa WWW server Threshold berekening : threshold (=maximum toegelaten #req/5 min) : 732.4515 berekend als gemiddelde + 4 * standaardafwijking

Figuur 6.2 : resultaat threshold berekening Alternatieve threshold berekening : threshold (=maximum toegelaten #req/5 min) : 460.516 berekend als gemiddelde + 2 * standaardafwijking

Figuur 6.3 : resultaat threshold berekening Alternatieve threshold berekening : threshold (=maximum toegelaten #req/5 min) : 519.1844 berekend als trimmedmean (12.5% aan beide uiteinden eraf) + 2 * interquartile range


80

Figuur 6.4 : resultaat threshold berekening

6.2.1.2 Clarknet WWW server Threshold berekening : threshold (=maximum toegelaten #req/5 min) : 1491.1252 berekend als gemiddelde + 2 * standaardafwijking


6.2.1.3 Atlantis WWW server We beperken ons tot een 100-tal dagen (op het einde van de logfile) van de access log. Threshold berekening : threshold (=maximum toegelaten #req/5 min) : 4.7161 berekend als trimmedmean (12.5% aan beide uiteinden eraf) + 2 * interquartile range


81



6.2.1.4 Atlantis firewall Threshold berekening : threshold (=maximum toegelaten #req/5 min) : 266.7678 berekend als gemiddelde + 4 * standaardafwijking


82



6.2.1.5 University of Saskatchewan WWW server We gebruiken weerom maar een stuk van de oorspronkelijk logfile : slechts van dag 20 t.e.m. dag 120. Threshold berekening : threshold (=maximum toegelaten #req/5 min) : 104.9058 berekend als trimmedmean (12.5% aan beide uiteinden eraf) + 2 * interquartile range


83


Figuur 6.11 : resultaat threshold berekening Deze laatste figuur geeft een duidelijk stijgende trend in belasting. We zullen deze dan ook later gebruiken in het voorbeeld van “capaciteitsexpansie toegepast op een logfile”.

6.2.1.6 University of Calgary WWW server We gebruiken enkel dag 40 t.e.m dag 100 uit de oorspronkelijke logfile. Threshold berekening : threshold (=maximum toegelaten #req/5 min) : 9.6519 berekend als trimmedmean (12.5% aan beide uiteinden eraf) + 2 * interquartile range © Adelbert Groebbens

84



6.2.2

Toepassen van capaciteitsexpansie model

Uit vorige figuren kiezen we Figuur 6.11 om ons model toe te passen. Voor terminologie verwijzen we naar de gegeven uitleg in 6.1. Threshold berekening (zelfde als in de figuur, dus) : threshold (=maximum toegelaten #req/5 min) : 85.5175 berekend als trimmedmean (12.5% aan beide uiteinden eraf) + 2 * interquartile range Concrete waarden in kostmodel : © Adelbert Groebbens

85

-

cap_unit_cost = 100; upg_step=TH_step/5; halveringstijd = 60; penalty_factor=3*cap_unit_cost;

Concrete waarden in expansiemodel : nr_bad = 3; (cf. x) TH_grens = 14; (cf. y) Opmerking : kies best geen veelvoud van 5 zoniet numerieke problemen omdat alle waarden van de overbelasting veelvouden van 5 (min) zijn (wegens het feit dat we in onze logfile enkel het totaal aantal requests (of bytes of ...) per 5 minuten tellen (beperking van ANALOG)). Mogelijke uitbreiding is MATLAB gebruiken i.p.v. ANALOG en direct de logfiles gaan uitlezen via MATLAB.

6.2.2.1 methode : “op basis van verleden” Bij deze methode gaf het Matlab script cap_exp_log.m de volgende output (zie ook Figuur 6.14 tot en met Figuur 6.17) : kost om 1 capaciteitsuitbreiding uit te voeren (aan het begin van de reeks): 100 originele totale kost : 300 3e opeenvolgende grensoverschrijding > 14 min/dag op dag 3 capacity upgrade kost op dag 4 : 95.4094 3e opeenvolgende grensoverschrijding > 14 min/dag op dag 81 capacity upgrade kost op dag 82 : 38.161 3e opeenvolgende grensoverschrijding > 14 min/dag op dag 86 capacity upgrade kost op dag 87 : 35.9839 totale capacity upgrade kost : 169.5543 totale penalty kost : 55.3691 totale kost : 224.9234


86

Figuur 6.14 : verloop van de overbelasting over een 100-tal dagen bij de WWW server van de University of Saskatchewan, geval : op basis van verleden

Figuur 6.15 : verloop van de overbelasting over een 100-tal dagen bij de WWW server van de University of Saskatchewan na 1 e capacity upgrade, geval : op basis van verleden


87




88

6.2.2.2 methode : “op basis van ideale voorspelling” Bij deze methode gaf het Matlab script cap_exp_ideal_fcast_log de volgende output (zie ook Figuur 6.18 tot en met Figuur 6.20) : kost om 1 capaciteitsuitbreiding uit te voeren (aan het begin van de reeks): 100 originele totale kost : 300 3e opeenvolgende grensoverschrijding > 14 min/dag op dag 3 capacity upgrade kost op dag 1 : 98.832 3e opeenvolgende grensoverschrijding > 14 min/dag op dag 81 capacity upgrade kost op dag 79 : 39.5299 3e opeenvolgende grensoverschrijding > 14 min/dag op dag 86 capacity upgrade kost op dag 84 : 37.2748 totale capacity upgrade kost : 175.6367 totale penalty kost : 41.9463 totale kost : 217.583

Figuur 6.18 : verloop van de overbelasting over een 100-tal dagen bij de WWW server van de University of Saskatchewan na 1 e capacity upgrade, geval : ideale forecasting


89

Figuur 6.19 : verloop van de overbelasting over een 100-tal dagen bij de WWW server van de University of Saskatchewan na 2 e capacity upgrade, geval : ideale forecasting

Figuur 6.20 : verloop van de overbelasting ove r een 100-tal dagen bij de WWW server van de University of Saskatchewan na 3 e capacity upgrade, geval : ideale forecasting


90

6.2.2.3 methode : “op basis van HW multiplicatieve voorspelling” Bij deze methode gaf het Matlab script cap_exp_ideal_fcast_log de volgende output (zie ook Figuur 6.21 tot en met Figuur 6.24) : kost om 1 capaciteitsuitbreiding uit te voeren (aan het begin van de reeks): 100 originele totale kost : 300 3e opeenvolgende grensoverschrijding > 14 min/dag (waarschijnlijk) op dag 3 capacity upgrade kost op dag 1 : 98.832 Errors ivm forecaster op dag 1: MSE, sqrt(MSE) : 0 , 0 MAD : 0 MAPE, MAPE(%) : 0 , 0 LAD : 0 3e opeenvolgende grensoverschrijding > 14 min/dag (waarschijnlijk) op dag 60 capacity upgrade kost op dag 58 : 50.5909 Errors ivm forecaster op dag 58: MSE, sqrt(MSE) : 4457.335 , 66.7633 MAD : 61.7604 MAPE, MAPE(%) : 1235.2086 , 123521 LAD : 92.9752 totale capacity upgrade kost : 149.4229 totale penalty kost : 52.5437 totale kost : 201.9666

We merken op dat de echte forecaster BETER presteert dan de ideale. De reden is dat onze voorspelling niet altijd correct zijn zodat we soms de upgrade-regel niet toepassen of juist wel toepassen. Vermits deze regel niet gegarandeerd een “goeie” is (zoals blijkbaar hier het geval is) kan dit falen van de forecaster toch leiden tot een betere prestatie. (Merk op dat we in de tabel hierboven de gemaakte fouten weergeven op de “nr_bad” (=3 hier) gemaakte voorspellingen (iedere dag wordt namelijk voor de volgende 3 dagen de voorspelling gemaakt en aan de hand daarvan wordt beslist of een capacity upgrade nodig is) en dat deze grote fouten bevatten.) Het feit dat de voorspeller tijdens het 1e seizoen (hier c=’lag’=7 dagen) geen fouten maakt is wegens de keuze van de beginvoorwaarden (nl. S(t)). Dat er nadien grote fouten worden gemaakt is o.a. te wijten aan het feit dat de tijdsreeks een minder uitgesproken seizoencomponent heeft, maar daarentegen veel nullen bevat. (De deling door nul in het algoritme werd opgevangen door deling door een kleine waarde en dit heeft soms afwijkingsfouten tot gevolg eens de waarden in het volgende seizoen niet meer nul zijn).


91

Figuur 6.21 : verloop van de overbelasting ove r een 100-tal dagen bij de WWW server van de University of Saskatchewan met vermelding van de 1 e dag waarop voor uitbreiding wordt beslist en de ‘x’ voorspellingen (dag aangeduid met pijl, voorspellingen aangeduid met bolletjes), geval : HW multiplicatieve forecasting

Figuur 6.22 : verloop van de overbelasting over een 100-tal dagen bij de WWW server van de University of Saskatchewan na 1 e capaciteitsuitbreiding, geval : HW multiplicatieve forecasting © Adelbert Groebbens

92

Figuur 6.23 : verloop van de overbelasting over een 100-tal dagen bij de WWW server van de University of Saskatchewan met vermelding van de 2 e dag waarop voor uitbreiding wordt beslist en de ‘x’ voorspellingen, geval : HW multiplicatieve forecasting

Figuur 6.24 : verloop van de overbelasting over een 100-tal dagen bij de WWW server van de University of Saskatchewan na 2 e capaciteitsuitbreiding, geval : HW multiplicatieve forecasting © Adelbert Groebbens

93

6.2.3

Bepalen van optimale parameters in model

We wensen nu de optimale instantie van onze regel te construeren, dwz de optimale ‘x’ en ‘y’ vinden (zie 6.1). We berekenen hiervoor eenvoudigweg de kost behorende bij een voldoend aantal ‘x’ en ‘y’ waarden en halen hieruit het minimum. De volgende 3D-figuren tonen aan waar het interessante gebied stopt. De kost van 300 komt overeen met geen capaciteitsuitbreidingen (en dus geen vermindering van de oorspronkelijke overbelasting). Meer dan 5 opeenvolgende dagen een voldoend hoge overbelasting toelaten heeft meestal geen upgrades tot gevolg. Meer dan 200 minuten per dag overbelasting gedurende 1 of meer dagen toelaten heeft ook geen upgrades tot gevolg (zie ook Figuur 6.14). De ongewenste piek voor ‘x’ = 1 dag en ‘y’ = enkele min per dag is het gevolg van steeds maar capaciteit gaan toevoegen vanaf de kleinste overbelasting, dit is duidelijk ook niet optimaal.

Figuur 6.25 : verloop van de kost na toepassen van capaciteitsexpansiemodel met x=opeenvolgende slechte dagen voor upgrade en y = grens : aantal min per dag (overbelasting), geval : op basis van verleden

eventueel x-as van de figuur herstellen “opeenvolgende”


94

Numerieke resultaten : model : op basis van verleden minimum = 192.5585 voor de gevallen (# dagen , getolereerde # min per dag): 2 36 2 41 2 46 model : ideale forecasting minimum = 185.2833 voor de gevallen (# dagen , getolereerde # min per dag): 2 36 2 41 2 46 model : HW multiplicative method forecasting minimum = 190.275 voor de gevallen (# dagen , getolereerde # min per dag): 2 16 2 21 2 26 2 31 Volgende 2 figuren tonen de 2 andere gevallen. Merk op dat ideale forecasting het beter doet dan het geval op basis van verleden, wegens het feit dat we anticiperen op een te hoge belasting, de penalty verdwijnt dus, terwijl we in beide geval capacity upgrades uitvoeren.

Figuur 6.26 : verloop van de kost na toepassen van capaciteitsexpansiemodel met x=opeenvolgende slechte dagen voor upgrade en y = grens : aantal min per dag (overbelasting), geval : op basis van ideale forecasting


95

Figuur 6.27 : verloop van de kost na toepassen van capaciteitsexpansiemodel met x=opeenvolgende slechte dagen voor upgrade en y = grens : aantal min per dag (overbelasting), geval : op basis van HW multiplicatieve forecasting

6.2.4

Andere logfiles

De Matlab files laten na kleine verandering van de parameters (filenames,...) toe dat de lezer eventueel zelf experimenteert met de andere logfiles.

6.3 Resultaten op eigen gemaakte trafiek generator We hebben hetzelfde eens toegepast op onze trafiekgenerator. De parameters van de generator zijn dezelfde als gegeven in 4.5.2.

6.3.1

Berekening van “aantal minuten per dag boven aanvaardbare belasting”

Dit is te zien in de originele figuur :


96

Figuur 6.28 : verloop van de overbelasting over een 60-tal dagen bij trafiek gegenereerd door onze eigen generator, originele toestand

6.3.2

Toepassen van capaciteitsexpansie model

We hebben voor andere parameters moeten kiezen om toch een interessant verloop te krijgen (parameterwaarden uit het voorbeeld met de access log leiden tot bvb. een quasi vlakke 3D figuur). Threshold berekening (zelfde als in de vorige figuur, dus) : threshold (=maximum toegelaten #req/5 min) : 176.3558 berekend als gemiddelde + 1.5 * standaardafwijking Concrete waarden in kostmodel : cap_unit_cost = 100; upg_step=TH_step/15; halveringstijd = 60; penalty_factor=10*cap_unit_cost; Concrete waarden in expansiemodel : nr_bad = 3; (cf. x) TH_grens = 10; (cf. y) merk op : vermits we een veelvoud van 5 hebben voor TH_grens zouden we wel eens eigenaardigheden ivm numerieke afrondingsfouten kunnen uitkomen (we zullen deze dan vermelden)

6.3.2.1 methode : “op basis van verleden” Bij deze methode gaf het Matlab script cap_exp de volgende output (zie ook Figuur 6.29 tot en met Figuur 6.31) : kost om 1 capaciteitsuitbreiding uit te voeren (aan het begin van de reeks): 100 originele totale kost : 1000 3e opeenvolgende grensoverschrijding > 10 min/dag op dag 17 capacity upgrade kost op dag 18 : 80.9395 © Adelbert Groebbens

97

3e opeenvolgende grensoverschrijding > 10 min/dag op dag 38 capacity upgrade kost op dag 39 : 63.2432 3e opeenvolgende grensoverschrijding > 10 min/dag op dag 52 capacity upgrade kost op dag 53 : 53.6517 totale capacity upgrade kost : 197.8344 totale penalty kost : 131.8603 totale kost : 329.6947

Figuur 6.29 : verloop van de overbelasting over een 60-tal dagen bij trafiek gegenereerd door onze eigen generator, na 1 e capacity upgrade, geval : op basis van verleden


98




99

6.3.2.2 methode : “op basis van ideale voorspelling” Bij deze methode gaf het Matlab script cap_exp_ideal_fcast de volgende output (zie ook Figuur 6.32 tot en met Figuur 6.34) : kost om 1 capaciteitsuitbreiding uit te voeren (aan het begin van de reeks): 100 originele totale kost : 1000 3e opeenvolgende grensoverschrijding > 10 min/dag op dag 17 capacity upgrade kost op dag 15 : 83.843 3e opeenvolgende grensoverschrijding > 10 min/dag op dag 38 capacity upgrade kost op dag 36 : 65.512 3e opeenvolgende grensoverschrijding > 10 min/dag op dag 52 capacity upgrade kost op dag 50 : 55.5763 totale capacity upgrade kost : 204.9313 totale penalty kost : 51.3186 totale kost : 256.2499

Figuur 6.32 : verloop van de overbelasting over een 60-tal dagen bij trafiek gegenereerd door onze eigen generator, na 1 e capacity upgrade, geval : op basis van ideale forecasting


100




101

6.3.2.3 methode : “op basis van HW multiplicatieve voorspelling” Bij deze methode gaf het Matlab script cap_exp_hwmult_fcast de volgende output (zie ook Figuur 6.35 tot en met Figuur 6.40) : kost om 1 capaciteitsuitbreiding uit te voeren (aan het begin van de reeks): 100 originele totale kost : 1000 3e opeenvolgende grensoverschrijding > 10 min/dag (waarschijnlijk) op dag 31 capacity upgrade kost op dag 29 : 71.1273 Errors ivm forecaster op dag 29: MSE, sqrt(MSE) : 31158.6527 , 176.5181 MAD : 174.6173 MAPE, MAPE(%) : 0.80183 , 80 LAD : 210.7709 3e opeenvolgende grensoverschrijding > 10 min/dag (waarschijnlijk) op dag 60 capacity upgrade kost op dag 58 : 50.5909 Errors ivm forecaster op dag 58: MSE, sqrt(MSE) : 3255002.3691 , 1804.1625 MAD : 1199.4824 MAPE, MAPE(%) : 3.9771 , 398 LAD : 3087.3073 3e opeenvolgende grensoverschrijding > 10 min/dag (waarschijnlijk) op dag 61 capacity upgrade kost op dag 59 : 50 merk op : voorspelling valt reeds verder dan tijdsreeksgegevens, geen errors voorhanden totale capacity upgrade kost : 171.7181 totale penalty kost : 463.4967 totale kost : 635.2148 Speciaal hierbij is op te merken dat bij de 3e upgrade we reeds (ten dele) voorbij einde van de time serie zitten, zodat er geen mogelijke forecast errors te berekenen zijn.


102

Figuur 6.35 : verloop van de overbelasting over een 60-tal dagen bij trafiek gegenereerd door onze eigen generator, met vermelding van de 1e dag waarop voor uitbreiding wordt beslist en de ‘x’ voorspellingen (dag aangeduid met pijl, voorspellingen aangeduid met bolletjes), geval : HW multiplicatieve forecasting

Figuur 6.36 : verloop van de overbelasting over een 60-tal dagen bij trafiek gegenereerd door onze eigen generator, na 1 e capaciteitsuitbreiding, geval : HW multiplicatieve forecasting © Adelbert Groebbens

103

Figuur 6.37 : verloop van de overbelasting over een 60-tal dagen bij trafiek gegenereerd door onze eigen generator, met vermelding van de 2 e dag waarop voor uitbreiding wordt beslist en de ‘x’ voorspellingen (dag aangeduid met pijl, voorspellingen aangeduid met bolletjes), geval : HW multiplicatieve forecasting

Figuur 6.38 : verloop van de overbelasting over een 60-tal dagen bij trafiek gegenereerd door onze eigen generator, na 2 e capaciteitsuitbreiding, geval : HW multiplicatieve forecasting


104

Figuur 6.39 : verloop van de overbelasting over een 60-tal dagen bij trafiek gegenereerd door onze eigen generator, met vermelding van de 3 e dag waarop voor uitbreiding wordt beslist en de ‘x’ voorspellingen (dag aangeduid met pijl, voorspellingen aangeduid met bolletjes), geval : HW multiplicatieve forecasting

Figuur 6.40 : verloop van de overbelasting over een 60-tal dagen bij trafiek gegenereerd door onze eigen generator, na 3 e capaciteitsuitbreiding, geval : HW multiplicatieve forecasting © Adelbert Groebbens

105

6.3.3

Bepalen van optimale parameters in model

We geven de 3D figuren en ook de projecties. Wegens het gebrek aan een kleurenafdruk is het het beste om de versie op de CD-ROM van dit document nu te raadplegen.


Figuur 6.42 : projectie van vorige figuur


106




107




108

7 Conclusies, verder werk en uitbreidingen 7.1 Conclusies We hebben o.a. : •

een studie gedaan van internet access netwerken

•

een studie gedaan van zaken ivm capacity planning

•

een studie gedaan over forecasting technieken

•

met behulp van ANALOG en MATLAB access logs verwerkt, ervaring opgedaan ivm het gebruiken van MATLAB als engineering en visualisation tool

•

een eenvoudige trafiekgenerator geimplementeerd

•

een eenvoudige beslisser voor capaciteitsexpansie geimplementeerd

Enkele besluiten of samengevatte stellingen zijn : •

de optimale vorm van de gegeven upgrade-regel blijkt niet geschikt voor lange termijn planning

•

capacity planning is een complex domein, we hebben slechts de mogelijkheden en technieken geëxploreerd, de basis is gelegd voor verder onderzoek

•

“real-world” conclusies zijn er weinig of niet, de oorzaken : o

geen echte trafiekmetingen vlot en/of openbaar beschikbaar (bedrijfsgeheim van commerciele access providers)

o

uitgebreide beschrijvingen van echte architectuur configuratie van commerciele access providers waren niet voorhanden (bedrijfsgeheim)

o

de (vrijwel vereiste) ervaring “in the field” was niet voorhanden : vragen zoals wat zijn de concrete op te lossen problemen bij access providers, hoe gebeurt de planning/dimensionering op dit moment bij internet access providers,...

o

de thesis omvatte een breed gebied mede door het aansnijden van statistische methodes

o •

...

er zijn waarschijnlijk ingewikkelde en complexe forecasting-systemen (cf. expertsystemen die beste forecast-methode kiezen) om bruikbare voorspellingen te doen, wel blijft de vraag of het nuttig is om hierin veel tijd (onderzoek) te investeren

•

foutieve voorspelling kunnen eventueel opgevangen worden door per element (vb. een router) een capaciteitsexpansie planning te maken en dan al deze samen te brengen en een gezamenlijke planning (voor bvb. 100 routers) te maken in de hoop dat de fouten elkaar compenseren

•

het capaciteitsexpansiemodel vereisen zeker nog verfijning en afwerking om bruikbaar te zijn

•

de resultaten hangen sterk af van de juistheid van de parameters, een praktisch bruikbare toepassing vereist dus voldoende en correcte kennis en modellering van de effecten die zich in


109

bij internet access providers in de realiteit manifesteren (zie ook opmerkingen hierboven ivm “real-world” conclusies) •

misschien zijn de eenvoudige modellen toch reeds toepasbaar om een kwalitatieve indicatie te geven (maar dan wel een automatische) ivm het (toekomstig) verbruik/gebruik van resources in een (access)netwerk

•

merk op bij dit laatste geval dat een automatische indicatie toch reeds nuttig kan zijn ook al is deze niet 100% correct (zolang er rekening meegehouden wordt dat deze foutief kan zijn)

7.2 Verder werk en uitbreidingen De uitbreidingen ivm het gedane werk werden reeds tijdens de voorgaande tekst vermeld op de gepaste plaatsen, zie : •

4.5.1 Elementen in onze trafiek generator

•

4.2 Trafiekmetingen bekomen

•

5.3.2 Optimalisatie van de parameters :

•

5.4.2 “moving average

•

5.4.4 “exponential smoothing with linear trend and seasonal factors (Holt Winter’s multiplicative method)

•

6.1 Inleiding, probleemstelling en overzicht

•

6.2.2 Toepassen van capaciteitsexpansie model


110

Appendix A : andere formules ivm forecasting

8 Appendix A : andere formules ivm forecasting Volgende formules en methoden zijn afkomstig uit [13] en kunnen als uitbreiding en bijkomende informatie dienen bij de reeds gegeven forecasting technieken. Double Exponential Smoothing: F(t) = a x(t) + (1- a )F(t-1) F'(t) = a F(t) + (1- a )F'(t-1) f(t+h) = F'(t) where a is the smoothing constant, 0 <= a <= 1, and default F(0) = F'(0) = x(1). Double Exponential Smoothing with Linear Trend: F(t) = a x(t) + (1- a )F(t-1) F'(t) = a F(t) + (1- a )F'(t-1) f(t+h) = 2F(t)-F'(t)+h[a/(1-a)] [F(t)-F'(t)] where a is the smoothing constant, 0 <= a <= 1, and default F(0) = F'(0) = x(1). Holt-Winters Additive Algorithm: F(t) = a [x(t)-S(t-c)] + (1- a )[F(t-1)+T(t-1)] T(t) = b [F(t)-F(t-1)] + (1- b )T(t-1) S(t) = g [x(t)-F(t)] + (1- g )S(t-c) f(t+h) = F(t)+hT(t)+S(t+h-c) for h=1,2,..., c f(t+h) = F(t)+hT(t)+S(t+h-2c) for h=c+1,c+2,..., 2c f(t+h) = F(t)+hT(t)+S(t+h-3c) for h=2c+1,2c+2,..., 3c etc. where c is the length of seasonal cycle, a, b, g are the smoothing constants, 0 <= a <= 1, 0 <= b <= 1 and 0 <= g <= 1. Let m be the average of the first cycle, i.e., t=1 to c. The default initial settings are: F(0)= m, T(0)=0, S(t) = x(t) - m for t=1 to c.


111

Appendix B : extra uitleg bij CD-ROM

9 Appendix B : extra uitleg bij CD-ROM Op de CD-ROM is het volgende te vinden : •

logs.zip

: de logfiles

•

matlab_files

: de .m files

•

results_figures

: de ANALOG software, het preproc C

programma en dan per logfile de .comp files en .comp_pp files en de figuren van sommige resultaten(.tif formaat)(waarvan er sommigen in dit document gebruikt werden) •

presentatie_en_documenten : de thesis presentatie (.ppt, .pdf en .ps formaat), dit document zelf (.doc, .pdf en .ps formaat) en webpagina met interessante links (.html formaat)

•

analog_plus_informatie : bevat (nog eens) de ANALOG software maar nu met documentatie

Wat betreft de MATLAB files wordt best voor uitleg gekeken naar (in volgorde) : de online help documentatie bij MATLAB (zie [14],[15],[16],[17] en [18]), de hulpcommentaar in de code (=de 1e lijntjes commentaar van een functie of script, op te roepen via help <script of functie .m file>), de commentaar die naast de code staat. De code is te vinden op de CD-ROM. De .m files zijn steeds te bekijken met een gewone text -editor. Er zijn vanzelfsprekend aanpassingen nodig wat betreft de aanduidingen van directories in de code ! We verontschuldigen ons voor de eventuele foutieve en/of verouderde commentaar die nog tussen de code te vinden is.


112

Appendix C : bandbreedtes/link-types

10 Appendix C : bandbreedtes/link-types TECHNOLOGIE/TYPE/NAAM

BANDBREEDTE

Ethernet Fast Ethernet Token Ring ATMF Analog (=modem) ISDN BRI

T1,DS1

10 Mbit/s 100 Mbit/s 4 of 16 Mbit/s 25.6 Mbit/s 56 kbit/s 2x64 kbit/s = 128 kbit/s 128 kbit/s 6*128 kbit/s = 768 kbit/s down = 1.54 Mbit/s (theoretisch : 8 Mbit/s) up = 175 kbit/s (theoretisch : 1 Mbit/s) down = 30 Mbit/s up = 0 tot 768 kbit/s 1.544 Mbit/s (> 24*64 kbit/s)

T3,DS3

44.736 Mbit/s (> 720*64 kbit/s (?))

STM-1, OC3c

155.55 Mbit/s

STM-4c,OC12

622 Mbit/s

E1

2 Mbit/s (> 30*64 kbit/s)

E3

34 Mbit/s

Frame Relay

1.5/2/15/34 Mbit/s

serial frame relay (?)

8 Mbit/s

HSSI frame relay (?)

52 Mbit/s

FDDI

100 Mbit/s

ISDL SDSL ADSL Cable modem


Opmerking

afstand : < 4.5 km afstand : < 6 km

? soms 672 ipv 720

vaak gemapped in VC3’s

113

Appendix D : details en specificaties van internet access equipment

11 Appendix D : details en specificaties van internet access equipment 11.1 Cisco AS5x00 Series 11.1.1 Cisco AS5800 Universal Access Server •

BELANGRIJKSTE COMPONENTEN : • dial shelf (met slots voor kaarten) • router shelf • AC input power shelf • interconnectie tussen dial shelf en router shelf : 100 Mbit/s full duplex (Cisco proprietary protocol)

•

Afbeelding in Figuur 11.1

Figuur 11.1 : Cisco AS5800 Access Server

•

DIAL SHELF 1. backplane (= soort motherboard waarop slots en een soort bus (voor interconnectie) voorzien zijn) • 14 slots waarvan 2 slots gereserveerd voor controller kaarten • 3 bussen : • 1 voor interconnectie dial shelf en router shelf • 1 voor TDM (clock and frame pulses) • 1 voor maintenance and environment 2. opsomming van alle mogelijke kaarten (=FRU’s = field replacable units) in de dial shelf • Modem card • maximaal 10 kaarten per shelf • geen externe poorten • 6 modem modules/hmm * 12 hmms/modem card * 10 modem cards/dial shelf = 720 DS0 calls maximaal mogelijk (opmerking : hmm = hex modem module)


114

Appendix D : details en specificaties van internet access equipment •

•

• •

functie : terminatie van analoge calls, stuurt de data door naar de dial controller card (die het naar de router card doorstuurt) T1 trunk card/E1 trunk card • maximaal 5 kaarten per shelf • 12 E1 of 12 T1/PRI poorten per kaart • 2 trunk cards/shelf * 12 PRI/trunk card * 30 DS0 calls/PRI = 720 DS0 calls maximaal mogelijk • functie : multiplexeert en demultiplexeert de DS0 calls op de inkomende T1 of E1 lijnen (komende van de telco operator) • geval ISDN call : dan terminatie van DS0 naar één van de HDLC controllers (deze zijn aanwezig op T1/E1 trunk cards) • geval analog modem call : dan via TDM bus naar modem module waar terminatie gebeurt Dial shelf controller card • functie : zorgt voor algemene controle en connectie met de router Blank filler cards

•

BLOWER ASSEMBLY

•

FILTER MODULE

•

POWER ENTRY MODULE (PEM)

•

AC-INPUT POWER SHELF

•

AC-INPUT SINGLE POWER SUPPLY

•

ROUTER SHELF : namelijk de CISCO 7206 router (=access router) 1. in combinatie met de AS5800, verzorgt deze router de call signaling voor PRI interfaces, routing en de packet processing 2. eigenschappen : • 6 slots voor poort adapters (= kaarten) • 1 I/O controller slot met console port en auxiliary port en optionele Fast Ethernet poort (= port adapter 0) • 1 network processing engine slot • plaats voor 2 AC of DC power supplies • functies midplane (ipv backplane) : connectie met SRAM, trafiekverdeling over PCI bussen, clocksignaalgeneratie • totale bandbreedte van de bus : 600 Mbps 3. over beschikbare port adapters (zoals fddi, ethernet, token ring) à interfaces : HSSI, Fast Ethernet, FDDI, ATM

11.1.2 Cisco AS5300 Universal Access Server •

CHASSIS MET VOLGENDE COMPONENTEN : • plaats voor 3 kaarten • 1 10Base-T poort en 1 10/100Base-T poort • 1 voeding, 1 console poort, 1 aux poort

•

MOGELIJKE INTERFACES : • 4x T1/E1 PRI card met 4 serial interfaces (laat geen Microcom carrier card toe) • 4x T1/E1 PRI card zonder serial interfaces • 8x T1/E1 PRI card met 4 serial interfaces (laat geen Microcom carrier card toe) • 8x T1/E1 PRI card zonder serial interface • opmerking : - “T1/E1” dwz een afzonderlijke type kaart voor T1 en ook een voor E1 - 8x of 4x geeft het aantal poorten van dat type aan • MICA carrier card (à modems) • maximaal 2 MICA carrier cards per chassis mogelijk


115


•

•

• 1 MICA card bevat 10 MICA slots • 1 slot kan één 6-poort of één 12-poort modem module bevatten • dus maximaal : 2*10*12 = 240 modems in een volledige chassis slot mogelijk Microcom carrier card (à modems) • maximaal 2 Microcom cards per chassis mogelijk • 1 Microcom card bevat 2 slots • 1 slot kan één 12-poort modem module bevatten (de 2 mogelijke modules : een v.34 12-poort modem module en een 56k 12-poort modem module) • dus : 2*2*12 = 48 modems in een volledige chassis slot mogelijk • toepassing : à Microcom carrier card is verouderd maar bestaat nog om compatibiliteit bij upgrading van de verouderde AS5200 naar AS5300 mogelijk te maken (VoIP card)

11.1.3 Cisco AS5200 Universal Access Server •

CHASSIS MET VOLGENDE COMPONENTEN : • plaats voor 3 kaarten • 1 Ethernet poort • 2 serial WAN poorten à we hebben dus keuze om te routeren naar Ethernet (LAN) of serial (WAN) • 1 voeding, 1 console poort, 1 aux poort

•

MOGELIJKE INTERFACES : • 2x T1 PRI card • 2x E1 PRI card • Microcom carrier card (à modems) : • deze bevat op zich 2 slots voor 12-port modem modules (v.34/56k/v.110) • dus : 2 * 2 * 12 = 48 poorten • opmerking : in geval E1 zijn er nog opties om per E1 card een 12-port modem module erbij te steken (om zodoende aan 72 poorten in geval van 2 2x E1 PRI card te bekomen met maximaal 60 poorten tegelijk te gebruiken (nl. E1 = 30 x DS0)) • MICA carrier card (à modems) : • 56 kbps • 30 modems per slot mogelijk

11.2 Nortel CVX 1800

Figuur 11.2 : Nortel CVX 1800 •

RACK (=CHASSIS) MET VOLGENDE COMPONENTEN : • 4 shelves per rack (7-foot) • system controller • trunk interfaces • access cards • 18-slots • meerdere parallelle bussen met een totaal van 5.8 Gbps geaggregeerde bandbreedte

•

willekeurige combinatie van modem en ISDN mogelijk : • 1344 modem/ISDN calls poorten per shelf


116

Appendix D : details en specificaties van internet access equipment •

96 modems per kaart/102 ISDN modems per kaart

•

MOGELIJKE INTERFACES : • “uplink” interfaces (meerdere interfaces zijn dus mogelijk) : • Ethernet 10 base-T/100 base-TX • T1/Frame Relay • HSSI (52 Mbit/s) • “access line” interfaces : • channelized T3 (dus 30*24 = 720 DS0 calls) • è 2 T3 connecties mogelijk (2 T3 = 48 T1) • channelized T1/E1 (dus 24/30 DS0 calls) • è 48 T1 connecties mogelijk (opm. 48*24 = 1152 DS0’s ?) • LAN interface (à voor management) : • Ethernet 10 base-T of Ethernet 100 base-TX

•

DATA FORWARDING : IP ROUTING à routeermogelijkheid

11.3 Ascend MAX TNT •

COMPONENTEN in MAX TNT systeem : • kan 3 shelves bevatten met per shelf 16 modules • 1 shelf controller • redundant, load-balancing power supplies • “scalable, modular and backplane architecture” • opmerking : backplane = soort motherboard waarop er kaarten ingestoken worden

• •

de MAX TNT ondersteunt maximaal 720 DS0 (=64 kbit/s) connecties (“WAN sessions”) (namelijk : DS3 backplane capacity : 30xT1=30x24xDS0 = 30x24x64 kbit/s) de MAX TNT ondersteunt : maximaal 150 T1/E1 access lines

•

afbeelding zie Figuur 11.3 :

Figuur 11.3 : MAX TNT Shelf : the back panel •

MODULES AND SOFTWARE OPTIONS :


117

Appendix D : details en specificaties van internet access equipment • •

•

• •

•

•

•

één module vereist normaal gezien één expansion slot (tenzij vermeld zoals bvb. bij modem modules) analog modem module • 36 poorten (opmerking : poort = “modem” hier) • 33.6 kbps • bezet 2 expansion slots in een shelf • per shelf 7 modules maximaal mogelijk • dus maximaal 252 modempoorten per shelf digital modem module • 48 modempoorten per module • 56 kbps • bezet 2 expansion slots in een shelf • max 288 (6*48) modempoorten per shelf (merk op < 720 !?) • dus maximaal 7 modules per shelf mogelijk • globale beperking : max 720 per 3 shelves (merk op 720=15*48 < 3*6*48) • “user inputs” : channelized T1/E1, ISDN PRI, channelized DS3 hybrid access module • 192 remote 56/64k frame relay or ISDN connecties • 720 maximaal in aantal per shelf frameline module • 10 T1/E1 user ports per module • 150 TE/E1 user ports per shelf mogelijk • à 15 frameline modules per shelf WAN interface modules • module met 8 channelized T1/PRI poorten • module met 8 ISDN E1/PRI poorten • module met 1 channelized DS3 poort • module met 1 unchannelized DS3 poort • module met 10 unchannelized T1/E1 poorten backbone interface module (opm. backbone is hier LAN of FR) • module met 4 Ethernet 10Base-T poorten • module met 4 Ethernet 10Base-T poorten en 1 Ethernet 100Base-T poort • module met 4 serial V.35 (8 Mbps) poorten • module met 1 HSSI (52 Mbps) poort • module met 1 unchannelized DS3 poort • module met 10 unchannelized T1/E1 poorten • module met 36 33.6 analog modem poorten • merk op overlap met andere modules, dus blijkbaar mogelijk om modules in beide richtingen te gebruiken verdere module kaarten : • ATM DS3 card (=module met 1 unchannelized DS3 poort) • voor connectie met ATM backbone • 1 (ATM UNI 3.0) DS3 poort per kaart • 1 (+ 1 spare) kaart per MAX TNT systeem maximaal mogelijk • ATM OC-3c/STM-1 card (nieuw ?) • versie met 1 copper of versie met 1 fibre poort • 1 (+ 1 spare) kaart per MAX TNT systeem maximaal mogelijk • maximaal 360 VCs per kaart • Frame relay DS3 card • 1 unchannelized DS3 poort per kaart • 1 (+ 1 spare) kaart per CHASSIS • maximaal 5 kaarten per MAX TNT systeem • laat toe om 10 (?) T1/E1 Frame Relay user poorten te termineren en hen naar een backbone netwerk om te leiden • maximaal support van 150 T1/E1 user poorten


118


11.4 Cisco 36x0 Series

Figuur 11.4 : de Cisco 3600 series, rechts de Cisco 3660 De doelgroep van deze kleinere (low-end) access servers (met routeermogelijkheden) zijn small/medium ISP’s. Er zijn op dit moment 3 modellen namelijk de 3620, de 3640 en de 3660 (deze laatste is de nieuwste in de reeks).

11.4.1 Cisco 3620 router • •

2 slots voor netwerk modules/WAN interface cards kan 1 DM module bevatten : 30 digital modems

11.4.2 Cisco 3640 router • • •

4 slots voor netwerk modules/WAN interface cards kan 2 DM modules bevatten : 30 digital modems slot meer dan bij 3620

11.4.3 Cisco 3660 router • • • • • •

6 slots voor netwerk modules/WAN interface cards 1 of 2 onboard Fast Ethernet interfaces 2 AIM-card (= Advanced Interface Module) slots • vb. de kaart “AIM-COMPR4” kan 4 E1 data compression AIM bevatten TDM-card support for redundant AC or DC power supplies 1 aux/1 console/2 pcmcia slots

11.4.4 NETWERK MODULES/WAN INTERFACE CARDS : Hieronder volgt een bewerking van de tabellen met interfaces uit de publikaties van Cisco. De modules ivm voice zijn niet vermeld in tabel.

•

THE CISCO 3600 NETWORK MODULES (LAN/WAN/MIXED MEDIA) :

Table : ATM Network Modules NM-1A-OC3MM One-port 155-Mbps multimode OC-3 ATM network module NM-1A-OC3SMI One-port 155-Mbps single-mode intermediate-reach OC-3 ATM network module NM-1A-OC3SML One-port 155-Mbps single-mode long-reach OC-3 ATM network module NM-1ATM-25 One-port ATM 25-Mbps network module Table : HSSI Network Modules NM-1HSSI One-port high-density serial interface network module Table : Serial Network Modules NM-16A 16-port high-density async serial network mo dule NM-32A 32-port high-density async serial network module © Adelbert Groebbens

119

Appendix D : details en specificaties van internet access equipment NM-4T NM-4A/S NM-8A/S

Four-port T1/E1 sync serial network module Four-port async/sync low-speed serial network module Eight-port async/sync low-speed serial network module

Table : LAN Network Modules NM-1FE-FX One-port Fast Ethernet network module (10/100BaseFX only) NM-1FE-TX One-port Fast Ethernet network module (10/100BaseTX only) NM-4E Four-port Ethernet network module (10BaseT) NM-1E One-port Ethernet network module (10BaseT) Table : Mixed-Media LAN/WAN Network Modules NM-1E2W One-port Ethernet, 2 WAN card slot network module NM-2E2W Two-port Ethernet, 2 WAN card slot network module NM-1E1R2W One-port Ethernet, one-port Token Ring, 2 WAN card slot network module Tables : ISDN and Channelized Serial Network Modules NM-1CT1

One-port channelized T1/ISDN PRI network module

NM-1CT1-CSU NM-2CT1 NM-2CT1-CSU NM-1CE1B NM-1CE1U NM-2CE1B NM-2CE1U NM-4B-S/T NM-4B-U NM-8B-S/T NM-8B-U

One-port channelized T1/ISDN PRI with CSU network module Two-port channelized T1/ISDN PRI network module Two-port channelized T1/ISDN PRI with CSU network module One-port channelized E1/ISDN PRI balanced network module One-port channelized E1/ISDN PRI unbalanced network module Two-port channelized E1/ISDN PRI balanced network module Two-port channelized E1/ISDN PRI unbalanced network module Four-port ISDN BRI network module Four-port ISDN BRI with NT-1 network module Eight-port ISDN BRI network module (S/T interface) Eight-port ISDN BRI with NT-1 network module (U interface)

Table : Mixed-media : Ethernet + Channelized Serial Network Modules NM-1FE1CT1 One-port 10/100BaseTX Ethernet with one-port PRI/channelized T1 NM-1FE2CT1 One-port 10/100BaseTX Ethernet with two-port PRI/channelized T1 NM-1FE1CT1One-port 10/100BaseTX Ethernet with one-port PRI/channelized T1 with integrated CSU CSU NM-1FE2CT1One-port 10/100BaseTX Ethernet with two-port PRI/channelized T1 with integrated CSUs CSU NM-1FE1CE1B One-Port 10/100BaseTX Ethernet with one-port PRI/channelized E1 balanced mode (120 ohm) NM-1FE2CE1B One-port 10/100BaseTX Ethernet with two-port PRI/channelized E1 balanced mode (120 ohm) NM-1FE1CE1U One-port 10/100BaseTX Ethernet with one-port PRI/channelized E1 unbalanced mode (75 ohm) NM-1FE2CE1U One-port 10/100BaseTX Ethernet with two-port PRI/channelized unbalanced mode (75 ohm) Table : Analog modem Network Modules NM-8AM Eight-port analog modem network module NM-16AM 16-port analog modem network module NM-8AM-J Eight-port analog modem network module for Japan NM-16AM-J 16-port analog modem network module for Japan Table : Digital modem Network Modules NM-6DM 6 digital modem network modules NM-12DM 12 digital modem network modules NM-18DM 18 digital modem network modules NM-24DM 24 digital modem network modules NM-30DM 30 digital modem network modules MICA-6MOD(=) 6 digital modem upgrade cards


120


•

THE CISCO 3600 WAN INTERFACE CARDS (toepassing : WAN card slots bij mixed media modules)

SERIAL WAN INTERFACE CARD WIC-1T One-port T1 sync serial WIC-1DSU-T1 One-port T1/fractional T1 sync serial with build in CSU/DSU WIC-1DSU-56K4 One-port, sync serial four-wire 56/64-kbps with build in CSU/DSU ISDN WAN INTERFACE CARD WIC-1B-S/T One-port ISDN BRI (S/T interface) WIC-1B-U One-port ISDN BRI with NT1 (U interface) Table : new network modules (à à vanaf augustus 1999) NM-4T1-IMA 4 port T1 ATM network module with Inverse Multiplexing over ATM (IMA) NM-4E1-IMA 4 port E1 ATM network module with Inverse Multiplexing over ATM (IMA) NM-8T1-IMA 8 port T1 ATM network module with Inverse Multiplexing over ATM (IMA) NM-8E1-IMA 8 port E1 ATM network module with Inverse Multiplexing over ATM (IMA)

11.5 Cisco 75xx Series Dit zijn “high end” routers. Er zijn 3 modellen : de 7505, de 7507 en de 7513. Er is een recente uitbreiding : de 7576. Volgende figuren geven een duidelijk beeld :

Figuur 11.5 : Cisco 7507 (rear view en front view)


121


Figuur 11.6 : Dual CyBus Backplane in the Cisco 7507

11.5.1 Cisco 7513 • • • •

11 interface processor slots 2 slots voor 2 RSP’s (=route switch processor) (2e RSP is optioneel) (nl. slot 6 en 7) 2 power supplies mogelijk 2 “CyBus 1.066 Gbps” backplanes (passive) à slot 0,1,2,3,4 en 5 naar Cybus 1 à slot 8,9,10,11 en 12 naar Cybus 2 à interface processors op de ene Cybus worden niet beïnvloed door de trafiek gegenereerd op de interface processors geconnecteerd met de andere Cybus

11.5.2 Cisco 7507 • • • •

5 interface processor slots 2 slots voor 2 RSP’s (nl. slot 2 en 3) 2 power supplies mogelijk 2 “CyBus 1.066 Gbps” backplanes (passive) à slot 0 en 1 naar Cybus 1 à slot 4,5 en 6 naar Cybus 2 à interface processors op de ene Cybus worden niet beïnvloed door de trafiek gegenereerd op de interface processors geconnecteerd met de andere Cybus

11.5.3 Cisco 7505 • • • •

4 interface processor slots 1 RSP slot 1 power supply 1 “Cybus 1.066 Gbps” backplane (passive)

11.5.4 Cisco 7576 (àuitbreiding van de 7513) • •

zelfde als 7513 maar andere backplane namelijk 4 Cybus’en nummering : • Cybus 0 : slot 0,1,3 en 5 • Cybus 1 : slot 2 en 4 • Cybus 2 : slot 8,10 en 12 • Cybus 3 : slot 9 en 11

11.5.5 Opsomming van de “Interface Processors” in deze routers • •

Ethernet Interface Processor : 2,4 of 6 poorten Fast Ethernet Interface Processor : 1 of 2 poorten


122

Appendix D : details en specificaties van internet access equipment • • • • • • •

• • •

Token Ring Interface Processor : 2 of 4 poorten (4 of 16 Mbps token ring) FDDI Interface Processor : multimode of singlemode fibre, 1 poort (opm. dit kan een 2-fibrepair of een 1-fibre-pair poort zijn) Fast Serial Interface Processor : 4 of 8 poorten, automatische detectie welk type serial (E1,T1,…) à dit is non-channelized HSSI Interface Processor : 1 poort à toepassing : DS3,E3,SMDS/CBDS en ATM (max speed 52 Mbit/s) Gigabit Ethernet Interface Processor : 1 poort Packet OC-3 Interface Processor : 1 poort ATM Interface Processor : 1 poort à (ondersteunt AAL 3,4 en 5) met aparte submodule te kiezen voor het type physical interface : SONET/SDH (dwz STS-3 or STM-1), DS3/E3 of TAXI 4B/5B als mogelijke interfaces Multichannel Interface Processor : à 2 channelized T1/E1 and PRI poorten à 256 channels in Cisco router mogelijk (?) IBM Channel Interface Processor : ivm escon, sna, mainframe connectie,… (nl. 1 of 2 bus and tag en/of 1 of 2 ESCON interfaces) Versatile Interface Processor (VIP) : à om in 1 slot van de router combinaties van verschillende media te ondersteunen (bvb. Ethernet en serial) à deze kaart bevat zelf veel packet memory : 512 Mb à vb van VIP : 4 Ethernet en 4 serial ports à vb van VIP : 1 Fast Ethernet en 4 Ethernet ports

11.5.6 Mogelijke “route switch processors” in deze routers • RSP1 (voor 7505)

•

•

• • • •

R4600 processor 100 Mhz o.a. 16 to 128 Mb DRAM memory, 1 Mb (=fixed) SRAM packet memory DRAM è voor routing tabel, protocols, accounting applications,… SRAM è voor packet buffering (en voor cache)

RSP2 (voor 7507 en 7513) • • •

R4600 processor 100 Mhz o.a. 16 to 128 Mb DRAM memory, 1 Mb (=fixed) SRAM packet memory ondersteunt high system availability (HSA)

RSP4 (voor 7505, 7507, 7513 en 7576) • • •

R5000 processor 200 Mhz o.a. 32 to 256 Mb DRAM memory, 2 Mb (=fixed) SRAM packet memory ondersteunt high system availability (HSA)

11.5.7 Verdere componenten in deze routers • • •

ARBITER : clock, round-robin priority scheme, global lock to shared data structures CHASSIS INTERFACE : monitoring environment (temperature, fan, power,…) FAN TRAY AND BLOWER ASSEMBLY


123

12 Referenties 12.1 Boeken [1] [2] [3] [4]

“Capacity Planning for Web Performance : metrix, models, and methods”, Daniel A. Menascé, Virgilio A.F. Almeida © 1998 Prentice Hall “chapter 9 : FORECASTING” van het boek “Applied Management Science : A ComputerIntegrated Approach for Decision Making”, John A. Lawrence JR, Barry A. Pasternack © … “HOOFDSTUK 10 : LINEAIRE REGRESSIE-ANALYSE“ uit “Waarschijnlijkheidsrekening en Statistiek, Prof. dr. ir. L. Taerwe, cursus 2e kan burg. ir.(RUG)” hoofdstukje HTTP protocol, p 344 from "A Guide to the TCP/IP Protocol Suite", by Floyd Wilder (©1998, ARTECH HOUSE INC.)

12.2 Artikelen,documenten en papers [5] [6] [7] [8] [9] [10] [11]

“Het remote access probleem” thesis van Kurt Devlaminck, RUG INTEC, 1997-1998 “Bandwidth pricing gets serious” artikel in Public Network, June1996 vol6 no6 “Ascend Resource Guide : 30 profit making tips for Internet Service Providers” pdf document 1998 White paper van Nortel Networks : “Remote Access Market and Product Evolution” (Shuang Deng, Ph.D) (http://www.nortelnetworks.com/products) “The THCMS Methodology for Evaluating Forecasting Systems”, Robert Carbone, Ph.D. © July 1999 “Measuring Web Site Usage : Log file Analysis” by Susan Haigh and Janette Megarity © 1998 “Why web usage statistics are (worse than) meaningless” by Jeff Goldberg (http://www.cranfield.ac.uk/docs/stats/)

12.3 Tutorials en documentatie [12] [13]

[14] [15]

[16]

[17] [18]

ANALOG (logfile analyzer) : “Readme for analog 4.03 : How the web works”, “Readme for analog 4.03 (the user manual)” (software en documentatie : http://www.analog.cx/ ) help documentation : forecasting module bij WINQSB (deel van “chapter 9 : FORECASTING” van het boek “Applied Management Science : A Computer-Integrated Approach for Decision Making”, John A. Lawrence JR, Barry A. Pasternack © …) “Getting Started With MATLAB”, David Hart (revised by Clinton Wolf (c) June 1999) http://www.indiana.edu/~statmath/math/matlab/gettingstarted/printable.pdf “A Practical Introduction to Matlab (Updated for Matlab 5) », Mark S. Gockenbach, Dep. of Math. Sciences, Michigan Technological University http://www.math.mtu.edu/~msgocken/intro/intro.html “MATLAB The Language of Technical Computing, Computation,Visualization,Programming, Getting Started with MATLAB, Version 5”, online documentatie (.pdf) bij MATLAB v5.0 Student Edition “MATLAB The Language of Technical Computing, Computation,Visualization,Programming, Using MATLAB, Version 5.3”, online documentatie (.pdf) bij MATLAB 5.3.1.29215a (R11.1) “Statistics Toolbox For use with MATLAB, Computation,Visualization,Programming, Guide, Version 2.1”, online documentatie (.pdf) bij MATLAB 5.3.1.29215a (R11.1)

12.4 Online webpages 12.4.1 Webpage artikelen van Datacomm Magazine (http://www.data.com) [19]

[20] [21]

“Close-Up on Remote Access Servers, High-end management and scalable throughput are getting RASs ready for the enterprise” webpage artikel in Datacomm Magazine door David Newman, Helen Holzbaur and John Fowler, 1996 “Tabel : The Remote Access Server Rundown” tabel gegenereerd door Datacomm Magazine “Remote Access Servers : No mess, No stress, Flexibility and modular features make new access servers right for today’s enterprise”, webpage artikel in Datacomm Magazine door Kieran Taylor, Juli 1996


124

[22]

“Internet Servers, A new class of turnkey Web servers helps corporate networkers take the effort out of the Internet”, webpage artikel in Datacomm Magazine door Erica Roberts, November 1997

12.4.2 Telecom-equipment [23] [24] [25]

[26] [27] [28]

[29] [30]

Product beschrijving van de MAX TNT Access Switch (Lucent & Ascend technologies) (http://www.lucent.com/dns/products/maxtnt en gerelateerde links) Informatie over ADSL producten bij Alcatel (o.a. http://www.alcatel.com/telecom/asd/keytech/adsl/) Informatie en beschrijving van de Cisco Access Servers (AS5x00 family) (http://www.cisco.com/warp/public/cc/cisco/mkt/access/accserv/index.shtml en gerelateerde links) Informatie over de Cisco 7500 series (High End router) (http://www.cisco.com/warp/public/cc/cisco/mkt/core/7500/index.shtml en gerelateerde links) Product beschrijving van de CVX 1800 Access Switch (Nortel Networks) (http://www.nortelnetworks.com/products/01/cvx/cvx_1800/ en gerelateerde links) Informatie en beschrijving van de Cisco 3600 Series (Access) Routers http://www.cisco.com/warp/public/cc/cisco/mkt/access/3600/prodlit/1fefx_ov.html en gerelateerde links) Informatie over de servers van IBM : http://www.ibm.com/servers/ Informatie over de servers van Compaq : http://www.compaq.com/alphaserver/servers.html


125

Universiteit Gent Faculteit Toegepaste Wetenschappen. Vakgroep Informatietechnologie (INTEC) Voorzitter : Prof. Dr. Ir. P. Lagasse

Recommend Documents