Скачать презентацию Design Implementation and Evaluation of Network Monitoring Tasks Скачать презентацию Design Implementation and Evaluation of Network Monitoring Tasks

10e486bf95ddf6c6fc67e3fdc1fe797c.ppt

  • Количество слайдов: 90

Design, Implementation, and Evaluation of Network Monitoring Tasks with the Telegraph. CQ Data Stream Design, Implementation, and Evaluation of Network Monitoring Tasks with the Telegraph. CQ Data Stream Management System INF 5100, Autumn 2006 Jarle Søberg INF 5100, Autumn 2006 © Jarle Søberg

Content l l l l Introduction Streaming Applications Data Stream Management Systems Telegraph. CQ Content l l l l Introduction Streaming Applications Data Stream Management Systems Telegraph. CQ Query Design System Implementation Performance Evaluation Conclusion INF 5100, Autumn 2006 © Jarle Søberg

Introduction l Network monitoring is important – – On-line Real-time Large amounts of data Introduction l Network monitoring is important – – On-line Real-time Large amounts of data A lot of programs exist l l Zone. Ranger Site. Alive In. Mon and so on … Source: http: //www. slac. stanford. edu/xorg/nmtf-tools. html INF 5100, Autumn 2006 © Jarle Søberg

Introduction l Different solutions based on the protocol standards – – – Cumbersome? Too Introduction l Different solutions based on the protocol standards – – – Cumbersome? Too specific? How about new protocols? Add-ons? Proprietary solutions? Written badly? INF 5100, Autumn 2006 © Jarle Søberg

Introduction l Declarative languages – – l Database management systems (SQL) The web (HTML) Introduction l Declarative languages – – l Database management systems (SQL) The web (HTML) Prolog What is solved? Use declarative languages to perform network monitoring! INF 5100, Autumn 2006 © Jarle Søberg

Introduction l A DBMS approach to network traffic analysis – – – l Declarative Introduction l A DBMS approach to network traffic analysis – – – l Declarative SQL queries Done after the traces are collected Real-time analysis is not possible “We need something that is declarative AND real-time!!” INF 5100, Autumn 2006 © Jarle Søberg

Introduction l Data stream management systems (DSMSs) – – E. g. SQL syntax Easy Introduction l Data stream management systems (DSMSs) – – E. g. SQL syntax Easy to learn Don’t have to be a programming expert Several DSMSs available (look at earlier INF 5100 lecture) l l STREAM Gigascope Borealis Aurora, Medusa Telegraph. CQ INF 5100, Autumn 2006 © Jarle Søberg

Introduction l We have chosen to evaluate the performance of Telegraph. CQ in an Introduction l We have chosen to evaluate the performance of Telegraph. CQ in an on-line network monitoring scenario – Build a general understanding/give a reminder of l l l Network monitoring DSMSs Telegraph. CQ INF 5100, Autumn 2006 © Jarle Søberg

Introduction – – – Create a set of network monitoring tasks Create a framework Introduction – – – Create a set of network monitoring tasks Create a framework for the network monitoring Evaluate the performance of Telegraph. CQ on the set of tasks provided Discuss and show results Conclude the performance evaluation INF 5100, Autumn 2006 © Jarle Søberg

Content l l l l Introduction Streaming Applications Data Stream Management Systems Telegraph. CQ Content l l l l Introduction Streaming Applications Data Stream Management Systems Telegraph. CQ Query Design System Implementation Performance Evaluation Conclusion INF 5100, Autumn 2006 © Jarle Søberg

Streaming Applications Revisited l The data stream model – A contrast to the traditional Streaming Applications Revisited l The data stream model – A contrast to the traditional stored data records l – – E. g. in databases On-line Un-ordered Un-bounded in size Append-only INF 5100, Autumn 2006 © Jarle Søberg

Streaming Applications Overview Streaming Applications Pull-Based Sensor Networks Push-Based Network Monitoring Others Network Traffic Streaming Applications Overview Streaming Applications Pull-Based Sensor Networks Push-Based Network Monitoring Others Network Traffic Measurement Active Passive Network Traffic Analysis INF 5100, Autumn 2006 © Jarle Søberg

