IETF Logo Mail Archive

Re: Unidirectional streams PR

Martin Thomson <martin.thomson@gmail.com> Fri, 07 July 2017 02:05 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811EC131537 for <quic@ietfa.amsl.com>; Thu, 6 Jul 2017 19:05:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tEcodrBatZ4N for <quic@ietfa.amsl.com>; Thu, 6 Jul 2017 19:05:01 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D706129B17 for <quic@ietf.org>; Thu, 6 Jul 2017 19:05:01 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id 188so879263itx.0 for <quic@ietf.org>; Thu, 06 Jul 2017 19:05:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ee5glioYRs5C6TmqxKQj92c4rh7P4eDVfHMLb0AQCts=; b=nRcdCnTps+67Yxdj1vEVfmc3GqVjZVz1R/MF5KZOHQFSfC4CuAG9wuKCj7dJoJRvUS sTOK9SKJs3rGwJ0jCOzUPiTinGZbkGBcbWy2HVsj217ZrsTmyhv16cHaqtMWPx2hriUe GAmlE74jxYwn5Nsb7mpadHY21FCvY4pg4rQjOYz2vNVfspHSAhlahzIoXNFFxjXBGPjH zFbrWL94PKA6Cdek7JPN1U3xNWkfixZB79gnzQ/nbD0UQvXfrFyHUjlH/j+Md7C/f29j +oq94fwF8zdl7x/j3t4vRJb2MjGwz0lzCNljY3klOKfB19pjIF8kdNW2scl1zQoZOfWD IVeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ee5glioYRs5C6TmqxKQj92c4rh7P4eDVfHMLb0AQCts=; b=bEuUPA4V2XDMzE72LMUzmB+xXrRjqDnPorsgygDjJoVpilrae4nNVfZoP/V3zhWd09 fqhJqDl0Efqrjx1fyQ0ShfiA5z1JDSNMIQew6OqTUhbgJKtDwL54nMACoPVL57Xe1F64 quXg0/siu5v00LAhX4yE8CIva/wyJIGjx98pRWjH8ww3oqwHiXZIgi85lAPo4d+PYVXO liKBX5IXrmt5JYMgLpLq+nfkHlnm9VdKAPxTZ4Kw5aJJhtOlC9jEwl6pP7SSkX1fNvtO Mg8SO5pK1s5ECZCktluc5ddAPaNtoiuLgxpzUhPyF0Zsv+EJg2mxrL0F4KK8XyH7sxdi hIQA==
X-Gm-Message-State: AIVw112plHeUqJQwQQGFluU0zzvuwhCjBi4y+cQDz8PLzkqvzAQ8c4c6 TQghowxbfIdeSTZa2w1BgQDW3a33xHJc
X-Received: by 10.36.125.81 with SMTP id b78mr806715itc.26.1499393100525; Thu, 06 Jul 2017 19:05:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.129.162 with HTTP; Thu, 6 Jul 2017 19:04:59 -0700 (PDT)
In-Reply-To: <CANatvzw6VGMH8tJbhCxmgTR8_uuxtodiwS2-LT6XkyuBHJz+Fg@mail.gmail.com>
References: <CABkgnnW+veDVq27v+wTz0cA=eGPRTLQ1A90A0ynHLPU88Pg77Q@mail.gmail.com> <CANatvzzN6sQ2Pqb4jkQyZAY-KUYDb_J2sbW=K0zrQ0LCTJ2NVw@mail.gmail.com> <CABkgnnV9JzZG6HY_y_pxSRSUwX3ocxv7L0UCaiuaJs1sMfPWcg@mail.gmail.com> <CANatvzw6VGMH8tJbhCxmgTR8_uuxtodiwS2-LT6XkyuBHJz+Fg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 07 Jul 2017 12:04:59 +1000
Message-ID: <CABkgnnUUd4B4HLzAb1OVVtG3KdNuyH3Cz+4GuyX-AqH5c26L6w@mail.gmail.com>
Subject: Re: Unidirectional streams PR
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Wo2NVojRwubCM6xnKf3feMlRS_s>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jul 2017 02:05:02 -0000

On 7 July 2017 at 11:43, Kazuho Oku <kazuhooku@gmail.com> wrote:
> So it would be sensible to stop initiating new requests on an existing
> connection when the number of unused stream IDs of the peer becomes as
> low as max-concurrent-streams multiplied by some safety factor
> (something like 10 would be enough, considering the probability of
> loss or reordering of packets carrying DATA frames and consecutive
> MAX_STREAM_ID frames).

Yeah, you have to allow for the possibility of the server wanting to
push some number of times in response to each of your requests.  I was
originally going to say that you hit the wall only once you
MAX_STREAM_ID hits the limit, but the server can always promise in
excess of this limit.  If you want those promises to be resolved, then
allowing more space is reasonable.  10 sounds reasonable, but we can't
know the distribution of pushes to requests (today it is close to 0 in
the aggregate, but this could change).

v2.23.0 | Report a Bug | By Email