This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[atlas] DNS RTT over TCP: twice as long than UDP?
- Previous message (by thread): [atlas] DNS RTT over TCP: twice as long than UDP?
- Next message (by thread): [atlas] New on RIPE Labs: Internet Tools BoF Discovers Common Challenges for Network Operators
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ponikierski, Grzegorz
gponikie at akamai.com
Thu Jul 11 00:06:26 CEST 2019
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: </ripe/mail/archives/ripe-atlas/attachments/20190710/c78d5dd0/attachment.html>
- Previous message (by thread): [atlas] DNS RTT over TCP: twice as long than UDP?
- Next message (by thread): [atlas] New on RIPE Labs: Internet Tools BoF Discovers Common Challenges for Network Operators
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]