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

Erik Nygren <> Tue, 19 August 2014 22:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9B6991A017E for <>; Tue, 19 Aug 2014 15:13:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.947
X-Spam-Status: No, score=-6.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3nPI6p5ThQ0P for <>; Tue, 19 Aug 2014 15:13:44 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C8DBF1A016A for <>; Tue, 19 Aug 2014 15:13:43 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1XJrbb-00030F-2V for; Tue, 19 Aug 2014 22:10:15 +0000
Resent-Date: Tue, 19 Aug 2014 22:10:15 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1XJrb6-0001hW-BP for; Tue, 19 Aug 2014 22:09:44 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1XJrb4-0007rP-UX for; Tue, 19 Aug 2014 22:09:44 +0000
Received: by with SMTP id la4so8096392vcb.5 for <>; Tue, 19 Aug 2014 15:09:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tlSl3F8heB/W6nnWOTFhFTO3mqbrhChCHDuBcs3jxug=; b=O4uw869IX0fZ/V013ZGJjh05IGSx+6D8B4AQZr/EZ8fz9m/nivdWRN9/zvFUTyDoX4 BAAGyl2nMUBw/Iu58e+zy7CXDpjBjkSaoHB+8TLg+qsMI+pIUtWkCQw6cBXrTHnx8lAu C83b77vuV0DFLWsiaerRKajlYeM5bWsDcgmF+pAS3MOj+aAnI+IwMdPtVj9nyaLNISxf XOpkedPNpfF0SJ3eiUygg5QkCU4POvKBSnjO5jA4uJb0JllxXWFjCESOU3d3G5L+yG5s ncUAdClyW0lUG3zdh9dmRYyPjCvjTleOagtU5Zzzxcihl1IIrQUfDAjzXYdJ053tn5Xs etnQ==
MIME-Version: 1.0
X-Received: by with SMTP id y7mr2117377vcl.69.1408486156804; Tue, 19 Aug 2014 15:09:16 -0700 (PDT)
Received: by with HTTP; Tue, 19 Aug 2014 15:09:16 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Tue, 19 Aug 2014 18:09:16 -0400
X-Google-Sender-Auth: _1t_wUmMY37cg3tM7EnOXtkd4Dw
Message-ID: <>
From: Erik Nygren <>
To: Martin Thomson <>
Cc: Julian Reschke <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="047d7b3a7eec0c292c050102bd7b"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.764, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1XJrb4-0007rP-UX 56f74853226ae9feeafc62668da26ad3
Subject: Re: Alt-Svc alternative cache invalidation (ext#16)
Archived-At: <>
X-Mailing-List: <> archive/latest/26661
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Tue, Aug 19, 2014 at 1:14 PM, Martin Thomson <>
> 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.