Re: Submitted new I-D: Cache Digests for HTTP/2
Eliezer Croitoru <eliezer@ngtech.co.il> Tue, 02 February 2016 06:42 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 02DED1A883C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 1 Feb 2016 22:42:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.703
X-Spam-Level:
X-Spam-Status: No, score=-5.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, J_CHICKENPOX_65=0.6, 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 aZzjn25LkNrq for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 1 Feb 2016 22:42:31 -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 72D861A884E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 1 Feb 2016 22:42:30 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aQUbK-00012q-6q for ietf-http-wg-dist@listhub.w3.org; Tue, 02 Feb 2016 06:38:10 +0000
Resent-Date: Tue, 02 Feb 2016 06:38:10 +0000
Resent-Message-Id: <E1aQUbK-00012q-6q@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <eliezer@ngtech.co.il>) id 1aQUbG-000128-Qo for ietf-http-wg@listhub.w3.org; Tue, 02 Feb 2016 06:38:06 +0000
Received: from mtaout25.012.net.il ([80.179.55.181]) by lisa.w3.org with esmtp (Exim 4.80) (envelope-from <eliezer@ngtech.co.il>) id 1aQUbD-0004qZ-VJ for ietf-http-wg@w3.org; Tue, 02 Feb 2016 06:38:05 +0000
Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0O1W00I00Q28NX00@mtaout25.012.net.il> for ietf-http-wg@w3.org; Tue, 02 Feb 2016 08:33:19 +0200 (IST)
Received: from mail.ngtech.co.il ([84.95.212.160]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPSA id <0O1W00FTDQ7I4530@mtaout25.012.net.il> for ietf-http-wg@w3.org; Tue, 02 Feb 2016 08:33:19 +0200 (IST)
Received: by mail.ngtech.co.il (Postfix, from userid 5001) id 297F61FF8F; Tue, 2 Feb 2016 08:37:33 +0200 (IST)
Received: from [192.168.10.131] (unknown [192.168.10.254]) by mail.ngtech.co.il (Postfix) with ESMTPA id 8C2831FF7C; Tue, 2 Feb 2016 08:37:29 +0200 (IST)
Date: Tue, 02 Feb 2016 08:37:30 +0200
From: Eliezer Croitoru <eliezer@ngtech.co.il>
In-reply-to: <CANatvzxEgfSPJoNT_MHe46SbJuMKu5zzdJWOFF+mr8ewaHh6Qg@mail.gmail.com>
X-012-Sender: eliezer-111@012.net.il
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <56B04EAA.5010407@ngtech.co.il>
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"; format="flowed"
Content-transfer-encoding: 7bit
References: <CANatvzxcKS46iAqAdfBHuWPt5k3XkR79NDMPPtDakOb2jPAywA@mail.gmail.com> <56A26B1E.4050303@rd.bbc.co.uk> <56A82F49.4030708@ngtech.co.il> <CANatvzxEgfSPJoNT_MHe46SbJuMKu5zzdJWOFF+mr8ewaHh6Qg@mail.gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
Received-SPF: none client-ip=80.179.55.181; envelope-from=eliezer@ngtech.co.il; helo=mtaout25.012.net.il
X-W3C-Hub-Spam-Status: No, score=-5.4
X-W3C-Hub-Spam-Report: AWL=-1.500, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1aQUbD-0004qZ-VJ e3a1be3f41ba4512aef15910e1ab654b
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/56B04EAA.5010407@ngtech.co.il>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31033
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>
Thanks for the response!! Your words made more sense to me now then before. Eliezer On 02/02/2016 03:45, Kazuho Oku wrote: > Thank you for your feedback. > > 2016-01-27 11:45 GMT+09:00 Eliezer Croitoru <eliezer@ngtech.co.il>: >> I would like to join from this point to understand and ask the list since I >> couldn't follow and understand what was proposed and implemented exactly and >> I wanted to make sure I understand right. >> >> On 22/01/2016 19:47, Richard Bradbury wrote: >>> >>> Hello. The general thrust of this I-D seems like a useful optimisation >>> of HTTP/2 server push. It is wasteful to push a representation to a >>> client when the client already has a fresh copy cached. But the reverse >>> is equally true, I think... >> >> >> In some relation to the above quote I would like to ask: >> What is basically more important the client or the server resources? >> >> From what I understood the basic proposal was to add into every request the >> cache digest am I right? Is it still that way? > > The original draft adds cache digest to every H2 connection. Recent > discussion has been about conveying the digest within every HTTP > request as an HTTP header. > >> Else then some privacy issues about sending the client cache-digest and TLS >> as being considered secure, there are other issues with it, for example >> mobile clients or metered WAN and LAN connections. >> If the client sends some KB(which can be more then couple cookies) on each >> request it means that for 20 requests the usage will be 10KB*20 <> 200KB >> which can become an issue for some but not all clients. > > In case of HTTP/2, the overhead will be much less thanks to HPACK. > With HPACK, cache-digest that is sent repeatedly can typically be > compressed to one or two octets. And unless HTTP/2 is being used, > there is practically no reason to send the cache digest over a public > network; only HTTP/2 supports push. > >> Maybe for youtube that sends files\objects ranging from 3MB to 500MB++ it's >> not always an issue but sites that sends\pushes X*3MB images for the >> homepage to a mobile app is kind of an issue. If I'm not wrong this is one >> of the reasons that mod_pagespeed was designed, to somehow solve wrongly >> consumed bandwidth. >> >> From my point of view and understanding a cache-digest will probably require >> some per client "cache-digest dictionary" which can cause some issues to >> systems\servers with lots of clients\connections. The other side would be >> the ongoing re-validation and maintenance of this dictionaries. > > That is a fair argument. However, servers are already required to > maintain such dictionary for HTTP/2 (i.e. HPACK). > >> It opens both the clients and the servers to some vulnerabilities. Also what >> would be the scope of the cache-digest, per connection? per request? per >> some client session id? >> >> And to polish out some aspects, what would happen if the server(which in >> many cases doesn't care about couple KB on the wire) will send a push offer >> for 20 objects and will be declined for each and every one of them with some >> kind of 304 by the client? >> - It will not require to open a new connection to the client and will use >> the same open connection. >> - It will not create a situation which the client resources(non-symmetric >> DSL clients) are being exhausted(imagine an office with 100+ PCs and 2 DSL >> 15MBit\1Mbit connection..) >> - It will simplify the server SW implementation and will prevent the need to >> store and look-up the client "cahce-digest dictionary" each and every time. >> >> And also if the html page contains the list of urls for objects that the >> client\browser can validate by itself someway, why do the client needs to be >> pushed some objects\content?(this is yet to be fully understood to me) >> I am looking for couple scenarios which will justify and clear out the need >> for such an implementation. Where is it needed else then advertisements? >> My basic understanding is that a cache-digest doesn't help for interactive >> applications or chats or real-time applications since the content there is >> always new or updated compared to the client. And compared to these a static >> files site will maybe require the client to send once the cache-digest but >> not on each and every request. >> >> I am almost convinced that: >> - Implementing a special request for an "update" request to a specific >> set\batch of files\objects will be much more efficient for both the client >> and the server then sending the cache-digest even once in a header. >> - Using some kind of push\offer 20 objects and being declined by the client >> would be much better then publishing the list of existing objects by the >> client. > > Such approach is already defined as part of HTTP/2. > > By using server-push defined in HTTP/2, it is possible for a server to > start sending resources that are expected to be used by the client. > However, the issue is that aggressively doing so wastes downstream > bandwidth, since without knowing what is already cached by the client > a server will repeatedly try to push the same objects (that are > rejected every time by the client after it receives the pushed > resource). > > This draft is an attempt to fix the problem, by eliminating the > bandwidth you would waste if you push blindly, at the cost of some > upstream bandwidth. > >> - For a client that doesn't care to send the header for 20 objects it would >> be pointless to not send if-modified-X requests for each and every one of >> these objects as an entity. >> - There are some security risks in the client sending a cache-digest in a >> specific scope which I would like to read about. >> >> Thanks, >> Eliezer >> >> > > >
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alex Rousskov
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alex Rousskov
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alex Rousskov
- Re: Submitted new I-D: Cache Digests for HTTP/2 Cory Benfield
- Re: Submitted new I-D: Cache Digests for HTTP/2 Chris Bentzel
- Re: Submitted new I-D: Cache Digests for HTTP/2 Ilya Grigorik
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Amos Jeffries
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Amos Jeffries
- Re: Submitted new I-D: Cache Digests for HTTP/2 Ilya Grigorik
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Cory Benfield
- Re: Submitted new I-D: Cache Digests for HTTP/2 Ilya Grigorik
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Julian Reschke
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Richard Bradbury
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Eliezer Croitoru
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Eliezer Croitoru
- Re: Submitted new I-D: Cache Digests for HTTP/2 Richard Bradbury
- Re: Submitted new I-D: Cache Digests for HTTP/2 Amos Jeffries
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- RE: Submitted new I-D: Cache Digests for HTTP/2 Mike Bishop
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- RE: Submitted new I-D: Cache Digests for HTTP/2 Mike Bishop
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- RE: Submitted new I-D: Cache Digests for HTTP/2 Mike Bishop
- Re: Submitted new I-D: Cache Digests for HTTP/2 Patrick McManus
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E