16 |
.. Affect-PEGs: |
.. Affect-PEGs: |
17 |
|
|
18 |
|
|
19 |
Performing GISP simulations we can increase our understanding about |
Performing GISP P2P simulations with Storm we can increase our understanding |
20 |
GISP's scalability properties and on the other hand, possible issues |
about GISP's scalability properties and on the other hand, possible issues |
21 |
related to scalability. Also, we want to know how GISP outperforms |
related to scalability. Also, we want to know how GISP outperforms |
22 |
against different threats such as network partition or security |
against different threats such as network partition or security |
23 |
attacks. |
attacks. |
31 |
First of all, we will create a PEG document (this document) which |
First of all, we will create a PEG document (this document) which |
32 |
discusses general aspects of the simulation process. Then, we plan |
discusses general aspects of the simulation process. Then, we plan |
33 |
to program (rather short) test cases which will test the GISP/Storm |
to program (rather short) test cases which will test the GISP/Storm |
34 |
P2P properties, discussed in this document. Finally, we wish to |
P2P properties, as discussed in this document. Finally, we will |
35 |
collect and analyse test cases' information and use this information |
collect and analyse test cases' information and use this information |
36 |
later on in our manuscripts. |
in the future in our manuscripts. |
37 |
|
|
38 |
|
We plan to perform all simulations on a single computer using the |
39 |
|
local loopback network interface to communicate with each other. The |
40 |
|
purpose is that Storm-servers would act as if they were on different |
41 |
|
machines. The simulation is ran under a standard Linux/Java environment. |
42 |
|
|
43 |
Research problems |
Research problems |
44 |
================= |
================= |
45 |
|
|
46 |
By using simulation as a research method, we try to test different kinds of |
By using simulation as a research method, we try to test different kinds of |
47 |
properties of the GISP protocol. There are number of research problems which |
properties of the GISP protocol without having to deploy real life experiments. |
48 |
we try to solve using the simulation process: |
There are number of research problems which we try to solve (or understand |
49 |
|
better) using the simulation process: |
50 |
- How well GISP can scale is there are lot of concurrent peer joins and |
|
51 |
leaves in the system ? What about effieciency ? |
- How well GISP can scale if there are lot of concurrent peer joins and |
52 |
|
leaves in the system ? What about lookup effieciency when the network |
53 |
|
grows ? |
54 |
|
|
55 |
- How well GISP gisp is able to perform in adverse conditions, e.g., a |
- How well GISP is able to perform in adverse conditions, e.g., a |
56 |
network partition occurs ? |
network partition occurs ? |
57 |
|
|
58 |
- How well GISP gisp is able to perform against different kind of |
- How well GISP is able to perform against different kind of |
59 |
security attacks and what are the impacts ? |
security attacks and what are the impacts ? |
60 |
|
|
61 |
|
|
62 |
|
For now, we assume that simulation network is rather optimal, e.g., there |
63 |
|
are no network latencies in the simulation network. In the future, however, |
64 |
|
we plan to perform simulations in a non-optimal network. |
65 |
|
|
66 |
Hypothesis |
Hypothesis |
67 |
========== |
========== |
68 |
|
|
69 |
Scalability |
- GISP can scale rather well when peers join and leave the system at a |
70 |
----------- |
constant/static rate for a given time period and cost of joining/leaving |
71 |
|
is logarithmic (e.g. Start with 1000 blocks and 1000 Storm-servers, 10 |
72 |
- GISP can scale well when peers join and leave the system at a |
peer(s) joins/leaves every 5 seconds). |
|
constant rate for a given time period |
|
73 |
|
|
74 |
- GISP cannot scale well when peers join and leave the system at a |
- GISP can scale well and is adaptable if the cost of join/leave is |
75 |
(huge) variable rate for a given time period |
logarithmic when peers join and leave the system constantly |
76 |
|
and the variable rate for joining/leaving changes greatly (e.g., Start with 1000 |
77 |
|
blocks and 1000 Storm-servers. 1-10 peer(s) joins/leaves every 1-10 second(s), |
78 |
|
at a given time suddenly 100-900 peers joins/leaves randomly). |
79 |
|
|
80 |
|
- GISP's data lookup is efficient if the number of of lookup length grows with a |
81 |
|
logarithmic growth inspite that the number of Storm-servers increases |
82 |
|
linearly (e.g. 10-10000 Storm-servers, 10000 Storm blocks, with 10-10000 |
83 |
|
Storm-servers perform 10000 lookups randomly) |
84 |
|
|
85 |
- A GISP peer is not able to handle all request properly when great amount |
- A GISP peer is not able to handle all request properly when great amount |
86 |
of query requests are performed toward a single peer (a peer is |
of query requests are performed towards a single peer/few peers (a peer is |
87 |
responsible for a given key). Thus, there can be query hotspots |
responsible for a given key). Thus, there can be query/routing hotspots |
88 |
in the system. |
in the system and load balancing properties may not scalable/tolerance |
89 |
|
against a hostile attack (e.g., 1000 Storm-server system, each server |
90 |
- GISP can scale well if the number of peers and and Storm blocks |
hosting 1-10 Storm block(s), 1-900 peers (randomly chosen) queries a |
91 |
increase side by side and logarithmic efficiency still holds |
single key every 1-10 second(s); calculate average block request |
92 |
|
failure, average lookup length, number of timed-out lookups and |
93 |
- GISP can well if there are heterogeneous peers and logarithmic |
the distribution of lookup messages processed per peer). |
94 |
data lookup efficiency still holds |
|
95 |
|
- GISP is is rather fault-tolerant if 80% of lookups are succesful when 20% of |
96 |
- A java based GISP implementation does not consume much memory if |
peers die (This is Chord's simulation result) (e.g., 1000 Storm blocks are |
97 |
it requires less than X Mb of memory |
insterted into a 1000 Storm-server system. After insertions, 1-99% of |
98 |
|
servers die randomly or in a controlled way. Before GISP starts rebuilding |
99 |
|
routing tables, perform 1000 Storm block fetches; calculate average block |
100 |
Adverse conditions |
request failure, average lookup length and number of timed-out lookups). |
|
------------------ |
|
|
|
|
|
- GISP is not able to self-organize fast enough/efficienly after a fatal network |
|
|
partition, i.e., half of the peers "die" suddenly |
|
|
|
|
|
|
|
|
Security |
|
|
-------- |
|
101 |
|
|
102 |
- A hostile entity is able to reroute a data lookup to a incorrect |
- A hostile entity is able to reroute a data lookup to a incorrect |
103 |
destination peer during a data lookup process |
destination peer during a data lookup process (e.g., e.g., 1000 Storm |
104 |
|
blocks are insterted into a 1000 Storm-server system in which a a fraction |
105 |
|
of peers are hostile. Perform data lookups 1000 lookups randomly so that |
106 |
|
in every lookup process, one forwarding request is rerouted incorrectly towards |
107 |
|
randomly chosen destionation peer; calculate average block request failure, |
108 |
|
average lookup length, number of timed-out lookups and the distribution of |
109 |
|
lookup messages processed per peer). |
110 |
|
|
111 |
|
|
112 |
Issues |
Issues |
113 |
====== |
====== |
114 |
|
|
115 |
Write something... |
How many virtual peers we are able to simulate on a single machine (e.g., |
116 |
|
with 256Mb of memory) ? |
117 |
|
|
118 |
|
|
119 |
Changes |
Changes |
120 |
======= |
======= |
121 |
|
|
122 |
Then, there can be free-form sections in which the changes proposed |
We will program simulation test cases into the Storm CVS module. Currently, |
123 |
are detailed. |
no changes are required to the Storm implementation codebase. |
124 |
|
|