17 |
|
|
18 |
|
|
19 |
Performing GISP P2P simulations with Storm we can increase our understanding |
Performing GISP P2P simulations with Storm we can increase our understanding |
20 |
about GISP's scalability properties and on the other hand, possible issues |
GISP's scalability properties. Also, we want to know how GISP performs |
|
related to scalability. Also, we want to know how GISP outperforms |
|
21 |
against different threats such as network partition or security |
against different threats such as network partition or security |
22 |
attacks. |
attacks. If not separately mentioned, in this context we mean with |
23 |
|
"Storm" as an entity which is able to do a (limited/simplified) number |
24 |
|
of Storm's functionalies. |
25 |
|
|
26 |
|
This PEG discusses research problems, hypotheses, the theoretical |
27 |
|
knowledge we have about the hypotheses, and possible simulations to |
28 |
|
validate hypotheses. |
29 |
|
|
30 |
|
|
31 |
|
Issues |
32 |
|
====== |
33 |
|
|
34 |
|
ISSUE: |
35 |
|
|
36 |
|
How many concurrent "Storm" entities with blocks are we able to simulate |
37 |
|
on a single machine (e.g., with 256Mb of memory) ? |
38 |
|
|
39 |
|
ISSUE: |
40 |
|
|
41 |
|
In the future, do we want to perform simulations in a LAN cluster (or |
42 |
|
relevant) ? |
43 |
|
|
44 |
|
RESOLVED: Yes, if we want to simulate huge virtual networks and/or |
45 |
|
memory requirements are too massive for a single desktop. |
46 |
|
|
47 |
|
ISSUE: |
48 |
|
|
49 |
|
For now, do we need "real" Storm servers or blocks during simulations |
50 |
|
or not ? |
51 |
|
|
52 |
|
RESOLVED: No, since we want to make our simulator environment |
53 |
|
as lightweight as possible (See issue #1). |
54 |
|
|
55 |
|
|
56 |
|
ISSUE: |
57 |
|
|
58 |
|
Why GISP? Why are we using it versus some other systems? |
59 |
|
What properties does it share with others, to such a degree |
60 |
|
that its performance might be deduced from theirs? |
61 |
|
|
62 |
|
ISSUE: |
63 |
|
|
64 |
|
What experiments / simulations / methods are used in the literature? |
65 |
|
|
|
This PEG discusses how these simulations should be planned, what are |
|
|
the research problems, hypothesis and issues. |
|
66 |
|
|
67 |
Plan |
Plan |
68 |
==== |
==== |
69 |
|
|
70 |
First of all, we will create a PEG document (this document) which |
First of all, we will create a PEG document (this document) which |
71 |
discusses general aspects of the simulation process. Then, we plan |
discusses general/theoretical aspects of the research problems. Then, |
72 |
to program (rather short) test cases which will test the GISP/Storm |
if necessary, we program (rather short) test cases which will test |
73 |
P2P properties, as discussed in this document. Finally, we will |
the GISP/Storm P2P properties, as discussed in this document. Finally, we will |
74 |
collect and analyse test cases' information and use this information |
collect and analyse test cases' information and publish any interesting |
75 |
in the future in our manuscripts. |
discoveries. |
|
|
|
|
We plan to perform all simulations on a single computer using the |
|
|
local loopback network interface to communicate with each other. The |
|
|
purpose is that Storm-servers would act as if they were on different |
|
|
machines. The simulation is ran under a standard Linux/Java environment. |
|
76 |
|
|
77 |
Research problems |
The GISP protocol |
78 |
================= |
================= |
79 |
|
|
80 |
By using simulation as a research method, we try to test different kinds of |
- GISP_ protocol resembles Kademlia_ |
81 |
properties of the GISP protocol without having to deploy real life experiments. |
- XOR-metrin for distances |
82 |
There are number of research problems which we try to solve (or understand |
- lacks of binary-tree abstraction ? |
83 |
better) using the simulation process: |
- uses Chord_'s extended routing table - more space for caching |
84 |
|
(Log^2 messages) |
85 |
|
- replicates in a same way as Kademlia |
86 |
|
- no concurrent RPCs during lookup -- no free of choice during |
87 |
|
lookups ? |
88 |
|
|
89 |
|
|
90 |
|
Research problems |
91 |
|
================= |
92 |
|
|
93 |
|
For determining whether Storm with unmodified GISP is practical, we want the |
94 |
|
answers to the following questions. |
95 |
|
|
96 |
- How well GISP can scale if there are lot of concurrent peer joins and |
- How well GISP can scale if there are lot of concurrent peer joins and |
97 |
leaves in the system ? What about lookup effieciency when the network |
leaves in the system ? |
98 |
grows ? |
|
99 |
|
- What about GISP's lookup effieciency when the network grows ? |
100 |
|
|
101 |
|
- GISP does not use Kademlia's binary-tree abstraction - does it have influence |
102 |
|
anf yes, what are the influences ? |
103 |
|
|
104 |
- How well GISP is able to perform in adverse conditions, e.g., a |
- How well GISP is able to perform in adverse conditions, e.g., a |
105 |
network partition occurs ? |
network partition occurs ? |
107 |
- How well GISP is able to perform against different kind of |
- How well GISP is able to perform against different kind of |
108 |
security attacks and what are the impacts ? |
security attacks and what are the impacts ? |
109 |
|
|
|
|
|
|
For now, we assume that simulation network is rather optimal, e.g., there |
|
|
are no network latencies in the simulation network. In the future, however, |
|
|
we plan to perform simulations in a non-optimal network. |
|
110 |
|
|
111 |
|
Simulations |
112 |
|
=========== |
113 |
|
|
114 |
|
If needed, using a simulation process we try solve research problems. Also, |
115 |
|
with a simulation process we are able test the GISP protocol without having |
116 |
|
to deploy real life experiments. |
117 |
|
|
118 |
|
During simulation process, we assume that simulation network is rather ideal, |
119 |
|
e.g., there are no network latencies in the simulation network. In the future, |
120 |
|
however, we plan to perform simulations in a non-ideal network. |
121 |
|
|
122 |
|
|
123 |
Hypothesis |
Hypothesis |
124 |
========== |
========== |
125 |
|
|
126 |
- GISP can scale rather well when peers join and leave the system at a |
In this section we introduce few hypothesis related to research problems. |
127 |
constant/static rate for a given time period and cost of joining/leaving |
Hypothesis are based on the simulation processes which are used in the |
128 |
is logarithmic (e.g. Start with 1000 blocks and 1000 Storm-servers, 10 |
literature. Also, values presented here (e.g., 1000-10000) are widely used |
129 |
peer(s) joins/leaves every 5 seconds). |
in simulation processes. |
130 |
|
|
131 |
|
|
132 |
|
- GISP's overlay can scale rather well when peers join and leave the system at a |
133 |
|
constant rate or constant fraction (both are used) for a given time period |
134 |
|
and cost of joining/leaving is logarithmic (e.g. Start with 1000 blocks and |
135 |
|
1000 Storm-servers, 10 peer(s) joins/leaves every 5 seconds). |
136 |
|
|
137 |
- GISP can scale well and is adaptable if the cost of join/leave is |
- GISP's overlay can scale well and is adaptable if the cost of join/leave is |
138 |
logarithmic when peers join and leave the system constantly |
logarithmic when peers join and leave the system constantly |
139 |
and the variable rate for joining/leaving changes greatly (e.g., Start with 1000 |
and the variable rate for joining/leaving changes greatly (e.g., Start with 1000 |
140 |
blocks and 1000 Storm-servers. 1-10 peer(s) joins/leaves every 1-10 second(s), |
blocks and 1000 Storm-servers. 1-10 peer(s) joins/leaves every 1-10 second(s), |
141 |
at a given time suddenly 100-900 peers joins/leaves randomly). |
at a given time suddenly 100-900 peers joins/leaves randomly). |
142 |
|
|
143 |
- GISP's data lookup is efficient if the number of of lookup length grows with a |
- GISP's data lookup is efficient and can scale if lookup's length grows with a |
144 |
logarithmic growth inspite that the number of Storm-servers increases |
logarithmic growth inspite that the number of Storm-servers increases |
145 |
linearly (e.g. 10-10000 Storm-servers, 10000 Storm blocks, with 10-10000 |
linearly (e.g. 10-10000 Storm-servers, 10000 Storm blocks, with 10-10000 |
146 |
Storm-servers perform 10000 lookups randomly) |
Storm-servers perform 10000 lookups randomly) |
169 |
in every lookup process, one forwarding request is rerouted incorrectly towards |
in every lookup process, one forwarding request is rerouted incorrectly towards |
170 |
randomly chosen destionation peer; calculate average block request failure, |
randomly chosen destionation peer; calculate average block request failure, |
171 |
average lookup length, number of timed-out lookups and the distribution of |
average lookup length, number of timed-out lookups and the distribution of |
172 |
lookup messages processed per peer). |
lookup messages processed per peer). |
|
|
|
|
|
|
|
Issues |
|
|
====== |
|
|
|
|
|
- How many virtual peers and Storm blocks we are able to simulate on a single |
|
|
machine (e.g., with 256Mb of memory) ? |
|
|
|
|
|
- In the future, do we want to perform simulations in a LAN cluster (or |
|
|
relevant) ? |
|
|
|
|
|
RESOLVED: Yes, if we want to simulate huge virtual networks and/or |
|
|
memory requirements are too massive for a single desktop. |
|
|
|
|
|
- For now, do we need "real" Storm blocks during simulations or not ? |
|
|
|
|
|
RESOLVED: No, since we want to make our simulator environment |
|
|
as lightweight as possible (See issue #1). In the future, however, it is |
|
|
possible that we use "real" Storm blocks instead of "number" blocks. |
|
173 |
|
|
174 |
|
|
175 |
Changes |
Changes |
176 |
======= |
======= |
177 |
|
|
178 |
We will program simulation test cases into the Storm CVS module. Currently, |
If we decide to perform simulations, we will program simulation test cases |
179 |
no changes are required to the Storm implementation codebase. |
into the Storm CVS module. No changes are required to the Storm implementation |
180 |
|
codebase. |
181 |
|
|
182 |
|
|
183 |
|
.. _GISP: http://gisp.jxta.org |
184 |
|
.. _Kademlia: http://kademlia.scs.cs.nyu.edu |
185 |
|
.. _Chord: http://www.pdos.lcs.mit.edu/chord/ |