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

Erik Nygren <erik@nygren.org> Tue, 19 August 2014 22:13 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6991A017E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 19 Aug 2014 15:13:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.947
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nPI6p5ThQ0P for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 19 Aug 2014 15:13:44 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DBF1A016A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 19 Aug 2014 15:13:43 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XJrbb-00030F-2V for ietf-http-wg-dist@listhub.w3.org; Tue, 19 Aug 2014 22:10:15 +0000
Resent-Date: Tue, 19 Aug 2014 22:10:15 +0000
Resent-Message-Id: <E1XJrbb-00030F-2V@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <nygren@gmail.com>) id 1XJrb6-0001hW-BP for ietf-http-wg@listhub.w3.org; Tue, 19 Aug 2014 22:09:44 +0000
Received: from mail-vc0-f174.google.com ([209.85.220.174]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <nygren@gmail.com>) id 1XJrb4-0007rP-UX for ietf-http-wg@w3.org; Tue, 19 Aug 2014 22:09:44 +0000
Received: by mail-vc0-f174.google.com with SMTP id la4so8096392vcb.5 for <ietf-http-wg@w3.org>; Tue, 19 Aug 2014 15:09:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.220.88.7 with SMTP id y7mr2117377vcl.69.1408486156804; Tue, 19 Aug 2014 15:09:16 -0700 (PDT)
Sender: nygren@gmail.com
Received: by 10.221.11.16 with HTTP; Tue, 19 Aug 2014 15:09:16 -0700 (PDT)
In-Reply-To: <CABkgnnVQqYhDyLBvfaqD7oWGjY7WuvuSqWERwjoH=bQeh8k79g@mail.gmail.com>
References: <CABkgnnUDKqPttrp0T-fyrenkgEm=YzwbdmoaJ=Jti3ER1SEAMw@mail.gmail.com> <CAKC-DJgBKoq_M3xMu5115j+OTudSNMNGwOakXjKRP=odVMPn_A@mail.gmail.com> <CABkgnnXRw7Rc7MJddW4UqSo2=hQ2E2EysLyzcaVM6_xf7h0R9g@mail.gmail.com> <CAKC-DJiG+pNAitg6z0wuL16NDnBp0tNwQhpvEWXs77x_c3f=2Q@mail.gmail.com> <53F34F02.2090807@gmx.de> <CABkgnnVQqYhDyLBvfaqD7oWGjY7WuvuSqWERwjoH=bQeh8k79g@mail.gmail.com>
Date: Tue, 19 Aug 2014 18:09:16 -0400
X-Google-Sender-Auth: _1t_wUmMY37cg3tM7EnOXtkd4Dw
Message-ID: <CAKC-DJiD6_3SZd-k7FXCcwuA4AK7kXVupqXuy2+XuQKWtqP2xA@mail.gmail.com>
From: Erik Nygren <erik@nygren.org>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="047d7b3a7eec0c292c050102bd7b"
Received-SPF: pass client-ip=209.85.220.174; envelope-from=nygren@gmail.com; helo=mail-vc0-f174.google.com
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: lisa.w3.org 1XJrb4-0007rP-UX 56f74853226ae9feeafc62668da26ad3
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Alt-Svc alternative cache invalidation (ext#16)
Archived-At: <http://www.w3.org/mid/CAKC-DJiD6_3SZd-k7FXCcwuA4AK7kXVupqXuy2+XuQKWtqP2xA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/26661
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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