Re: [quicwg/base-drafts] Talk about concurrency in H3 vs. H2 (#3114)

Lucas Pardue <notifications@github.com> Fri, 18 October 2019 18:41 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B951208C0 for <quic-issues@ietfa.amsl.com>; Fri, 18 Oct 2019 11:41:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
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 YyqVOfUEC1we for <quic-issues@ietfa.amsl.com>; Fri, 18 Oct 2019 11:41:03 -0700 (PDT)
Received: from out-18.smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1B8120811 for <quic-issues@ietf.org>; Fri, 18 Oct 2019 11:41:03 -0700 (PDT)
Received: from github-lowworker-cd7bc13.ac4-iad.github.net (github-lowworker-cd7bc13.ac4-iad.github.net [10.52.25.102]) by smtp.github.com (Postfix) with ESMTP id 7B1576E1478 for <quic-issues@ietf.org>; Fri, 18 Oct 2019 11:41:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571424062; bh=hJtRtZf23ATFdJ7gWVs8J1WpB3J89cVpsa+PqItoySo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=PlkoZU1fMKPcFtDh6jz+rzM/pCdaBfwtGrEFOOJVgbDmOQ5OElGl/R2G6aprPssuD 6mOpcrRDGsxXe3YIhu35IAWJskWia06T6IKoooIf/u/kHKVJypEXlY+y/4gLg052D7 eLpZsePBeszasZpshEdjM8XenFanCmMzgplmHhFU=
Date: Fri, 18 Oct 2019 11:41:02 -0700
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6DJ6VSSYOFQBUJT3V3W5D45EVBNHHB4UJDX4@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3114/review/304071242@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3114@github.com>
References: <quicwg/base-drafts/pull/3114@github.com>
Subject: Re: [quicwg/base-drafts] Talk about concurrency in H3 vs. H2 (#3114)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5daa073e6b06b_2dd63f937a8cd96026561"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/IwbF1vSQBnuMsq5rUM8yBm1BS6Q>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Oct 2019 18:41:06 -0000

LPardue commented on this pull request.



> @@ -1814,6 +1814,22 @@ considerations about exhaustion of stream identifier space apply, though the
 space is significantly larger such that it is likely that other limits in QUIC
 are reached first, such as the limit on the connection flow control window.
 
+In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by QUIC.  QUIC
+considers a stream closed when all data has been received and sent data has been
+acknowledged by the peer.  HTTP/2 considers a stream closed when the frame
+containing the END_STREAM bit has been committed to the transport. As a result,
+the stream for an equivalent exchange will typically remain "active" for one
+additional round trip.  HTTP/3 servers might choose to permit a larger number of
+concurrent client-initiated bidirectional streams to achieve equivalent
+concurrency than were permitted in HTTP/2, depending on the expected usage
+patterns.
+
+Due to the presence of other unidirectional stream types, HTTP/3 does not rely
+exclusively on the number of concurrent unidirectional streams to control the
+number of concurrent pushes received by a client.  Instead, HTTP/3 clients use

```suggestion
number of concurrent in-flight pushes.  Instead, HTTP/3 clients use
```

Avoid the rabbit whole of received by client or sent by server.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3114#pullrequestreview-304071242