On 11/11/15, 5:01 PM, "Tony Finch" <d...@dotat.at> wrote:
>Paul Vixie <p...@redbarn.org> wrote: >> On Wednesday, November 11, 2015 04:41:27 PM Tony Finch wrote: >> > Paul Vixie <p...@redbarn.org> wrote: >> > >> > > yes, that's flooding the channel. you're allowed one work-stream per >> > > query, in order that timeouts and other loss are only felt as >> > > backpressure by those apps who caused them. >> > >> > Where is that specified? >> >> it's written in tire tracks down my backside. > >Sounds painful :-) > >> > > i have no objection to multiple parallel outstanding upstream >>queries >> > > over a TCP stream. >> > >> > Why is TCP special? >> >> because it has per-flow congestion control. > >Which is perfectly fair, but there is a big difference between saying that >high-volume DNS clients need congestion control, and saying that they must >have at most one query outstanding at any time. If you say TCP is OK, you >are implicitly saying that it's OK to have a window size greater than one >packet. And that implies there are engineering questions about how that >window size should be managed. > >And this implies it is unreasonable to forbid concurrent queries over UDP. >(And it would be futile to break running code in every browser.) > >The upshot of all this is that how you use concurrent queries to improve >performance without breaking things is a matter of engineering and >implementation quality. > >And since (as far as I know) no-one has done that engineering, I think it >is premature to try to deploy a protocol fix for a hypothetical problem. >(adns's concurrency control is quite simplistic, for example.) > >What edns-chain-query says to DNSSEC users is, DNSSEC still isn't finished >or ready for deployment on edge devices, and you have to wait another 5 or >10 years for another protocol change to be deployed before you can get >decent performance. > >This is wrong! Another way to read the message of edns-chain-query is: DNSSEC has many use cases and operation implications. If you would like an alternate path that may reduce latency under some conditions but not compromise the security of the query/response here is one way to tackle it. > >In order to make edns-chain-query work, validators will need to be >refactored to decouple the validation logic from the network chatter. At >the moment there aren't APIs that let you present a chain of DNSKEY and DS >RRsets to a validator and get an assessment. The current model is >"validate this RRset please" and then wait for a dozen RTTs. At this stage there aren¹t widely deployed validating stub resolvers. This is true of new technology in general - I don¹t think the bar for improvements should be ³has this already been implemented?² There are some budding ideas and implementations out there, but any support for DNSSEC on the client/host currently requires changes to the host APIs. > >But once you have a validator API that works with edns-chain-query you >also have a validator API that works with concurrent queries on the >existing DNS. > >So really we should be trying to make that work first, since it has a much >more compelling deployment story. > >And if well-informed engineering makes it clear that the existing DNS >can't reliably handle 6 ish concurrent queries, then maybe it's time to >think about upgrading everything with a new protocol feature. > >Tony. >-- >f.anthony.n.finch <d...@dotat.at> http://dotat.at/ >Northwest Fitzroy: Southwesterly 5 to 7, occasionally gale 8. Rough or >very >rough, becoming very rough or high. Occasional rain. Good, occasionally >poor. > >_______________________________________________ >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
