Re: [Tsv-art] Tsvart last call review of draft-ietf-httpbis-priority-10

Bob, thank you for your thorough review.

I think we have addressed or Lucas has responded to most of the points, but
I've been notified that the point below has been left to me.

2021年12月21日(火) 21:17 Bob Briscoe <ietf@bobbriscoe.net>:

>
> T#5c) Nothing said about caching and priority
>>
>> The paragraph about caching and priority just ends having talked a bit
>> about
>> caching but not about priority. It left me none the wiser about what a
>> cache
>> ought to store about priority with the response. §13.8 talks about
>> fairness
>> between multiple live connections in the presence of coalescing. But
>> doesn't
>> the discussion of caching and priority here need to talk about what
>> must/should/may be stored about priority in a cache for later
>> connections. Even
>> if it's implementation dependent, wouldn't it be worth a brief discussion
>> (as
>> in the 2 paras below).
>>
>> The priority of a response is the outcome of an interaction between the
>> client's original (e2e) priority combined with the server's logic about
>> the
>> resource. If only the priority outcome is stored, then when another
>> request
>> arrives at the cache from a different client, there will be no record of
>> the
>> original client's priority. So the  cache will not know what client
>> priority
>> led to the priority stored with the response. And it will not know
>> whether the
>> current client priority is the same or different.
>>
>> On the other hand, if the cache stores the original client priority with
>> the
>> response priority, then should it refer a request with a different (e2e)
>> client
>> priority to the server, then store the new pair of priorities with the
>> original
>> cached response? And I guess it could serve the request in parallel,
>> rather
>> than waiting for the server to tell it whether to serve the request
>> urgently
>> (!). This would probably scale reasonably well, given the likely small
>> number
>> of different client priorities. But who knows how it would scale if the
>> parameter space is extended in future.
>>
>
> Answer supplied by Kazuho - As discussed in the last paragraph of section
> 5, CACHING defines if and how requests with different header field values
> can be mapped to one response. If the capabilities provided by CACHING
> (i.e. Vary) is too limited, then we should fix that as an extension to
> CACHING (as have been previously proposed as draft-ietf-httpbis-key). In
> practice, re Extensible Priorities, IMO, there aren't many sensible
> combinations of urgency and incremental. Therefore, backend servers that
> want to tune priority based on the value that the client sends can simply
> send Vary: priority and call it a day.
>
>
> [BB] I think my point has been missed. I'll try an example:
> Client A requests
>     priority u=4
> Server responds
>     priority u=2,
> which gets cached.
> Client B requests same object
>     priority u=4.
> Client C requests same object
>     priority u=0
>
> If requests B & C were forwarded to the origin, it would respond with
>     priority u=2    # for B
>     priority u=0    # for C
>
> However, even though the cached object has the same priority header that
> the origin server would give to Client B's request, it's different to that
> cached. And the cache cannot tell that B's request would match, but C's
> wouldn't.
>
> Vary doesn't help here, does it? At least not without storing the client
> request priority as well as the server response.
>

[KO] Vary does exactly that.

Quoting from draft-ietf-httpbis-cache-19 section 4.1: When a cache receives
a request that can be satisfied by a stored response and that stored
response contains a Vary header field (Section 12.5.5 of [HTTP]), the cache
MUST NOT use that stored response without revalidation unless all the
presented request header fields nominated by that Vary field value match
those fields in the original request (i.e., the request that caused the
cached response to be stored).
https://httpwg.org/http-core/draft-ietf-httpbis-cache-latest.html#rfc.section.4.1.p.1

-- 
Kazuho Oku