On 06 Jul (13:52:50), Ian Goldberg wrote: > Hello tor-dev, > > Steve Engler (currently part of the Shadow team) and I have a paper of > possible interest to appear at ARES 2021 next month. > > It's a design of a multi-threaded relay architecture, of possible > particular interest when considering relay support in arti, for example > (though the proof-of-concept implementation is based on the usual C > codebase). > > If you're interested, here are previews of: > > Paper: https://cs.uwaterloo.ca/~iang/pubs/mttor-ares21.pdf > Video: https://www.youtube.com/watch?v=41a6nLUJye8 > Code: https://git-crysp.uwaterloo.ca/sengler/tor-parallel-relay-conn > https://git-crysp.uwaterloo.ca/sengler/relay-throughput-testing Interesting!!! One part caught my eye in section 4.3: "The large amount of locking would harm the relay’s performance, and mes- sage passing would break some of the assumptions of Tor’s primary scheduler, the KIST scheduler. Rather than using a global scheduler, each local connection manager uses its own local scheduler which processes only the connections it owns." So KIST was also put in place in order to be able to consider _all_ channels within one scheduling loop so to properly applied EWMA scheduling that is basically loud circuits (lots of traffic) are less prioritize from quiet ones. Moving to a scheduler per thread (as in only handling its set of connections), we loose that property no? And so loud circuits end up crushing quiet circuits on the physical link? Another thing. Looking at figure (c), it appears only "relay/edge connections" can queue cells on a circuit half *directly* that is not using a channel. I assume that concurrency there between a relay connection writing a cell on a circuit half and a cell received through a channel (from another circuit half) has been thought of? :) I'm asking also because within Tor, there are numerous places where a cell is enqueued on a circuit (even an OR circuit like TRUNCATE for instance) and so those place would need to use a channel or use the way relay connections write them (which appears to be without a channel)? Anyhow, good read, thanks for this paper! Cheers! David -- 6wN+FRCe3M9NFjAhiEkBEUpGWtZEa3ayD2xpq4CyMkE=
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev