Re: Submitted new I-D: Cache Digests for HTTP/2

Kazuho Oku <kazuhooku@gmail.com> Wed, 13 January 2016 05:09 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BBD1B2D6C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 12 Jan 2016 21:09:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.003
X-Spam-Level:
X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5yvdxrl7oXG for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 12 Jan 2016 21:09:26 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4DAF1B2D6B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 12 Jan 2016 21:09:26 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aJDbv-0004KD-S2 for ietf-http-wg-dist@listhub.w3.org; Wed, 13 Jan 2016 05:04:43 +0000
Resent-Date: Wed, 13 Jan 2016 05:04:43 +0000
Resent-Message-Id: <E1aJDbv-0004KD-S2@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <kazuhooku@gmail.com>) id 1aJDbq-0004JV-SN for ietf-http-wg@listhub.w3.org; Wed, 13 Jan 2016 05:04:38 +0000
Received: from mail-wm0-f42.google.com ([74.125.82.42]) by maggie.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <kazuhooku@gmail.com>) id 1aJDbm-0003mV-5e for ietf-http-wg@w3.org; Wed, 13 Jan 2016 05:04:38 +0000
Received: by mail-wm0-f42.google.com with SMTP id f206so278777897wmf.0 for <ietf-http-wg@w3.org>; Tue, 12 Jan 2016 21:04:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P5MBjjH6ZzJ/mKS1Jjx97sdD7IHpQnsUT+Tr4AvqT9Y=; b=P6eV1dra9Qladv3y8fyW3cCbEtw76HWFVbYvidhTE53Pq8fQtZBfVAhSTKTQctFoUE OCDQBJKlCDO/i44g/sKiTmBaf35Yb/h2BMg3ddRaJNSTs0uLv4Rzi52eMk5Z0don+DM+ qQBdXsZsULazIIY8rk+m68iGM/vB4NwY5r8JedaRQsknu+mgTqjLtzI0oaBxWCMkXVP/ m5c3kgbeh/bvROlt78Qd4A7lnhPk7axcI7RZNMXn3VivvCOCcYGV1lmPMDAWAjBYBS29 YB+RJDlfLuKA4wtUeSbppywCctgQL01YMd1RdRL/JvIEeVXVnMF0ONG3tHaaKZy85pW1 QIIA==
MIME-Version: 1.0
X-Received: by 10.28.1.210 with SMTP id 201mr23952299wmb.90.1452661447750; Tue, 12 Jan 2016 21:04:07 -0800 (PST)
Received: by 10.194.235.163 with HTTP; Tue, 12 Jan 2016 21:04:07 -0800 (PST)
In-Reply-To: <56958980.1030307@treenet.co.nz>
References: <CAAMqGzYUoCMxBxUEY9wfLOHZp7nrO4d1q5JZo=96pfEbVS1-ew@mail.gmail.com> <652C3E3A-3DA6-40BB-82FF-01A7D65FF65C@lukasa.co.uk> <CABCZv0piAoDnA1J+2pJ3HyF_iRwj9AaFGfonFjdKGfYr=cGZgQ@mail.gmail.com> <CAKRe7JG16u+MteBz4Rz7iCnHxfhLZ=QbWekrhgNhNkq+pKhVAg@mail.gmail.com> <CANatvzyT_ohm5hEcJ1o8B+AEa70607E-LUnPp5cD8sSO8X0HKA@mail.gmail.com> <56958980.1030307@treenet.co.nz>
Date: Wed, 13 Jan 2016 14:04:07 +0900
Message-ID: <CANatvzyOnMSLHfXcDrGSjbtZi5nFX2e9_4tHOjmR2OqBWEYUcg@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=74.125.82.42; envelope-from=kazuhooku@gmail.com; helo=mail-wm0-f42.google.com
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Hub-Spam-Report: AWL=-0.409, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1aJDbm-0003mV-5e 90b2c0bf9d0c02d963fd0dd313d53f21
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Submitted new I-D: Cache Digests for HTTP/2
Archived-At: <http://www.w3.org/mid/CANatvzyOnMSLHfXcDrGSjbtZi5nFX2e9_4tHOjmR2OqBWEYUcg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30913
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

2016-01-13 8:17 GMT+09:00 Amos Jeffries <squid3@treenet.co.nz>:
> On 12/01/2016 2:20 p.m., Kazuho Oku wrote:
>> 2016-01-12 0:39 GMT+09:00 Ilya Grigorik:
>>> Glad to see this proposal!
>>>
>>> FWIW, another +1 for enabling this functionality via an HTTP header.
>>> Limiting it to h2 frames makes it effectively inaccessible to web developers
>>> that want to experiment with own cache management logic (via ServiceWorker,
>>> etc).
>>
>> Glad to hear from you.
>>
>> While it is possible to use an HTTP header to implement cache-digest
>> (and that is what we are doing now in H2O + ServiceWorker/cookie), I
>> believe it should ideally be implemented as an HTTP/2 header since:
>>
>> * including the digest value (the value changes as client receives
>> responses) in every HTTP request is a waste of bandwidth
>
> Bandwidth may or may not be a problem relative to the digest design and
> amount of compression applied by the protocol (eg. h2 dynamic table vs
> HTTP/1.1 repetition).

That is generally true.

However the specification will become complicated if we are to include
the cache digest in the headers, while achieving a good compression
ratio.

To send cache digests using headers while achieving good compression
ratio with HPACK, we would need to split the digest into at least two
headers: a large value that changes infrequently, and small values
that change frequently.  A client will send those headers attached to
every HTTP request, a server will merge the header values into one and
decode the digest for every HTTP request.

And even if we did include such headers in every HTTP request, it is
still better for a  server to maintain the client's cache state per
connection, since there is a time slot between when a server sends a
resource (so that it would get cached by the client), and when a
client is capable of notifying the server that it has actually cached
something.  For example, if a client requests `/a.html` and `/b.html`
(that both rely on `/style.css`), a server should push `/style.css`
only once.  To do so, the draft expects a server to maintain and
update the estimated cache digest of the client, connected over a
single TCP connection.

To summarize, the draft utilizes the fact that HTTP/2 multiplexes HTTP
requests into a single, ordered stream to make things simple.
Considering the fact that we need to rely on HTTP/2 to push things
anyways (that is the primary target of the draft), I think that is a
reasonable trade-off.

>> * cache state is an information that is bound to the connection, not
>> to a request
>
> You assume a browser endpoint cache.
>
> Intermediary caches are constructed from content flowing over multiple
> parallel connections. Potentially from multiple origins. Which makes it
> very likely to have changed between any two given requests to contain
> things that cannot be inferred by the server from those two requests.

Do you consider that caching proxies should establish multiple
connections to upstream when using HTTP/2?

> This type of problem is also more likely to happen in the presence of
> domain sharding. Where the temporal locality of the index request is
> different from the 100's of content requests.
>
> ALTSVC may also make similar things happen with browser caches.
>
> Amos
>



-- 
Kazuho Oku