from an attacker POV, I would strongly support PUSH, as it would increase DDoS effectiveness. The performance enhancement seems to be based on some presumptions about servers retaining residual knowledge of the resolver behaviours. PULL minimizes the attack surface. wrt cache coherence and delay, I think the resolver is closer to the APPs using the data and so may be in a batter place to understand what is and will be needed. Those needs can be met with prefetching/caching, which mitigate the RTT/delay issues. Status Quo - if it was good enough for Phil Almquist, it's good enough for me! :)
/Wm On Tue, Aug 16, 2016 at 3:32 PM, George Michaelson <g...@algebras.org> wrote: > On Tue, Aug 16, 2016 at 10:57 PM, Tim Wicinski <tjw.i...@gmail.com> wrote: > > > All of these documents are attempting to solve a larger problem in > different > > ways. The end result is "Return Associated Answer" to the client. > > > > The question is starting to coalesce around these two premises: > > > > - Do we want to Server to PUSH any or all Associated Answers, or > > This option reduces effective RTT delay. It has the most performace > improvement in DNS delay reduction, assuming the extra payload is > determined to be needed eg flags, or heuristical analysis of client > behaviour. > > Its cost is additional data on the server->client path. Personally, I > think this is the best option and the one most likely to increase > cache coherence, timeliness, and reduce delay in the DNS phase. > > > > > - Do we want the Client to PULL any or all Associated Answers, or > > This minimizes traffic. Otherwise, it maximises delay if subsequent > query is needed. I would suggest that a client option or flag to > request this behaviour is plausible if PUSH is the norm. > > > > > - Do we want the Status Quo? > > This seems the safest option and the most inherently boring, and > pointless. Why are we here if we think the best bet is the status quo? > Down down, deeper and down... > > -G > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
