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

On Tue, Aug 19, 2014 at 1:14 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:
> I'm not certain about this.  More from an architectural standpoint
> than anything else.  Conceptually, alternative services is build on
> the idea that there are multiple potential sources of information.
> We've defined two, but there are also potentially other avenues (DNS,
> for instance).

I'd actually been thinking that the record set model might actually more
consistent with multiple avenues of data.
For example, DNS records come in an RRset as a unit which could be added
fairly cleanly to the set received
from the origin.  In that world, (origin, data_source) would be the key,
such that each data source would
update its set.  This likely does bring the priority/ordering discussion
back into play regardless of how it is
approached (ie, which get priority beyond client choice).

I don't think that this is annoying to implement at all.  Simply find
> the entry that matches, create one if none exists, and update its time
> to match.  It also keeps independent header field processing simpler.
> You don't have to worry that another Alt-Svc header field might appear
> in the block before you act.
>

I'd think this would be painful for clients.  If a server emits a series
of ALTSVC frames with multiple choices, does the client buffer up
or wait some before it starts making connections?  With a set of options
it becomes much more clear when the client can start taking action
without needing to worry about thrashing.

Additionally, how does a server remove/replace an ALTSVC record it set
previously without waiting for a TTL expiration?  There isn't enough data
in Alt-Svc-Used for servers to know which values clients may have in their
cache so without set replacement it's unclear how a server would remove
or replace an entry.

       Erik