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 1DBB7120158
 for <quic-issues@ietfa.amsl.com>; Tue, 26 Mar 2019 20:26:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Level: 
X-Spam-Status: No, score=-8.001 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,
 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 QjCK0vc3nUcb for <quic-issues@ietfa.amsl.com>;
 Tue, 26 Mar 2019 20:26:19 -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 0712C120132
 for <quic-issues@ietf.org>; Tue, 26 Mar 2019 20:26:19 -0700 (PDT)
Date: Tue, 26 Mar 2019 20:26:17 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com;
 s=pf2014; t=1553657177;
 bh=/KR8IAvm81WzecwYuC89TwHo1QS08+ygrFl9n4cQLr0=;
 h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID:
 List-Archive:List-Post:List-Unsubscribe:From;
 b=NHLaGHGkNH9zA/JqgWwBmiKq6tgRHNsHvRZUj9obmvgZgbLfViyygBwiPVDyL2r8l
 hkjtHAY6TyEDWnDEkXKo2iCqWSFyEPkpTpzDlRkWYWYwP+vjl7IU0Qs13tFso2/tPU
 JlQevkXpWXpLRJx9G7/xIoMfMfDodyz8HYLDRm74=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab83aa1ae9285cc9fc597993700d0535f431f298fe92cf0000000118b2af5992a169ce196054ab@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/476955236@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_5c9aed598dd42_2b893fa6bded45c411396c";
 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/73OUc3qG_JLyLvte-JKw9rg8AlI>
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:26:21 -0000


----==_mimepart_5c9aed598dd42_2b893fa6bded45c411396c
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

> c) will this just devolve to a cycle of one endpoint sending STREAMS_BLOCKED and the other echoing back MAX_STREAMS (value +1) until the other side shuts up?

It seems to me that this is the worst case, and that if we think it's fine then every other questions can be considered fine.

My position is that having this worst case is fine.

Many types of greasing (e.g., version negotiation, retry, HelloRetryRequest) introduces one extra roundtrip. So having one extra round-trip when opening one greasing stream sounds not unreasonable.

-- 
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-476955236
----==_mimepart_5c9aed598dd42_2b893fa6bded45c411396c
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<blockquote>
<p>c) will this just devolve to a cycle of one endpoint sending STREAMS_B=
LOCKED and the other echoing back MAX_STREAMS (value +1) until the other =
side shuts up?</p>
</blockquote>
<p>It seems to me that this is the worst case, and that if we think it's =
fine then every other questions can be considered fine.</p>
<p>My position is that having this worst case is fine.</p>
<p>Many types of greasing (e.g., version negotiation, retry, HelloRetryRe=
quest) introduces one extra roundtrip. So having one extra round-trip whe=
n opening one greasing stream sounds not unreasonable.</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m=
dash;<br />You are receiving this because you are subscribed to this thre=
ad.<br />Reply to this email directly, <a href=3D"https://github.com/quic=
wg/base-drafts/issues/2559#issuecomment-476955236">view it on GitHub</a>,=
 or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkq33o=
sCJH3Tmkh_V2Ho1XjCej_yySks5vauTZgaJpZM4cM3dJ">mute the thread</a>.<img sr=
c=3D"https://github.com/notifications/beacon/AWbkq_BM3JTVEDcgW2SLe1UhYSqp=
lmQBks5vauTZgaJpZM4cM3dJ.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_versio=
n":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name"=
:"GitHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"=
quicwg/base-drafts","subtitle":"GitHub repository","main_image_url":"http=
s://github.githubassets.com/images/email/message_cards/header.png","avata=
r_image_url":"https://github.githubassets.com/images/email/message_cards/=
avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/q=
uicwg/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@=
kazuho in #2559: \u003e c) will this just devolve to a cycle of one endpo=
int sending STREAMS_BLOCKED and the other echoing back MAX_STREAMS (value=
 +1) until the other side shuts up?\r\n\r\nIt seems to me that this is th=
e worst case, and that if we think it's fine then every other questions c=
an be considered fine.\r\n\r\nMy position is that having this worst case =
is fine.\r\n\r\nMany types of greasing (e.g., version negotiation, retry,=
 HelloRetryRequest) introduces one extra roundtrip. So having one extra r=
ound-trip when opening one greasing stream sounds not unreasonable."}],"a=
ction":{"name":"View Issue","url":"https://github.com/quicwg/base-drafts/=
issues/2559#issuecomment-476955236"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/issues/2559#issuecomment=
-476955236",
"url": "https://github.com/quicwg/base-drafts/issues/2559#issuecomment-47=
6955236",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5c9aed598dd42_2b893fa6bded45c411396c--