Pull-Based Applications l Sensor networks revisited – – – Pull data from environment at Pull-Based Applications l Sensor networks revisited – – – Pull data from environment at certain intervals Wireless Minimize power usage Aggregate data before sending Locate and communicate with other sensors Send data streams to access points where the data is further analyzed INF 5100, Autumn 2006 © Jarle Søberg

Push-Based Applications l Network monitoring – Data packets l Protocol headers – l Header Push-Based Applications l Network monitoring – Data packets l Protocol headers – l Header fields Nice match for DSMS? – Let’s see! INF 5100, Autumn 2006 © Jarle Søberg

Content l l l l Introduction Streaming Applications Data Stream Management Systems Telegraph. CQ Content l l l l Introduction Streaming Applications Data Stream Management Systems Telegraph. CQ Query Design System Implementation Performance Evaluation Conclusion INF 5100, Autumn 2006 © Jarle Søberg

Data Stream Management Systems (DSMSs) Revisited l l Introduction Database management systems (DBMSs) versus Data Stream Management Systems (DSMSs) Revisited l l Introduction Database management systems (DBMSs) versus DSMSs – l A comparison Issues in DSMS – – Continuous queries and windows See earlier lecture for: l l Approximation and optimization Query languages INF 5100, Autumn 2006 © Jarle Søberg

DSMSs: Introduction l l l Pose queries on a stream of data Extract information DSMSs: Introduction l l l Pose queries on a stream of data Extract information in real-time Compared to DBMSs for simplicity – – – A data packet can be viewed as a tuple The header(s’) fields can be viewed as attributes Still, there are some critical differences between DBMSs and DSMSs INF 5100, Autumn 2006 © Jarle Søberg

DBMSs versus Persistent storage Transient queries Random access and finite data sets l l DBMSs versus Persistent storage Transient queries Random access and finite data sets l l l Unbounded storage Correct answers l Optimize once l l l l DSMSs Transient streams Persistent queries Sequential access and possibly unlimited data streams Memory limitations Throw away tuples and aggregate at high loads Adaptive INF 5100, Autumn 2006 © Jarle Søberg

Transient and persistent l Continuous queries – Run query at each instance of time Transient and persistent l Continuous queries – Run query at each instance of time l – Investigate each tuple Monotonic and append-only due to sequential access Give me all the messages that have not been replied to – Blocking of the data stream!! l l Must be avoided Stream is stopped and tuples are shedded INF 5100, Autumn 2006 © Jarle Søberg

Introducing Windows Give me all messages that have not been given a reply within Introducing Windows Give me all messages that have not been given a reply within five minutes after it has been sent l l l Partition data stream into smaller parts Use windows to unblock Different types: – – – Sliding Jumping Tumbling INF 5100, Autumn 2006 © Jarle Søberg

Windows l Sliding window l Jumping window l window Tumbling window window INF 5100, Windows l Sliding window l Jumping window l window Tumbling window window INF 5100, Autumn 2006 © Jarle Søberg

Storage? l Disk I/O is expensive! – – Can not store tuples to disk Storage? l Disk I/O is expensive! – – Can not store tuples to disk Can only watch tuples once l l – Dependent on memory and window size Query processing must be simple Windows solve the blocking problem INF 5100, Autumn 2006 © Jarle Søberg

Content l l l l Introduction Streaming Applications Data Stream Management Systems Telegraph. CQ Content l l l l Introduction Streaming Applications Data Stream Management Systems Telegraph. CQ Query Design System Implementation Performance Evaluation Conclusion INF 5100, Autumn 2006 © Jarle Søberg

Telegraph. CQ l l Introduction and overview Description of concepts – – – l Telegraph. CQ l l Introduction and overview Description of concepts – – – l l Wrappers Fjords Eddies Ste. Ms CACQ Other features A practical overview Limitations INF 5100, Autumn 2006 © Jarle Søberg

Telegraph. CQ: Introduction l l Developed at Berkeley Written in C – l l Telegraph. CQ: Introduction l l Developed at Berkeley Written in C – l l Based on the Postgre. SQL DBMS Current version: 2. 1 on Postgre. SQL 7. 3. 2 code base – l Open source GNU license Each group has a running copy on dmms-lab 107 Closed down Summer 2006 – Still, many interesting and important features to discuss INF 5100, Autumn 2006 © Jarle Søberg

