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

[Tuomas Lukka]

On Tue, Jun 10, 2003 at 02:23:19PM +0300, 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. 
> > 
> > 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").

Then, explain it in the PEG and give the estimates of the time.

> > Also, you need to estimate what you expect to find beforehand.
> 
> Chord's fault tolerance properties which can be found from the original
> paper ?

State them here, too. Does the metric affect them?

You need to give here exactly the results you'd expect to see when
running the experiment.

> > > 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.

No, you need to actually give the settings you plan to test.
And the scaling you expect.

> > > +- 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 ?

That's up to you to calculate ;)

> > > +- 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 ?

Ditto.

> > > +- 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.

Is it able to do that? 

Then you need to run until you've reached a steady state, and have an estimate
of how long that will take beforehand, and also about what the steady
state will be like.

        Tuomas