> On Sep 26, 2020, at 5:01 AM, Ian Swett <ianswett=40google....@dmarc.ietf.org> > wrote: > > > >> On Fri, Sep 25, 2020 at 10:09 PM Tommy Pauly >> <tpauly=40apple....@dmarc.ietf.org> wrote: >> Hi Jana, >> >> Currently, HTTP/3 support in Safari needs to be enabled by the user (under >> Experimental Features). When it is enabled, the ALPN hint in the HTTPS >> record causes the stack to race QUIC first (assuming we have no history of >> QUIC failures), even when no previous connections had been made to the host. > > What if there is a history of QUIC failures and what constitutes a failure? > And is the history per-host, per-user or some combination thereof? > > I'm curious how this logic compares to Chrome's current logic.
We store a history of success/failure/losing the race on a per-host basis. This is based on our logic for racing IPv6 and IPv4 for happy eyeballs. If we have no successful QUIC connections within a certain period of time, but have a number of failures or lost races above a threshold (~10), we’ll race with TCP first. If a failure is detected at the H3 layer (not in the race or in the QUIC handshake), we have a lower threshold before swapping the race order. Thanks, Tommy > > Thanks, Ian > >> >> Thanks, >> Tommy >> >>>> On Sep 25, 2020, at 6:08 PM, Jana Iyengar <jri.i...@gmail.com> wrote: >>>> >>> >>> Thanks for sharing this, Tommy -- this is exciting indeed. >>> Can you share if Safari uses this information for deciding when to race a >>> QUIC connection? >>> >>> - jana >>> >>>> On Fri, Sep 25, 2020 at 1:19 PM Tommy Pauly >>>> <tpauly=40apple....@dmarc.ietf.org> wrote: >>>> Hi David, >>>> >>>> Sorry for the lack of clarity! The HTTPS query will be made alongside >>>> A/AAAA queries for all connections that use Network.framework/NSURLSession >>>> for URL schemes “http://“ and “https://“, or TCP port 80 or port 443. >>>> >>>> Thanks, >>>> Tommy >>>> >>>>> On Sep 25, 2020, at 1:12 PM, David Schinazi <dschinazi.i...@gmail.com> >>>>> wrote: >>>>> >>>>> Hi Tommy, >>>>> >>>>> Thanks for the announcement! It's really exciting to see this deployed in >>>>> the wild. >>>>> Clarification question: your email mentioned support for the HTTPS DNS >>>>> query, >>>>> but it didn't mention when iOS makes those queries. For example, do you >>>>> query >>>>> this record every single time you perform A/AAAA queries? (in the context >>>>> of >>>>> a Network.framework connection to port 443) >>>>> >>>>> David >>>>> >>>>> On Fri, Sep 25, 2020 at 12:59 PM Tommy Pauly >>>>> <tpauly=40apple....@dmarc.ietf.org> wrote: >>>>>> Hello DNSOP & QUIC, >>>>>> >>>>>> I wanted to provide an update that the production version of iOS 14, >>>>>> which shipped last week, includes support for sending HTTPS (SVCB) DNS >>>>>> queries (RR type 65) for applications using our system networking APIs. >>>>>> >>>>>> The implementation status has been updated here: >>>>>> https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md >>>>>> >>>>>> For those with HTTP/3 QUIC deployments, this means that (when HTTP/3 >>>>>> experimental support is enabled) iOS will use the ALPN indication in the >>>>>> HTTPS record to enable HTTP/3 prior to receiving an Alt-Svc indication. >>>>>> As previously noted on the DNSOP list, Cloudflare is already supporting >>>>>> publishing these records, and we’d encourage other server deployments >>>>>> that support QUIC to do the same. >>>>>> >>>>>> To note, this behavior is the same in the betas of macOS 11. >>>>>> >>>>>> Best, >>>>>> Tommy >>>>> _______________________________________________ >>>>> DNSOP mailing list >>>>> DNSOP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnsop >>>>
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
