<div dir="ltr">To quote the late Douglas Adams, from HHGttG:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><h1 class="gmail-quoteText" style="margin:0px 0px 15px;color:rgb(24,24,24);font-weight:normal;padding:0px;font-size:14px;font-family:Merriweather,Georgia,serif;line-height:21px">“There’s no point in acting surprised about it. All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for 50 of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start making a fuss about it now. … What do you mean you’ve never been to Alpha Centauri? Oh, for heaven’s sake, mankind, it’s only four light years away, you know. I’m sorry, but if you can’t be bothered to take an interest in local affairs, that’s your own lookout. Energize the demolition beams.”</h1></blockquote><div><br></div><div>The main issue with having the discussion on github, is that it is a discussion on github, not on a major mailing list involving the operators and folks doing independent implementations.</div><div><br></div><div>The other main issue is, that EDNS UDP size is negotiated.</div><div>This means that it is NOT required that the default be the same on both the client and server.</div><div>I would argue that which end should be lower, should depend largely on:</div><div><ol><li>The number of potential places overrides are necessary</li><li>The comparative skill and expertise of the operators in those places</li><li>The log-log nature of distribution of volume of queries between the top-talkers (biggest recursives and biggest authorities) and the long tail</li><li>The position in the ecosystem of the various software elements, i.e. client-recursive vs recursive-root vs recursive-TLD vs recursive-leaf-auth</li></ol><div>There is asymmetry involved, when a lot of small-ish clients have new defaults that end up triggering excessive TCP traffic, which disproportionately impacts the authority server operators who then have no control over the situation.</div></div><div><br></div><div>As such, I would greatly prefer the recommendation be lifted to a higher number, that is supported by the data, which achieves the following simultaneous goals:</div><div><ul><li>Minimize probability of fragmentation (to approximately 0.1% or 0.01% or even lower)</li><li>Minimize the resulting degree of TCP traffic triggered by DNS responses that exceed the UDP size negotiated</li></ul><div>To me, that means maximizing the UDP size within a reasonable range of observed data points with similar-enough behavior.</div></div><div><br></div><div>From a theoretical perspective, I would be surprised if 1452 wouldn't work, but the data suggests otherwise, from what I recall. (1452 = 1500 - 8 bytes for MPLS or 802.1q, twice, plus L2 (ethernet frame) encapsulation over MPLS, plus IP-in-IP encapsulation, either/or (twice).</div><div>If 1400 will work pretty much as well as 1232, I really want to encourage re-evaluating consensus regarding the Flag Day 2020 number.</div><div><br></div><div>Brian</div><div><br></div><div>P.S. Maybe we could call this "frag day" instead? Apologies if anyone finds that term offensive for any reason. But this is all about fragmentation, and "frag" is much less of a mouthful, and it rhymes with "flag".</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 11, 2020 at 9:46 AM Vladimír Čunát <<a href="mailto:vladimir.cunat%2Bietf@nic.cz">vladimir.cunat+ietf@nic.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/11/20 4:44 PM, Paul Hoffman wrote:<br>
> If this is really just a vendor-driven flag day, please be clearer about that on the web page.<br>
<br>
The GitHub repo and other places have been open for *everyone* to<br>
participate in the discussions.  That's how I understand the "we",<br>
similarly to "we DNSOP".  Yes, the final number was not unanimous, but<br>
such a thing rarely happens.  And yes, I think it's true that<br>
open-source resolver vendors were the most active there.<br>
<br>
--Vladimir<br>
<br>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div>