-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ed Tomlinson wrote: > We probably want to size a peers token bucket relative to the ammount > of the keyspace the peer is the best path for (resizing after all location > swaps).
The token buckets are for incoming traffic, so we'd have to know how much of each peer's keyspace we were responsible for. I'm not sure if that's a good idea from an anonymity perspective - but on the other hand we can probably work it out passively anyway, by seeing which keys the peer requests from us. There's also a trust issue - assuming I've made the mistake of connecting to a malicious peer who's trying to flood the network, fair sharing will restrict the amount of my resources (and my peers' resources) the malicious peer can use. On the other hand if I allow the peer to influence the size of its share (eg by claiming that I'm responsible for a large part of its keyspace and therefore should accept a large number of requests), the attacker can get access to more resources. > Hopefully we can find a metric that allows the node to self adjust. Hopefully - not sure what the feedback signals should be. > Bandwidth control (packet level) does look at all packets. Really? As far as I can tell, BlockTransmitter only throttles CHK replies. > It makes sense not to throttle replys to intransit message. It makes sense not to reject them, but I'm not sure ignoring the (user-specified) bandwidth limit is a good idea. Replies could be queued rather than rejected if the bandwidth limiter's token bucket is empty. > Maybe throttling swap requests would be a good thing? Maybe - not sure how this would impact the swapping algorithm. If fewer swaps lead to less efficient routing, it could exacerbate the load problems. > We now use a ethernet like alg to control backoff. My patch changes this to > (G)AIMD which > might be better. If we use a token scheme both the existing and/or my > (G)AIMD scheme > probably can be scrapped. OK, I'm not very happy about chasing a moving target but on the other hand I understand that people might not want to wait until the end of the SoC project to see improvements in the backoff situation. It's up to Matthew really. > Do you see any value in implementing the metric mentioned previously? > > Node percent of time backed off > Peer percent time backed off > Node percent of time routed to non optimal node due to backoff Yup, it would definitely be useful to have this information if we're planning to modify the backoff code before the SoC work is finished. Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFElWkZyua14OQlJ3sRAgcdAJ9SPVjiU1n65u5o9uq9xf+OcchnHACg7auQ x0mt9iKFnM+CjAbnBpVwIfQ= =tHCm -----END PGP SIGNATURE-----
