-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TTL vs. Max-Age #5
Comments
In DoH this is accounted for by using the Age header.
Couldn't we do something similar with |
I think that'd amount to the same thing, and may be easier to implement. Asking on core@ for experience there. |
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 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. |
Was addressed in #19. |
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:
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.
The text was updated successfully, but these errors were encountered: