RE: returning results for partial downloads

Michael Rogers wrote:
> The idea of using stability as a metric to be optimised in its own right
> is very interesting - I'll have to think about how to apply that locally.

Stability is in fact probably the first goal to achieve in a heterogeneous
network. Without it, no other policy can be tuned, as the system will never
converge to the conditions where this policy is applicable.

The network will naturally be heterogeneous, because each participant node
will have different goals based on their opinion about what is "fair":
maximum local download speed, or maximum distribution of upload bandwidth. I
do think that the second option is best because it globally enhances as well
the average download speed per node with more sources (so with more
stability too).

The other factor of stability is also the speed of convergence, this speed
highly depends on how much requests and results are finely grained, so that
the cycle time is reduced: convergence speed is directly linked to the
frequency of updates when tuning the policy (however you're limited for this
reduction also by the other resources: processing speed, available memory,
available routes, maximum number of open ports per process or per host; the
optimum policy will need to tune its own local policy precisely and
constantly by monitoring all the bounded resources, not just the theoretical
or measured maximum bandwidth which will also be eaten by the protocol
overhead if the cycle time is too short...).

So we need some minimum (non null) stability metric even in the worst case.
Once this minimum is reached, the system will gradually converge to ausable
state (even if some parts of the resources remain wasted; wasting resources,
such as duplicate requests through several paths is still useful to keep the
system stable, when the topology of the network is constantly changing).

I'm really convinced that the best policy will try not to maximize the total
upload or download bandwidth used, but the number of clients served, even if
each client is served completely at lower speed, because the same clients
will gain more by seeking for more other participants to what it is
requesting, and will use them. If instead of depending from a single
critical resource we depend on a much larger cluster made of heterogeneous
nodes, the stability will be better, as we can't predict how each node will
tune its policy.