Tim, [ Apologies for coming late to the party. I was on vacation. ]
At 2016-08-16 08:57:04 -0400 Tim Wicinski <tjw.i...@gmail.com> wrote: > In Berlin we had two presentations on different methods of returning > multiple responses: > > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/ > > https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/ > > and a presentation in Buenos Aires: > > https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/ > > 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 > > - Do we want the Client to PULL any or all Associated Answers, or > > - Do we want the Status Quo? In Berlin there was discussion of measurement, IIRC. ----- For the PULL approach, as I mentioned in Berlin it seems like such an obvious win to collect A and AAAA together into a single query - at least from the stub to the recursive resolver. For the recursive-to-authority side it seems much less obvious and less of a win, since caching will tend to overwhelm any benefit and since you have to worry about maintaining state about whether a given authority server supports the protocol change. Looking at the SIDN statistics it seems like there is about a 4- or 5-to-1 ratio of A to AAAA queries: https://stats.sidnlabs.nl/#/dns In this case, the maximum expected "win" on the authority side seems to be about 10%, which is not great, but maybe worth pursuing. ----- For the PUSH approach, again metrics would help. I guess the main beneficiaries would be CDN or other content sites who use low TTL and generated replies, so maybe someone who works in that environment could think of a reasonable metric? Or is the expectation here also that a recursive resolver would be able to deliver answers before the client asks for them? I can see potential big benefits for mobile or other high-latency devices if done right. Instead of thinking about evil advertising deliveries, a smart recursive resolver can just use statistics and delivery high-probability answers before the stub resolvers ask for them... Cheers, -- Shane
pgpNFU3gE5V0L.pgp
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
