Re: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams

William Chan (陈智昌) <willchan@chromium.org> Mon, 29 April 2013 18:38 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 1161321F9AE7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 11:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.676
X-Spam-Level:
X-Spam-Status: No, score=-9.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 ySaL2XGcbjWV for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 11:38:32 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 58E2A21F9AE5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 29 Apr 2013 11:38:32 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UWsx6-0002mY-BV for ietf-http-wg-dist@listhub.w3.org; Mon, 29 Apr 2013 18:37:28 +0000
Resent-Date: Mon, 29 Apr 2013 18:37:28 +0000
Resent-Message-Id: <E1UWsx6-0002mY-BV@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1UWswv-0002lX-Bp for ietf-http-wg@listhub.w3.org; Mon, 29 Apr 2013 18:37:17 +0000
Received: from mail-qa0-f54.google.com ([209.85.216.54]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UWswt-0008BB-Vf for ietf-http-wg@w3.org; Mon, 29 Apr 2013 18:37:17 +0000
Received: by mail-qa0-f54.google.com with SMTP id j8so1198317qah.13 for <ietf-http-wg@w3.org>; Mon, 29 Apr 2013 11:36:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XRMr8x5Ax3HKA9MKm4keQv7m52yaFl4HGE20+JclLig=; b=O7prVFPEYz7X85J1Osxk0BRr1fLQ0xbB0/dhzKl/EZzgoVbyRY/in0abPx9wi/mhcW RGRIACdBPS79somom6mn77xR2aTpeylfpwNOx78Xfc64c1nVdtfkXtb4XQdOZxLbkeMk AWkRNYtpwp3DQRvPVsGaAbtmvRNyzBiPbxuwGfzZzpF22KvfUrvov//CXcby3wCQakjF Clg1x1HsTo2/fz+/GwtXMgSql2Aviae31CTITVzXtIGyrCffAHzOAxoDSz+2JPVqwf9p lBzVPJGa6jXTh3D3uvrtTxT9ToVLPpxqyRYuhuOEp3r4gtILxLmD1SPmImdBZz+qZRef qAtg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XRMr8x5Ax3HKA9MKm4keQv7m52yaFl4HGE20+JclLig=; b=ECdh/V8y8bO/YaWl77vgyp8DPHhr8pbdwZBAUHHJmFyUaGRoFSTdrND6sJ5XO3IkHX +tfW/1b8bcKBHfp4hQoZbpVjz82n6kPKYCCivFjPbq15zo7cqefopAF7LnZLApu93Vrp tcu1zpgl6sHon2LUWMbBIZuwgGABIHJmtSJho=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=XRMr8x5Ax3HKA9MKm4keQv7m52yaFl4HGE20+JclLig=; b=dhRE4X59vFF+XdDzdK/PZcN2dL1H2xbIimHWv9R6I8XWFfYxt7MoHMo9MHzfpIQ5ja TY1kxMJJ7RZ1n/cVQJ+B0j4AYp3K4tQkG3e/vuZGROp3/Atr/UkKRXuSipHcxn/a+0QF SxGXtru8InIPvyxgoK79ZdxJjYIE3Q9jIqVNZD5aRPEMILHwO2Wu5JGw4PKxzx4qbq4X 4RSvCoz3otVzuylo0vFc4fNV5+a4pjI6B8wzRAjdOi868AKUWLH2bMVsMWLSvajfj7sN fPx9Q1mscQXUA7hLGGFfi9e8JkJV1ZPIhGjuPt1kzdrXp3PzirS7BjiD7pB8113qhfJg RDQw==
MIME-Version: 1.0
X-Received: by 10.224.57.82 with SMTP id b18mr7316818qah.36.1367260610162; Mon, 29 Apr 2013 11:36:50 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Mon, 29 Apr 2013 11:36:49 -0700 (PDT)
In-Reply-To: <CABkgnnVdU=cZ53Bqg5Un=E80NMpcgYO37DVmwUFW0O-i7SNf8w@mail.gmail.com>
References: <CABP7RbdBe-Xkx+CMvpN=_oNAqm6SyLyL+XNHRUKSqn8mjSDw1Q@mail.gmail.com> <CAA4WUYgCiyWerT0tUUVKcbNPqdTGuXHd_MG59DjcUsEWst5t7g@mail.gmail.com> <CABkgnnVdU=cZ53Bqg5Un=E80NMpcgYO37DVmwUFW0O-i7SNf8w@mail.gmail.com>
Date: Mon, 29 Apr 2013 15:36:49 -0300
X-Google-Sender-Auth: 7Ys4mf8ALQfV97ftHq876lgKX_Q
Message-ID: <CAA4WUYhz64FsEGgGhx91RfWwuPPxWdAkesOV-bmqWVWE7ZxdjA@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: James M Snell <jasnell@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=089e01538d54fc0a4004db842a78
X-Gm-Message-State: ALoCoQn5xutc0mqH0Bm3vDUNOo2f93Y/Ya1FyxuJLnNtJq/vROTdBNu5kHtPSYMJ6wpFbqlbXHhjzU6fj/i7N2UAfy9s0DSXnWjjqInw36rmd5lLSHa6WbDUEYT1Z1Lxg06DVZVzPFWS6+6tpXaTWtj+eeGKmnWphoiHVEJ0sD+cCkj3H6cbQZqnAOMZaYJNHZI+uJ16ncnh
Received-SPF: pass client-ip=209.85.216.54; envelope-from=willchan@google.com; helo=mail-qa0-f54.google.com
X-W3C-Hub-Spam-Status: No, score=-4.7
X-W3C-Hub-Spam-Report: AWL=-1.484, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.442, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UWswt-0008BB-Vf 099f9d044df5027d7009689f627ed15b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams
Archived-At: <http://www.w3.org/mid/CAA4WUYhz64FsEGgGhx91RfWwuPPxWdAkesOV-bmqWVWE7ZxdjA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17667
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>

On Mon, Apr 29, 2013 at 3:20 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 29 April 2013 10:40, William Chan (陈智昌) <willchan@chromium.org>; wrote:
> > I read this entire thread and don't really see the problem we want to
> solve.
> > Can someone clarify? Let me reviewe the paint points as I understand
> them:
> > * Stream data buffers are expensive - flow control solves this
>
> s/solves/mitigates/  - they aren't free
>

Fair enough.


>
> > * Stream headers are potentially expensive - MAX_CONCURRENT_STREAMS
> > mitigates this, although I'm not entirely convinced this is a complete
> > solution, especially when you can keep adding HEADERS for a stream
> without
> > bound (headers are problematic since you have to process them due to the
> > shared compression context).
>
> MAX_CONCURRENT_STREAMS also helps with the buffer size problem.
>

To a certain degree, yes, but the real thing that controls the bounds is
the session window or not calling read().


> > * Stream ids are cheap. They're ids and don't require much context.
> > Historically PUSH_PROMISEs were cheap, but now that they can carry header
> > blocks, we've regressed on that. I forget why we added the header blocks
> > into the PUSH_PROMISE, can someone remind me (better yet, link to the
> > appropriate email thread)?
>
> You have to signal what you intend to push to give the client a chance
> to reject it.  That's all.  So the only things that have to be in the
> promise are resource identification things (:scheme, :host, :path),
> and maybe (maybe) things that help identify cache (content-type, vary,
> cache-control)
>

Oops, forgot about that. See, the issue with that is now we've made
PUSH_PROMISE as potentially expensive as a HEADERS frame, since it does
more than just simple stream id allocation. I guess it's not really a huge
issue, since if it's used correctly (in the matter you described), then it
shouldn't be too expensive. If clients attempt to abuse it, then servers
should probably treat it in a similar manner as they treat people trying to
abuse header compression in all other frames with the header block, and
kill the connection accordingly.


>
> > As far as the potential problem above, the root problem is that when you
> > have limits you can have hangs. We see this all the time today with
> browsers
> > (it's only reason people do domain sharding so they can bypass limits).
> I'm
> > not sure I see the value of introducing the new proposed limits. They
> don't
> > solve the hangs, and I don't think the granularity addresses any of the
> > costs in a finer grained manner. I'd like to hear clarification on what
> > costs the new proposed limits will address.
>
> I don't believe that the proposal improves the situation enough (or at
> all) to justify the additional complexity.  That's something that you
> need to assess for yourself.  This proposal provides more granular
> control, but it doesn't address the core problem, which is that you
> and I can only observe each other actions after some delay, which
> means that we can't coordinate those actions perfectly.  Nor can be
> build a perfect model of the other upon which to observe and act upon.
>  The usual protocol issue.
>

OK then. My proposal is to add a new limit for PUSH_PROMISE frames though,
separately from the MAX_CONCURRENT_STREAMS limit, since PUSH_PROMISE exists
as a promise to create a stream, explicitly so we don't have to count it
toward the existing MAX_CONCURRENT_STREAMS limit (I searched the spec and
this seems to be inadequately specced). Roberto and I discussed that before
and may have written an email somewhere in spdy-dev@, but I don't think
we've ever raised it here.