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

Tue Jul 9 13:51:07 CEST 2019

Just to confirm I verified what exactly dig measures. For example, this dig takes 8ms (which is always rounded):

[gponikie at krk-mptoy atlas_day68_step1]$ dig +tcp example.com @1.1.1.1

; <<>> DiG 9.14.3 <<>> +tcp example.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14416
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;example.com.                                        IN            A

;; ANSWER SECTION:
example.com.                         5212        IN            A              93.184.216.34

;; Query time: 8 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Jul 09 13:17:55 CEST 2019
;; MSG SIZE  rcvd: 56

If you check it with wireshark it looks like this:

No.     Time            Source                Destination           Protocol Length Window size value Shift count Info
      1 13:17:55.014898 192.168.1.83          1.1.1.1               TCP      78     65535             6           53593 → 53 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=676915370 TSecr=0 SACK_PERM=1
      2 13:17:55.029784 1.1.1.1               192.168.1.83          TCP      74     29200             10          53 → 53593 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1412 SACK_PERM=1 WS=1024
      3 13:17:55.029883 192.168.1.83          1.1.1.1               TCP      54     4096                          53593 → 53 [ACK] Seq=1 Ack=1 Win=262144 Len=0
      4 13:17:55.030041 192.168.1.83          1.1.1.1               DNS      108    4096                          Standard query 0x3850 A example.com OPT
      5 13:17:55.038351 1.1.1.1               192.168.1.83          TCP      68     29                            53 → 53593 [ACK] Seq=1 Ack=55 Win=29696 Len=0
      6 13:17:55.038572 1.1.1.1               192.168.1.83          DNS      120    29                            Standard query response 0x3850 A example.com A 93.184.216.34 OPT
      7 13:17:55.038624 192.168.1.83          1.1.1.1               TCP      54     4095                          53593 → 53 [ACK] Seq=55 Ack=59 Win=262080 Len=0
      8 13:17:55.039580 192.168.1.83          1.1.1.1               TCP      54     4096                          53593 → 53 [FIN, ACK] Seq=55 Ack=59 Win=262144 Len=0
      9 13:17:55.047201 1.1.1.1               192.168.1.83          TCP      68     29                            53 → 53593 [FIN, ACK] Seq=59 Ack=56 Win=29696 Len=0
     10 13:17:55.047273 192.168.1.83          1.1.1.1               TCP      54     4096                          53593 → 53 [ACK] Seq=56 Ack=60 Win=262144 Len=0

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 1st 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.

Regards,
Grzegorz

From: Giovane Moura <giovane.moura at sidn.nl>
Date: Friday 2019-07-05 at 14:34
To: "ripe-atlas at ripe.net" <ripe-atlas at ripe.net>
Subject: [atlas] DNS RTT over TCP: twice as long than UDP?

Folks,

This page at Atlas provides a great visualization on the RTT of DNS
queries over TCP/UDP to the Root DNS servers:

https://atlas.ripe.net/results/maps/root-server-performance/

We can see that the RTT of TCP queries  is at least twice as long than
UDP ones (which, according to the page " TCP is expected to be 2-3 times
" longer.

I cannot replicate these results in my setup, even in large scale from
various vantage points: I always get very similar results for either TCP
or UDP. Example:

UDP:
   * $ dig  example.nl @ns1.dns.nl
      Query time: 8 msec

TCP:
   * $dig +tcp example.nl @ns1.dns.nl
      Query time: 9 msec

I think there might be something with the definition of RTT.

My hypothesis is that the field *rtt* on DNS queries on Atlas[1], for
TCP, is, in fact, measuring 2 RTTs: the RTT of the TCP handshake, and
the RTT of query/response itself.

By definition,  however, RTT is "the length of time it takes for a
signal to be sent plus the length of time it takes for an
acknowledgement of that signal to be received."[2]. So if DNS TCP
measurements starts measuring from the SYN packet, that', in fact, be
two RTTs. Is this the case with Atlas?

I know it may sound a bit like nitpicking, but I just want to be sure of
what's exactly being measured.

thanks a lot,

/giovane

[1] https://atlas.ripe.net/docs/data_struct/#v4750_dns
[2] https://en.wikipedia.org/wiki/Round-trip_delay_time

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