[tor-scaling] Summary of 5/31 meeting; next steps

[David Goulet]

On 03 Jun (22:11:00), Mike Perry wrote:
> David Goulet:

[snip]

> > On 31 May (20:39:00), Mike Perry wrote:
> > And I would also like to point out that for optimal performance, whatever
> > client measuring it should follow the workaround in #29427 (bring down the
> > KISTSchedRunInterval to 2msec.
> 
> How certain are we about this value? And what about relays?

We are very certain about that bug ;). You can even experience it by yourself
very easily: spin out a chutney with 029, transfer 100MB file between
client<->exit.

Then, do the same on latest master, it will take much more time as long to
transfer it. Reason is we are cap ~3MB/sec with KIST with a tor having very
low amount of channels (a couple). It is actually exactly like that I found
that we had this huge difference while testing authenticated SENDMEs...

For relays, it is not affecting them since they have a _lot_ of channels and
thus 10msec is quite enough to go through a lot of them and saturate their TCP
buffers avoiding any wait period of doing nothing.

> 
> I wanted to tune this value as a separate experiment:
> https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor/PerformanceExperiments#KIST
> 
> Does that make sense? Can you help provide info for the fields there,
> and clarify if we want to set different values for clients vs relays?

For client, it would be of big help. However, considering that I never went
above 1.5MB/s with my tor client, that 3MB/sec cap is still far ahead. But
over time scalability of the network, this limitation is really ridiculous...

> 
> I also assume this means that the KIST tuning must be done before the
> EWMA tuning?

As I said above, for relays, won't change anything (in theory!!!). I recall
Rob/Matt did experiment during the KIST development and 10msec was the optimal
waiting time they found between filling kernel buffers and coming back seeing
them "empty".

This whole approach is honestly expensive (not KIST) but the busy loop network
scheduling. One of the main reason we need to have this "wait period" is
because cell priority as the KIST paper explains it.

I had a long phone call with Rob/Matt about this some months ago, and there
are real optimization we could do to how tor works regarding its cell
relaying.

Basically, getting rid of this "timed busy loop" and instead make tor wake up
when the kernel tells us when we can write on the socket because the TCP
buffer has room. We could still do priority based on the set of channels that
wake up at once. And because we know we can put bytes on the wire and won't
get delayed, we get into this pattern of "writing as soon as we can" thus
being a more proper "relay" imo.

Unfortunately, that feature in the Linux kernel doesn't exists...

So I went ahead and coded that feature in the kernel (not that hard). In a
nutshell, makes it that epoll_wait()/poll() with EPOLLOUT would wake you up
when the TCP queue has room for some value you set prior on the socket with
setsockopt().

And then I spent time thinking of a way for "tor" to use it properly which is
quite a refactor from how tor functions right now... It would require a new
thread. Nick had an idea on how to do it with the mainloop so it would
simplify quite a bit the first iteration of such a piece of work.

I'm still very optimistic that we can/should go that way one day (sooner than
later), I've already reached out to kernel dev. friend of mine that put me in
contact with the Linux network stack team. The way to pitch the idea to them
is to provide them 1) a patch (we have!) and 2) use cases + proof.

That (2) part is where I don't have time to do anything there _but_ Rob
reminded me that shadow controls the network stack so this is something we
could artificially inject in shadow and see how it works out. But then that
approach would require me to heavily change "tor"... Thus, probably creating a
small program that would take advantage of this feature instead of "tor" would
be the avenue.

But _again_, time++....

Cheers!
David

-- 
mo/FoOvGZ+X1wZ0kabmLPai7yXUjiJZSPXCuo8Sdg7M=
-------------- 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/20190604/79df5cb3/attachment.sig>