Telegraph. CQ: Overview Postmaster Server Back end Fjords Eddies Ste. Ms CACQ Shared memory Telegraph. CQ: Overview Postmaster Server Back end Fjords Eddies Ste. Ms CACQ Shared memory queues Front end Planner Parser Listener Client Shared memory buffer pool Wrapper clearing house Disk INF 5100, Autumn 2006 © Jarle Søberg

Telegraph. CQ: Overview l Based on modules – – – l Query processing Adaptive Telegraph. CQ: Overview l Based on modules – – – l Query processing Adaptive routing Ingress and caching Communicate via Fjords – – Push and pull data in pipeline fashion Reduce overhead by non-blocking behavior INF 5100, Autumn 2006 © Jarle Søberg

Wrappers l l l Transform data to Datum items Push or pull Several formats Wrappers l l l Transform data to Datum items Push or pull Several formats – l l Contacted via TCP Wrapper clearing house (WCH) – l Comma separated format (CSV) is used by Telegraph. CQ Many connections possible Store streams to database if needed INF 5100, Autumn 2006 © Jarle Søberg

Wrappers l Shedded tuples, Data Triage – Support for dropping tuples l – Look Wrappers l Shedded tuples, Data Triage – Support for dropping tuples l – Look at Vera’s presentation about methods Periodically summarize tuple information shed – Shared Memory Buffer Pool Runs “shadow” queries on shedded tuples l Described later INF 5100, Autumn 2006 © Jarle Søberg

Eddies l DBMSs – – – Query plan created once E. g. joined on Eddies l DBMSs – – – Query plan created once E. g. joined on some attributes may give this plan: Ok, as long as data set is finite and pulled INF 5100, Autumn 2006 © Jarle Søberg

Eddies Blocking or throwing away tuples is unavoidable! l How about pushed data? INF Eddies Blocking or throwing away tuples is unavoidable! l How about pushed data? INF 5100, Autumn 2006 © Jarle Søberg

Eddies • Might be much changes in the different streams • Reconfiguration may take Eddies • Might be much changes in the different streams • Reconfiguration may take long time • Not dynamic enough l A reconfiguration is necessary INF 5100, Autumn 2006 © Jarle Søberg

Eddies • Dynamic on a tuple-per-tuple basis eddy • Adaptive to changes in the Eddies • Dynamic on a tuple-per-tuple basis eddy • Adaptive to changes in the stream l An alternative is to use an eddy: INF 5100, Autumn 2006 © Jarle Søberg

Eddies: Details l Bitmap per tuple represents each operator – – – ready and Eddies: Details l Bitmap per tuple represents each operator – – – ready and done bits The ready bits specifies the operators the tuple should visit Tuple is ready for output when all done bits are set Manipulate bits to set a route for a tuple On creation of new tuples due to e. g. joins: OR the bitmaps 1 0 0 0 tuple 1 0 1 1 tuple INF 5100, 1 0 1 1 Autumn 2006 © Jarle Søberg tuple

Eddies: Routing policy l Priority scheme – Tuples coming from an operator = high Eddies: Routing policy l Priority scheme – Tuples coming from an operator = high priority l l Originally: Back-pressure – – l Prevents starvation Self regulating due to queuing Naïve, hence not optimal Extended to lottery scheduling INF 5100, Autumn 2006 © Jarle Søberg

Eddies: Lottery scheduling l Each operator has ticket account – – l Credited for Eddies: Lottery scheduling l Each operator has ticket account – – l Credited for each arriving tuple Debited for each leaving tuple Lottery among available operators – – Empty in-queue: Fast operators High number of tickets: Low selectivity operators INF 5100, Autumn 2006 © Jarle Søberg

Eddies: Lottery scheduling l Low selectivity operators – – Win even if the operator Eddies: Lottery scheduling l Low selectivity operators – – Win even if the operator is slowing down Expand with a window scheme l l Banked tickets Escrow tickets 2 1 0 operator 0 5 4 3 2 1 window INF 5100, Autumn 2006 © Jarle Søberg

Eddies l l Works for single query environments Simple and adaptive May still not Eddies l l Works for single query environments Simple and adaptive May still not be optimal with respect to dynamic changes over e. g. a single join Extend the eddy’s strength by introducing state modules (Ste. Ms) INF 5100, Autumn 2006 © Jarle Søberg

