[dns-operations] DNS server benchmarking sanity check

[Robert Edmonds]

bert hubert wrote:
> On Mon, Aug 15, 2016 at 03:38:52PM -0400, Jared Mauch wrote:
> > Moving from using send() to sendmsg() can help performance as well as
> > other tuning, but these tend to be less portable and avoided by developers
> > in my experience.  Simply put, this is the one case where I would still use
> 
> So here is something someone might want to try if we don't find time for it
> first.
> 
> I experimented a bit with using the interface for retrieving errors for UDP
> sockets.  Normally we connect() outgoing datagram sockets so we get errors
> via recv().  This allows us to more quickly discover a UDP port 53 that is
> closed.  But I wanted to see if we could make this work without connect().
> 
> This actually works, and I was stunned to read in man recvmsg:
> 
>        MSG_ERRQUEUE (since Linux 2.2)
>               This flag specifies that queued errors should be received from
>               the socket error queue.  The error is passed in an ancillary
>               message with a type dependent on the protocol (for IPv4
>               IP_RECVERR).  The user should supply a buffer of sufficient
>               size.  See cmsg(3) and ip(7) for more information.  The
>               payload of the original packet that caused the error is passed
>               as normal data via msg_iovec.  The original destination
>               address of the datagram that caused the error is supplied via
>               msg_name.
> 
> "The payload of the original packet that caused the error". In order to do
> this, the kernel must keep a copy of all recently sent UDP packets around,
> if only to verify the authenticity of the ICMP responses.

Hi, bert:

The ICMP header has an “original datagram” field that returns (part of?)
the original packet that elicited the ICMP error response. Is it
possible the manpage author garbled the distinction between the actual
original packet, and the copy of the original packet that gets reflected
in the ICMP response?

This blog post kind of implies that it's the copy of the original packet
embedded in the ICMP message:

    https://dominic-wong.name/2013/01/per-socket-extended-error-queues/

    Per-socket extended error queues
    …

    If you’re after the nitty-gritty details, the actual ICMP message
    data can be accessed either through the struct sock_extended_err
    struct, or via casting into a struct icmphdr the data buffer we
    supplied in the msg_iov member of the msghdr structure.
    …

> A nice experiment if someone feels like it. If this turns out to be the
> case, a Linux kernel change to not track ICMP for UDP if IP_RECVERR is not
> set might be wise. Or conversely, maybe a setsockopt IP_FIREANDFORGET.

I have an idea for a meta-experiment: we could invite a couple of kernel
network developers to a DNS-OARC, and feed them coffee/beer until all of
our kernel questions are answered :-)

-- 
Robert Edmonds