-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You seem to state some things as fact here that are still rather
debatable:
On 12 Apr 2006, at 10:25, Michael Rogers wrote:
* TCP's congestion control is designed for use between a single sender
and a single receiver - it doesn't work for a single sender and
multiple
receivers (see reliable multicast)
The rationale was to treat the network collectively as a single
receiver. Do you see reasons why that approach won't work?
* TCP's congestion control also assumes the sender is well behaved - a
badly behaved sender can cause all other flows to back off, for
selfish
or malicious reasons
True, but is this even a solvable problem, noting that it hasn't been
solved with the Internet?
* Despite being well designed and widely tested, TCP is not
suitable for
end-to-end congestion control in Freenet
So you say, but you are assuming the point that is being debated -
why isn't it suitable, and what is the better alternative?
* However, TCP-like congestion control between neighbours would make
sense (see DCCP for TCP-friendly congestion control algorithms)
That is one way that we are using it already (although it appears
that our implementation was flawed, Matthew is now fixing that). We
were basically using it at two different layers of Freenet, the node-
to-node layer, and at the insert and request layer.
* I suggest replacing the backoff and ping mechanisms:
* TCP-like congestion control between neighbours
* Forward each packet to the neighbour that:
* Is online
* Is ready to receive more packets
* Is closest to the target
* Rather than having an explicit backoff timer, congested
neighbours are
temporarily avoided until they are ready to receive more packets
(according to the local TCP-like congestion control)
* "Route as greedily as possible, given the available capacity"
The problem here, and it is one we have faced before, is that this
degrades routing, which means requests take longer, which further
increases the load on the network, isn't this the last thing we want
to do in this situation - or perhaps we don't have a choice?
2) Restrict the amount of load a node can place on the network
I need to give these further thought.
Ian.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
iD8DBQFEPVxyQtgxRWSmsqwRAsgUAJ9J7p2M/t0AC/vGZhYZ7JHdtS0MhgCeLcSL
+lRyjp1jFMFFLwnl7H6A9I4=
=qbYc
-----END PGP SIGNATURE-----
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
