/[storm]/storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst
ViewVC logotype

Diff of /storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.3 by hemppah, Tue Jun 3 09:12:19 2003 UTC revision 1.4 by hemppah, Wed Jun 4 08:05:03 2003 UTC
# Line 17  PEG storm_gisp_simulation--hemppah: Stor Line 17  PEG storm_gisp_simulation--hemppah: Stor
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 ?
# Line 58  better) using the simulation process: Line 107  better) using the simulation process:
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)
# Line 106  Hypothesis Line 169  Hypothesis
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/

Legend:
Removed from v.1.3  
changed lines
  Added in v.1.4

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26