-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > > > 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.

> Why does it reduce the anonymity set of the traffic carried?

Extreme example, for clarity: 

if everyone has 10 links and there is only one sequence of peers in
the whole network pushing 100KBps, with everyone else is pushing
1KBps, if you are able to pull more than 10KBps of low latency data,
you know you're getting data from one of the peers with the fast CBR
links (since everyone else can only send at 10KBps max).

> > > > (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.

> How does the pipenet fail?

Congestion along the path exposes chaff - if you have a sequence of
peers with link level CBR @ 10KBps and you're pulling 10KBps of
data, if one of them chokes and you keep getting data, you know its
not that path.

> > > > (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?

> Not true. We adjust the CBR bitrate according to the long term rate of
> real data transmission.  Certainly there are issues with doing this in a
> way which won't give away the real data transmission rate, but a
> combination of quantization and the right kind of averages should make
> something usable.

Ok, I misunderstood.  I don't really understand how it'd work now,
but perhaps one could come up with something.

> And even if it does give away the *rate*, it won't give away the
> individual packets for timing/forwarding correlation attacks, as
> we have been discussing, which become increasingly easy over
> time without CBR.

The importance of the rate is for correlating related flows of
packets.  Perhaps it wouldn't be an issue if every packet's routing
is independent - is this what you're getting at?

> So the issue is how to make it work with bandwidth limiting?

Nah, I was just talking about how one particular token bucket based
algorithm could fit into what I thought you were proposing.  I don't
know any concrete algorithm, but one might be able to come up with
something when necessary.

> #4 IIRC was to negotiate a bitrate with each node, independantly
> of the actual data transferred, just on the basis of each involved
> node's links.  So essentially it's a more flexible variant on #1.

Ah, ok.

=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDYR5eWYfZ3rPnHH0RArgBAJkBMZFluxyT8yIrUvrWebevlXouHwCfUY4F
Cd0pQ6Jf+kYII2Lp4sFzrD4=
=zWq1
-----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]

Reply via email to