Subject: Re: New Version Notification for draft-cdn-control-header-00.txt

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Jan 2021 13:41:35 +1100

[ document author hat on ]

Hi everyone,

We're requested time for discussion of this draft at the upcoming interim. We'd like the WG to consider adoption.

Cheers,

> On 24 Nov 2020, at 1:01 pm, Mark Nottingham <[email-masked]> wrote:
> 
> FYI / for discussion.
> 
>> Begin forwarded message:
>> 
>> From: [email-masked]
>> Subject: New Version Notification for draft-cdn-control-header-00.txt
>> Date: 24 November 2020 at 1:01:02 pm AEDT
>> To: "Mark Nottingham" <[email-masked]>, "Stephen Ludin" <[email-masked]>, "Yuchen Wu" <[email-masked]>
>> 
>> 
>> A new version of I-D, draft-cdn-control-header-00.txt
>> has been successfully submitted by Mark Nottingham and posted to the
>> IETF repository.
>> 
>> Name:		draft-cdn-control-header
>> Revision:	00
>> Title:		The CDN-Cache-Control HTTP Response Header Field
>> Document date:	2020-11-23
>> Group:		Individual Submission
>> Pages:		7
>> URL:            https://www.ietf.org/archive/id/draft-cdn-control-header-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-cdn-control-header/
>> Html:           https://www.ietf.org/archive/id/draft-cdn-control-header-00.html
>> Htmlized:       https://tools.ietf.org/html/draft-cdn-control-header-00
>> 
>> 
>> Abstract:
>>   This specification defines an HTTP header field that conveys HTTP
>>   cache directives to CDN caches.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
>> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Piotr Sikora <[email-masked]>
Date: Mon, 25 Jan 2021 15:49:00 -0800

Thanks for working on this! Two comments:

1) Since this header is already using structured headers, could we use a
"for=" parameter instead of the suggested vendor-specific header names? i.e.

  VENDOR1-CDN-Cache-Control: max-age=61
  VENDOR2-CDN-Cache-Control: max-age=62

would become:

  CDN-Cache-Control: for=vendor1; max-age=61, for=vendor2; max-age=62

This would better match the style of Cache-Status and Proxy-Status headers,
IMHO.

2) From the protocol point of view, CDNs are no different than any other
intermediaries, so we should be providing a generic solution that works in
modern cloud deployments with many layers of intermediaries, and not
another special CDN-header. If we define common roles for all the peers,
then we could have something like:

  Cache-Control2: for=reverse_proxy; max-age=5, for=cdn; max-age=60,
for=user_agent; no-store

Thoughts?

Best regards,
Piotr Sikora

On Sun, Jan 17, 2021 at 6:45 PM Mark Nottingham <[email-masked]> wrote:

> >> To: "Mark Nottingham" <[email-masked]>, "Stephen Ludin" <
> [email-masked]>, "Yuchen Wu" <[email-masked]>
> >>
> >>
> >> URL:
> https://www.ietf.org/archive/id/draft-cdn-control-header-00.txt
> >> Status:
> https://datatracker.ietf.org/doc/draft-cdn-control-header/
> >> Html:
> https://www.ietf.org/archive/id/draft-cdn-control-header-00.html

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 Jan 2021 12:35:56 +1100

Hi Piotr!

> On 26 Jan 2021, at 10:49 am, Piotr Sikora <[email-masked]> wrote:
> 
> 1) Since this header is already using structured headers, could we use a "for=" parameter instead of the suggested vendor-specific header names? i.e.
> 
> This would better match the style of Cache-Status and Proxy-Status headers, IMHO.

That makes it harder to reuse existing Cache-Control machinery for the header; not a deal killer, but that's a major upside for adoption. Also, I'd argue that it's harder for someone to understand when looking at the headers; in the current approach, there's a clear differentiation between the intended targets for the header. Remember, these are instructions, not just debug info; having a single header with sometimes conflicting instructions for multiple components is... tricky.

> 2) From the protocol point of view, CDNs are no different than any other intermediaries, so we should be providing a generic solution that works in modern cloud deployments with many layers of intermediaries, and not another special CDN-header. If we define common roles for all the peers, then we could have something like:
> 
>   Cache-Control2: for=reverse_proxy; max-age=5, for=cdn; max-age=60, for=user_agent; no-store
> 
> Thoughts?

