-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Toseland wrote: > When Ian eventually returns from The Real World, I'll invite you to > #freenet-dev (irc.freenode.net) to discuss this.
Cool, I'll be going offline soon but hopefully I'll get my connection back later this evening. > Reliable multicast is a contradiction in terms. :) I'm inclined to agree, but try telling that to the IETF working group. ;-) >>* Despite being well designed and widely tested, TCP is not suitable for >>end-to-end congestion control in Freenet > > > Then what is? I'm not sure congestion control should be done end-to-end in Freenet. Instead, each node's traffic should be limited by its immediate neighbours, and each node should route around its overloaded neighbours. > Backoff happens when a node returns a local=true RejectedOverload (due > to high local ping times), or a timeout. It is solely based on local > feedback. It is a close analog of e.g. Ethernet backoff, and I don't see > any urgent reason to change it. Fair enough, I misunderstood what was triggering backoff. If the current local congestion control works then there's no need for the complexity of TCP. > I don't see that you are actually addressing the problem here. How do we > limit the amount of load the node can place on the network? Let's say we have perfect fair queueing. If a selfish node's neighbours are honest then they'll only give it a fair share of their bandwidth. On the other hand if they're selfish too then they'll give it nothing - either way it gets less than if they just forwarded packets on a first-come first-served basis. > Yes we > should have fair queueing, but we need to have the requestors slow down > according to network load in order to minimize backoff. Fair queueing achieves this to some extent because if your packets are in a separate queue from everyone else's and you start to experience packet loss, the only way to prevent further loss is to reduce your own transmission rate - you can't force anyone else to back down. However this assumes the closest link is the bottleneck - I'm not sure whether the same would be true if you could be sure that the bottleneck was more than one hop away, where your packets would be sharing a queue with other nodes' packets... >> * No incentive to forward inserts (but is this even possible, >>since there's no way to verify they've been forwarded?) > > > Well there is if they succeeded. Is it possible to distinguish a genuine "insert succeeded" from a fake one? Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEPUAeyua14OQlJ3sRAsXmAKC8/ZPlZU9960vtBlY/BJeriIn46ACg5odN CCq7sQQFzzkip5fhD5ebKh0= =4SGA -----END PGP SIGNATURE-----
