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

Mark Nottingham <mnot@mnot.net> Fri, 20 February 2015 04:28 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ietf.org@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 289BF1A1C03 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 19 Feb 2015 20:28:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 C6YLjrFwEboF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 19 Feb 2015 20:28:14 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648861A1B07 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 19 Feb 2015 20:28:14 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YOf9U-0003PE-IR for ietf-http-wg-dist@listhub.w3.org; Fri, 20 Feb 2015 04:25:20 +0000
Resent-Date: Fri, 20 Feb 2015 04:25:20 +0000
Resent-Message-Id: <E1YOf9U-0003PE-IR@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1YOf9K-0003ON-5m for ietf-http-wg@listhub.w3.org; Fri, 20 Feb 2015 04:25:10 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1YOf9J-0004Nv-2a for ietf-http-wg@w3.org; Fri, 20 Feb 2015 04:25:10 +0000
Received: from [192.168.1.29] (unknown [59.167.195.195]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2121A22E200; Thu, 19 Feb 2015 23:24:41 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <E977E2BD-AFCF-4C32-B99C-B747CD4E6412@mnot.net>
Date: Fri, 20 Feb 2015 15:24:37 +1100
Cc: Martin Thomson <martin.thomson@gmail.com>, "Julian F. Reschke" <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <38E70447-193C-4F7A-8722-9019B6B20BC8@mnot.net>
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> <CAKC-DJiD6_3SZd-k7FXCcwuA4AK7kXVupqXuy2+XuQKWtqP2xA@mail.gmail.com> <CABkgnnW+QM8brr2FkBnOHAhFi9kjdrVoZ+yThckbURq9V5jmnQ@mail.gmail.com> <CAKC-DJhHz1mk0vdVtwmwyccv=LqUb+GrYVukkUYJY4mWdHE-mg@mail.gmail.com> <CABkgnnWENAO=4TnwK9Rtxudh+SQTzhrwRZdp=Et4DhPjU7m5_w@mail.gmail.com> <CAKC-DJjG1xv+FXM9=KVR=WBM9DcMweYEzhokKdkRZN2VyDffmg@mail.gmail.com> <E977E2BD-AFCF-4C32-B99C-B747CD4E6412@mnot.net>
To: Erik Nygren <erik@nygren.org>
X-Mailer: Apple Mail (2.2070.6)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-2.4
X-W3C-Hub-Spam-Report: AWL=-1.675, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001
X-W3C-Scan-Sig: lisa.w3.org 1YOf9J-0004Nv-2a 989f046cc01a498ec9742dc3a0067c6e
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Alt-Svc alternative cache invalidation (ext#16)
Archived-At: <http://www.w3.org/mid/38E70447-193C-4F7A-8722-9019B6B20BC8@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/28858
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>

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 <mnot@mnot.net> 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 <erik@nygren.org> wrote:
> 
>> On Fri, Aug 22, 2014 at 7:50 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>> On 22 August 2014 14:53, Erik Nygren <erik@nygren.org> 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/