1 / 22

Efficient Monitoring of QoS Parameters (EMQP)

Efficient Monitoring of QoS Parameters (EMQP). Authors: Vadim Drabkin Arie Orlovsky Constantine Elster. Instructors: Dr. Danny Raz Mr. Ran Wolff. EMQP - Document Structure. Introduction Overview Terms and Conditions Proposed Solution Program Flow Implementation Issues Results

louis
Download Presentation

Efficient Monitoring of QoS Parameters (EMQP)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Efficient Monitoring of QoS Parameters (EMQP) Authors: Vadim Drabkin Arie Orlovsky Constantine Elster Instructors: Dr. Danny Raz Mr. Ran Wolff

  2. EMQP - Document Structure • Introduction • Overview • Terms and Conditions • Proposed Solution • Program Flow • Implementation Issues • Results • Conclusion Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  3. EMQP - Introduction Today’s Internet delivers "best-effort" performance dictated by the very design of the Internet Protocol (IP). That is, traffic is processed as quickly as possible, but there is no guarantee as to timeliness or actual delivery. Consequently, important business applications packets such as real-time video or audio packets could be lost or to be delivered too late because of displacement by less important packets. This leads to the need for Quality of Service in order to provide a consistent predictable data delivery service for different kinds of packets. Quality of Service (QoS) is an umbrella term for a collection of technologies that allow network-aware applications to request and receive predictable service levels in terms of data throughput capacity (bandwidth), latency variations (jitter) and propagation latency. Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  4. EMQP - Overview • The EMQP project comes to introduce an algorithm proposed by Dr. Danny Raz and Mr. Ran Wolff. • The EMQP aims to achieve an efficient monitoring of network traffic. • One of the main goals is discovering if the proposed algorithm is more efficient than currently proposed techniques in the case of monitoring heavy traffic networks. • The EMQP project comes to test the proposed algorithm by means of network simulator, which has the monitoring capability of the proposed algorithm. Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  5. EMQP – Terms and Conditions • Network Topology • a graph with nodes and edges • Node – a host connected to network • Edge - hop-to-hop path between two nodes • Stream • A path between two nodes in a given network. • Latency – metric value of an edge • the cost of going from one of the edge’s end to the another edge’s end. • Latency threshold • Local problem considered, if an edge’s latency is greater than its latency threshold. Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  6. EMQP – Terms and Conditions (cont.) • Stream latency • The sum of latencies of stream edges • Threshold for stream latency • maximum allowed stream latency • Considered as a stream problem if greater than stream latency • Bandwidth Broker • The controlling host managing network streams Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  7. EMQP – Proposed Solution • The algorithm outline • Every edge checks if its latency exceeds its latency threshold for every stream going through the edge. • If it does – trigger message to the next edge of the stream containing: • Edge latency • Latency threshold • The stream identificator Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  8. EMQP – Proposed Solution (cont.) • The algorithm outline (cont.) • If edge receives a message • Checks if received latency is greater than stream latency threshold • If true – report about the stream problem to the bandwidth broker. • Otherwise: checks if the (received latency + edge latency) is greater than (received latency threshold + edge’s latency threshold) • If true - send to the next stream’s edge: • (received latency + edge) • (received latency threshold + edge’s latency threshold) • Stream identificator Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  9. n1 latency = 2 latency threshold = 1 e1 n2 latency = 4 latency threshold = 6 e2 n3 • Figure 3. • n2 triggers <route, 2, 1> message to n3. • n3 gets the message, but does not forward any information to other edges, since 2 + 4 < 1 + 6 EMQP – Proposed Solution (cont.) Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  10. Object Text File Network Model Stream Generator (BFS & Distribution) Brite Parser Network Model Brite Object Object Results Data Network Model Containing streams Graph Generator EMQP EMQP – Program Flow Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  11. EMQP – Implementation Issues • Message driven • Messages are stored in message queue • Delivered by nodes • Messages are delivered to nodes • Node answers whether it wants to deliver a new message Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  12. EMQP – Implementation Issues (cont.) Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  13. Results 100 nodes 100 streams average fan out 4 latency deviation 0.1 average latency 0.93 Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  14. Results (cont.) 100 nodes 100 streams average fan out 4 latency deviation 0.1 average latency 0.97 Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  15. Results (cont.) 100 nodes 100 streams average fan out 4 latency deviation 0.1 average latency 1.0 Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  16. Results (cont.) 100 nodes 100 streams average fan out 4 latency deviation 0.1 average latency 1.025 Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  17. Results (cont.) 100 nodes 100 streams average fan out 4 latency deviation 0.1 average latency 1.05 Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  18. Results (cont.) 50 streams 200 streams 100 streams Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  19. Results (cont.) 100 nodes Variable number of streams Average fan out 4 Latency deviation 0.1 Average latency 0.95 Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  20. Results (cont.) 50 streams 100 streams 200 streams Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  21. Results (cont.) 100 nodes 100 streams Variable average fan out Latency deviation 0.1 Average latency 0.95 Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

  22. Results - Conclusion • The EMQP algorithm has significantly better performance than the standard 1 • EMQP algorithm has better performance than standard 2 when the possibility of edge problem decreases • It leaves us the the main drawback of the EMQP algorithm, which appears when there is high possibility of message triggering from several stream points, which in addition causes several messages sent to Bandwidth Broker addressed from the same stream. In such cases we see that the standard 2 performs better despite of its simplicity • It could require an extra work on finding how to eliminate the unnecessary traffic. One can think on a way of sending the messages to both directions and then eliminating the unnecessary message in their meeting point Vadim Drabkin, Constantine Elster, Arie Orlovsky, Technion I.I.T. 2002

More Related