Re: Informal meeting on blind caching

Richard Bradbury <richard.bradbury@rd.bbc.co.uk> Thu, 28 July 2016 09:12 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFD212D9F0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 28 Jul 2016 02:12:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.207
X-Spam-Level:
X-Spam-Status: No, score=-8.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 jdaSMemxrLMC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 28 Jul 2016 02:12:37 -0700 (PDT)
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 C947F12D9DB for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 28 Jul 2016 02:12:36 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bShIQ-0003Xk-BQ for ietf-http-wg-dist@listhub.w3.org; Thu, 28 Jul 2016 09:08:02 +0000
Resent-Date: Thu, 28 Jul 2016 09:08:02 +0000
Resent-Message-Id: <E1bShIQ-0003Xk-BQ@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <richard.bradbury@rd.bbc.co.uk>) id 1bShIJ-0003Wy-Bk for ietf-http-wg@listhub.w3.org; Thu, 28 Jul 2016 09:07:55 +0000
Received: from gateh.kw.bbc.co.uk ([132.185.132.17]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <richard.bradbury@rd.bbc.co.uk>) id 1bShIF-0007pw-8w for ietf-http-wg@w3.org; Thu, 28 Jul 2016 09:07:54 +0000
Received: from mailhub0.rd.bbc.co.uk ([172.29.120.128]) by gateh.kw.bbc.co.uk (8.14.5+Sun/8.13.6) with ESMTP id u6S97R87004519; Thu, 28 Jul 2016 10:07:27 +0100 (BST)
Received: from rd000299.rd.bbc.co.uk ([172.29.136.177]:50261) by mailhub0.rd.bbc.co.uk with esmtp (Exim 4.84_2) (envelope-from <richard.bradbury@rd.bbc.co.uk>) id 1bShHr-00009G-1W; Thu, 28 Jul 2016 10:07:27 +0100
To: ietf-http-wg@w3.org
References: <CABkgnnXYSxyS2hg5aUxT8R2c_M44OoR=g8-7U1iGjNeqXT-zJQ@mail.gmail.com> <57988DF6.9010501@rd.bbc.co.uk>
From: Richard Bradbury <richard.bradbury@rd.bbc.co.uk>
Message-ID: <03a5d205-4713-bd10-35ab-8efefbdce525@rd.bbc.co.uk>
Date: Thu, 28 Jul 2016 10:07:26 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <57988DF6.9010501@rd.bbc.co.uk>
Content-Type: multipart/mixed; boundary="------------AEDAF1F161DCB64793D78232"
Received-SPF: none client-ip=132.185.132.17; envelope-from=richard.bradbury@rd.bbc.co.uk; helo=gateh.kw.bbc.co.uk
X-W3C-Hub-Spam-Status: No, score=-5.8
X-W3C-Hub-Spam-Report: AWL=-0.571, BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1bShIF-0007pw-8w 5541af2cc0724b11856a92f1a1fb6a5f
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Informal meeting on blind caching
Archived-At: <http://www.w3.org/mid/03a5d205-4713-bd10-35ab-8efefbdce525@rd.bbc.co.uk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32064
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 27/07/2016 11:33, Richard Bradbury wrote:
> On 17/07/2016 18:03, Martin Thomson wrote:
>> We are having a meeting on blind caching on Tuesday 08:30 in
>> Charlottenburg I.  Folks who are interested are invited to join us.
>>
>> Rough agenda is to discuss what this is, the status of specs and
>> implementations.  Then we are looking to get some input on the work
>> that has been done and what might need to happen next.
>>
>> For those not familiar with this, the following drafts are recommended reading:
>> https://tools.ietf.org/html/draft-thomson-http-scd
>> https://tools.ietf.org/html/draft-thomson-http-bc
>> https://tools.ietf.org/html/draft-reschke-http-oob-encoding
>> https://tools.ietf.org/html/draft-thomson-http-mice
>> https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding
>
> Hi. Thanks for an interesting session last week.
>
> Based on my reading of the Internet Drafts I think these are the two 
> main Use Cases under consideration here:
>
>  1. *Blind caching in a CDN edge cache that is acting as a delegated
>     origin server.*
>       * Described in draft-thomson-http-scd.
>       * Making use of the techniques described in
>         draft-reschke-http-oob-encoding, draft-thomson-http-mice and
>         draft-ietf-httpbis-encryption-encoding.
>  2. *Blind caching in an explicitly configured proxy server.*
>       * Described in draft-thomson-http-bc.
>       * Making use of the techniques described in
>         draft-reschke-http-oob-encoding, draft-thomson-http-mice and
>         draft-ietf-httpbis-encryption-encoding.
>
> The discussion in Berlin last Tuesday morning flowed fairly freely 
> between the two Use Cases, so I just wanted to check my understanding.
>

OK. Now I feed I understand Use Case 2 better, I attach a couple of 
sequences describing my (incomplete) understanding of Use Case 1 above. 
The main question in my mind here is whether the resources are 
explicitly pushed into the CDN cache (what I have called "Mode P") or 
whether they are retrieved on demand from the origin server by the CDN 
only on cache miss ("Mode G").

Perhaps you are looking to support both modes of operation? The Internet 
Draft could usefully clarify this.

*Mode G*
    In the cache pull-through mode, there appears to be a requirement
    for the CDN to know the resource mapping in order to support the URL
    obfuscation feature. But that appears to negate one of the key
    benefits of the feature – keeping the mapping secret from the CDN
    provider. I'm clearly missing something here. Or maybe URL
    obfuscation just doesn't fly in this mode, which would be a shame
    since this is our primary mode of operation for some media types.
*Mode P*
    With the push mode, the resource mapping can remain secret to the
    origin server, which is great. But the mechanism for pushing content
    onto the CDN remains a bit of a mystery, so I have made an educated
    guess on my diagram. Perhaps you intend this mechanism to remain
    private? In which case, perhaps the Internet Draft could include a
    note to this effect?

Clarifications and comments gratefully received.


Regards,

-- 
Richard Bradbury | Lead Research Engineer
BBC Research & Development
Centre House, 56 Wood Lane, London  W12 7SB.
T: 0303 040 9672  F: 020 8811 8815