draft-ietf-httpbis-cache-digest-00 comments

[Martin Thomson <[e-mail]>]

As I've said before, this is really interesting work, I'm very much
interested in seeing this progress.  However, I found a lot of issues
with the current draft.

The latest version seems to be a bit of a regression.  In particular,
the addition of all the flags makes it a lot more complicated, and I'm
already concerned about managing complexity here, especially since
this is an optimization.

The draft doesn't actually say where this frame should be sent - on a
stream that carries a request, or on stream 0.  This is important
because there are several mentions of origin.  For instance, the new
RESET flag talks about clearing digests for the "applicable origin".
That establishes a large point of confusion about the scope that a
digest is assumed to apply to; by their nature, this isn't necessarily
fatal, until you want to talk about RESET and COMPLETE.

To up-level a bit on this general issue, I'd like to see a better
formulated description of the information that clients and servers are
expected to maintain.  There seem to be multiple objects that are
stored, but I'm not sure what scope they are maintained in; is the
scope an origin?

Assuming a particular scope, are there two objects, or four?  That is,
is there could be four stores:

1. assumed fresh by URL
2. assumed fresh by URL and etag
3. assumed stale by URL
4. assumed stale by URL and etag

Or are 1+2 and 3+4 combined?  The definition of RESET implies that all
four stores are cleared.  The definition of COMPLETE implies that only
1+2 or 3+4 are affected.

The draft doesn't talk about URL normalization.  That is a risk to the
feasibility of this; fail to do something sensible here and you could
get a lot of spurious misses.  Given that it is just an optimization,
we don't need 100% agreement for this to work, but saying something is
probably wise.  We can probably get away with making some lame
recommendations about how to encode a URL.  Here's a rough cut of
something that didn't make the draft deadline this time around:
https://martinthomson.github.io/http-miser/#rfc.section.2.1

I don't see any value in COMPLETE.  Even if we accept that there is
only one connection from this client to this server, the benefit in
knowing that the digest is complete is marginal at best.  Is there
just one extra resource missing, or thousands.  As such, it changes
the probability by some unknown quantity, which isn't actionable.

Can a frame with the RESET flag include a digest as well?

N and P could fit into a single octet.  Since you are into the flags
on the frame anyway, reduce N and P to 4 bits apiece and use flags to
fill the upper bits as needed.  But I don't think that they will be
needed.  At the point that you have more than 2^16 entries in the
digest, you are probably not going to want to use this.  Even with a
tiny P=3 - which is too high a false positive probability to be useful
- with N=2^16 you still need 32K to send the digest.  You could safely
increase the floor for P before you might need or want higher bits
(and make the minimum higher than 2^0, which is probably too high a
false-positive probability in any case).

Is the calculation of N really round(log2(urls.length)).  I thought
that you would want to use ceil() instead.  Is the word "up" missing
from step 1 in Section 2.1.1?

The draft never actually mentions that it uses [Rice-]Golomb-coding
until the appendix.  Including a reference to the Rice paper would
help people implementing this understand where this comes from, as
well as leading them to being able to find the relevant research.
(nit: Spelling Golomb correctly would help here.)