-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > > - Both dark and open (maybe) freenet can be insulated from this via CBR > > > links because nodes are of low order and links change slowly. - IF there > > > is no fundamental problem with CBR links. I2P probably can't be. > > > > I'd posit that "IF" is appropriately questionable ;) > > I'm not sure why. There is a big problem with CBR *tunnels*. What is the > big problem with CBR *links* ?
CBR links only hide information from external adversaries. They're transparent to internal adversaries. In addition, you've got pipenet-esque issues. For the four scenarios you described: > 1. Pure CBR. All node links are exactly 1kB/sec. Not practical for I2P, > very wasteful for freenet. > 2. Negotiated CBR based on current traffic level. > 3. Negotiated CBR based on average long-term traffic level. > 4. Negotiated CBR based on hosts available capacity. ~= #1, but more > friendly to slower nodes. > > I think what jr is critiquing here is #2. I was thinking more #3. (1) is a nonstarter. You've just jacked the queueing times into *hours* for most uses. That is, assuming people stop adding to the queues and it doesn't fall into congestion collapse. For 2-4, how are the CBR rates negotiated? In any case, 2-4 must use a CBR no higher than the individual nodes' free capacity, and the rate selected reduces the anonymity set of the traffic carried to the order of other links with similar rates. (2), if I understand correctly, means the tunnel stays constant at the tunnel's negotiated CBR rate at all times. This fails pretty clearly in the same way pipenet does. (3), if I understand correctly, means the tunnel doesn't do any CBR, beyond some algorithm that verifies that by the end of the tunnel's lifetime, the total number of messages transmitted equals what it would have transmitted if it were CBR'ed like (2). Right? Off the top of my head, I don't see a simple algorithm for achieving reasonable CBR without leaking the flow. For instance, I2P uses a token bucket for bandwidth limiting - every 100ms, we add in some new tokens, and whenever we want to send out a packet, we wait until we can grab enough tokens from the bucket. The 'always active' state of such a scheme is CBR, but its patterns of downtime (when tokens accumulate in the bucket) as well as its patterns of bursting (when excess tokens are pulled from the bucket faster than they are added) are visible. I'm not sure I understand (4). =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDYQrTWYfZ3rPnHH0RAgYQAJ4m8vROjE6J5tIFf/DqrPVB599LqgCfbwfO X97OYyerUGjuU3ZR2P/YEQk= =xOMM -----END PGP SIGNATURE----- _______________________________________________ chat mailing list chat@freenetproject.org Archived: http://news.gmane.org/gmane.network.freenet.general Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/chat Or mailto:[EMAIL PROTECTED]