I have serious doubts about whether that's going to get implemented correctly, and I don't think the impetuous is great enough to make a *replacement* cc header viable (see: Set-Cookie2).

CDNs are different in that they're a non-local gateway ("reverse proxy") cache; having a single header that targets them (as opposed to local gateways and "forward' proxies, along with server-side and UA caches) promotes interoperability. The point here is to allow an origin server to set one header and know that it'll still operate when they switch CDNs. More to the point, it's so that content frameworks like Drupal and Wordpress can set CDN-specific caching information "out of the box".

Local gateway caches might also benefit from something like this, but it needs to be separate from the non-local gateway instructions; that seems to be now fully emerged common architecture. "CDN" was chosen because a) it's short and b) because it aligns with how everyone thinks about "non-local gateway cache."

So if there's demand for it,* I could see:

1) Cache-Control --> all caches unless overridden
2) CDN-Cache-Control --> non-local gateway caches
3) ???-Cache-Control --> local gateway caches
4) xxx-Cache-Control --> implementation/deployment specific override

For #3, maybe Gateway-Cache-Control?

Cheers,

* I think the question here is whether interoperability would be improved by having a single control mechanism for these local gateway caches -- i.e., would someone swap out Squid for Nginx or Varnish for ATS and expect it to still work?

---

From: Piotr Sikora <[email-masked]>
Date: Tue, 26 Jan 2021 01:00:33 -0800

Hi Mark,

> That makes it harder to reuse existing Cache-Control machinery for the header; not a deal killer, but that's a major upside for adoption.

I was thinking about this for a while, but I don't see how this plays
any role in terms of adoption. All the web frameworks need to
explicitly add support for this new header, and CDN providers need to
generalize existing functions parsing the Cache-Control header anyway,
so I don't think it really matters.

> Also, I'd argue that it's harder for someone to understand when looking at the headers; in the current approach, there's a clear differentiation between the intended targets for the header.

If you're concerned about human-readability, then you can split the
list members across multiple headers:

    CDN-Cache-Control: for=vendor1; max-age=61
    CDN-Cache-Control: for=vendor2; max-age=62

it's all the same in the end.

Having said that, I'm not sure I completely understand the need for
vendor-specific headers. Are users expected to set different
expiration times for different vendors? What's the reasoning for this
feature?

> Remember, these are instructions, not just debug info; having a single header with sometimes conflicting instructions for multiple components is... tricky.

Exactly! Those are instructions for HTTP intermediaries, and I'm sure
that they can figure out how to split header values on the delimiters.

> I have serious doubts about whether that's going to get implemented correctly, and I don't think the impetuous is great enough to make a *replacement* cc header viable (see: Set-Cookie2).

Fair enough. Maybe let's drop the user-agent and keep using existing
Cache-Control for that purpose. How about Proxy-Cache-Control only for
intermediaries?

> * I think the question here is whether interoperability would be improved by having a single control mechanism for these local gateway caches -- i.e., would someone swap out Squid for Nginx or Varn…

I strongly disagree with the premise that this draft does anything to
improve interoperability, it does the opposite.

Nowadays, virtually all downstream caches support Cache-Control:
s-maxage (I understand that it conflicts with no-store, etc. so we
need an improved version, hence this proposal), so when an application
developer deploys their service, it doesn't matter whether it's
fronted by NGINX or Varnish or HAProxy, or maybe even FooCDN, they all
respect the same header. The intent to make the content cacheable is
there.

The current proposal replaces that intent with deployment details,
something that the developers often have no control over. E.g. imagine
an application developer using FooPaaS, where they deployed their Go
application. If the FooPaaS provider makes any changes to the
networking layer (e.g. switching from local NGINX caching gateway to a
3rd-party CDN or vice-versa), then content suddenly becomes
uncacheable, even though the intent is still there. Similarly, in
enterprise environments, where the networking layer and applications
are owned by different teams, the cacheability shouldn't be affected
by changes to the underlying infrastructure.

I'm fine with replacing Cache-Control: s-maxage with a generic
Proxy-Cache-Control (or whatever we want to call it), but I don't see
how adding dedicated CDN-Cache-Control (or worse,
VENDOR-CDN-Cache-Control) benefits users.

Best regards,
Piotr Sikora

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 26 Jan 2021 10:50:43 +0000

