[quicwg/base-drafts] HTTP/3 has less concurrency than HTTP/2 (#2787)

Kazuho Oku <notifications@github.com> Thu, 13 June 2019 02:42 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 []) by ietfa.amsl.com (Postfix) with ESMTP id CF8D1120178 for <quic-issues@ietfa.amsl.com>; Wed, 12 Jun 2019 19:42:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.008
X-Spam-Status: No, score=-8.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8EOqPv2TOc3B for <quic-issues@ietfa.amsl.com>; Wed, 12 Jun 2019 19:42:40 -0700 (PDT)
Received: from out-15.smtp.github.com (out-15.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC61120177 for <quic-issues@ietf.org>; Wed, 12 Jun 2019 19:42:40 -0700 (PDT)
Date: Wed, 12 Jun 2019 19:42:39 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1560393759; bh=3/cyPY8uaS5brTf56ZxxGgj6LBol/y3/rP9t0hDpdV0=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=SG4SXbsTRiZw1povLQgXsYFHY6ttpeqR2oEKuGamD+uy+bSWtM3w/mdeIkF6lu2Se EabByvt+6WdkrlQYywAQP55vClVmi1XWg+HhspuAX9lhzb5hHuBcOCsNnnbDuWzVsz 6ow2uditqnCjND2ku/Pesk/I5gOU9wkl2zitBOZg=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYKM5L7A277G24A6JF3B3VJ7EVBNHHBWJUB5A@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2787@github.com>
Subject: [quicwg/base-drafts] HTTP/3 has less concurrency than HTTP/2 (#2787)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d01b81f94374_289f3fa5f7ecd95c60113c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/3v9ZJ7PNaronaUHM1NvbaCFKoaw>
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, 13 Jun 2019 02:42:43 -0000

At the moment, we state that "It is RECOMMENDED that initial_max_bidi_streams be no smaller than 100, so as to not unnecessarily limit parallelism."

This means that there is a reduction in parallelism compared to HTTP/2 that allows 100 concurrent requests, due to the following reasons:
1. unlike HTTP/2, a QUIC server is likely to consider a stream to be existing until receiving an ACK for the stream-level FIN that it has sent
2. even after the stream state is discarded (when receiving an ACK for FIN), a server might not immediately send a MAX_STREAMS frame to indicate the client can open new streams

IIUC, one of the primary reasons we want parallelism is to fulfill the bandwidth of a high latency connection even when the size of the HTTP responses are small<sup>2</sup>.

The differences pointed out above means that in such a scenario (where the responses are small, e.g. 304), the concurrency could go down from 100 requests per RTT to 50, because the minimal latency of retiring a stream state changes from 1 RTT to 2 RTT (see point 1 above).

I think we should provide some better guidance, assuming that we consider "100" that we have in HTTP/2 as a good advice.

One way would be to change the recommended minimum of initial_max_bidi_streams to 200. The other way would be to recommend servers providing clients "window to issue 100 requests in parallel," without giving them concrete suggestion on how, because the way the QUIC servers retain stream-level states and how they send MAX_STREAMS can be different.

2: The other reason is to provide sufficient amount of window for prioritization.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: