Re: Clarification on Alternative Service Connection Failures

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. So in my mind marking an alternative
server as not working is synonymous with retry, but that doesn't really
need to be the case. And your point about all the alternatives being
semantically equivalent makes me that that perhaps a 5xx should not trigger
a retry, but may well cause us to stop using the alternative.

fwiw 5xx does not actually impact firefox's alt-svc cache today.. but it
> seems like the right change to make.
>

​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)

Cheers,

Ryan
​