Re: Increase outdegree

Am Montag, 10 de September de 2007 17:29:58 schrieb Greg Bildson:
> > Af far as I understand it this doesn't apply to small scale increase of
> > outdegree without TTL reduction, or does it?
>
> I'm not sure what "this" your referring to.   

Sorry, that I was unclear. 

"This" refers to old connections. 

<snip>

> changes, you would increase the average query time by increasing the
> outdegree.  Ultrapeers would have to be queried at a faster rate leaving
> less time to see the feedback from those queries.   If the TTL of the
> query drops however, then feedback rate is less an issue.   

The time a query needs shouldn't be too much of an issue (at least to a user), 
I think, because the results will come in at a faster rate, even when the 
query behaviour isn't adjusted (i.e. the time between querying the first and 
second UP). It will just have the difference, that a query can reach far 
further, when it doesn't get enough results, so a query can last longer, but 
doesn't have to. 

But when you look at traffic for UPs, QRP is also a factor, and as you wrote, 
too, it will be more efficient with higher outdegree, so only the first and 
second hop UPs (those which get a broadcast query) get hit with full force, 
and they are only a small percentage of all routing UPs. 

<snip>

> Increasing
> outdegree will magnify the power of any incoming query so if you don't
> want a disproportionate amount of resources to be devoted to incoming
> queries from old network hosts, you need to route those queries to less
> hosts to at least balance this out.  You need to do this to keep the old
> hosts from using up the resource gains that the new structure affords
> you.  (In practice, you should probably cheat the old network hosts a
> little so that they are encouraged to upgrade to new software.)

Do you mean, that a small scale increase of outdegree would make the current 
behaviour of older hosts bad behaviour? 

This may sound naive, but couldn't the query behaviour stay the same, just 
with a longer tail (hosts queried when the first requests don't give enough 
results)? That way an old query might get more results, but since a leaf 
stops after a certain number of results instead of after a certain number of 
queried hosts, and a UP does listen to the requesting leaf, I don't see where 
such many more effects come from. 

Maybe from the second UP not having queried all nodes, so the older hosts 
query a new UP too early? 

Would it be possible to check this by slowly increasing the outdegree over the 
next few versions? 
Maybe with a plan posted here? For example: 
2007-10-01: outdegree 36
2007-12-01: outdegree 40
2007-12-24: outdegree 44 - christmaas present :) 
2008-02-01: outdegree 48
2008-04-01: outdegree 50

Any client developer who publishes a new version can then check which 
outdegree should be used for that version. 


I think cheating has a major problem: When you need to manage cheating, every 
connected UP will consume a bit more memory. 

<snip>

> The effect on spam is somewhat unknown.   One thing that would happen
> with LimeWire now is that we would receive more spam on rare queries but
> ignore it.  Thus, there could be a huge increase of spam that is ignored
> with respect to dynamic querying while we are still trying to get our
> target number of results.  If you increase the horizon, you could
> dramatically increase the spam results and load just to get a few more
> results from a rare query.   Spam would be bad in multiple ways - this
> doesn't necessarily defeat the idea but has to be thought through in
> detail.

Could we do this thinking inside the GDF? 

There are a number of very knowledgeable people in here, so could you maybe 
start a new thread for a general discussion of spam among all Gnutella 
developers? 

<snip>

> You really need to start with what you want as the resulting maximum
> traffic limit on ultrapeers and work backwards.  

What is your traffic limit? 

> There is never any 
> guarantee of being able to query the entire network so I don't like to
> hear that as a goal.   

For me as user (that's still what I mainly am) it is a very important goal, 
since I often search for rare materials. 

And for content distribution, it is important, too. 

But I can state it differently: I see it as goal to be able to reach all 
_files_ in the network. 

This means, for example, that I don't need to reach all sources of a file. A 
few sources which are in the download mesh for that file suffice. 

And it is satisfied by Dynamic Querying and the Query Routing Protocol, but 
only with sufficient network reach, and this means, with sufficient 
outdegree. 

> If you can achieve it without burdening 
> ultrapeers too much then fine.  Otherwise, it just isn't doable.
> Ultrapeer traffic flow is sensitive to various factors with outdegree
> being one major factor.

So it depends on the traffic limit you try to archieve. 

At the moment, a Gnutella servent can work off a 24kbit modem line as leaf. 
As UP you need at least ISDN, if you want to download something while being 
UP, you should at least have DSL 2000. 

(I know I repeat myself, but I'm really very interested in your traffic limit, 
and I think knowing it is vital to thinking about outdegree.)

> At higher
> outdegree, dynamic querying might need better support for doing
> fractional TTLs to satisfy intermediate cases (i.e. TTL=2.5 implies
> alternating between a TTL of 2 and 3 for sequential connections).

Could you write fractional TTL as an idea in a new thread? 

I'd prefer not to have the discussion diverge into everything since I think 
it's more efficient to keep each thread somehow focussed (even though I'm not 
that good at that myself). 

Best wishes, 
Arne
-- 
Unpolitisch sein
Heißt politisch sein
Ohne es zu merken. 
- Arne Babenhauserheide ( http://draketo.de )
-- Weblog: http://blog.draketo.de

-- Mein öffentlicher Schlüssel (PGP/GnuPG): 
http://draketo.de/inhalt/ich/pubkey.txt


[Non-text portions of this message have been removed]