[Gzz-commits] storm/doc/pegboard/attacking_gisp--hemppah peg.rst

[Hermanni Hyytiälä]

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

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

Log message:
        updates

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

Patches:
Index: storm/doc/pegboard/attacking_gisp--hemppah/peg.rst
diff -u storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.27 
storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.28
--- storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.27     Thu Jun 12 
03:21:23 2003
+++ storm/doc/pegboard/attacking_gisp--hemppah/peg.rst  Thu Jun 12 10:03:53 2003
@@ -4,8 +4,8 @@
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-06-05
-:Last-Modified: $Date: 2003/06/12 07:21:23 $
-:Revision: $Revision: 1.27 $
+:Last-Modified: $Date: 2003/06/12 14:03:53 $
+:Revision: $Revision: 1.28 $
 :Status:   Incomplete
 
 .. :Stakeholders:
@@ -101,7 +101,6 @@
 - Numerial metric: no "peer-choice" during lookups
 
 Additionally, the current version of GISP (3.4) have following properties:
-
 - Only uses the idea of XOR-metric in Kademlia.
 - The protocol specification of GISP-3.4 allows the "free choice", *but*
   the current Java implementation just selects fixed peers (like Chord)
@@ -146,11 +145,68 @@
   is 0.1 (corresponds to peer joining and leaving every 10 seconds
   on average)
   
+
+Simulation Process: 
+- Fraction of "dumb" peers is constant: create 9*10^k normal peers, 
+  create 1*10^k "dumb" peers, where k = 1..3
+- Fraction of "dumb" peers is dynamic: create n*10^k normal peers, 
+  d*10^k "dumb" peers, where k = 1..3, n = 1..9 and d = 1..9
+- Use both the constant and dynamic fraction scenarios, start with the
+  constant
+- Create 100*N key/value items in the network, where the N is the number of 
all peers in the network
+- Each peer queries a set of random keys
+- Try to use same code as in GISP's implementation/simulation base
+- For "dumb" peers we have to create own class 
+  (extends GISPXML-class) which has "dumb" methods for query 
+  forward and processing
+
+During the simulation process we will use a single hostile  peer
+or a group of hostile peers (fraction of all peers) in the test network.
+We assume that hostile peer(s) takes part in forming of the network normally. 
+
+By using above scenarios, we want to clarify GISP's properties with regard to 
research 
+questions.
+
+\*=We start the simulation process with these scenarios.
+
+
+Hypothesis:
+
+ 
+  
+  
+- GISP has average of O(log n) lookup length in a static network, where n is 
+  the total number of peers in the network, since GISP uses Chord-like routing 
+  table
+  
+.. to different PEG ?
+  
+- It is expected that (popular) data items can be found with fewer hops in 
+  *some cases* in GISP network w.r.t Chord network, since GISP extends Chord's 
+  routing table to have more information as a cache
   
-The results we expect from the experiment:
+.. more specific, what effects cache has ?
+
+  
+- GISP's lookup failure rate increases linearly with the fraction of "dumb" 
+  peers. More specifically, fraction f of lookups fail after a randomly 
+  selected fraction of f peers become "dumb" in a static network
+  
+.. make "dumb"
+  
+- It is expected that fraction f of all network traffic k is "lost" in 
+  a static GISP network and therefore may have negative influence to network's
+  behaviour, since the current GISP implementation do not handle "dumb" peers 
+  properly, i.e., "dumb" peers reply to "alive"-queries but do 
+  not process or forward queries at all
+  
+.. more specific, create a formula (?)
+  
+
+If fraction f of the peers are dumb in a static network with 10 - 10000
+  peer and fraction f of the lookups, then fraction of the lookups will 
+  fail at all network sizes
 
-- GISP has O(log n) lookup efficiency, e.g., with 10000 peers
-  the lookup length is 6 (average)
   
 .. No, you should not say "expect similar" - it's far too vague.
    You should make explicit statements as to what the results will
@@ -169,33 +225,13 @@
   except as last recourse).
 
 .. more to come
+   "two way proof":
+   1) The hypothesis holds true for the experiment
+   2) The hypothesis does not hold true from a "random/pseudo experiment"
   
 
 We will compare (and validate) our test results with the Chord's 
-performance and fault tolerance properties.
-
-Simulation Process: 
-- Fraction of "dumb" peers is constant: create 9*10^k normal peers, 
-  create 1*10^k "dumb" peers, where k = 1..3
-- Fraction of "dumb" peers is dynamic: create n*10^k normal peers, 
-  d*10^k "dumb" peers, where k = 1..3, n = 1..9 and d = 1..9
-- Use both the constant and dynamic fraction scenarios, start with the
-  constant
-- Create 100*N key/value items in the network, where the N is the number of 
all peers in the network
-- Each peer queries a set of random keys
-- Try to use same code as in GISP's implementation/simulation base
-- For "dumb" peers we have to create own class 
-  (extends GISPXML-class) which has "dumb" methods for query 
-  forward and processing
-
-During the simulation process we will use a single hostile  peer
-or a group of hostile peers (fraction of all peers) in the test network.
-We assume that hostile peer(s) takes part in forming of the network normally. 
-
-By using above scenarios, we want to clarify GISP's properties with regard to 
research 
-questions.
-
-\*=We start the simulation process with these scenarios.  
+performance and fault tolerance properties.  
   
 Issues
 ======