NSD TCP and UDP performance

NSD
1

Hi,

After the discussion on the mailing-list the other week the development
team revisited the issues with respect to TCP-Nagle-algorithm and the
the UDP performance increase by implementing multiple reads after a
single select.

These improvement ideas are from Aaron Hopkins (thanks! :-)), and
implement non-blocking I/O, UDP performance and TCP performance
features. The non-blocking I/O has already been implemented as part of a
bugfix for NSD 3. The UDP performance gain (using multiple reads per
select) increases NSD resilience to high load (denial of service
attacks). The TCP performance gain (avoiding extra roundtrip by TCP
Nagle algorithm) increases NSD resilience to high TCP load (DoS). Code
size of the features is expected to be pretty small.

As you may be aware we are trying to stick to NSD's design principles
and simplicity is key. Hence we are careful with changes that are
potentially non-standard and/or non-portable. In the past, we did not
implement the UDP performance improvement because they represented a
paradigm shift in select/read usage that might lead to non-portability.
Besides, we were concentrating on proper behavior of NSD3 as secondary
server.

With respect to tweaking the Nagle algorithm, resiliency to DOS is an
important design criterion for NSD. The fact that in the last few years
DOS attacks with non-spoofed addresses become more likely has made us
look very careful at the proposed patch again

You may expect these features to be available in 3.1.

Best regards,
  Wouter

2

After the discussion on the mailing-list the other week the development
team revisited the issues with respect to TCP-Nagle-algorithm and the
the UDP performance increase by implementing multiple reads after a
single select.

[...]

You may expect these features to be available in 3.1.

From my quick examination of NSD 3.2.0, these optimizations aren't yet

included. Is there a revised timeline for implementing them?

I also just noticed that NSD select()s on the ability to write() for every
TCP reply. In the common case, this is unnecessary and will lead to
slightly increased CPU utilization and reply latency versus optimistically
write()ing and falling back to select() if necessary. Was this optimization
considered and deemed unnecessarily complex?

                                     -- Aaron

3

Hi Aaron,

They are not included in 3.2.

Thanks for the optimisation suggestions. They work.

However, the reason it is postponed (and still is being postponed), is
that the patch is not critical, and there are concerns that it may
elicit undefined behaviour from (old or poorly written) network stacks.

TCP performance is considered less pressing, as DNS mostly uses UDP.

I did implement your suggestions in unbound, by the way, although that
took some code, and needed stack sanity tests. Matthijs has since
picked up the NSD maintainer role, and your suggestions are on his todo
list (he says) but just not as high as IXFR-fallback and port-selection
were.

Best regards,
   Wouter

Aaron Hopkins wrote: