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

[Hermanni Hyytiälä]

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 ?

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

AFAIK, no. The routing table abstraction is the thing what matters
(e.g., how many connections a peer maintains in the routing table).


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

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


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

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


-Hermanni