Ste. Ms l Split joins in two – Dynamic T R – Send build Ste. Ms l Split joins in two – Dynamic T R – Send build tuples l – S eddy Build hash tables Send probe tuples l Look for matches R S T INF 5100, Autumn 2006 © Jarle Søberg

Ste. Ms l Any possible problems? S – l R Two equal intermediate tuples! Ste. Ms l Any possible problems? S – l R Two equal intermediate tuples! Solved by globally unique sequence number – Only youngest tuples allowed to match INF 5100, Autumn 2006 © Jarle Søberg

Ste. Ms: Issues l Ste. Ms are implemented using hash tables – l Only Ste. Ms: Issues l Ste. Ms are implemented using hash tables – l Only equi-joins work properly Alternatively, use B-trees – – Can correctly express more: “<>”, “>>”, “<=”, … Not fast enough for conference show-off? INF 5100, Autumn 2006 © Jarle Søberg

Eddies and Ste. Ms l l Still single-query environment DSMSs aim to support many Eddies and Ste. Ms l l Still single-query environment DSMSs aim to support many concurrent queries This feature needs to be adaptive and manage creation and deletion of queries in real-time Optimization is proven NP-hard INF 5100, Autumn 2006 © Jarle Søberg

Introducing CACQ l l Continuously adaptive continuous queries Heuristics – – l l Adding Introducing CACQ l l Continuously adaptive continuous queries Heuristics – – l l Adding more information to the tuples Creating even more meta information Avoid sending same singleton and intermediate tuples to same operators First of all: Use grouped filters! INF 5100, Autumn 2006 © Jarle Søberg

CACQ: Grouped Filters l Module for early filtering of selection predicates – For example: CACQ: Grouped Filters l Module for early filtering of selection predicates – For example: SELECT * FROM stream WHERE stream. a = 7 – – All tuples without stream. a = 7 are not sent to the eddy Includes “>”, “<”, and “ ”, as well INF 5100, Autumn 2006 © Jarle Søberg

The CACQ Tuple l l Extended the eddy tuple to include bitmaps for queries. The CACQ Tuple l l Extended the eddy tuple to include bitmaps for queries. Completed and source. Id The queries. Completed bitmap – – l Represents the queries Shows a lineage of the tuple The source. Id bitmap – Source when queries do not share tuples INF 5100, Autumn 2006 © Jarle Søberg

Eddies, Ste. Ms, and CACQ: Issues l Bitmap statically configured – l Faster, but Eddies, Ste. Ms, and CACQ: Issues l Bitmap statically configured – l Faster, but not dynamic Much overhead experienced by the developers – – Tuple-by-tuple processing takes time Batching tuples are suggested l Static for shorter periods INF 5100, Autumn 2006 © Jarle Søberg

Continuous Queries in Telegraph. CQ l Windowing supports sliding, hopping, and jumping behavior – Continuous Queries in Telegraph. CQ l Windowing supports sliding, hopping, and jumping behavior – – Aggregations are important for correct results Output does not start until window is reached when aggregations are used SELECT stream. color, COUNT(*) FROM stream [RANGE BY ‘ 9’ SLIDE BY ‘ 1’] GROUP BY stream. color window 2 2 2 1 1 1 INF 5100, Autumn 2006 © Jarle Søberg START OUPUT!

Other Information l Pros: – – – l Introspective streams Sub-queries, to some extent Other Information l Pros: – – – l Introspective streams Sub-queries, to some extent Shadow queries for Data Triage tuples Cons: – – OR is not understood Only istreams, and not dstreams Only six ANDs between Ste. Ms Telegraph. CQ is very unstable at high pressure INF 5100, Autumn 2006 © Jarle Søberg

Content l l l l Introduction Streaming Applications Data Stream Management Systems Telegraph. CQ Content l l l l Introduction Streaming Applications Data Stream Management Systems Telegraph. CQ Query Design System Implementation Performance Evaluation Conclusion INF 5100, Autumn 2006 © Jarle Søberg

Query Design and Implementation l l The IP/TCP header definition Three tasks for evaluation Query Design and Implementation l l The IP/TCP header definition Three tasks for evaluation – – – Two simple One complex and large Show we think when creating these tasks INF 5100, Autumn 2006 © Jarle Søberg

