gzz-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Hermanni Hyytiälä
Subject: [Gzz-commits] storm/doc/pegboard/storm_gisp_simulation--hempp...
Date: Wed, 04 Jun 2003 04:05:03 -0400

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

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

Log message:
        Tuomas' comments

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/storm/storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst.diff?tr1=1.3&tr2=1.4&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.3 
storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst:1.4
--- storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst:1.3       Tue Jun 
 3 05:12:19 2003
+++ storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst   Wed Jun  4 
04:05:03 2003
@@ -5,8 +5,8 @@
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-06-02
-:Last-Modified: $Date: 2003/06/03 09:12:19 $
-:Revision: $Revision: 1.3 $
+:Last-Modified: $Date: 2003/06/04 08:05:03 $
+:Revision: $Revision: 1.4 $
 :Status:   Incomplete
 
 .. :Stakeholders:
@@ -17,40 +17,89 @@
 
 
 Performing GISP P2P simulations with Storm we can increase our understanding 
-about GISP's scalability properties and on the other hand, possible issues
-related to scalability. Also, we want to know how GISP outperforms
+GISP's scalability properties. Also, we want to know how GISP performs
 against different threats such as network partition or security 
-attacks.
+attacks. If not separately mentioned, in this context we mean with 
+"Storm" as an entity which is able to do a (limited/simplified) number 
+of Storm's functionalies.
+
+This PEG discusses research problems, hypotheses, the theoretical 
+knowledge we have about the hypotheses, and possible simulations to 
+validate hypotheses.
+
+
+Issues
+======
+
+ISSUE:
+
+    How many concurrent "Storm" entities with blocks are we able to simulate 
+    on a single machine (e.g., with 256Mb of memory) ?
+
+ISSUE:
+
+    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.
+
+ISSUE:
+    
+    For now, do we need "real" Storm servers or blocks during simulations 
+    or not ?
+ 
+    RESOLVED: No, since we want to make our simulator environment 
+    as lightweight as possible (See issue #1). 
+    
+    
+ISSUE: 
+
+    Why GISP? Why are we using it versus some other systems?
+    What properties does it share with others, to such a degree
+    that its performance might be deduced from theirs?
+
+ISSUE:
+        
+    What experiments / simulations / methods are used in the literature?
 
-This PEG discusses how these simulations should be planned, what are
-the research problems, hypothesis and issues.
 
 Plan
 ====
 
 First of all, we will create a PEG document (this document) which 
-discusses general aspects of the simulation process. Then, we plan 
-to program (rather short) test cases which will test the GISP/Storm 
-P2P properties, as discussed in this document. Finally, we will 
-collect and analyse test cases' information and use this information
-in the future in our manuscripts.
-
-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. 
+discusses general/theoretical aspects of the research problems. Then, 
+if necessary, we program (rather short) test cases which will test 
+the GISP/Storm P2P properties, as discussed in this document. Finally, we will 
+collect and analyse test cases' information and publish any interesting 
+discoveries. 
 
-Research problems
+The GISP protocol
 =================
 
-By using simulation as a research method, we try to test different kinds of
-properties of the GISP protocol without having to deploy real life 
experiments. 
-There are number of research problems which we try to solve (or understand 
-better) using the simulation process:
+- GISP_ protocol resembles Kademlia_
+- XOR-metrin for distances
+- lacks of binary-tree abstraction ?
+- uses Chord_'s extended routing table - more space for caching 
+  (Log^2 messages)
+- replicates in a same way as Kademlia
+- no concurrent RPCs during lookup -- no free of choice during 
+  lookups ? 
+
+
+Research problems
+=================
+ 
+For determining whether Storm with unmodified GISP is practical, we want the 
+answers to the following questions.
 
 - 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 ?
+  leaves in the system ? 
+  
+- What about GISP's lookup effieciency when the network grows ?
+
+- GISP does not use Kademlia's binary-tree abstraction - does it have 
influence 
+  anf yes, what are the influences ? 
          
 - How well GISP is able to perform in adverse conditions, e.g., a
   network partition occurs ?
@@ -58,26 +107,40 @@
 - 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
-are no network latencies in the simulation network. In the future, however, 
-we plan to perform simulations in a non-optimal network.
 
+Simulations
+===========
+
+If needed, using a simulation process we try solve research problems. Also, 
+with a simulation process we are able test the GISP protocol without having 
+to deploy real life experiments.
+
+During simulation process, we assume that simulation network is rather ideal, 
+e.g., there are no network latencies in the simulation network. In the future,
+however, we plan to perform simulations in a non-ideal network.
+
+   
 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).
+In this section we introduce few hypothesis related to research problems.
+Hypothesis are based on the simulation processes which are used in the 
+literature. Also, values presented here (e.g., 1000-10000) are widely used
+in simulation processes.
+
+
+- GISP's overlay can scale rather well when peers join and leave the system at 
a 
+  constant rate or constant fraction (both are used) 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 
+- GISP's overlay 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 
+- GISP's data lookup is efficient and can scale if lookup's 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)
@@ -106,31 +169,17 @@
   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 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.
+  lookup messages processed per peer).  
 
 
 Changes
 =======
 
-We will program simulation test cases into the Storm CVS module. Currently,
-no changes are required to the Storm implementation codebase.
+If we decide to perform simulations, we will program simulation test cases 
+into the Storm CVS module. No changes are required to the Storm implementation
+codebase.
+
 
+.. _GISP: http://gisp.jxta.org
+.. _Kademlia: http://kademlia.scs.cs.nyu.edu
+.. _Chord: http://www.pdos.lcs.mit.edu/chord/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]