Re: Clarification on Alternative Service Connection Failures

On Fri, Sep 29, 2017 at 10:44 PM, Ryan Hamilton <rch@google.com> wrote:

> On Fri, Sep 29, 2017 at 4:33 PM, Patrick McManus <mcmanus@ducksong.com>
> wrote:
>
>>
>> But pre-Alt-Svc we would never automatically retry an even idempotent
>>> request on receipt ​of a 5xx. But I think you're suggesting that it in an
>>> Alt-Svc world, that might be something a browser would do?
>>>
>>
>> you have defeated my plan of not answering the question..
>>
>
> ​\o/
> ​
>
>> I don't really know that the alt-svc vs default-svc makes a difference to
>> me.. the real question is one of replay risk and that answer seems equally
>> opaque in each circumstance because you have no idea what the source of the
>> unexpected internal error might be.
>>
>
> ​Fair point. I confess, my understanding of Alt-Svc is quite colored by my
> experience with QUIC. Since many (~5%, irrc) users do not have UDP
> connectivity, when QUIC is a specified Alt-Svc, connection errors are
> expected and need to be transparent to the user. Since QUIC has 0-RTT, this
> also means that we end up needing to transparently "retry" requests which
> were sent on failed 0-RTT connections.
>

I'm hoping that the 5% no-udp, is much much larger than the failed 0-RTT
case (as those folks would have needed to do QUIC in the past)? And only
the latter have a bad retry problem.


​Ditto. That reminds me. So when Chrome decides to stop using an
alternative, it marks that alternative as broken for 5 minutes (subject to
exponential backoff). Does Firefox do something similar? (This is, of
course, an artifact of QUIC in which if a user has no UDP connectivity but
the server keeps advertising a QUIC alternative, we wouldn't want to keep
attempting QUIC connections in the background)

yeah.. firefox adds a negative-entry to the alt-svc cache and while that
entry is fresh it won't try and validate it again. It is initially set at
something very small (a few seconds) just to prevent a spin loop on servers
that quickly fail via RST but I'm prepared to make it bigger. we have a
small difference here that firefox will never use an alternate it hasn't
validated at some point - even if there are no connections open to the
origin at request time. (it would connect to the default origin and try to
asynchronously validate)