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

Lucas Pardue <notifications@github.com> Thu, 17 October 2019 18:24 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 70FE2120BAF for <quic-issues@ietfa.amsl.com>; Thu, 17 Oct 2019 11:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 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_IMAGE_ONLY_32=0.001, 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 5Qcif4yna8m2 for <quic-issues@ietfa.amsl.com>; Thu, 17 Oct 2019 11:24:44 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A26120BCC for <quic-issues@ietf.org>; Thu, 17 Oct 2019 11:24:24 -0700 (PDT)
Date: Thu, 17 Oct 2019 11:24:23 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571336663; bh=qPdEL3vqzPajLEZxmRwKPpZ9N6CQV1Yq/tVQa1DnXT8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ShjuLl5tk+1WKxxpeweuf6n8JVg3etiUb4rZA4vgXDf2+7qQVNDFyHeCkPAgD+emo SwYPzG23WZKjLiVQ6SG8PPf/Sc0roJCp7PuBMAeVXypnbOni4URCydu+aZIdjspXiE DFxGZPDVQb43Y1p4Y0xBE3Y0QSYsxbxXXp2CQxZ4=
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4ZM6ZJ6EXTKVFM2FF3WXZGPEVBNHHB4UJDX4@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/303456374@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_5da8b1d78003a_64fc3fbc1cecd96c54412"; 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/wrUyGCTCQk6qnWJUZ61T4zG9ndc>
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: Thu, 17 Oct 2019 18:24:48 -0000

LPardue commented on this pull request.



> +QUIC manages stream concurrency on behalf of HTTP/3.  QUIC considers a stream
+closed when all sent data and all acknowledgements for received data have 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 remain "active" for at least one
+additional round trip.  Implementations of HTTP/3 might choose to permit a
+larger number of concurrent streams than in HTTP/2 to achieve equivalent
+concurrency, depending on the expected usage patterns.

This looks good but if you're gonna pop the bonnet to fix something, I think we probably want to talk about the concurrency of request and push streams separately.  

The text here is more focused on describing the behaviour of request streams. So I would be more specific and say that a HTTP/3 server might choose to permit a larger number of concurrent client-initiated bidirectional streams. 

Then I would discuss considerations for push concurrency, highlighting the additional controls in the shape of push ID but identifying that push stream concurrency is competing against other unidirectional stream type (core or extensions) for the server-initiated unidirectional stream space.

-- 
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-303456374