Re: MAX_CONCURRENT_STREAMS=0 and PUSH_PROMISE

Roberto Peon <grmocg@gmail.com> Wed, 24 July 2013 00:45 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 6973D11E81A1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Jul 2013 17:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.561
X-Spam-Level:
X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 dR7wqkGPGsyo for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Jul 2013 17:45:26 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0D611E816F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Jul 2013 17:45:23 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1V1nBd-0007nm-7C for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Jul 2013 00:44:13 +0000
Resent-Date: Wed, 24 Jul 2013 00:44:13 +0000
Resent-Message-Id: <E1V1nBd-0007nm-7C@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1V1nBS-0007mV-Ui for ietf-http-wg@listhub.w3.org; Wed, 24 Jul 2013 00:44:02 +0000
Received: from mail-oa0-f44.google.com ([209.85.219.44]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1V1nBS-0007xd-2d for ietf-http-wg@w3.org; Wed, 24 Jul 2013 00:44:02 +0000
Received: by mail-oa0-f44.google.com with SMTP id l10so12954995oag.31 for <ietf-http-wg@w3.org>; Tue, 23 Jul 2013 17:43:36 -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=OzBBqd5+Z38pD6tsnc4/d1CZKpfQ2zr+FrVjxtx2aEc=; b=b/eb+BjR+G2oG+IDtpGyhcuE8da8TIjNAQiHw1AxVNDoZrK3rzN/L22KfYXGSSUT1a 7LGy1imrGGu6SJxjyArlOlgge1k7VxNFPmhLMSRR4reJnJ8mFsGazPh6pptBXCzf66R/ N+rvMfrl8mkzY2KRWXcrReNSlh+YnxUBjJ54wppS/4qJ28j68tIkh6QcaVhiovNT736m ffgBPFt9zTzTHIjeAQ1GB8yvRkYUFroEcDacZy4F9TQL0+yh8HYBmd96sBXeatOnInvx WT53LJAxt7P4KRt5gGgn4AINqEV748Cmxsuyh6uKgZuu5XSu/1peRsz9Iflddgq3hcJu J1Gw==
MIME-Version: 1.0
X-Received: by 10.60.140.168 with SMTP id rh8mr33785179oeb.17.1374626615975; Tue, 23 Jul 2013 17:43:35 -0700 (PDT)
Received: by 10.76.91.229 with HTTP; Tue, 23 Jul 2013 17:43:35 -0700 (PDT)
In-Reply-To: <CABkgnnUK45jVj1f=QuJnE7w3gSWJZ_jAPq=87SLyvyGYxUt0kw@mail.gmail.com>
References: <CA+KJw_5PcUxBiUnQ00=G2C4Q6MnaB=hpNDk+9eTeZMs3Lz-CpA@mail.gmail.com> <CAP+FsNf7YBDfO_=fW7nPHXdUi0F+0+4S2AUm_T2gHtqYhER8MA@mail.gmail.com> <20130723190419.GA25817@LK-Perkele-VII> <CAP+FsNc5tef8WRCaH-_6z5se=vVPscSQ3+GfEF0T02q8oKq6WA@mail.gmail.com> <CABkgnnWx5d_3U+tFQYG68+NCGC3Q2Hfm_PD0hgALeawb+PY-ZA@mail.gmail.com> <CAP+FsNfauVPhGZH31_LFeQKOuPF0KcYKp7U4qMBtDUsv-Ja-cQ@mail.gmail.com> <CABkgnnV7ZZ_MWeuP2cDKombNWJJahES02XYTJh0OJY7yo17ytQ@mail.gmail.com> <CAP+FsNfgEqP2dwHsG0RD2ZizpVNw=98mTJ=1Q33b3UK8NdhjYA@mail.gmail.com> <CABkgnnUK45jVj1f=QuJnE7w3gSWJZ_jAPq=87SLyvyGYxUt0kw@mail.gmail.com>
Date: Tue, 23 Jul 2013 17:43:35 -0700
Message-ID: <CAP+FsNdrNYK7ZWJS79JkWewbuu82VD5BbbTiRkw9-bnZbDvHvA@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Gábor Molnár <gabor.molnar@sch.bme.hu>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="047d7b2e4c4624e5b504e23733ee"
Received-SPF: pass client-ip=209.85.219.44; envelope-from=grmocg@gmail.com; helo=mail-oa0-f44.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.672, 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: lisa.w3.org 1V1nBS-0007xd-2d ab918c82596ea95cc52b278dc6ab3ed8
X-Original-To: ietf-http-wg@w3.org
Subject: Re: MAX_CONCURRENT_STREAMS=0 and PUSH_PROMISE
Archived-At: <http://www.w3.org/mid/CAP+FsNdrNYK7ZWJS79JkWewbuu82VD5BbbTiRkw9-bnZbDvHvA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18899
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>

For reasons of DoS prevention, a proxy may wish to throttle the push'd
entity-body data by limiting the concurrency without messing around with
the flow-control (since that would also slow down the main-resource
transfer, unless on separate connections).
As an example DoS attack, a client could start out a connection with push
enabled, then disable it in an attempt to run the proxy out of memory/make
the proxy do useless work.
The proxy may still wish to get the push-promise metadata, however, as it
both indicates what work might have been done (so it can anaylze the effect
of things), and as a first-order effect, allows the proxy to determine what
elements it can serve from cache instead of spending CPU on IO, which is
pretty expensive.
-=R




On Tue, Jul 23, 2013 at 4:43 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 23 July 2013 15:38, Roberto Peon <grmocg@gmail.com> wrote:
> > I'm a proxy guy, actually.
>
> Everyone writing a stack deals with these problems at some level.
> Some will just have to worry about concurrency and queuing at a
> different layer, that's all :)
>
> After some offline discussion, I understand that we still (perhaps
> grudgingly) need a way to signal that a client is unwilling to receive
> pushes.  However, that operates at two levels:
> a) a client is unwilling to receive pushes, ever
> b) a client is currently unwilling to receive pushes, but will accept
> promises (i.e., the requests) in the expectation that it can receive
> the corresponding responses in time
>
> The concern here is that setting the maximum concurrent streams to
> zero could be used to communicate either situation, and that sometimes
> the distinction is important.
>
> I think that onus is on Roberto to more effectively motivate the need
> for this distinction.
>
> If indeed we agree that the two cases are distinct, then we probably
> need to consider ways to communicate this distinction effectively.  A
> separate setting that expressly disables push promise or limits the
> number of promises might work.
>