Re: HTTP router point-of-view concerns
Roberto Peon <grmocg@gmail.com> Fri, 12 July 2013 16:33 UTC
Return-Path: <ietf-http-wg-request@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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1940321F9684 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 12 Jul 2013 09:33:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.545
X-Spam-Level:
X-Spam-Status: No, score=-10.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ivmc2us6kAZm for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 12 Jul 2013 09:33:15 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3785021F9F02 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 12 Jul 2013 09:33:15 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UxgGb-0006c9-Hz for ietf-http-wg-dist@listhub.w3.org; Fri, 12 Jul 2013 16:32:21 +0000
Resent-Date: Fri, 12 Jul 2013 16:32:21 +0000
Resent-Message-Id: <E1UxgGb-0006c9-Hz@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UxgGT-0006Xu-AZ for ietf-http-wg@listhub.w3.org; Fri, 12 Jul 2013 16:32:13 +0000
Received: from mail-oa0-f47.google.com ([209.85.219.47]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UxgGS-0008Gc-Bt for ietf-http-wg@w3.org; Fri, 12 Jul 2013 16:32:13 +0000
Received: by mail-oa0-f47.google.com with SMTP id m1so12988104oag.20 for <ietf-http-wg@w3.org>; Fri, 12 Jul 2013 09:31:46 -0700 (PDT)
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=1cXrea2XGeV3hxfy/yv1at8bmmlfNLYeJ/N1Ga2Gwxk=; b=MA1mHM5HVAZK2FWNMIFP2KDdu/bxjMsKl/zv8Jldz+bHoWwGU3x8Lg1E9DHl4tOwBP MM15LeILuVj9pTM6uivf+G5q+Gz3b9f/31FOrR2bswTmzJvjYRokhRz63Hs5Je6HiNZ9 wqF2iZn/INVfVG9jWnq25CUJOZYnh3MT95CNsm3sDh/cPrFnlaCCa6jrS9lHIi9jYlUN nxE6GChHomnFuUiTxjYUL03OD74fwAaz/V5FS8yewkwr456+XpTQmrW/noxJxRy+n0c0 686vFWvOTlSLO38iJRJOcx7IEu3deqVE7WYysdf6fV1vhzbTn1jcYRA7KpRI4LLHhMiO AYmg==
MIME-Version: 1.0
X-Received: by 10.182.181.99 with SMTP id dv3mr36494823obc.71.1373646706249; Fri, 12 Jul 2013 09:31:46 -0700 (PDT)
Received: by 10.76.91.229 with HTTP; Fri, 12 Jul 2013 09:31:46 -0700 (PDT)
In-Reply-To: <51DFBDAB.9010505@treenet.co.nz>
References: <CA+qvzFPUpcm6kUtJx+rTw8Dpp4Gtx4Bmr3XPDhjNsjchUfN9_w@mail.gmail.com> <51DE1E32.9010801@treenet.co.nz> <CAP+FsNdcYhA=V5Z+zbt70b5e7WmcmXgjG5M9L3vfXeXfTwmRnw@mail.gmail.com> <51DE327C.7010901@treenet.co.nz> <CABkgnnXeqD6wh0dcJ1Dz=4PLAJNkDeGcCuzMr9ATd_7xS7nbGQ@mail.gmail.com> <CABP7RbcUkLf3CTAB4jwicnsiKWLGVY6=hX0k=0256SR_gcVt9A@mail.gmail.com> <CAP+FsNcOZnLa9GCr6XcZNFdq-mSXG6Q-_1Lb5u=a2YyXNCsVfQ@mail.gmail.com> <51DFBDAB.9010505@treenet.co.nz>
Date: Fri, 12 Jul 2013 09:31:46 -0700
Message-ID: <CAP+FsNeXkJ5rcnvuqXdahGQ=Bfqf3gxdV1XVisPaNy9HwRCXLQ@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="089e0158b6a6f916c804e1530b58"
Received-SPF: pass client-ip=209.85.219.47; envelope-from=grmocg@gmail.com; helo=mail-oa0-f47.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.689, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UxgGS-0008Gc-Bt 7ae75e6137a2f24dbaf171e781b10bc4
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP router point-of-view concerns
Archived-At: <http://www.w3.org/mid/CAP+FsNeXkJ5rcnvuqXdahGQ=Bfqf3gxdV1XVisPaNy9HwRCXLQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18728
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>
Correct, I mean to say that, if you can't deal with 4k of state in the first RT then you RST those requests, causing them to suffer one RT of latency. Personally, I think one should be able to deal with state for the first RT, especially you're going to have more than that in general in the IO buffers, kernel buffers, etc. But, anyway, assuming you're under DoS attack, there are multiple options: 1) send a new settings frame with the size you want, and RST everything 'till that becomes effective. 2) we implement James' proposal of a goaway-and-come-back after sending the settings, where the settings are effective on the next connection 3) If we kept the persistent settings on the client, the first time the client spoke to the intermediary, it would learn and have appropriate settings in the future. 4) reject HTTP/2 (which uses more state in exchange for lower latency) in preference for HTTP/1.0, which will put less data as persistent state for the first RT. 5) assuming we did the DNS thing, the client would already have the correct setting, and there'd be no additional latency. I'm confused the complaining about extra latency of any of the solutions above, however. Do we care about latency or not? Arguments that complain that we have to hold state for 1 RT, and that we want to eliminate all state make me think that latency is viewed as a distant-second consideration. Is latency a prime consideration, as indicated in the charter, or not? (And you can call it session caching or whatever, it is still just state on the other side and is all the same idea). -=R On Fri, Jul 12, 2013 at 1:26 AM, Amos Jeffries <squid3@treenet.co.nz> wrote: > On 12/07/2013 7:35 a.m., Roberto Peon wrote: > >> I think it is perfectly reasonable for an intermediary to set the >> compression size to zero if it wishes. >> >> Market forces will (in the long-term) pick the correct strategy for >> this-- assuming the compression is effective at reducing latency, and that >> people care about latency reductions, then eventually intermediaries might >> evolve to use it. >> If it is ineffective at reducing latency, or if reduced latency is not >> actually desirable, then intermediaries would not use it. >> >> >> The DoS vector you're talking about is not a DoS vector if the >> intermediary resets all streams before the change-of-state-size comes into >> effect. >> > > If you means RST_STREAM on all the initial streams which use a larger > compression size then what you are doing is adding an RTT penalty to all > those requests over and beyond what HTTP/1 suffers from already on a normal > transaction. This is not a useful way forward (wastes packets, RTT and > stream IDs) and resolving it is to make decompression with the default > state size mandatory for all recipients. Which brings us full circle on the > problem of having a default >0 in the dynamic part of the state tables. > > > > When the state size is 0, one should be able to use some kinds of >> 'indexed' representations, so long as those representations refer only to >> items in the static tables. Why do you believe that this would use more or >> less CPU? (It should use less CPU and less memory...) >> > > I did not mention CPU. Only the bandwidth amplification effects that > agents disabling compression would incur and need to consider carefully. > > Personally I would like to see a 127 entry mandatory static table in the > spec itself and tied to the "2.0" version with a 127 entry optional dynamic > table indicated by the high-end bit of the byte code. With a capacity byte > size for dynamic table sent each way and senders forbidden to add new > entries to the dynamic table until they hold the value from both ends of > the connection. Agreed value being the minimum of both ends capacities. > > Amos > >
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- HTTP router point-of-view concerns Christian Parpart
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Christian Parpart
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Michael Sweet
- Re: HTTP router point-of-view concerns Martin Thomson
- Re: HTTP router point-of-view concerns James M Snell
- Re: HTTP router point-of-view concerns Sam Pullara
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Sam Pullara
- Re: HTTP router point-of-view concerns Patrick McManus
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns James M Snell
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns James M Snell
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Sam Pullara
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Martin Thomson
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Mark Nottingham
- Re: HTTP router point-of-view concerns Mike Belshe
- Re: HTTP router point-of-view concerns Gábor Molnár
- Re: HTTP router point-of-view concerns Gábor Molnár
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Michael Sweet
- Re: HTTP router point-of-view concerns Christian Parpart
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Patrick McManus
- Re: HTTP router point-of-view concerns Jeff Pinner
- Re: HTTP router point-of-view concerns Martin Thomson
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Ludin, Stephen
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns James M Snell
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Amos Jeffries
- Re: HTTP router point-of-view concerns Roberto Peon
- Re: HTTP router point-of-view concerns Yoav Nir
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Sam Pullara
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Mark Delany
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Yoav Nir
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Yoav Nir
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Stephen Farrell
- Re: HTTP router point-of-view concerns Willy Tarreau
- Re: HTTP router point-of-view concerns Sam Pullara
- Re: HTTP router point-of-view concerns Nicolas Mailhot
- Re: HTTP router point-of-view concerns Nicolas Mailhot
- Re: HTTP router point-of-view concerns Nicolas Mailhot
- Re: HTTP router point-of-view concerns Martin Nilsson
- Re: HTTP router point-of-view concerns Nico Williams
- Re: HTTP router point-of-view concerns Nico Williams
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Nico Williams
- Re: HTTP router point-of-view concerns Poul-Henning Kamp
- Re: HTTP router point-of-view concerns Nico Williams