Re: [GNUnet-developers] Patch for network load measurement

[Christian Grothoff]

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

On Friday 16 January 2004 07:59 am, Hendrik Pagenhardt wrote:
> After testing my code with bandwidth limitations far below my upstream
> capacity I found that GNUnet uses to much bandwidth with my new code.
> Probably that's why the more pessimistic estimates were implemented. I
> spent some time now looking through the parts of the source which
> implement the bandwidth allocation strategy I concluded the following:
>
> - Downstream network load is nowhere used in the code to control
> anything (only gnunet-stats). Maybe it could be used to tell peers to
> reduce the amount of data sent when its over the limit. Or did I miss a
> place were downstream bandwidth control is implemented?

Yes, you did.  It does not use the load though.  Since we can not precisely 
control what we receive (as opposed to what we send), the code takes the 
total number of bytes we have available and distributes them among all 
connected peers (see connection.c).  Look at "BufferEntry" with the members 
recently_received (how much traffic came from peer X), 
current_connection_value (how much did we appreciate the traffic) and 
"transmitted_limit" and "idealized limit" (how much is the peer allowed to 
send us at the moment) and the related code in connection.c.

> - Upstream control works be looking at the load and then decide whether
> a message of a certain priority can be sent. If the priority is greater
> than 2500 it is always sent. I don't know whether is is an unusual high
> priority, but it seems suspect.

2500? Where didi you get that from I thought it was ADMIN_PRIORITY (defined to 
0xFFFF = 65536). The idea is that certain administrative messages must go 
through regardless of bandwidth limits (like, say, HANGUP).  Now, I also 
suspect that this priority cap is to blame for the spikes, but I thought that 
we may be generating too many messages with ADMIN_PRIORITY at times.  But if 
you are right with 2500, that'll be a different story...

> - For the upstream control to work effectively it needs a momentous
> value estimation of the load. Moving averages are probably not very
> suited for the current policy implementation.

I'm not sure that they are not.  TCP and the OS will smooth things out a bit 
for us anyway.  And we may not have the CPU cycles to always precisely send a 
message instantly once we're momentously under the limit.  Also, given the 
fact that the messages are of different importance and processing is highly 
concurrent, I don't see how a momentous value estimation could possibly work 
as smoothly as the moving averages (and it is important that all changes are 
smoothed over time to avoid instabilities in the network of the form of 
quickly going back and forward between low-load (everyone sends) and 
high-load (nobody sends) states.  This type of oscillation can easily happen 
and is reduced with the moving average but might easily become a problem 
without one.

> I have a few more ideas to make the bandwidth usage more effective and
> more predictable, but I will spend some more time trying to understand
> the current code before posting more unneeded patches.

Btw, I didn't have time to look at the patch yet.

C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFACB7/9tNtMeXQLkIRAt1wAJ9OAoEJNKfQ4p3QX0PpE5HVQmZ2/wCfTBoF
4ahMyMmIPkhMBDZHnhgtWfM=
=+w9g
-----END PGP SIGNATURE-----