/[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.1 by hemppah, Mon Jun 2 13:28:14 2003 UTC revision 1.2 by hemppah, Tue Jun 3 08:58:22 2003 UTC
# Line 16  PEG storm_gisp_simulation--hemppah: Stor Line 16  PEG storm_gisp_simulation--hemppah: Stor
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.
# Line 31  Plan Line 31  Plan
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    

Legend:
Removed from v.1.1  
changed lines
  Added in v.1.2

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