/[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.2 by hemppah, Tue Jun 3 08:58:22 2003 UTC revision 1.3 by hemppah, Tue Jun 3 09:12:19 2003 UTC
# Line 48  properties of the GISP protocol without Line 48  properties of the GISP protocol without
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
# Line 66  we plan to perform simulations in a non- Line 66  we plan to perform simulations in a non-
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

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

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