Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query

[Paul Vixie <[e-mail]>]

On Wednesday, November 11, 2015 10:01:51 PM Tony Finch wrote:
> Paul Vixie <[e-mail]> wrote:
> > > > 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.

there has to be a limit. i think we agree on that much. you must know that from the earliest 
days after i took over BIND from UCB/CSRG, it has limited the number of transactions it 
would initiate to any given server, and also the number of transactions it would initiate at 
one time, overall. the first limit is because the other end has buffers. the second limit is 
because my cpu is faster than my LAN which is faster than my WAN.

to meet the "has to be a limit" constraint, we use receive clocking. when the other end 
sends us a packet, that's our signal that we can send one or more packets. if the other end 
can send us a window size (as TCP can) then we might send more than one packet. if not, 
then we have to guess how many packets we can send in that "clock cycle". a stub should, 
unless it has better information, choose the lowest non-zero number available, that being 
one.

"better information" might be the result of new research for estimating available BDP 
between DNS initiators and responders. you're welcome to start that research. i'd love to 
consult with you and help you evaluate alternatives and results.

"better information" might be to aggregate all of the outbound stub flows through some 
local proxy, in which case the answer could be that not all stub flows can run at full (one 
or more transactions per clock cycle) rate, because some finite limit is shared by more than 
one flow, which then take turns in some way.

i hope that clears up what i meant by "at most one transaction outstanding per flow".

> 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.)

your reasoning is nonsequitur. DNS initiators do indeed have more than one concurrent 
transaction at a time, and always have had. however, there is and always has necessarily 
been a limit to the number of transactions per flow. in DNS terms, a flow is a work unit. for 
example, a transaction in progress on the downstream side.

so, i didn't forbid the thing you were afraid i was forbidding. rather, i'm saying that if a 
gethostbyaddr() call for an IPv6 call needs up to 16 DNSKEY and DS RRsets, it is not 
acceptable to send 16 concurrent DS queries and 16 concurrent DNSKEY requests. i'm 
saying that there is no other way to compress the arbitrary amount of work needed to do 
DNSSEC stub validation into a single RTT except to either rely on TCP (which serializes the 
requests and allows the responses to come in any order) or change the protocol to allow 
"chain" queries.

if you'd like this draft changed to reference the tcp negotiation draft now in progress, and 
to say, if the stub can successfully negotiate with the RDNS to keep a tcp session open, 
then serializing the requests over TCP is a reasonable alternative to chain queries, then i 
would have no objections.

> 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.)

BIND's concurrency also works. but all the ADNS-speaking agents on a single "host" do 
not currently share uplink capacity/response metrics. so, you are rationalizing extensively 
here -- making your data fit your conclusions.

the onus of proof is on she who asserts the possible. so, since you agree that there must be 
some limit, it's up to you to show that there is a respected limit in the many-labels case, 
for common configurations, including ADNS. i see no reason to expect such a limit to be 
respected currently, and so i'm saying, the just-send-everything-at-once approach is 
unworkable for UDP/53.

> 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