Re: [quicwg/base-drafts] HTTP/3 unidirectional streams arms race (#2559)

Lucas Pardue <notifications@github.com> Wed, 27 March 2019 03:53 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 E1E10120328 for <quic-issues@ietfa.amsl.com>; Tue, 26 Mar 2019 20:53:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.002
X-Spam-Level:
X-Spam-Status: No, score=-8.002 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, RCVD_IN_MSPIKE_H2=-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 gxBIyIvsEl-v for <quic-issues@ietfa.amsl.com>; Tue, 26 Mar 2019 20:53:22 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE32120222 for <quic-issues@ietf.org>; Tue, 26 Mar 2019 20:53:20 -0700 (PDT)
Date: Tue, 26 Mar 2019 20:53:19 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1553658799; bh=SI4dD8y6wf0BZgu1f18wrdYhOyPUgxwsScPYc1uMHw0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=0/CpJY8mQ99/bU/YlPzmNeZVf2pg40wPCsf64PlQ640SkmB5TASA84/2Ns3GD9VRM PVlcEBnpPii6cgYuIH05qy1qAM/168deEAlw5az/WUcg2ejopdrW8hxn5NtUQG4/tx PHRREZaO+W1owHielSF0OJOF0+PXRzmMBFDq+eIo=
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abfda88f10c280e58b137b708e672a8f30c7e52eba92cf0000000118b2b5af92a169ce196054ab@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2559/476961392@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2559@github.com>
References: <quicwg/base-drafts/issues/2559@github.com>
Subject: Re: [quicwg/base-drafts] HTTP/3 unidirectional streams arms race (#2559)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c9af3af4d3c1_3a5b3f7ef0ad45b81426c3"; 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/LMoYQzvfeR8GHcfngukrbt1YrHo>
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: Wed, 27 Mar 2019 03:53:25 -0000

> So having one extra round-trip when opening one greasing stream sounds not unreasonable.

I'm ok with that but it also risks affecting all unidirectional stream types. Server push somewhat skirts the issue by providing a signal (counting PUSH_PROMISEs) that enhances the clients knowledge. QPACK is part way there because non-zero SETTINGS_QPACK_MAX_TABLE_CAPACITY implies that some credit from both ends is required. 

Perhaps we could summarise some guidance for people about the RTT incurred by these streams and ways to avoid them.

A totally different alternative that might turn out in practice easier is to simply set max_initial_uni_streams to a very large number, and set the initial_max_stream_data_uni to a low number (8 bytes would be enough to peak at the stream type). This way the client has far more insight into what the other side is attempting to do and can exercise stream control as suited to its needs. All while avoiding this weird cycle.

-- 
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/issues/2559#issuecomment-476961392