[katzenpost] mixnet notes from visit to KU Leuven

[dawuud]

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

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.

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)

Therefore the Loopix paper essentially describes the client as having
three distinct send schedulers each with their own lambda parameter for tuning.


> 
> Regards,
> 
> -- 
> Yawning Angel
> 
> [0]: An alternative approach would be to determine the token bucket
> refill rate based on the Poission distribution CDF or something, but
> forcing a minimum delay is "better" for the health of the network while
> a lot of the congestion avoidance stuff is still "for future research".


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