[atlas] DNS RTT over TCP: twice as long than UDP?

Count me in for second pony :D

Regards,
Grzegorz

From: Petr Špaček <petr.spacek at nic.cz>
Organization: CZ.NIC
Date: Wednesday 2019-07-10 at 09:14
To: "ripe-atlas at ripe.net" <ripe-atlas at ripe.net>
Subject: Re: [atlas] DNS RTT over TCP: twice as long than UDP?

On 09. 07. 19 13:51, Ponikierski, Grzegorz wrote:
From this traffic looks like dig measures time between packets 4 (DNS
query) and 6 (DNS response) which is precisely 8.5ms and matches what
dig shows. Including TCP handshake it takes 23.7ms, 2.8x longer which is
expected .

RTT can be measured on different layers for the same communication
stream. In case of DNS over UDP we just ignores UDP overhead because it
doesn't add any packets. With TCP additional packets are added which
significantly increase time that end-user have to wait from first packet
to get information that he/she needs. IMO RTT should always be measured
from 1^st packet to packet which has information that you have actual
data. If we want to measure raw DNS performance without overhead then it
must be explicitly market it measurement description.

If I could get a ponny, I would like to get both numbers:

a) Time measured from moment of sending the very first packet (TCP SYN
or UDP query) to arrival of DNS answer (not counting TCP FIN etc.).

b) Time measured from moment of sending the DNS query (also think of TCP
fast open!) to arrival of DNS answer (not counting TCP FIN etc.).

Having both numbers would allow to calculate latency of connection vs.
DNS query separately, which gets even more important when we consider
DNS-over-TLS etc.

--
Petr Špaček  @  CZ.NIC


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20190710/c78d5dd0/attachment.html>