Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

[Shane Kerr <[e-mail]>]

Tim,

[ Apologies for coming late to the party. I was on vacation. ]

At 2016-08-16 08:57:04 -0400
Tim Wicinski <[e-mail]> 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