Subject: Re: Alt-Svc alternative cache invalidation (ext#16)

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Mar 2015 16:42:41 +1100

I’m not hearing any pushback on this, so I’ve marked #16 as editor-ready, with this note:

“””
Discussed on-list. Cache invalidation is to be scoped to a specific discovery mechanism; e.g., the alternatives you discover via the response header will be invalidated when you see a new response header, while those that were discovered via the frame will be invalidated only when a new frame is received.

This means each mechanism needs to define its own exact invalidation semantics, and probably needs to be capable of carrying multiple alternatives.
“””

Cheers,

> On 20 Feb 2015, at 3:24 pm, Mark Nottingham <[email-masked]> wrote:
> 
> Reading the thread again -- AIUI the intent is for invalidation to be scoped to a single discovery mechanism (the frame, a header, whatever).
> 
> If that's the case, the use cases below will work, because they both use different mechanisms.
> 
> So, I'm OK with this. We will need to be *very* careful to scope the invalidations, however.
> 
> Cheers,
> 
> 
>> On 25 Aug 2014, at 10:30 am, Mark Nottingham <[email-masked]> wrote:
>> 
>> So, to be clear, you're suggesting that both the Alt-Svc header field and the ALTSVC frame type have the side effect of cache invalidation?
>> 
>> Personally -- I'm not sure that's a good idea. 
>> 
>> For example, imagine a http:// service that a) wants to use Opp-Sec and b) the alternate wants to do some load balancing, etc.
>> 
>> The http:// service sets an Alt-Svc header field with a very long lifetime, so that Opp-Sec is as sticky as possible.
>> 
>> The alternate, OTOH, uses a fairly short lifetime for load balancing.
>> 
>> With cache invalidation, the alternate doing load balancing is going to clear the cache of the Opp-Sec hint, thereby forcing the client to go back to the http:// origin once the (short lifetime) load balancing policy expires.
>> 
>> Without invalidation, it'd fall back to the original Opp-Sec alternative.
>> 
>> Likewise for the SNI segmentation use case. 
>> 
>> Regards,
>> 
>> 
>> On 24 Aug 2014, at 11:30 am, Erik Nygren <[email-masked]> wrote:
>> 
>>> On Fri, Aug 22, 2014 at 7:50 PM, Martin Thomson <[email-masked]> wrote:
>>> On 22 August 2014 14:53, Erik Nygren <[email-masked]> wrote:
>>>> but does not define anything similar for the ALTSVC frame.  Aligning the
>>>> frame and the
>>>> header would allow this to apply to both.
>>> 
>>> I think that we would want to move the Origin field up to the header
>>> with Max-Age.  Logically, you store alternatives for different origins
>>> separately, so requiring different frames makes sense there.  It also
>>> removes any potential for duplication.
>>> 
>>> Also 8 bits of length is not sufficient for an HTTP origin if the name
>>> is maximum size.  I'd assume that the same applies to authority.
>>> 
>>> 
>>> Agreed on both counts.  What about this, then:
>>> 
>>> 0                   1                   2                   3
>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> |                          Max-Age (32)                         |
>>> +---------------+---------------+-------------------------------+
>>> | Origin-Len (16)               |         Origin? (*)         ...
>>> +---------------------------------------------------------------+
>>> |Num-Alt-Auth(8)|
>>> +---------------+---------------+-------------------------------+
>>> | Proto-Len(8)  |        Protocol-ID (*)                        |
>>> +---------------+-----------------------------------------------+
>>> | Alt-Auth-Len (16)             |        Alt-Auth (*)         ...
>>> +---------------+-----------------------------------------------+
>>> |                        Ext-Param? (*)                       ...
>>> +---------------------------------------------------------------+
>>> 
>>> where Origin-Len=0 would be used in the case where this was part of a Stream != 0
>>> and Num-Alt-Auth>=1.  The {Proto-Len, Protocol-ID, Alt-Auth-Len, Alt-Auth} would be
>>> repeated Num-Alt-Auth times.  Alt-Auth is a string such as "server.example.com:443"
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 
>> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Mar 2015 08:20:54 +0100

> This means each mechanism needs to define its own exact invalidation semantics, and probably needs to be capable of carrying multiple alternatives.

We have two mechanisms, and both can carry multiple alternatives, right?

So what's left to do is to state the invalidation semantics?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Mar 2015 18:31:07 +1100

Think so…

> On 17 Mar 2015, at 6:20 pm, Julian Reschke <[email-masked]> wrote:
>