[Gzz-commits] storm/doc/pegboard/storm_gisp_simulation--hempp...

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/storm
Module name:    storm
Changes by:     Hermanni Hyytiälä <address@hidden>      03/06/03 05:12:19

Modified files:
        doc/pegboard/storm_gisp_simulation--hemppah: peg.rst 

Log message:
        formatting and some issues

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/storm/storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst.diff?tr1=1.2&tr2=1.3&r1=text&r2=text

Patches:
Index: storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst
diff -u storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst:1.2 
storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst:1.3
--- storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst:1.2       Tue Jun 
 3 04:58:22 2003
+++ storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst   Tue Jun  3 
05:12:19 2003
@@ -5,8 +5,8 @@
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-06-02
-:Last-Modified: $Date: 2003/06/03 08:58:22 $
-:Revision: $Revision: 1.2 $
+:Last-Modified: $Date: 2003/06/03 09:12:19 $
+:Revision: $Revision: 1.3 $
 :Status:   Incomplete
 
 .. :Stakeholders:
@@ -48,15 +48,15 @@
 There are number of research problems which we try to solve (or understand 
 better) using the simulation process:
 
- - How well GISP can scale if there are lot of concurrent peer joins and
-   leaves in the system ? What about lookup effieciency when the network
-   grows ?
+- How well GISP can scale if there are lot of concurrent peer joins and
+  leaves in the system ? What about lookup effieciency when the network
+  grows ?
          
- - How well GISP is able to perform in adverse conditions, e.g., a
-   network partition occurs ?
+- How well GISP is able to perform in adverse conditions, e.g., a
+  network partition occurs ?
    
- - How well GISP is able to perform against different kind of
-   security attacks and what are the impacts ?
+- How well GISP is able to perform against different kind of
+  security attacks and what are the impacts ?
    
    
 For now, we assume that simulation network is rather optimal, e.g., there
@@ -66,54 +66,66 @@
 Hypothesis
 ==========
 
- - GISP can scale rather well when peers join and leave the system at a 
-   constant/static rate for a given time period and cost of joining/leaving 
-   is logarithmic (e.g. Start with 1000 blocks and 1000 Storm-servers, 10 
-   peer(s) joins/leaves every 5 seconds).
-   
- - GISP can scale well and is adaptable if the cost of join/leave is 
-   logarithmic when peers join and leave the system constantly
-   and the variable rate for joining/leaving changes greatly (e.g., Start with 
1000 
-   blocks and 1000 Storm-servers. 1-10 peer(s) joins/leaves every 1-10 
second(s), 
-   at a given time suddenly 100-900 peers joins/leaves randomly).
-   
- - GISP's data lookup is efficient if the number of of lookup length grows 
with a 
-   logarithmic growth inspite that the number of Storm-servers increases 
-   linearly (e.g. 10-10000 Storm-servers, 10000 Storm blocks, with 10-10000
-   Storm-servers perform 10000 lookups randomly)
+- GISP can scale rather well when peers join and leave the system at a 
+  constant/static rate for a given time period and cost of joining/leaving 
+  is logarithmic (e.g. Start with 1000 blocks and 1000 Storm-servers, 10 
+  peer(s) joins/leaves every 5 seconds).
+   
+- GISP can scale well and is adaptable if the cost of join/leave is 
+  logarithmic when peers join and leave the system constantly
+  and the variable rate for joining/leaving changes greatly (e.g., Start with 
1000 
+  blocks and 1000 Storm-servers. 1-10 peer(s) joins/leaves every 1-10 
second(s), 
+  at a given time suddenly 100-900 peers joins/leaves randomly).
+   
+- GISP's data lookup is efficient if the number of of lookup length grows with 
a 
+  logarithmic growth inspite that the number of Storm-servers increases 
+  linearly (e.g. 10-10000 Storm-servers, 10000 Storm blocks, with 10-10000
+  Storm-servers perform 10000 lookups randomly)
      
- - A GISP peer is not able to handle all request properly when great amount 
-   of query requests are performed towards a single peer/few peers (a peer is 
-   responsible for a given key). Thus, there can be query/routing hotspots
-   in the system and load balancing properties may not scalable/tolerance
-   against a hostile attack (e.g., 1000 Storm-server system, each server 
-   hosting 1-10 Storm block(s), 1-900 peers (randomly chosen) queries a 
-   single key every 1-10 second(s); calculate average block request 
-   failure, average lookup length, number of timed-out lookups and
-   the distribution of lookup messages processed per peer).
+- A GISP peer is not able to handle all request properly when great amount 
+  of query requests are performed towards a single peer/few peers (a peer is 
+  responsible for a given key). Thus, there can be query/routing hotspots
+  in the system and load balancing properties may not scalable/tolerance
+  against a hostile attack (e.g., 1000 Storm-server system, each server 
+  hosting 1-10 Storm block(s), 1-900 peers (randomly chosen) queries a 
+  single key every 1-10 second(s); calculate average block request 
+  failure, average lookup length, number of timed-out lookups and
+  the distribution of lookup messages processed per peer).
      
- - GISP is is rather fault-tolerant if 80% of lookups are succesful when 20% of
-   peers die (This is Chord's simulation result) (e.g., 1000 Storm blocks are 
-   insterted into a 1000 Storm-server system. After insertions, 1-99% of 
-   servers die randomly or in a controlled way. Before GISP starts rebuilding 
-   routing tables, perform 1000 Storm block fetches; calculate average block 
-   request failure, average lookup length and number of timed-out lookups).
+- GISP is is rather fault-tolerant if 80% of lookups are succesful when 20% of
+  peers die (This is Chord's simulation result) (e.g., 1000 Storm blocks are 
+  insterted into a 1000 Storm-server system. After insertions, 1-99% of 
+  servers die randomly or in a controlled way. Before GISP starts rebuilding 
+  routing tables, perform 1000 Storm block fetches; calculate average block 
+  request failure, average lookup length and number of timed-out lookups).
  
- - A hostile entity is able to reroute a data lookup to a incorrect 
-   destination peer during a data lookup process (e.g., e.g., 1000 Storm 
-   blocks are insterted into a 1000 Storm-server system in which a a fraction
-   of peers are hostile. Perform data lookups 1000 lookups randomly so that 
-   in every lookup process, one forwarding request is rerouted incorrectly 
towards
-   randomly chosen destionation peer; calculate average block request failure, 
-   average lookup length, number of timed-out lookups and the distribution of 
-   lookup messages processed per peer).
-
-
+- A hostile entity is able to reroute a data lookup to a incorrect 
+  destination peer during a data lookup process (e.g., e.g., 1000 Storm 
+  blocks are insterted into a 1000 Storm-server system in which a a fraction
+  of peers are hostile. Perform data lookups 1000 lookups randomly so that 
+  in every lookup process, one forwarding request is rerouted incorrectly 
towards
+  randomly chosen destionation peer; calculate average block request failure, 
+  average lookup length, number of timed-out lookups and the distribution of 
+  lookup messages processed per peer).
+  
+  
 Issues
 ======
 
-How many virtual peers we are able to simulate on a single machine (e.g.,
-with 256Mb of memory) ?
+- 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.
 
 
 Changes