[katzenpost] mixnet notes from visit to KU Leuven

[Yawning Angel]

On Tue, 13 Feb 2018 10:25:30 +0000
dawuud <dawuud at riseup.net> wrote: 
> > >  * What fraction of client decoy traffic should be loop vs
> > > discard?
> > 
> > Unless someone tells me otherwise, my plan for client decoy discard
> > traffic is to add yet another network wide parameter
> > `SendLoopFraction`, that specifies how much of the decoy traffic
> > will be looped, with a "for debugging, subject to change" value that
> > dramatically favors discard traffic over loop traffic.
> 
> Why should this be described as a fraction?
> I'm asking because this diverges from the Loopix design
> and as such should be justified. No?

As far as I can tell the net behavior is equivalent.

> Firstly, "client decoy discard" is a bit ambiguous.
> There are client loops and drops. Drops are sent
> to Providers and are dropped by those Providers.

Discard as opposed to loop, as in drop.  In context of Katzenpost
and the rest of the sentence, it is entirely unambiguous.

> The Loopix paper describes lambda_L as controlling rate of send for
> client loops. While lambda_P controls rate of send for forward
> messages AND client drops. Lambda_D controls rate of send for drops.
> (See Loopix section 3.2)

   Since clients send also streams of cover traffic messages with rates
   λL for loops and λD for drop cover messages, the traffic sent by
   the client follows Pois(λP +λL +λD). 

Katzenpost's SendLambda is `λP +λL +λD`, because this makes
implementation easier, particularly for per-client rate limiting.  The
important properties of the externally observable distribution are left
intact.

With the design out of the paper, it's impossible to impose effective
rate limiting without false positives.

Regards,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.mixnetworks.org/pipermail/katzenpost/attachments/20180213/ae6d4bf5/attachment.sig>