<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 22, 2020, at 2:31 PM, Steve Crocker <<a href="mailto:steve@shinkuro.com" class="">steve@shinkuro.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div style="font-family:garamond,times new roman,serif;font-size:large" class="gmail_default">Ken,</div><div style="font-family:garamond,times new roman,serif;font-size:large" class="gmail_default"><br class=""></div><div style="font-family:garamond,times new roman,serif;font-size:large" class="gmail_default">Thanks for this. After reading the document and your email, I have the following comments and questions.</div><div style="font-family:garamond,times new roman,serif;font-size:large" class="gmail_default"><ol class=""><li class="">I believe I understand the general idea of measuring both availability and latency to each of the various root server identities (RSIs) multiple times over a 30 minute period. I had a bit of trouble understanding the precise specifications. I am completely comfortable with math and math notation, so my trouble is due to some missing pieces in the description. I suspect this is easily remedied with a few more words.<br class=""></li></ol></div></div></div></blockquote><div><span style="font-size: 14px;" class="">Agree that it could be expressed better. Adding formulas with more squiggly lines and Greek letters would be good. I’d like to talk through the metric on the call tomorrow and get some consensus. I may then ask for help with the notation.</span></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div style="font-family:garamond,times new roman,serif;font-size:large" class="gmail_default"><ol start="1" class=""><li class="">What is the justification for the numbers, e.g. 20 times, σ = .65, etc</li></ol></div></div></div></blockquote><div><span style="font-size: 14px;" class="">The justification for σ = 0.65 is in the user narrative document, but pasted here:</span></div><span style="color: rgb(60, 64, 67); font-family: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; font-variant-ligatures: normal; letter-spacing: 0.2px; orphans: 2; widows: 2; background-color: rgb(255, 255, 255); text-decoration-thickness: initial;" class=""><div class=""><div class=""><br class=""></div></div></span></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><span style="color: rgb(60, 64, 67); font-family: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; font-variant-ligatures: normal; letter-spacing: 0.2px; orphans: 2; widows: 2; background-color: rgb(255, 255, 255); text-decoration-thickness: initial;" class=""><span style="font-size: 14px;" class="">desired probability 0.95 success rate for measurement point among N=3 RSIs.</span></span></div><div><span style="color: rgb(60, 64, 67); font-family: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; font-size: 14px; font-variant-ligatures: normal; letter-spacing: 0.2px; orphans: 2; widows: 2; background-color: rgb(255, 255, 255); text-decoration-thickness: initial;" class="">(1-p)^N = (1 - 0.95)</span></div><div><span style="color: rgb(60, 64, 67); font-family: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; font-size: 14px; font-variant-ligatures: normal; letter-spacing: 0.2px; orphans: 2; widows: 2; background-color: rgb(255, 255, 255); text-decoration-thickness: initial;" class="">p = 0.63. (for N=3)</span></div><div><span style="color: rgb(60, 64, 67); font-family: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; font-size: 14px; font-variant-ligatures: normal; letter-spacing: 0.2px; orphans: 2; widows: 2; background-color: rgb(255, 255, 255); text-decoration-thickness: initial;" class="">round to p = 0.65</span></div><div><span style="color: rgb(60, 64, 67); font-family: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; font-size: 14px; font-variant-ligatures: normal; letter-spacing: 0.2px; orphans: 2; widows: 2; background-color: rgb(255, 255, 255); text-decoration-thickness: initial;" class="">note that desired rate of 0.95 is starting point for discussion</span></div><div><span style="color: rgb(60, 64, 67); font-family: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; font-size: 14px; font-variant-ligatures: normal; letter-spacing: 0.2px; orphans: 2; widows: 2; background-color: rgb(255, 255, 255); text-decoration-thickness: initial;" class=""><br class=""></span></div></blockquote><font color="#3c4043" face="Roboto, RobotoDraft, Helvetica, Arial, sans-serif" class=""><span style="font-size: 14px; letter-spacing: 0.20000000298023224px;" class="">As for the “20" values, those are somewhat out of the blue. Just waiting for someone to ask why and start the discussion. For availability, we need a moderate number of samples. 20 samples seems reasonable to me right now, but open to other thoughts. As for averaging 20 metrics before competing to other sites, I just wanted something that can wash away some anomalies and get a better idea of what is happening at a location. I feel the same about the T=30 minute interval; open to ideas.</span></font><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div style="font-family:garamond,times new roman,serif;font-size:large" class="gmail_default"><ol start="2" class=""><li class="">What conclusion would you draw if the local measurements show there is extremely high availability but latency varies between very low and not so low. For example, there might be one RSI that is topologically close but suffers intermittent availability and other RSIs that are not as close but extremely reliable?<br class=""></li></ol></div></div></div></blockquote><div><span style="font-size: 14px;" class="">These scenarios will hopefully average out over enough samples (do we need more than 20?). We are not treating latency and availability as equal factors, but the 2 scenarios you describe above might end having similar metrics.</span></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div style="font-family:garamond,times new roman,serif;font-size:large" class="gmail_default"><ol start="3" class=""><li class="">Adding one or more additional root servers is one way to improve both reliability and availability. Installing local root service is another way to accomplish the same goals. How do you expect the measurement process described in this document will affect discussions regarding these two approaches?</li></ol></div></div></div></blockquote><div><span style="font-size: 14px;" class="">This measurement process should just be data points for each case. A recursive operator might use a bad result as justification to implement local root for its user base (although this measurement would not reflect the improvements of local root). A RSO would probably want a lot of data points to inform their subjective “underserved” decision. Bottom line is that this metric will not be a definitive answer or a direct reason for any particular action. You still need to do your homework.</span></div><div><span style="font-size: 14px;" class=""><br class=""></span></div><div><span style="font-size: 14px;" class="">Thanks for the comments!</span></div><div><span style="font-size: 14px;" class=""><br class=""></span></div><div><span style="font-size: 14px;" class="">-Ken</span></div></div></body></html>