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

[Hermanni Hyytiälä]

Don't worry :).

This commit left *before* I sent the email ("earlier" one). So, the
changes I have made in this commit can be considered as outdated.


-Hermanni


On Tue, 2003-06-10 at 21:32, Tuomas Lukka wrote:
> On Tue, Jun 10, 2003 at 09:10:34AM -0400, Hermanni Hyytiälä wrote:
> > -We expect that GISP is able to route some queries to their destination 
> > peers eventually,
> > -altough the performance of a lookup is expected to decrease (Chord's fault 
> > tolerant
> > -properties). Also, we except that some of the queries are lost. With this 
> > test case, we wish 
> > -to get more information how big the lost rate is (Chord's fault tolerant 
> > properties). 
> > +We expect that GISP's fault tolerance is at least at the same level as 
> > Chord_'s 
> > +fault tolerace since GISP's routing table is based on Chord's routing 
> > table:
> > +
> > +.. place here some results from the Chord paper
> > +
> > +Thus, we expect that GISP is able to route some queries to their 
> > destination 
> > +peers eventually, altough the performance of a lookup is expected to 
> > decrease. Also, 
> > +we except that some of the queries are lost. With this test case, we wish 
> > +to get more information how big the lost rate is.
> > +
> > +Eventually, we will compare (and validate) our test results with the 
> > Chord's 
> > +fault tolerance properties.
> 
> Still far too vague. 
> 
> You're leaving so much "wriggle room" for yourself that you're not actually
> saying much anything. Almost any results from a test would fit what you
> say above. That's *NOT* good.
> 
> The questions you need to answer theoretically *carefully* are:
> 
>       - do you think that eventually the network will regain its original
>         performance with time or not?
> 
>       - if not, what can you say about the eventual steady state performance?
> 
>       - how long will it take to reach it?
> 
> >  Simulation Process: 
> >  - Create 90 normal peers in the network (ID is in the format "peer1 
> > -peer90")
> >  - Create 10 "dumb" peers in the network (ID is in the format 
> > "dumb1-dumb10")
> >  - If necessary, the number of total peers and "dumb" peers can be 
> > increased/decreased
> > -  (for "clearer" analysic etc)
> > -- Create 5000 key/value items in the network (the format is "key1-100", 
> > "value1-100")
> > -- Perform 2500 queries randomly with *normal* peers (random peer selection 
> > (peer1-100) 
> > -  and random query selection (key1-100))
> > +  
> > +    .. list different settings...
> > +  
> > +- Create 5000 key/value items in the network (the format is "key1-5000", 
> > "value1-5000")
> 
> You were saying earlier 100*N?
> 
> 
> > +- Perform 2500 queries randomly with *normal* peers (random peer selection 
> > (peer1-5000) 
> > +  and random query selection (key1-5000))
> 
> Why 2500? What is your expectation for the routing info to converge?
> 
>       Tuomas