[Mldonkey-users] Bandwith control (new concept)

[Goswin Brederlow]

Hi,

while we are all waiting for the secret files to be released I thought
I would let you know about the bandwith control I have in mind.
It might look a bit complex at first but bear with me.

There are 4 building blocks:

1. Resorvoirs
   A Resorvoir is a storage for bandwith. Something fills it up and
   something can drain it. All other types use this. This is used to
   buffer traffic, to allow peaks and smoth them out over
   time. Resorvoirs have a maximum fill.

2. Pipes
   Pipes connect resorvoirs and regulate the flow between them. A pipe
   has multiple source resorvoirs and multiple destination
   resorvoirs. At each tick a pipe takes some bandwith out of all
   sources at fixed values and outputs another fixed value to one or
   all of its destinations. The destination(s) is chosen eigther by
   priority or by ratio. If a destinations resorvoir is full it is
   ignored. If a source resorvoir is empty the pipe does nothing. The
   number of ticks per second limits the flow.

   A pipe without sources is just limited by its ticks and its output
   value.

3. Queues
   A Queue is a buffer that manages actual packets. Each packet has a
   priority, an age and a flag if it can be safely forgotten. A queue
   has a certain size. If that size is reached forgettable packets are
   deleted to make room. If thats not enough the queue won't accept
   more packets.

4. Drains
   A drain consumes bandwith. A drain is a special pipe. It has
   multiple source resorvoirs but instead of destination resorvoirs it
   has a queue. It takes out bandwith out of the sources and a packet
   out of the queue and sends it of. The queue should tell the ratios
   of how much bandwith is taken out of each source resorvoir, usually
   that would be the size of the packet send or recieved, and a
   minimum fill level each resorvoir must have for this packet, this
   would depend on the priority and age of the packet.

Lets draw an example:

pipes              drains                               queues

server-queries---
1/min            \              <-(use 1 query)
                  server-drain--------------------------server-queue
          2. pri /              <-(use size many bytes)
upload-----------
 8KB/s    1. pri \
                  \               <-(use 40 byte for ACK)
                   download-drain-----------------------download-queue
                  /               <-(use size many bytes)                      
download----------
 80KB/s

The server-drain will only query a server if there is something in the
resorvoir filled by the server-queries pipe and if the resorvoir fille
by the upload pipe has size many bytes. It then takes the first query
out of the queue and sends it.

The download-drain likewise will use 40 bytes from upload and size
many bytes download per queued packet. The 40 bytes would account for
the upload traffic generated by acknowledging the download packet.

The server-queries pipe and download pipe are trivial, but the upload
pipe will allways fill up the download-drain resorvoir and only if
that is full the server-drain resorvoir.




I hope implementing the datastructures for this proves to be simple.
Most is just writing up the interfaces. Configuring the right pipes
and resorvoirs might be more difficult.

I'm not sure if the setup of pipes should be user configurable. Its
hard to set it up right and easy to make it break completly. Also I
wouldn't know how do design an interface thats understandable. I think
exporting a few key values to be changeable by the user should be
enough, the more delicate internal working should be set in the
source.

User defined settings should be total up and download speed.
Priorities or ratios how to devide up and down between different
protocols. The ratios and speeds of queries and downloads and the
limits for when to accept or open connects.

Most values should have certain limits, e.g. 1 KB/s minimum for upload
and it can be all for server queries. Also server queries are limited
to one every minute or something. But thats all for the interface to
the gui to handle.

Another possibility would be to offer a small variety of setups and
let the user chose one of them. Offer setups that favour a certain
protocols or setups for a high speed but limit traffic connections.
For example some cable modem ISPs have a limit of 10 GB a month but
speeds of 300 KB/s. You want to limit the mldonkey traffic to 5 GB a
month but still allow 300KB/s downloads peaks. With the proper pipes
and resorvoirs that can be setup.


So what do you think?

MfG
        Goswin