[tor-scaling] Tuning KIST and EWMA parameters

[David Goulet]

On 05 Jun (22:04:00), Mike Perry wrote:
> Ok, we're starting have a lot of KIST and EWMA tuning discussion in the
> meeting thread, so I'm going to summarize things (please correct me if I
> make mistakes), and then ask some questions for Rob, Ian, dgoulet, and
> pastly.
> 
> Why is this important? Together, KIST and EWMA have the potential to
> make a massive impact on page load times and interactive web app
> performance, if tuned properly for that use case.
> 
> However, both of these systems have only been tuned using results from
> simulation, and in a way, they are the poster children for a case study
> on how simulation and reality do not always match up.
> 
> Prior to developing KIST, we made some efforts to tune EWMA on the live
> network, but it did not change our performance metrics much. When Rob
> and team investigated why, they discovered that it was because relays on
> the live Tor network were buffering everything in their kernels instead
> of in their Tor daemons, which prevented EWMA from working properly, and
> the idea for KIST was born.

Data point: Until 3 years ago roughly, EWMA was not working properly due to
this bug:

https://trac.torproject.org/projects/tor/ticket/20459

This was backported but *NOT* to 0.2.9. I can't recall why we did not, only
this comment talks about this. Could be maybe some logs of that meeting...

https://trac.torproject.org/projects/tor/ticket/20459#comment:12

Which means that 0.2.9 relays/clients should be considered as *NOT* using
EWMA.

> 
> So let's back up, and review the technical details of KIST and EWMA.

[snip]

> 
> Ok, so now for the questions:
> 
>   * What client-side KISTSchedRunInterval torrc values should we use?
> 1ms, 2ms? I saw pastly doing some chutney tests, but has anyone tried
> these values in the torrc of clients on the live network?

I've been using 2msec here on my local client since that bug was discovered.
My client fetches emails from 4 different accounts each on a .onion so there
is lots of activity.

So far so good. No bugs, no mad CPU busy loop, it seems fine.

The big worry for me is onion service. They have basically 2 channels open at
best (Primary Guard and maybe a secondary guard...).

This means a busy HS can't go above ~3MB/sec because of this 10msec.

So it appears that we might want to do a tor release with KISTSchedRunInterval
being different values for client and relays? Or just tell the world to use
"2msec" for their onion service but that won't work well...

> 
>   * What relay-side KISTSchedRunInterval consensus parameter values
> should we try? How confident are we that 10ms is our best
> one-size-fits-all value for now? Should we also try 2ms on the live
> network? 5ms? 20ms?
> 
>   * Can/How should we concurrently tune CircuitPriorityHalflifeMsec? We
> know that we can make throughput worse with KIST intervals that are too
> large, but if CircuitPriorityHalflifeMsec is not set right, we won't see
> as much benefit from KIST on the latency side. Should we tune it first,
> or after, or pick a couple (KISTSchedRunInterval,
> CircuitPriorityHalflifeMsec) value pairs?
> 
>   * How should we record and analyze the echo server RTT metric that we
> discussed in the jitsi meeting? We want some way to capture that RTTs
> are constant over time over a circuit, as well as measure the
> network-wide RTT distribution over all circuits. Are these separate metrics?

You want to report such a metric publicly?

Top of my head, I would use our flow control protocol (SENDME).

However, the protocol allows for an end point to send data as long as the
window is above 0. In theory, in a full maximum window of 1000 cells, 10
SENDMEs should be sent (at every 100 cells, the increment value). But it is
entirely possible that all 1000 cells are sent towards the end point before
even 1 SENDME is received/handled by the sender or even sent by the receiver.

In practice, *our* tor program sends a SENDME at each window increment meaning
100 cells. But the other side is _not_ waiting on that SENDME to send more
data if the window is still above 0.

Which is annoying when you want to compute a RTT ;).

Thus, the only real guarantee I think we can rely on here would be when the
window goes down to 0, once tor sends the SENDME, it can be sure that the
other side will send a DATA cell because that side is has stopped everything
waiting for that SENDME.

You'll get a more reliable RTT at that point.

Then there is the classic ping-pong set of cells that can be used but they are
all control cells used only once when setting up a circuit... (CREATE/CREATED,
EXTEND/EXTENDED) and worst, don't always measure the full length...

Cheers!
David


-- 
1mNwEGRBGwA+KV0QAcUNjXeckIqFcZmhiwewCdRWKac=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-scaling/attachments/20190607/d1a8c0b4/attachment.sig>