TTL vs. Max-Age

[chrysn]

Interpreting times relative to a cached request's request time is tricky, and AFAIK there is no good precedent in CoRE. (SenML speaks of 'roughly "now"', without talking about Max-Age). Trouble arises when there's an application-unaware caching proxy on the line (which is generally to be expected).

The simple thing to do (and I think that's the direction currently taken, but just not in text or I missed it) is that clients generally ignore the stated DNS lifetimes, and only use the request for Max-Age. The downside here is that a) information about longer-lived parts of the response is lost (not sure if that's an issue), and b) that the response can't be plugged as-is into a local DNS system (for that'd see the times and happily cache for 5 more minutes, even though the response may have been sitting in a cache for almost that time).

Options IMO are:

• State that we want it to behave like this, and that any client is to consider all lifetimes in the response clamped to Max-Age.
• About the same, but ask it from the server. ("MUST NOT set a longer Max-Age than the shortest lifetime, and MUST zero all lifetimes").
• (Most complex server-side, but still easy to use minimally on the client and IMO most powerful) Interpret all times relative to the expiry of the cache, and ask DoC servers to pick a Max-Age such that the smallest lifetime become zero (or as small as practical).
  This allows an unaware cache (typically in a proxy) to keep the response available for as long as it is usable, and still allows aware clients to push the limits.

If you even want to explore the 3rd option, I can start a discussion on core@ietf.org on whether taking the max-age expiry as a reference point is a practical pattern.

[miri64]

In DoH this is accounted for by using the Age header.

[RFC7234] when calculating the DNS TTL of a response. For example,
if an RRset is received with a DNS TTL of 600, but the Age header
field indicates that the response has been cached for 250 seconds,
the remaining lifetime of the RRset is 350 seconds. This requirement
applies to both DoH client HTTP caches and DoH client DNS caches.

Couldn't we do something similar with Max-Age? If Max-Age is lesser than the smallest TTL in the response, the difference between that smallest TTL and the Max-Age option value must be subtracted from all TTLs in the DNS response by the client.

[chrysn]

I think that'd amount to the same thing, and may be easier to implement. Asking on core@ for experience there.

[chrysn]

I'd assume that it's easier for a client to add Max-Age than to traverse all records to find the difference, but let's see what CoRE says.

[chrysn]

See also https://mailarchive.ietf.org/arch/msg/core/CzRQTARwPgIwJN0s_kmlLRCNMKY

[ektrah]

@chrysn makes a good point about application-unaware caching proxies on the path. I guess, as soon as you have multiple such proxies involved that all do their own Max-Age and ETag processing, any kind of time indications relative to the time of a request (that is not visible to the whole chain of proxies) or a response (that may have been cached for a while and then validated via ETag) become pretty meaningless...

While DNS resolvers can update responses on the granularity of record, the caching in CoAP really revolves around avoiding the transmission of whole responses (either by reusing a previous response from a cache because it’s still valid for the same request or because it can be quickly validated to be still valid).

Maybe it would be possible to define a FETCH format where the client states what is has and what is missing, so that the server can “patch” the information the client already has, but that sounds like a lot of work to specify. IMHO, the easiest solution would be to acknowledge that DNS over CoAP isn’t as powerful and efficient as the original DNS protocol (whole-response caching only) and to optimize the whole thing for use cases where using the original DNS protocol isn’t feasible (“better this than nothing”).

Over OSCORE, this would mean that there’s no caching happening on the path between the client and the origin server. Over everything else, this would mean any non-absolute time information in representations is meaningless.

[miri64]

Was addressed in #19.