[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz] Re: [Gzz-commits] storm/doc/pegboard/attacking_gisp--hemppah peg.r
From: |
Tuomas Lukka |
Subject: |
[Gzz] Re: [Gzz-commits] storm/doc/pegboard/attacking_gisp--hemppah peg.rst |
Date: |
Tue, 10 Jun 2003 21:28:37 +0300 |
User-agent: |
Mutt/1.5.4i |
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