gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-developers] Re: [Help-gnunet] INDIRECTION_TABLE_SIZE


From: Christian Grothoff
Subject: [GNUnet-developers] Re: [Help-gnunet] INDIRECTION_TABLE_SIZE
Date: Sun, 11 Aug 2002 16:01:56 -0500
User-agent: KMail/1.4.1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think this discussion (started on help-gnunet) fits better in here.

On Sunday 11 August 2002 02:58 am, you wrote:
> Here's another ignorant question. ;) Is the indirection table usage
> taken into account in economics? Perhaps we should, in addition
> to watching available bandwidth, also have entries_used -ratio
> (or something based on number of collisions lately) of the
> indirection table, and if its high, behave in a similar manner
> as when the bandwidth is used up?

Good point, I had been thinking about this before, but had not made up my
mind yet. Let me summarize what the code does and what I was thinking.

It is not directly modeled by the economics, but the 'discard' strategy should 
take care of getting the incentives right. If a new query is received, it is 
added to the table if:

a) the slot has expired (absolute-ttl < now)
b) the slot would expire *after* the new query would expire 
     (absolute-ttl > now+query->ttl)

Thus a query that has a very high ttl is likely to be removed early if a 
short-lived query arrives in the meantime. 

While this gives an incentive to send short-lived queries, it may be unfair 
towards very important queries with high ttls from good hosts compared to 
unimportant short-lived queries from 'bad' hosts. So yes, we may want to 
factor in some more economics in the routing table, e.g. by factoring the
priorities into the computation in b).

Note that a) is the 'excess' in the economy in this case. Except if
we have explicit collision handling, I would not see any need to take some
ratio of full/empty slots into account here.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9VtDE9tNtMeXQLkIRAtVDAJ4/x+sH4ECKv0ZKYViCwqgrZ0+3lACffMZc
Qbrs10knduXHiU8z2tVy9gE=
=ux13
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]