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

[Tuomas Lukka]

On Tue, Jun 10, 2003 at 04:06:32PM +0300, Hermanni Hyytiälä wrote:
> On Tue, 2003-06-10 at 15:24, Tuomas Lukka wrote:
> > 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.
> 
> Should I include both the "big Os" and the number from the figures from
> the Chord paper ?

Yes, *with* a reference.

> > > > > 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.
> 
> E.g., 
> 
> Setting 1: 90 normal peers, 10 "dumb" peers
> Setting 2: 900 normal peers, 100 "dumb" peers
> Setting 3: 9000 normal peers, 1000 "dumb" peers
> 
> Like this ?

For example. Or just 9*10^n, 1*10^n for n = 1..3

And you also need to check different fractions.

> > 
> > > > > +- 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 ;)
> 
> In the original Chord paper, the authors use 100*N keys, if N is the
> number of all peers. Perhaps I will use this setting.

Sounds fairly reasonable; using too many is better than too few.

> > > > > +- 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 ?
> > 
> 
> Again, Chord paper cites, "Each peer in an experiment picked a random
> set of keys to query from the system, and we measured the path length
> required to resolve each query."
> 
> So, I'll use the same method...

Once or several times?

What is it that we want to measure? Among other things, whether gisp
is able to adapt itself...

> > > > > +- 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? 
> 
> 
> Somewhat "yes", according to the GISP paper ("..a peer can discard
> information of
> unreachable peers"). However, I will look for the source how it's
> implemented; is it able to recognize if a peer is alive "dumb" (answers
> to PING) or not.

Indeed. This is pretty vital.

        Tuomas