Re: Informal meeting on blind caching

For the "Blind caching in a CDN edge cache that is acting as a delegated
origin server" scenario I think we'd be better off separating out the
high-level mechanism (ie, getting oob-encoding) right from the actual
business model and implementation details for how the caches get
populated.  The former is something we can tractably do here (have a way to
delegate content bodies out to third-parties) but the latter is something
that could easily fill up its own working group to get all of the details
worked through.

I also think that we shouldn't refer to "CDN" in this scenario as much as
referring to delegating between a server acting as an authoritative origin
and a collection of servers at a lower trust level.  (In some deployment
scenarios, the former might be a CDN and the latter might be either a
different trust tier of CDN nodes or federated-but-less-trusted partners.)

The specific blind caching with a configured proxy cache is a well-defined
use-case, but the others have many different ways to implement that trying
to standardize something now before there has been more experience with
implementations and business models seems like asking for trouble (and is
something that some of us may be less interested in than in defining common
underlying mechanisms and affordances to allow developing technologies in
this area).

        Erik




On Thu, Jul 28, 2016 at 5:07 AM, Richard Bradbury <
richard.bradbury@rd.bbc.co.uk> wrote:

> 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-scdhttps://tools.ietf.org/html/draft-thomson-http-bchttps://tools.ietf.org/html/draft-reschke-http-oob-encodinghttps://tools.ietf.org/html/draft-thomson-http-micehttps://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
>
>