Re: [systemd-devel] high latency on systemd-resolved repsonses of LLMNR names
Am Mon, 10 Apr 2017 12:46:02 +0200 schrieb Lennart Poettering : > On Mon, 10.04.17 12:41, Kai Krakow (hurikha...@gmail.com) wrote: > > > > Queries and responses in LLMNR are supposed to be delayed by a > > > random time up to 100ms according to the RFC. See: > > > > > > https://tools.ietf.org/html/rfc4795 section 2.7, and section 7. > > > > > > If you add up the delay for the query and the response you'll get > > > a delay up to 200ms for a full transaction. > > > > Well it seems a bit more complicated: > > > > The random delays are a combined value of jitter and timeout. And it > > depends on whether you're currently the sender or responder: > > Responders have shorter timeouts (only jitter), according to > > section 2.7. > > > > It also says SHOULD wait (so it is a good idea), and it says the > > jitter MAY be ignored if the responder knows the name is unique. > > Only the sender MUST wait for timeout+jitter. > > > > This is where the 200ms come from, but it may even be 1000+100ms if > > you are connected to none-IEEE 802.* media, e.g. VPN or PPP > > interfaces and LLMNR is configured to listen on these, as far as I > > understand section 7. > > > > According to RFC2119, the terminology SHOULD suggests that systemd > > could maybe make this configurable? Maybe taking the proper > > warnings for this configuration into account for administrators... > > Still you would see delays of at least 100ms then because the > > sender MUST wait. > > I am not a fan of configuration options in zeroconfey technology like > this one I must say. I mean "zeroconf" is about "zero configuration", > hence making it configurable creates kind of a tautology... As I pointed out it wouldn't have a big effect anyways, so probably you're perfectly right. Is there a way to know the delays used, i.e. if it 1000 or 100ms? -- Regards, Kai Replies to list-only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] high latency on systemd-resolved repsonses of LLMNR names
On Mon, 10.04.17 13:50, Kai Krakow (hurikha...@gmail.com) wrote: > > > According to RFC2119, the terminology SHOULD suggests that systemd > > > could maybe make this configurable? Maybe taking the proper > > > warnings for this configuration into account for administrators... > > > Still you would see delays of at least 100ms then because the > > > sender MUST wait. > > > > I am not a fan of configuration options in zeroconfey technology like > > this one I must say. I mean "zeroconf" is about "zero configuration", > > hence making it configurable creates kind of a tautology... > > As I pointed out it wouldn't have a big effect anyways, so probably > you're perfectly right. > > Is there a way to know the delays used, i.e. if it 1000 or 100ms? IIRC debug logging shows it. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] high latency on systemd-resolved repsonses of LLMNR names
On Mon, 10.04.17 12:41, Kai Krakow (hurikha...@gmail.com) wrote: > > Queries and responses in LLMNR are supposed to be delayed by a random > > time up to 100ms according to the RFC. See: > > > > https://tools.ietf.org/html/rfc4795 section 2.7, and section 7. > > > > If you add up the delay for the query and the response you'll get a > > delay up to 200ms for a full transaction. > > Well it seems a bit more complicated: > > The random delays are a combined value of jitter and timeout. And it > depends on whether you're currently the sender or responder: Responders > have shorter timeouts (only jitter), according to section 2.7. > > It also says SHOULD wait (so it is a good idea), and it says the jitter > MAY be ignored if the responder knows the name is unique. Only the > sender MUST wait for timeout+jitter. > > This is where the 200ms come from, but it may even be 1000+100ms if > you are connected to none-IEEE 802.* media, e.g. VPN or PPP interfaces > and LLMNR is configured to listen on these, as far as I understand > section 7. > > According to RFC2119, the terminology SHOULD suggests that systemd could > maybe make this configurable? Maybe taking the proper warnings for this > configuration into account for administrators... Still you would see > delays of at least 100ms then because the sender MUST wait. I am not a fan of configuration options in zeroconfey technology like this one I must say. I mean "zeroconf" is about "zero configuration", hence making it configurable creates kind of a tautology... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] high latency on systemd-resolved repsonses of LLMNR names
Am Mon, 10 Apr 2017 10:26:14 +0200 schrieb Lennart Poettering : > On Sun, 09.04.17 19:22, Paul Freeman (p...@coredev.org.uk) wrote: > > > Hi, > > We are seeing high latency (>100ms) when resolving local names via > > LLMNR. > > Queries and responses in LLMNR are supposed to be delayed by a random > time up to 100ms according to the RFC. See: > > https://tools.ietf.org/html/rfc4795 section 2.7, and section 7. > > If you add up the delay for the query and the response you'll get a > delay up to 200ms for a full transaction. Well it seems a bit more complicated: The random delays are a combined value of jitter and timeout. And it depends on whether you're currently the sender or responder: Responders have shorter timeouts (only jitter), according to section 2.7. It also says SHOULD wait (so it is a good idea), and it says the jitter MAY be ignored if the responder knows the name is unique. Only the sender MUST wait for timeout+jitter. This is where the 200ms come from, but it may even be 1000+100ms if you are connected to none-IEEE 802.* media, e.g. VPN or PPP interfaces and LLMNR is configured to listen on these, as far as I understand section 7. According to RFC2119, the terminology SHOULD suggests that systemd could maybe make this configurable? Maybe taking the proper warnings for this configuration into account for administrators... Still you would see delays of at least 100ms then because the sender MUST wait. -- Regards, Kai Replies to list-only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] high latency on systemd-resolved repsonses of LLMNR names
On Sun, 09.04.17 19:22, Paul Freeman (p...@coredev.org.uk) wrote: > Hi, > We are seeing high latency (>100ms) when resolving local names via > LLMNR. Queries and responses in LLMNR are supposed to be delayed by a random time up to 100ms according to the RFC. See: https://tools.ietf.org/html/rfc4795 section 2.7, and section 7. If you add up the delay for the query and the response you'll get a delay up to 200ms for a full transaction. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] high latency on systemd-resolved repsonses of LLMNR names
Hi,
We are seeing high latency (>100ms) when resolving local names via
LLMNR.
systemd v233 / Gentoo
There appears to be a large delay between systemd-resolved receiving
the udp query over 127.0.0.53:53 and when it dispatches the LLMNR query:
18:29:38.752644 clock_gettime(CLOCK_BOOTTIME, {18217, 767968786}) = 0
18:29:38.752854 recvfrom(12, NULL, 0, MSG_PEEK|MSG_TRUNC, NULL, NULL) =
46
18:29:38.753119 recvmsg(12, {msg_name={sa_family=AF_INET,
sin_port=htons(52277), sin_addr=inet_addr("127.0.0.1")},
msg_namelen=128->16, msg_iov=[{iov_base="9m\1
\0\1\0\0\0\0\0\1\5zeusv\0\0\1\0\1\0\0)\20\0\0\0\0\0"..., iov_len=3936}],
msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_IP,
cmsg_type=IP_PKTINFO, cmsg_data={ipi_ifindex=if_nametoindex("lo"),
ipi_spec_dst=inet_addr("127.0.0.53"),
ipi_addr=inet_addr("127.0.0.53")}}, {cmsg_len=20, cmsg_level=SOL_IP,
cmsg_type=IP_TTL, cmsg_data=[64]}], msg_controllen=56, msg_flags=0}, 0)
= 46
18:29:38.753680 stat("/etc/hosts", {st_dev=makedev(8, 4),
st_ino=17019407, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0,
st_blksize=4096, st_blocks=8, st_size=1213,
st_atime=2017/01/23-05:40:35.417021678, st_mtime=2016/09/01-21:55:25,
st_ctime=2017/03/20-01:21:31.905862840}) = 0
18:29:38.754087 stat("/etc/resolv.conf", {st_dev=makedev(8, 4),
st_ino=1667316, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0,
st_blksize=4096, st_blocks=8, st_size=484,
st_atime=2017/04/07-02:39:49.250057911,
st_mtime=2017/04/07-02:26:21.445885318,
st_ctime=2017/04/07-02:39:55.170044459}) = 0
18:29:38.754466 getrandom("G\355", 2, GRND_NONBLOCK) = 2
18:29:38.754665 stat("/etc/resolv.conf", {st_dev=makedev(8, 4),
st_ino=1667316, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0,
st_blksize=4096, st_blocks=8, st_size=484,
st_atime=2017/04/07-02:39:49.250057911,
st_mtime=2017/04/07-02:26:21.445885318,
st_ctime=2017/04/07-02:39:55.170044459}) = 0
18:29:38.755028 clock_gettime(CLOCK_BOOTTIME, {18217, 770345701}) = 0
18:29:38.755224 clock_gettime(CLOCK_BOOTTIME, {18217, 770532540}) = 0
18:29:38.755399 getrandom("$\367\2557x\301\261!", 8, GRND_NONBLOCK) = 8
18:29:38.755581 timerfd_settime(19, TFD_TIMER_ABSTIME, {it_interval={0,
0}, it_value={18217, 960132000}}, NULL) = 0
18:29:38.755766 epoll_wait(4, [{EPOLLIN, {u32=44602104,
u64=292102378232}}], 20, -1) = 1
18:29:38.950146 clock_gettime(CLOCK_BOOTTIME, {18217, 965532171}) = 0
18:29:38.950445 read(19, "\1\0\0\0\0\0\0\0", 8) = 8
18:29:38.950760 sendmsg(13, {msg_name={sa_family=AF_INET,
sin_port=htons(5355), sin_addr=inet_addr("224.0.0.252")},
msg_namelen=16,
msg_iov=[{iov_base="G\355\0\0\0\1\0\0\0\0\0\0\5zeusv\0\0\1\0\1",
iov_len=23}], msg_iovlen=1, msg_control=[{cmsg_len=28,
cmsg_level=SOL_IP, cmsg_type=IP_PKTINFO,
cmsg_data={ipi_ifindex=if_nametoindex("eth0"),
ipi_spec_dst=inet_addr("0.0.0.0"), ipi_addr=inet_addr("0.0.0.0")}}],
msg_controllen=28, msg_flags=0}, 0) = 23
18:29:38.951422 timerfd_settime(19, TFD_TIMER_ABSTIME, {it_interval={0,
0}, it_value={18218, 278485000}}, NULL) = 0
18:29:38.951757 epoll_wait(4, [{EPOLLIN, {u32=44630672,
u64=292102406800}}], 20, -1) = 1
18:29:38.952078 clock_gettime(CLOCK_BOOTTIME, {18217, 967408726}) = 0
18:29:38.952388 recvfrom(13, NULL, 0, MSG_PEEK|MSG_TRUNC, NULL, NULL) =
23
18:29:38.952782 recvmsg(13, {msg_name={sa_family=AF_INET,
sin_port=htons(5355), sin_addr=inet_addr("192.168.166.49")},
msg_namelen=128->16,
msg_iov=[{iov_base="G\355\0\0\0\1\0\0\0\0\0\0\5zeusv\0\0\1\0\1",
iov_len=3936}], msg_iovlen=1, msg_control=[{cmsg_len=28,
cmsg_level=SOL_IP, cmsg_type=IP_PKTINFO,
cmsg_data={ipi_ifindex=if_nametoindex("eth0"),
ipi_spec_dst=inet_addr("192.168.166.49"),
ipi_addr=inet_addr("224.0.0.252")}}, {cmsg_len=20, cmsg_level=SOL_IP,
cmsg_type=IP_TTL, cmsg_data=[255]}], msg_controllen=56, msg_flags=0}, 0)
= 23
18:29:38.953365 epoll_wait(4, [{EPOLLIN, {u32=44630672,
u64=292102406800}}], 20, -1) = 1
18:29:38.953616 clock_gettime(CLOCK_BOOTTIME, {18217, 968941015}) = 0
18:29:38.953831 recvfrom(13, NULL, 0, MSG_PEEK|MSG_TRUNC, NULL, NULL) =
39
18:29:38.954057 recvmsg(13, {msg_name={sa_family=AF_INET,
sin_port=htons(5355), sin_addr=inet_addr("192.168.166.52")},
msg_namelen=128->16,
msg_iov=[{iov_base="G\355\200\0\0\1\0\1\0\0\0\0\5zeusv\0\0\1\0\1\300\f\0\1\0\1\0\0\0"...,
iov_len=3936}], msg_iovlen=1, msg_control=[{cmsg_len=28,
cmsg_level=SOL_IP, cmsg_type=IP_PKTINFO,
cmsg_data={ipi_ifindex=if_nametoindex("eth0"),
ipi_spec_dst=inet_addr("192.168.166.49"),
ipi_addr=inet_addr("192.168.166.49")}}, {cmsg_len=20, cmsg_level=SOL_IP,
cmsg_type=IP_TTL, cmsg_data=[255]}], msg_controllen=56, msg_flags=0}, 0)
= 39
18:29:38.954738 clock_gettime(CLOCK_BOOTTIME, {18217, 970057860}) = 0
18:29:38.954965 sendmsg(12, {msg_name={sa_family=AF_INET,
sin_port=htons(52277), sin_addr=inet_addr("127.0.0.1")}, msg_namelen=16,
msg_iov=[{iov_base="9m\201\200\0\1\0\1\0\0\0\1\5zeusv\0\0\1\0\1\300\f\0\1\0\1\0\0\0"...,
iov_len=50}], msg_iovlen=1, msg_control=[{cmsg_len=28,
cmsg_level=
