<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 11, 2020 at 1:01 PM 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 9:14 PM, Randy Bush wrote:<br>
>> The main issue with having the discussion on github, is that it is a<br>
>> discussion on github, not on a major mailing list involving the<br>
>> operators and folks doing independent implementations.<br>
> for cabals which like a bubble, this is a feature, not a bug<br>
<br>
Are you telling me that Flag Day 2020 got too little publicity in here<br>
and similar circles?  (its web, linked to GitHub, the plans, etc.)  I<br>
rather thought we've pushed it everywhere often enough to make anyone<br>
sick of the topic, but perhaps my perception is biased.  I'm really<br>
sorry if anyone feels excluded from the discussion.  To be clear, we've<br>
had multiple "Flag Day 2020" threads just on this list.<br></blockquote><div><br></div><div>TL;DR: Yes, or rather the content of that discussion was not necessarily raised adequately in other venues, IMNSHO.</div><div><br></div><div>The main participants on that github site appear to not have had enough breadth and depth of experience on networks, low-level transports, and all the roles in the DNS ecosystem, to collectively make supportable conclusions/decisions.</div><div>E.g. "voting" based on participant's opinions is neither justifiable nor sensible, especially if there are only five voters. The majority of those votes appeared to be suffering from "group think" after reading the paper discussing the range of 12xx to 1400.</div><div><br></div><div>In particular, things really went off the rails when discussing using client-side defaults lower than current defaults, i.e. Paul Vixie's suggestion to leave the offered client bufsize as is, and only change the server-side configured max size.</div><div><br></div><div>The discussion around that mostly devolved to vendors/implementers defending past engineering/implementation choices (that's how we did it), without adequately considering the actual real-world impact.</div><div><br></div><div>The deployment to client side machines will be a slow roll, for sure.</div><div><br></div><div>But the difficulty, time, and pain, to roll that *back* when it is discovered as a major operational PITA and cost for authority operators, has been completely overlooked.</div><div><br></div><div>In short: I would be perfectly okay if the recommendation were ONLY for the authority (and server side of resolvers) to lower their default configured UDP bufsizes, at which point having a range of recommended values (rather than a single value) would be more appropriate.</div><div>Server-side defaults can have their values changed (overridden) by config changes, but that ONLY has effect if the clients are NOT ALSO implementing the SAME values.</div><div><br></div><div>That's the problem: EDNS0 UDP Bufsize negotiation allows different values to be configured/offered, and uses the MINIMUM value. If both ends have their defaults lowered, and that causes a problem, it CANNOT be fixed unilaterally.</div><div><br></div><div>Even only considering the recursive resolver population (estimated at ~3M), this is a huge issue, and IMHO a huge mistake.</div><div><br></div><div>The analysis of the relative impact (e.g. N x cost for TCP) ignores things like state exhaustion, where the state CANNOT be increased (since port 53 is mandated, and server IP addresses are hardcoded everywhere). You cannot add IP addresses or ports to fix state exhaustion, which can be a localized issue on anycast operated networks. </div><div><br></div><div>Sorry for the long message, but it is really a big deal, and the timeline is unfortunate. I'd suggest pushing the date back by a month or two minimum, and re-opening discussion on these issues on the github site.</div><div><br></div><div>Or, discuss them here with a wider set of participants.</div><div><br></div><div>Brian</div></div></div>