Re: [DNSOP] SVCB without A/AAAA records at the service name

[Martin Thomson <[e-mail]>]

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 <[e-mail]> wrote:
> > 
> > 
> > On Tue, Jan 19, 2021 at 7:40 PM Martin Thomson <[e-mail]> 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