The IP/TCP Stream l l All TCP/IP header fields are included Use Telegraph. CQ’s The IP/TCP Stream l l All TCP/IP header fields are included Use Telegraph. CQ’s data types – – Try to save space Change most fields into integer values l – – – l smallint (16), int (32), and bigint (64) (all signed) Use the cidr data type for IP addresses Option fields as text Control bits as char(1) Eddy and CACQ bits are added as well INF 5100, Autumn 2006 © Jarle Søberg

Task 1 l Measure the average load of packets and network load per second Task 1 l Measure the average load of packets and network load per second over a one minute interval – – Two results simultaneously Create two different queries l l Sub-query Non-sub-query INF 5100, Autumn 2006 © Jarle Søberg

Task 1: Sub-query (task_1. 1) WITH streams. task 1 1 AS ( SELECT COUNT(*), Task 1: Sub-query (task_1. 1) WITH streams. task 1 1 AS ( SELECT COUNT(*), SUM(total. Length), wtime(*) FROM streams. iptcp [RANGE BY ’ 1 second’ SLIDE BY ’ 1 second’] ) (SELECT AVG(total. Num), AVG(total. Length)*8 FROM streams. task 1 1 [RANGE BY ’ 1 minute’ SLIDE BY ’ 1 second’]); INF 5100, Autumn 2006 © Jarle Søberg

Task 1: Non-sub-query (task_1. 2) SELECT COUNT(*)/60, AVG(s. total. Length) FROM streams. iptcp AS Task 1: Non-sub-query (task_1. 2) SELECT COUNT(*)/60, AVG(s. total. Length) FROM streams. iptcp AS s [RANGE BY ’ 1 minute’ SLIDE BY ’ 1 second’]; INF 5100, Autumn 2006 © Jarle Søberg

Task 2 l How many packets have been sent to certain ports during the Task 2 l How many packets have been sent to certain ports during the last five minutes? – – Join between table and stream Which ports are interesting? INF 5100, Autumn 2006 © Jarle Søberg

Task 2’s query SELECT wtime(*), streams. iptcp. dest. Port, COUNT(*) FROM streams. iptcp [RANGE Task 2’s query SELECT wtime(*), streams. iptcp. dest. Port, COUNT(*) FROM streams. iptcp [RANGE BY ’ 5 minutes’ SLIDE BY ’ 1 second’], ports WHERE ports. port = streams. iptcp. dest. Port GROUP BY streams. iptcp. dest. Port; INF 5100, Autumn 2006 © Jarle Søberg

Task 3: A Theoretical Approach l How many bytes have been exchanged on each Task 3: A Theoretical Approach l How many bytes have been exchanged on each connection during the last ten seconds? – Identify connections l We try to complicate the connection identification by looking at connection establishment – l Investigate payload’s size Overall task: Investigate protocol requirement INF 5100, Autumn 2006 © Jarle Søberg

Task 3: Connection establishment l The 3 -way handshake Sequence number 3 SYN 1 Task 3: Connection establishment l The 3 -way handshake Sequence number 3 SYN 1 0 ACK Acknowledgement number Client Closed SYN-sent Established 2 4 1 1 SYN-received Server Established Listen 4 3 0 1 INF 5100, Autumn 2006 © Jarle Søberg

Express establishment with query l Most ACK packets! Ohoh, what to do? SYN Merge Express establishment with query l Most ACK packets! Ohoh, what to do? SYN Merge 3 -way handshake Time window lasting for a given period SYN/ACK INF 5100, Autumn 2006 © Jarle Søberg

Task 3: Challenges l l All connections in first interval are not registered There Task 3: Challenges l l All connections in first interval are not registered There are time limitations for how long a connection can be stored No possibility of storing a connection in Telegraph. CQ and remove when connection is closed Telegraph. CQ only supports six Ste. Ms concurrently, needing to reduce the number of conditions INF 5100, Autumn 2006 © Jarle Søberg

Content l l l l Introduction Streaming Applications Data Stream Management Systems Telegraph. CQ Content l l l l Introduction Streaming Applications Data Stream Management Systems Telegraph. CQ Query Design System Implementation Performance Evaluation Conclusion INF 5100, Autumn 2006 © Jarle Søberg

System Implementation: fyaf l l l Simple filter for transforming binary packets to comma System Implementation: fyaf l l l Simple filter for transforming binary packets to comma separated values (CSVs) understood by Telegraph. CQ Use the pcap interface Monitors the stream and itself – – l Runs two threads to stop after a time-to-live after the final tuple – l l Harder to implement such behavior using Linux programs like sed and awk More control and less possible sources of failure Precise with regard to start and stop Batch monitor Higher throughput than the DSMSs INF 5100, Autumn 2006 © Jarle Søberg

Experiment Setup Computer B Computer A TG NIC Header NIC TG Payload fyaf DSMS Experiment Setup Computer B Computer A TG NIC Header NIC TG Payload fyaf DSMS INF 5100, Autumn 2006 © Jarle Søberg

Content l l l l Introduction Streaming Applications Data Stream Management Systems Telegraph. CQ Content l l l l Introduction Streaming Applications Data Stream Management Systems Telegraph. CQ Query Design System Implementation Performance Evaluation Conclusion INF 5100, Autumn 2006 © Jarle Søberg

Performance evaluation l Metrics – Relative throughput l – Accuracy l – How much Performance evaluation l Metrics – Relative throughput l – Accuracy l – How much data the DSMS receives versus how much it manages to compute Are the results correct? Consumption l l Memory CPU INF 5100, Autumn 2006 © Jarle Søberg

Performance evaluation l Factors – l Network load Evaluation technique – Measurements INF 5100, Performance evaluation l Factors – l Network load Evaluation technique – Measurements INF 5100, Autumn 2006 © Jarle Søberg

Performance evaluation l Workload selection – TCP packets l The TG traffic generator – Performance evaluation l Workload selection – TCP packets l The TG traffic generator – l l Manages to create accurate loads up to approx. 10 Mbits/s (according to sar output) Packet size of 576 bytes How is this for the eddy with respect to load shedding? INF 5100, Autumn 2006 © Jarle Søberg

Telegraph. CQ Monitors l Use shadow queries for shedded tuples Wrapper Telegraph. CQ – Telegraph. CQ Monitors l Use shadow queries for shedded tuples Wrapper Telegraph. CQ – Both count kept and dropped tuples l – Gives relative throughput Use introspective queries INF 5100, Autumn 2006 © Jarle Søberg

Telegraph. CQ Monitors l Use introspective streams – Queries about inner life in Telegraph. Telegraph. CQ Monitors l Use introspective streams – Queries about inner life in Telegraph. CQ l l – Queues Modules Not very much implemented l Hard to obtain any useful information INF 5100, Autumn 2006 © Jarle Søberg

Simple Filtering Task l l Three tasks projecting “*”, “sourceip, sourceport, destip, destport”, “destport” Simple Filtering Task l l Three tasks projecting “*”, “sourceip, sourceport, destip, destport”, “destport” Using both introspective queries and not – – Intro: called task_101, task_101. 1, and task_101. 2 Non-intro: called task_101. 3, task_101. 4, and task_101. 5 INF 5100, Autumn 2006 © Jarle Søberg

Relative Throughput: Simple filtering INF 5100, Autumn 2006 © Jarle Søberg Relative Throughput: Simple filtering INF 5100, Autumn 2006 © Jarle Søberg

Load Shedding Accuracy l See how accurate Telegraph. CQ is – – fyaf should Load Shedding Accuracy l See how accurate Telegraph. CQ is – – fyaf should not drop any packets since Telegraph. CQ supports load shedding We investigated log files from both Telegraph. CQ and fyaf on the filtering task l – For both introspective (lines) and non-introspective tasks (linespoints) Found relation by dividing between fyaf’s and Telegraph. CQ’s results INF 5100, Autumn 2006 © Jarle Søberg

Load Shedding Accuracy INF 5100, Autumn 2006 © Jarle Søberg Load Shedding Accuracy INF 5100, Autumn 2006 © Jarle Søberg

Conclusion, Filtering l Projecting few attributes using introspective queries seems to be most accurate Conclusion, Filtering l Projecting few attributes using introspective queries seems to be most accurate – So we do this for the remaining tasks INF 5100, Autumn 2006 © Jarle Søberg

Task 1 l Measure the average load of packets and network load per second Task 1 l Measure the average load of packets and network load per second over a one minute interval l task_1. 1 with sub-query task_1. 2 without sub-query l INF 5100, Autumn 2006 © Jarle Søberg

Task 1: Relative throughput INF 5100, Autumn 2006 © Jarle Søberg Task 1: Relative throughput INF 5100, Autumn 2006 © Jarle Søberg

Task 1: Relative throughput l task_1. 1 probably faster because of the aggregation streams. Task 1: Relative throughput l task_1. 1 probably faster because of the aggregation streams. iptcp l Q 1 streams. task_1. 1 Q 2 Still, not that much faster – – – If one eddy, the eddy still has to manage a lot of tuples Eddy versus Ste. Ms Remember how and where the shedding is performed… INF 5100, Autumn 2006 © Jarle Søberg

Task 1: Accuracy INF 5100, Autumn 2006 © Jarle Søberg Task 1: Accuracy INF 5100, Autumn 2006 © Jarle Søberg

Task 1 l l Telegraph. CQ manages to perform simple aggregations to investigate a Task 1 l l Telegraph. CQ manages to perform simple aggregations to investigate a stream Low relative throughput – – Can possibly use shedded tuple information in real-time to adjust for failure Can use a sub-query to aggregate smaller partitions of the stream l Still uncertain how large this window should be INF 5100, Autumn 2006 © Jarle Søberg

Task 2 l l How many packets have been sent to certain ports during Task 2 l l How many packets have been sent to certain ports during the last five minutes? Run at three different table sizes – – l l l 65536, 1024, and 1 Ste. Ms use hash lookups at O(1) task_2. 1: 65536 ports task_2. 2: 1025 ports task_2. 3: 1 port INF 5100, Autumn 2006 © Jarle Søberg

Task 2: Relative Throughput INF 5100, Autumn 2006 © Jarle Søberg Task 2: Relative Throughput INF 5100, Autumn 2006 © Jarle Søberg

Task 2: Relative throughput, task_2. 1 INF 5100, Autumn 2006 © Jarle Søberg Task 2: Relative throughput, task_2. 1 INF 5100, Autumn 2006 © Jarle Søberg

Task 2: Accuracy, task_2. 1 INF 5100, Autumn 2006 © Jarle Søberg Task 2: Accuracy, task_2. 1 INF 5100, Autumn 2006 © Jarle Søberg

Task 2: Accuracy l Use sar to verify accuracy for 1 Mbits/s l What Task 2: Accuracy l Use sar to verify accuracy for 1 Mbits/s l What do we see? – – – Memory and CPU? Internal adaptation? Some kind of other adaptation? l Run for one hour to investigate patterns INF 5100, Autumn 2006 © Jarle Søberg

Task 2: Equilibrium INF 5100, Autumn 2006 © Jarle Søberg Task 2: Equilibrium INF 5100, Autumn 2006 © Jarle Søberg

Task 2: Equilibrium l At 5 Mbits/s – Converge to approx 188 packets each Task 2: Equilibrium l At 5 Mbits/s – Converge to approx 188 packets each second l – l About 1 Mbits/s Analytical modeling may help predicting the future behavior of the relative throughput Future work: Look at aggregations! – Though, remember throughput from other tasks… INF 5100, Autumn 2006 © Jarle Søberg

Content l l l l Introduction Streaming Applications Data Stream Management Systems Telegraph. CQ Content l l l l Introduction Streaming Applications Data Stream Management Systems Telegraph. CQ Query Design System Implementation Performance Evaluation Conclusion INF 5100, Autumn 2006 © Jarle Søberg

Conclusions about Telegraph. CQ l Ok support for basic requirements – Problems expressing protocols Conclusions about Telegraph. CQ l Ok support for basic requirements – Problems expressing protocols l l Not that fast for high traffic monitoring – – 2 -2. 5 Mbits/s just for filtering in our current setup Has to perform heavy aggregations l l l E. g. connection establishment Loose fine granularity information, e. g. single packets Accurate Unstable INF 5100, Autumn 2006 © Jarle Søberg

Conclusion about DSMSs and network monitoring l Interesting application for DSMSs – – l Conclusion about DSMSs and network monitoring l Interesting application for DSMSs – – l Simple way of describing data streams Still interesting to look at several other DSMSs for applicability, expressiveness, and accuracy Ideas: – Declarative protocol descriptions in dynamic and self aware and self configuring networks? INF 5100, Autumn 2006 © Jarle Søberg

Questions? ? INF 5100, Autumn 2006 © Jarle Søberg Questions? ? INF 5100, Autumn 2006 © Jarle Søberg