[GNUnet-developers] Load policing revisited

[I. Wronsky]

On Wed, 8 May 2002, Christian Grothoff wrote:

> Hmm. Strange. Well, if you have any good idea why, I'll surely listen
> closely :-)

Good. ;) 

Then lets get to the actual nasties. A bug from the
statuscalls.c section. Here's part of my /proc/net/dev

  eth0:4123030205 18721240    0    0    0     0          0         0 
4099219815 11291320 1681696    0    0 1256252       1          0

This makes your networkUsage() go unoperational. The reason is 
that 4 gigs goes over the range of integers you use. Try 
using "unsigned long long" or something.

Anyway, even if bigger integers were used, there will
still be problems. Atleast on systems like mine.

Lets revisit the bandwidth limiting script I talked about. 
Its working now, but I see now that it can't be anything else
than a tool aiding during current beta phase, as in the end 
gnunet node must know its own load so that it can decide 
what to route and what to discard. Using an external script 
would just bypass the crediting system and give each node 
equal status, as the node won't know that its loaded and 
honours all requests, of which some are randomly discarded 
by the external methods.

The original motivation for the script was the unsymmetric
connections, e.g. 20kb/s up, 600kb/s down, possible in for
example cable modems, and particularly here. :-) Now setting
limit according to 20kb/s would rarely let any traffic pass, 
as just downloading something would easily go over that. Using 
600kb on the other hand could enable the node to stuff 
>20kb/s up the pipe, jamming virtually anything else. And
how about some solution in-between? Perhaps a regular gnunet 
user is expected to start constructing Lagrangians and so on? :D 
Some time ago I suggested such traffic calculations where both 
directions are noted separately. However, as we are just 
interested in limiting the upstream, a simple suggestion
that could make the system work, would just be to count 
the bytes sent by gnunet and give a max value of bytes/sec 
in the config that can be sent by the node, not including 
any non-gnunet traffic. I admit its more crude than your 
current solution, but it wouldn't depend on any platform 
dependent stuff as the current one does. One of the problems 
with the current solution is bursty traffic: at subsequent 
calls the txdiff in networkUsage() is either really high or 
zero. And in the times of zero, the node reasons that its ok
to push at full blast, jamming the small upstream, causing
again a really high txdiff, making heavy fluctuation but
very little useful limiting. Perhaps instead of diffs
gnunet should try to keep up some kind of average load
counter, so instead of bursts a smoother load, averaged
over time, would be perceived by the bandwidth policing system. 

I'll perhaps try to investigate this after I get
the big integer problem kludged (no, shutting down eth0
and starting again doesn't make the biggie numbers drop to
zero. Perhaps reboot would be in order? Won't do that.)
There was some problem with the trivial scanf solution ...