Opened 7 months ago

Last modified 5 months ago

#33763 new enhancement

Consider setting TCP_NOTSENT_LOWAT to 1 byte on our TCP connections

Reported by: dgoulet Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-relay, performance, scaling, tcp, 044-deferred
Cc: Actual Points:
Parent ID: Points: 0.2
Reviewer: Sponsor:

Description

This TCP option would provide us and important performance benefit at the relay side.

In an effort to work on a new tor design to reduce kernel queuing delays, see it as an improvement to KIST and tor architecture, Rob and I submitted this paper to NetDev 0x14 conference in hope of sitting down with the Linux kernel developers and network experts about this idea.

https://www.robgjansen.com/publications/epollcwnd-netdev2020.pdf

Ultimately we want a new poll TCP option in the kernel which our experimentation shows how it improves performance drastically.

But turns out that starting with setting TCP_NOTSENT_LOWAT to 1 byte would significantly improve performance close to what we wanted. See Figure 1. (page 3) in the paper for the performance improvements.

Setting TCP_NOTSENT_LOWAT is minimal change to tor and thus we should do it.

Child Tickets

Change History (2)

comment:1 Changed 7 months ago by robgjansen

I thought this would be done after moving Tor to using epoll directly, so that we could stop using the part of KIST that checks for *tcp_info* every 10 milliseconds. Is that correct? Or do you envision using *TCP_NOTSENT_LOWAT* on top of KIST (which we never simulated/tested)?

comment:2 Changed 5 months ago by nickm

Keywords: 044-deferred added
Milestone: Tor: 0.4.4.x-finalTor: unspecified

Bulk-remove tickets from 0.4.4. Add the 044-deferred label to them.

Note: See TracTickets for help on using tickets.