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

William Chan (陈智昌) <willchan@chromium.org> Mon, 29 April 2013 17:41 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 3FDB721F9A8A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 10:41:55 -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 vQOP8ta56Xaj for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 10:41:50 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9913B21F9A8C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 29 Apr 2013 10:41:49 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UWs4d-0004ul-Gg for ietf-http-wg-dist@listhub.w3.org; Mon, 29 Apr 2013 17:41:11 +0000
Resent-Date: Mon, 29 Apr 2013 17:41:11 +0000
Resent-Message-Id: <E1UWs4d-0004ul-Gg@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 1UWs4X-0004tp-O0 for ietf-http-wg@listhub.w3.org; Mon, 29 Apr 2013 17:41:05 +0000
Received: from mail-qa0-f49.google.com ([209.85.216.49]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UWs4W-0006B1-Op for ietf-http-wg@w3.org; Mon, 29 Apr 2013 17:41:05 +0000
Received: by mail-qa0-f49.google.com with SMTP id bs12so1166907qab.15 for <ietf-http-wg@w3.org>; Mon, 29 Apr 2013 10:40:39 -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=yvoMEyYRESiGFB4hdaxF67AOZOiutmMPonxSg+7yF+I=; b=L2tnDyekSVuhRRyQs+cstqAuKsP812v1h3+rN3CVx2zsEoCH29oUoRyr4WP2vUXLwZ SM/rpAi9zCHeu2TKUmFz54Otnn9srwGa/6RXq8WOBrY9pn3NKsGP3zIgho2clhRyszFN uscKbFvYPNbaZmbv6qsBZYh/LxfBvkJZTEe/9n2AQTu6NXeybpDPr5ZB2XbJWmH2/9Ir d7yaiYcde3A+FXzaZ6azRxxUksqwGWDvmpMGmKDos9iVpCxyXA71DjKN1YNlWijDJoIt tOzzfQtpoSFH22y/Fqqt85rl3iDrEvhlx45u71thFuQmko2BPSSfJOVzNGJjbUkpssGL c7bA==
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=yvoMEyYRESiGFB4hdaxF67AOZOiutmMPonxSg+7yF+I=; b=gEmmtlmQWNUfEsLoi9QQMWpfi8CrxOhl3jHmzWNyyBV7Hu8vFZTy0mgsPzKLvwDXTj HEkKfn8xulyZHArVb9ylARfyUwxjkV9kvmOUBse+bkTTm/3wgFGiNlmDDkeBfg5P545p mrpJkm8Je5Nuwz2wiuzSTSSPqE5AruvfAQeeo=
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=yvoMEyYRESiGFB4hdaxF67AOZOiutmMPonxSg+7yF+I=; b=T01FmHsBaxpRV0CSq6HHi/hzYH39TyeL82WyxaG2l4swymJPBt9t2SQOl53enxJg6B etI4409MvSt31NmobrY/N846ZnNp4mt2LFGRcedLfo31capPl37lQbJt6eo+16cC1eh2 +JCX5dzipnCabVyuV9cjjxnJ9tIlFRAARKQ2AryFBXqNtRCgNkEDR0/Wn6BHCZ3FUPgm IETOWljTwEAvSCtVQsGhWdoVhwv4IR5odKYg+bY1YNx1o4nJrDEX1bZ2/vsGNEzFpgjs UVHV94JrmcBtQFU0yWCnDHHuVuCqP+Z2GQuzpk73oNwsZnSoF5nBGMSDblQNnAMBNFTE R9fA==
MIME-Version: 1.0
X-Received: by 10.224.199.199 with SMTP id et7mr6868511qab.31.1367257239045; Mon, 29 Apr 2013 10:40:39 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Mon, 29 Apr 2013 10:40:38 -0700 (PDT)
In-Reply-To: <CABP7RbdBe-Xkx+CMvpN=_oNAqm6SyLyL+XNHRUKSqn8mjSDw1Q@mail.gmail.com>
References: <CABP7RbdBe-Xkx+CMvpN=_oNAqm6SyLyL+XNHRUKSqn8mjSDw1Q@mail.gmail.com>
Date: Mon, 29 Apr 2013 14:40:38 -0300
X-Google-Sender-Auth: hFj754v9klpOh5HsSxiPbuBxvyI
Message-ID: <CAA4WUYgCiyWerT0tUUVKcbNPqdTGuXHd_MG59DjcUsEWst5t7g@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: James M Snell <jasnell@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=20cf300fb3e30cd8c804db836219
X-Gm-Message-State: ALoCoQmSFMOeVhKZsKMMOy7WYwwbQ3MDiqTFxCK9fDR6yujuPp9mX8+2E7F2xj2AnQLzpvgZmvhku3NPAtTGc1KOTzJdty5pkoVPZo5AV7hCtydHoN80PnilYhz9LAre4lf422eTVbEOoUFK5jUaLtfoAsBtWyXi+vhRkfACp2CuuJt2uU2VqJKMQp6Bbcii0YK2EPbLPqjh
Received-SPF: pass client-ip=209.85.216.49; envelope-from=willchan@google.com; helo=mail-qa0-f49.google.com
X-W3C-Hub-Spam-Status: No, score=-4.7
X-W3C-Hub-Spam-Report: AWL=-1.498, 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 1UWs4W-0006B1-Op 6b2cf266a634822114bbe7edb014c218
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/CAA4WUYgCiyWerT0tUUVKcbNPqdTGuXHd_MG59DjcUsEWst5t7g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17664
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>

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
* 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).
* 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)?

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.


On Thu, Apr 25, 2013 at 2:50 PM, James M Snell <jasnell@gmail.com>; wrote:

> https://github.com/http2/http2-spec/issues/78
>
> In the current draft (-02), we state that:
>
> A. Any endpoint can initiate and half-close a fully unidirectional
> stream that does not require any action or acknowledgement from the
> receiving peer. Once half-closed, these remain in a constant
> half-closed state with the receiving peer having the option of sending
> frames for that stream at any time for the full duration of the
> session.
>
> B. An endpoint MUST NOT exceed the maximum concurrent streams limit
> set by it's peer and that streams initiated by the endpoint that are
> half-closed in any direction count towards this limit.
>
> C. Unless I missed it somewhere, clients are never required to
> half-close PUSH_PROMISE streams.
>
> The potential problem here is simple:
>
> If a client sets a limit of 4 concurrent streams, and the server
> initiates 4 separate PUSH_PROMISE streams that the server half-closes
> but that are never half-closed by the client, the server will not be
> able to initiate new push streams for the duration of the session.
>
>