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

[Hermanni Hyytiälä]

On Tue, 2003-06-10 at 13:50, Tuomas Lukka wrote:
> > There are two variations of this scenario. The first
> > +variation is the static scenario in which peers do join or leave the 
> > system while
> > +the test is running. In the second variation, peers can join and leave the
> > +system while the test is running. 
> 
> You're missing a negation somewhere, I think.


True (typo).

> 
> > +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. 
> 
> How do you suppose that will happen? 

Since GISP uses Chord-like routing table --> it is expected that the
destination can be found eventually using finger tables (i.e. "backup
links").


> 
> Also, you need to estimate what you expect to find beforehand.

Chord's fault tolerance properties which can be found from the original
paper ?

> 
> > 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. 
> > +
> > +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 "dumb" peers can be changed (for more 
> > "clearer" 
> > +  analysic etc)
> This is not good - we want to understand
> the scaling with both network size and dumb peer fraction.


Ok, I change it so that the number of normal peers and "dumb" peers can
increase/decrease.

> 
> > +- Create 100 data items in the network (the format is "key1-100", 
> > "value1-100")
> 
> Not good - several of the peers will have no items. I'd recommend enough
> to have a good probability that each peer will have its own items.

Is 5000 items enough ?

> 
> > +- Perform 100 queries randomly (random peer selection (1-100) and random 
> > query 
> > +  selection (1-100)) with *normal* peers
> 
> 100 is rather little if the routing tables &c are expected to morph
> during the experiment.


What about 2500 queries ?


> 
> > +- Update all peers' routing information every loop pass 
> 
> How realistic is that? What changes will there be, if the network
> itself is static?

For example, If a GISP peer is able determine that an another peer is
not "useful" because it doesn't  reply/forward queries.



-Hemppa