Re: #444: Flushing Alt-Svc Cache

I'm concerned about this requirement. With QUIC, we rely on
Alternate-Protocol (the intellectual equivalent of Alt-Svc) to discover
QUIC. When the alternate service is unknown, the first request goes over
the traditional transport. Once the response is received, a new transport
can be spun up, but since this might not succeed, we generally end up
sending the second request over the existing established connection, while
the alternate connection is established. Eventually requests finally start
flowing over the alternate connection. But this is quite unfortunate. The
performance benefits of the alternate service can be severely impacted.

If we think that the alternate services advertised by some servers will be
network specific, then I would be inclined to suggest that we modify
Alt-Svc to explain the policy to the client. This would allow other servers
which do not serve network-specific alternate services to permit client to
continue using alternate services across network changes.

With the increasing prevalence of mobile devices, the issue of changing
networks will become increasingly common. If every time a mobile device
changes IP it has to stop using alternate services, this would be a real
performance hit.



On Thu, Apr 24, 2014 at 9:29 PM, Mark Nottingham <mnot@mnot.net> wrote:

> Agreed; we could mention that with a MAY...
>
>
> On 25 Apr 2014, at 2:26 pm, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
> > I think that's workable.  The cost is that certain classes of device
> > will perform discovery a lot.  Those devices could maintain
> > per-network caches for alt-svc, I suppose.
> >
> > For example, my phone goes from home, to a mobile network, to the
> > office quite often, it would be nice if alt-svc for my home were able
> > to be reused when I return in the evening, subject to the TTL, of
> > course.
> >
> > On 24 April 2014 17:34, Mark Nottingham <mnot@mnot.net> wrote:
> >> <https://github.com/http2/http2-spec/issues/444>
> >>
> >>> For the load balancing use case, it's necessary for clients to always
> flush altsvc cache upon a network change, but right now they're only
> required to examine the cache for suspicious entries. We should discuss
> whether this should be upgraded to always flush.
> >>
> >> I think the logical proposal would be to change <
> http://http2.github.io/http2-spec/alt-svc.html#caching>
> >>
> >> """
> >> To mitigate risks associated with caching compromised values (see
> Section 7.2 for details), user agents should examine cached alternative
> services when they detect a change in network configuration, and remove any
> that could be compromised (for example, those whose association with the
> trust root is questionable). UAs that do not have a means of detecting
> network changes should place an upper bound on their lifetime.
> >> """
> >>
> >> to read:
> >>
> >> """
> >> To mitigate risks associated with caching compromised values (see
> Section 7.2 for details), user agents should remove all cached alternative
> services when they detect a change in network configuration. UAs that do
> not have a means of detecting network changes should place an upper bound
> on their lifetime.
> >> """
> >>
> >> Thoughts?
> >>
> >>
> >> Cheers,
> >>
> >> --
> >> Mark Nottingham   http://www.mnot.net/
> >>
> >>
> >>
> >>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>