-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> > CBR links only hide information from external adversaries. They're
> > transparent to internal adversaries.
>
> True enough. But there are ways to prevent internal attackers
> masquerading as zillions of nodes:
> - Costly identity via hash- and think- cash.
Agreed, there are methods for minimizing Sybil with regards to the
P = (c/n)^h here.
> - Darknets, with cellular tunnel selection.
Depending on darknets for the peer selection is the same as saying
"dunno, let the user figure it out". But, thats a topic for another
discussion.
> > > 1. Pure CBR. All node links are exactly 1kB/sec. Not practical for I2P,
> > > very wasteful for freenet.
> >
> > (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.
>
> Feasible for Freenet, including distributed pub/sub streams using
> passive requests. Not so sure about 1:1 streams! Remember that we've
> probably only got 20kB/sec or so upstream.
We've already had these discussions about whether Freenet's routing
can deal with congestion, with the net result being "we'll see".
Now you're saying you'll enforce a maximum link capacity of 1KBps?
Well, there are enough details not specified yet for us to continue
with the "we'll see" response, I suppose.
> > For 2-4, how are the CBR rates negotiated?
>
> Sorry, below you're talking tunnels; I was talking links, to prevent
> external attackers (both passive and active) from exposing traffic.
Ah, you're right, though the above question still stands. Let me
revise my questions:
> > 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.
Still pertinent for CBR links.
> > (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.
Still pertinent for CBR links, replacing "tunnel" with "link".
> > (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.
Needs adjustment for CBR links, but only by replacing the "tunnel
lifetime" variable with duration of the "long term" averaging.
> > I'm not sure I understand (4).
Still pertinent for CBR links :)
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDYRRvWYfZ3rPnHH0RAh0nAJ9bCqtbKjdw+nyGk1BkcU22x3TFpACfd+GN
RifkHu6BKCYEpFTR251QDEc=
=PgXU
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.