On Wednesday, November 11, 2015 10:01:51 PM Tony Finch wrote:
> Paul Vixie <p...@redbarn.org> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
