SvcPriority and complex clients

[bemasc]

The SVCB SvcPriority was designed to guide a simple client that is connecting "from scratch", with no further information about the service or the network. In that context, the function of SvcPriority is fairly clear.

For clients with a memory of prior connection attempts, the function of SvcPriority is less clear. If the most preferred endpoint failed recently, can the client skip it the next time?

And what about highly optimized clients that are racing multiple connections? Can they race connections across multiple SvcPriorities, or should they wait until all the priority 1 endpoints fail?

Even in the simple case, the definition of "failure" is somewhat nebulous. TCP (and QUIC) connection initiation generally relies on exponential backoff that may not give up until multiple minutes have passed. Surely we don't want clients to wait 100+ seconds before trying the priority 2 endpoint...

These questions are obviously relevant to mobile- and browser-like clients. They're also increasingly relevant to DNS servers, as the DELEG group is considering SVCB-based definitions of DNS delegation. DNS resolvers already use complex heuristics to estimate the latency and reliability of each nameserver, in order to select the best one (while still monitoring the others).

@enygren @MikeBishop

[MikeBishop]

I'd be inclined toward similar guidance to the preference Happy Eyeballs currently gives to IPv6 -- give higher preference endpoints a brief head start, then use whichever connection first completes successfully.

[bashi]

Another similar complexity may come from the Alt-Svc header and the ALTSVC HTTP/2 frame.