[katzenpost] mixnet notes from visit to KU Leuven

[Yawning Angel]

Replying to myself, because I changed some things.

On Thu, 8 Feb 2018 15:38:01 +0000
Yawning Angel <yawning at schwanenlied.me> wrote:
>  * How is the client supposed to schedule sends?
> 
>    Right now there is one (network wide) parameter `LambdaP`, that
>    specifies the mean of a Poisson distribution (in seconds).  The
>    client will attempt to send traffic (be it cover or otherwise) by
>    sampling from this distribution.

This was totally wrong so now client send scheduling is parameterized
around `SendLambda`, `SendShift`, and `SendMaxInterval` like thus:

  v = Exp(rng, SendLambda)
  if v > sendMaxInterval:
    v = sendMaxInterval
  v += SendShift

  # v is wait till a packet send is triggered in milliseconds.

So basically client sends are paced based on sampling a shifted
exponential distribution with the long tail clipped.  The rationale for
applying the shift was to impose a minimum delay between sends so that
it is possible to easily implement a per-client rate limiter[0].  A
shift of 0 is a legal value but specifying such will disable the rate
limiter.

Both the client decoy loop traffic (disabled by default) and the rate
limiter (enabled) are now merged into the respective trees.

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

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: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.mixnetworks.org/pipermail/katzenpost/attachments/20180213/b5f097a3/attachment.sig>