My apologies here, I think that I misunderstood the structure of the proposed
algorithm originally, however, that might be an opportunity to improve the
description.
My conclusion here is not the same as yours. If you require SVCB, you might
need a different algorithm, or at a minimum you need to run the math (as you
have) for whether you will get a TargetName and whether the TargetName will be
"." before considering the optimizations you are promoting.
If you use HTTPS as the example, the algorithm, as described, is completely
reasonable. But HTTPS is weird. If you are looking at a new protocol
deployment, other factors, such as compatibility with HTTPS deployments, might
change those numbers considerably. That is, P_svcb in this alternative setting
is 1. If we were to do this for a protocol that was allergic to HTTPS - SMTP
is probably a bad example because MX exists, but imagine a similar deployment
arrangement - the result might be that the probability of there being a
TargetName in the record is closer to 0 due to the prevalence of outsourcing of
serving. At that point, you might decide not to spend the cycles on A/AAAA
queries.
HTTPS is also weird in the sense that it is so aggressively latency sensitive.
Even if P_targethost was extraordinarily low (maybe not 1%, but we've wasted
cycles on gains with far worse odds), we'd still probably spend the effort on
it.
So I think that you have this entirely backwards. The concurrent querying of
SVCB and A/AAAA is some combination of an optimization and unique to the one
worked example we have. Acknowledging that might allow the draft to be much
clearer about the logical structure of the process clients follow AND make it
clearer where the optimization opportunities are and how clients might
reasonably decide to take advantage of them. Then you can explain how
different deployment choices (such TargetName == ".") might further take
advantage of those optimizations.
As it is, the algorithm is presented as being definitive, but it really isn't.
What you have is the optimized version of the algorithm, with no real
acknowledgment that alternatives might exist.
--Martin
On Wed, Jan 27, 2021, at 06:59, Ben Schwartz wrote:
> I'd like to try to get to consensus on this point, which is one of the
> last open issues for the draft.
>
> To restate my previous argument, let P_svcb be the probability that a
> SVCB record is present, and if so, let P_targethost be the probability
> that it contains a TargetName that is the hostname. Then (ignoring
> Additional Section processing) the initial AAAA/A query saves (1 -
> P_svcb) + P_svcb*P_targethost resolver roundtrips, on average.
>
> Currently, for HTTPS, P_svcb is about 15%(!), and P_targethost is
> ~100%*, so this always saves one resolver roundtrip.
>
> For a SVCB-reliant protocol, P_svcb is 100%, so the formula simplifies
> to "P_targethost". If P_svcb for HTTPS were to approach 100%, the
> result would be the same, even though HTTPS is not SVCB-reliant.
>
> In other words, keeping P_targethost high, and using speculative
> queries, is good for performance when SVCB is heavily used.
>
> * Assuming Cloudflare has the only current large-scale deployment of
> HTTPS records.
>
> On Tue, Jan 19, 2021 at 10:00 PM Ben Schwartz <bem...@google.com> wrote:
> >
> >
> > On Tue, Jan 19, 2021 at 7:40 PM Martin Thomson <m...@lowentropy.net> wrote:
> >> On Wed, Jan 20, 2021, at 09:17, Ben Schwartz wrote:
> >> > As I noted in that discussion, the client generally doesn't know in
> >> > advance that they aren't needed.
> >>
> >> I am asserting that the client very much knows. Indeed, it has to know.
> >> If we define a new protocol that relies on SVCB and that protocol is able
> >> to use SVCB exclusively (which would be a good thing in my view, all this
> >> parallel DNS querying is unnecessary, even if the DNS protocol is pretty
> >> good at it), then a client can very much know.
> >
> > Querying in parallel is of course just an optimization, but the client
> > can't obviously know that those queries won't be needed, even for a
> > protocol that uses SVCB exclusively.
> >
> > Every SVCB mapping ultimately relies on A/AAAA records for the ServiceMode
> > TargetName. The client doesn't know what that TargetName will be until it
> > gets the SVCB response. However, in every protocol considered thus far,
> > the most likely TargetName is the original hostname (or its CNAME alias).
> > By querying that name in parallel, the client can short-circuit a
> > subsequent lookup and reduce latency. This has nothing to do with fallback.
> >
> > Section 10.2 ("Structuring zones for performance") takes this observation
> > and turns it into a recommended convention for the use of TargetName. You
> > can place TargetName anywhere, but if you can line it up with the hostname
> > you'll get better performance, so that's recommended.
> >
> > If I were arguing for your version, I would say either:
> > 1. By the time we have SVCB-reliant protocols, nearly all resolvers will
> > have implemented Additional Section processing, so the client won't have to
> > issue A/AAAA queries at all.
> > OR 2. There will be SVCB-reliant protocols where it is normally
> > inconvenient to use A/AAAA records on the hostname, so the client knows
> > that the TargetName->hostname convention doesn't apply.
> >
> > Personally, I don't believe either of those things ... and since they're
> > both predictions about future standards, we can always clarify in the
> > future.
> >
> > It's worth noting that the sentence in question (Section 3 point 2) has no
> > normative force. That section is just describing what clients are expected
> > to do. So if you want to do it differently ... whatever works.
> >
> >> > Another thing I like about the arrangement in #288 is that it
> >> > simplifies a protocol-independent app/library boundary. The app can
> >> > say "SVCBQuery(hostname, prefixes)" and get back a fully resolved
> >> > object like {svcbEntries: [{...}, ...], hostIPs: [...]}.
> >>
> >> I'm suggesting that the interface might be a little wider.
> >
> > Sure, that's fine too.
> >
> > ...
> >> svcb.query_with_fallback(name) -> Either<svcbEntry[], address[]>
> >
> > Nit: Pair<svcbEntry[], address[]>. If the svcbEntries are all unreachable,
> > clients SHOULD fall back to bare IPs.
> Attachments:
> * smime.p7s
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
