[Yeti DNS Discuss] Study on ATR timer

[Davey Song(宋林健)]

Hi colleagues,

 

I’m writing to brief you about my current study on ATR (https://tools.ietf.
org/html/draft-song-atr-large-resp-02 ). I recently struggle with an issue
which you may give me some comments if you are interested.

 

In short, ATR is a hybrid solution of DNS TCP and DNS UDP by trailing a
small truncated response right after a large response(fragmented). If
resolver fails to receive the first fragmented udp response, it will end up
with fall back to TCP sooner by receiving the second truncated response.
There is a time interval (set via ATR timer) between the two packets. If ATR
timer is too small, it is possible that the second fragmented will be
received first due to Network Reordering(NR) which will cause unnecessary
TCP fallback. If ATR timer is too long, resolver will waste more time to
re-query via TCP impact the benefit of ATR 

 

So the conclusion is made that ATR timer should be set neither too small nor
too long. But the
<http://dict.youdao.com/w/qualitative%20analysis/#keyfrom=E2Ctranslation>
qualitative conclusion cannot fully convince people. People still hesitate
to adopt ATR even when the reordering is very rare under a certain timer.
That’s why I’m ask all Yeti root server to adopt it right now. I think I
need to demonstrate and prove quantitatively how rare the NR is under a
certain time interval of two packets of ATR. Given that the NR is very hard
to avoid, so it is helpful to know the statistic of timer interval caused by
NR between two packets sent sequential without delay. 

 

Now I have some preliminary idea for ATR timer issue. Comments are welcome. 

 

Firstly I convert reordering impact question into an equivalence question of
RTT difference. My argument is that the end-to-end RTT varies every time
which actually reflects the phenomenon of network reordering. If the
variable of RTT for each pair subject to normal distribution, the delay of
two sequential packets caused by NR share similar statistics property with
the difference of RTT of that pair. NR is unpredictable but end-to-end RTT
is easy to measure. In addition there is lots of RTT data for us to analyze.
If we have sufficient data on the global difference of RTT for many
end-to-end pairs, we can calculate the statistic for the standard deviation
of RTT of each pairs. The standard deviation of RTT is meaningful that
trebled of that standard deviation will cover most reordering case (99.7%).
2 times that standard deviation will give us a 95.5% coverage. So if more
pairs’ standard deviation of RTT are understood. We can safely and
confidently choose a general value for ATR timer. If a customized ATR timer
is needed, we can use the same approach to analyze the historic RTT and
offer a proper ATR timer for particular name server.

 

I’m not sure I make this argument clear or not. Does it sounds like a plan?
Now I’m searching data from RIPE Atlas for RTT to fixted destination. They
have built-in measurement on every probe. 

 

Best regards,

Davey

 

 

 

 

I would like invite you to review my ATR draft () and make your voice
because its status is candidate for WG document in DNSOP. 

 

ATR 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yeti-dns.org/pipermail/discuss/attachments/20181219/01b7fc0a/attachment.html>