Subject: [core] draft-ietf-core-block-08 - Caching

From: Klaus Hartke <[email-masked]>
Date: Wed, 11 Apr 2012 06:32:35 +0200

A few questions related to caching:

* Can blocks be individually cached or is it expected that a cache
obtains the complete representation before it serves parts of it?

* What are the rules for using a cached block to satisfy a request
that is presented to a cache?

* Can different blocks have different Max-Age values? What happens
when blocks overlap? Does a response with a block update the freshness
of the complete representation?

* Can individual blocks be validated? Does validating a single block
validate the complete representation?

* Does a response with Block1 Option in control usage with the M bit
set invalidate cached responses for the target URI?

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Apr 2012 13:04:06 +0200

> obtains the complete representation before it serves parts of it?

I'm not sure you would "cache blocks"; you would cache partial representations.
I don't see a reason to wait for the complete representation.
So, e.g., a proxy could respond with the first block (say, 128-size) as soon as it has received the first two blocks (say, 64-size) from the origin.

> that is presented to a cache?

The same as usual, maybe augmented with "you can't use what you don't have"?

> * Can different blocks have different Max-Age values?

Certainly (this is hard to avoid unless all responses are generated at the same time).
The question is what the cache does with the re-combined representation; see below.

> What happens
> when blocks overlap?

Nothing special, I think.  Newer wins.

> Does a response with a block update the freshness

Good question.
Clearly, any Etag present pertains to the whole resource.
The question would be what it means to obtain a block with a longer max-age than the other blocks in the cache, but without an Etag.

I would assume that servers that serve large resources that change will provide an Etag.
So I think it is OK to optimize for rarely changing resources.  Re-freshening the entire representation to the max-age of the freshest block should be easy to implement and provide better caching.

The danger is, of course, that this re-freshening behavior, in combination with a server that does serve a changing resource without an Etag, might perpetuate stale content.

> * Can individual blocks be validated?

Etags validate the whole resource representation.

> Does validating a single block

If you are talking about Etags:  Yes.

> set invalidate cached responses for the target URI?

That sounds prudent to me.

Some of this probably should be specified in further detail.
Are you able to supply text for a subsection on caching to be added to section 2 of -block?

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 11 Apr 2012 20:28:30 +0200

> The same as usual, maybe augmented with "you can't use what you don't have"?

The usual procedure is:

- put the response into the cache as-is, i.e. without any reassembling;

- use a stored response only if all options in the presented request
are equal to the options in the request that caused the response to be
stored, with the exception of the Token, Max-Age and ETag options.

So currently each response containing a block is cached individually,
and a stored response with Block2=0/0/64 that is the result of a
request with Block2=0/0/128 cannot be used to satisfy a request with
Block2=0/0/64.

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Apr 2012 23:24:53 +0200

> - put the response into the cache as-is, i.e. without any reassembling;

I don't think that would be a very useful cache.

I'm assuming that most intermediaries will implement block and run the cache on reassembled representations.  Do you think we need to spell out the implementation considerations for this in detail?

Grüße, Carsten