48 |
There are number of research problems which we try to solve (or understand |
There are number of research problems which we try to solve (or understand |
49 |
better) using the simulation process: |
better) using the simulation process: |
50 |
|
|
51 |
- 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 |
52 |
leaves in the system ? What about lookup effieciency when the network |
leaves in the system ? What about lookup effieciency when the network |
53 |
grows ? |
grows ? |
54 |
|
|
55 |
- 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 |
56 |
network partition occurs ? |
network partition occurs ? |
57 |
|
|
58 |
- How well 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 |
For now, we assume that simulation network is rather optimal, e.g., there |
66 |
Hypothesis |
Hypothesis |
67 |
========== |
========== |
68 |
|
|
69 |
- GISP can scale rather well when peers join and leave the system at a |
- 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 |
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 |
is logarithmic (e.g. Start with 1000 blocks and 1000 Storm-servers, 10 |
72 |
peer(s) joins/leaves every 5 seconds). |
peer(s) joins/leaves every 5 seconds). |
73 |
|
|
74 |
- GISP can scale well and is adaptable if the cost of join/leave is |
- GISP can scale well and is adaptable if the cost of join/leave is |
75 |
logarithmic when peers join and leave the system constantly |
logarithmic when peers join and leave the system constantly |
76 |
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 |
77 |
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), |
78 |
at a given time suddenly 100-900 peers joins/leaves randomly). |
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 |
- 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 |
logarithmic growth inspite that the number of Storm-servers increases |
82 |
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 |
83 |
Storm-servers perform 10000 lookups randomly) |
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 towards a single peer/few peers (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/routing hotspots |
responsible for a given key). Thus, there can be query/routing hotspots |
88 |
in the system and load balancing properties may not scalable/tolerance |
in the system and load balancing properties may not scalable/tolerance |
89 |
against a hostile attack (e.g., 1000 Storm-server system, each server |
against a hostile attack (e.g., 1000 Storm-server system, each server |
90 |
hosting 1-10 Storm block(s), 1-900 peers (randomly chosen) queries a |
hosting 1-10 Storm block(s), 1-900 peers (randomly chosen) queries a |
91 |
single key every 1-10 second(s); calculate average block request |
single key every 1-10 second(s); calculate average block request |
92 |
failure, average lookup length, number of timed-out lookups and |
failure, average lookup length, number of timed-out lookups and |
93 |
the distribution of lookup messages processed per peer). |
the distribution of lookup messages processed per peer). |
94 |
|
|
95 |
- GISP is is rather fault-tolerant if 80% of lookups are succesful when 20% of |
- GISP is is rather fault-tolerant if 80% of lookups are succesful when 20% of |
96 |
peers die (This is Chord's simulation result) (e.g., 1000 Storm blocks are |
peers die (This is Chord's simulation result) (e.g., 1000 Storm blocks are |
97 |
insterted into a 1000 Storm-server system. After insertions, 1-99% of |
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 |
servers die randomly or in a controlled way. Before GISP starts rebuilding |
99 |
routing tables, perform 1000 Storm block fetches; calculate average block |
routing tables, perform 1000 Storm block fetches; calculate average block |
100 |
request failure, average lookup length and number of timed-out lookups). |
request failure, average lookup length and number of timed-out lookups). |
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 (e.g., e.g., 1000 Storm |
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 |
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 |
of peers are hostile. Perform data lookups 1000 lookups randomly so that |
106 |
in every lookup process, one forwarding request is rerouted incorrectly towards |
in every lookup process, one forwarding request is rerouted incorrectly towards |
107 |
randomly chosen destionation peer; calculate average block request failure, |
randomly chosen destionation peer; calculate average block request failure, |
108 |
average lookup length, number of timed-out lookups and the distribution of |
average lookup length, number of timed-out lookups and the distribution of |
109 |
lookup messages processed per peer). |
lookup messages processed per peer). |
110 |
|
|
111 |
|
|
112 |
Issues |
Issues |
113 |
====== |
====== |
114 |
|
|
115 |
How many virtual peers we are able to simulate on a single machine (e.g., |
- How many virtual peers and Storm blocks we are able to simulate on a single |
116 |
with 256Mb of memory) ? |
machine (e.g., with 256Mb of memory) ? |
117 |
|
|
118 |
|
- In the future, do we want to perform simulations in a LAN cluster (or |
119 |
|
relevant) ? |
120 |
|
|
121 |
|
RESOLVED: Yes, if we want to simulate huge virtual networks and/or |
122 |
|
memory requirements are too massive for a single desktop. |
123 |
|
|
124 |
|
- For now, do we need "real" Storm blocks during simulations or not ? |
125 |
|
|
126 |
|
RESOLVED: No, since we want to make our simulator environment |
127 |
|
as lightweight as possible (See issue #1). In the future, however, it is |
128 |
|
possible that we use "real" Storm blocks instead of "number" blocks. |
129 |
|
|
130 |
|
|
131 |
Changes |
Changes |