Hi Piotr,

> On 26 Jan 2021, at 09:00, Piotr Sikora <[email-masked]> wrote:
> 

I think CDNs are a special case. CDNs are typically considered to be “delegated origins” (i.e. from an authority/caching perspective they are an extension of the origin rather than a “consumer” side cache).

This leads to lots of use cases where one would like the caching behaviour of the CDN (acting as an extension to the origin) to be different to the caching behaviour of any downstream (from the origin/CDN) caches. 

The current Cache-Control header semantics are not rich enough to express the uses cases that already exist and so they are typically implemented via CDN-specific/proprietary configuration/policies. This header would remove that need and provide a single mechanism to express the required CDN caching “policy” regardless of CDN which would improve interoperability vs today’s mess of CDN-specific configuration.

My guess is that proxies such as nginx/haproxy/etc would add support for CDN-Cache-Control (as they are often deployed within CDNs or as part of a provider’s origin infrastructure) and would provide a configuration switch to honour it or not (probably not honouring it by default). [Note: I am not involved with any proxy implementations so I cannot speak on their behalf regarding their actual plans for implementation]

In your FooPaaS provider case, if FooPaaS provider is using a CDN (which they consider to be an extension of their origin) and they are sending CDN-Cache-Control and they decide to change to using, say, haproxy instead (and they still consider haproxy to be an extension of their origin) then they would configure haproxy to honour the CDN-Cache-Control header so the caching behaviour would be the same as before.

Regards
Ben

---

From: Piotr Sikora <[email-masked]>
Date: Tue, 26 Jan 2021 11:03:26 -0800

Hi Ben,

> This leads to lots of use cases where one would like the caching behaviour of the CDN (acting as an extension to the origin) to be different to the caching behaviour of any downstream (from the ori…

The same is true for reverse proxies, local gateways and caching cloud
load-balancers. Again, the intent to make the content cacheable at the
"delegated origins" is the same, regardless of the specific
deployment.

> The current Cache-Control header semantics are not rich enough to express the uses cases that already exist and so they are typically implemented via CDN-specific/proprietary configuration/policies…

CDN-Cache-Control (as written today) is limited to "max-age",
"must-revalidate", "no-store", "no-cache", and "private", so it
primarily fixes incompatibilities between "s-maxage" and "no-store" /
"no-cache". I don't believe it allows for expressing richer policy
than Cache-Control.

> My guess is that proxies such as nginx/haproxy/etc would add support for CDN-Cache-Control (as they are often deployed within CDNs or as part of a provider’s origin infrastructure) and would provid…

Would they, though? I know it's not exactly the same, but none of them
supports CDN-Loop out of the box, AFAIK.

> In your FooPaaS provider case, if FooPaaS provider is using a CDN (which they consider to be an extension of their origin) and they are sending CDN-Cache-Control and they decide to change to using,…

But this is what I'm talking about - if local gateways or even reverse
proxies are expected to honour the CDN-Cache-Control header, then it's
not really a CDN-specific header, and we should have something more
generic than that.

Also, I'm not a HAProxy user, so I cannot speak to that specific
implementation, but I know it's impossible to configure other proxies
to consume cache control instructions from a "random" header, so we
would need all open source proxies to explicitly support
CDN-Cache-Control header.

Best regards,
Piotr Sikora

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Jan 2021 19:44:18 +1100

Hi Piotr,

> On 27 Jan 2021, at 6:03 am, Piotr Sikora <[email-masked]> wrote:
> 
> Hi Ben,
> 

Absolutely. The question is whether sites need to be able to distinguish *between* those different types of deployments. There's lots of evidence that at least for CDNs, they do; pretty much every CDN has its own "control me" header, and the variety is a headache for customers who want to switch between CDNs easily, or go multi-CDN.

> "no-cache". I don't believe it allows for expressing richer policy

CDN-Cache-Control, just like Cache-Control, is extensible -- see <https://httpwg.org/http-core/draft-ietf-httpbis-cache-latest.html#cache.control.extensions>.

> not really a CDN-specific header, and we should have something more

They're not - they're expected to ignore it, unless they're specifically configured to pay attention (because they're part of what the deployment considers to be a CDN).

> CDN-Cache-Control header.

Only if they wanted to be able to be controlled in this fashion.

Cheers,