Re: Unidirectional streams PR

Kazuho Oku <kazuhooku@gmail.com> Fri, 07 July 2017 01:43 UTC

Return-Path: <kazuhooku@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 5F19112F3D5 for <quic@ietfa.amsl.com>; Thu, 6 Jul 2017 18:43:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 Np9bYQwBYjOi for <quic@ietfa.amsl.com>; Thu, 6 Jul 2017 18:43:33 -0700 (PDT)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 06CEE129AFA for <quic@ietf.org>; Thu, 6 Jul 2017 18:43:33 -0700 (PDT)
Received: by mail-pf0-x234.google.com with SMTP id e7so9344820pfk.0 for <quic@ietf.org>; Thu, 06 Jul 2017 18:43:33 -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=cLdLsk+2vZpTnZZ6mIuzHS6ZNvCruA4jySBy4s2PDUc=; b=kiBDyUWtoZRE1XqPj4RRj4Z1QUE9ulOxIfj8qL/ofeZOJu+gv8r7gq1uab2+V2vcM9 IMeHHNg6tuj2VObhPK9lFBdXXUUtS6aCnY4ATOWQnd0rHyqIa6kf3F83rgxMnkMftz/J bzqW2/IVk/vRdvPomVTIvvWWrSM6VAdqokEXDMtf78OMI9cVp29C1husxUJyBOGXT8vx +e/jzH93OFH5SKSCJe13ccodj1X7QE9CeOzY/9htbr3Ca3LH3IJ8WSMQIpkGYyHIVgg2 LZDNmUaZWJ7ITRtXEE/Ae1jYI1c5ZRB86hsfyLlgY2rtMuqI1bdL7C1dE+SHiF/Mvzm1 4+Uw==
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=cLdLsk+2vZpTnZZ6mIuzHS6ZNvCruA4jySBy4s2PDUc=; b=FO7IQfFsxaEWd7QvAT0a2gCfXjkcvK+gCF6CfH0rcl13kuiMF68RDP1IWvfgV6ozes 7P0x6lZideAweL4+r5PDoTu/mNJ2wkNjNhwuYf5yKXStqkkxgWtoxFtkoX6NXgXaw+vN cV/nHc1l15JFFpma9dRRVHZQdWcDr3fK4DF8Gjsg12rkqK8fid/Zd1Qwoj14G1lFtXen x3fKYv3Xd8hzeePXYQ2VBzGadH7p4e6DfE+aQWOM1rZfbormzXZRfBKrLilEQKi/WU1W AJXNRb2myVZXZVxeVM3EWU+A8Oaed1Mfd9vmAnllWNNtgABQH7ZjT0RrEE6D7PLR1FDV GzJA==
X-Gm-Message-State: AIVw113fPM/jiRwd5Eaa5zj5h40qDQE1DbPntVqh5Jo6AfrpiSVi7oxo b4W1vveawszLte7AnRJ02qyqkIb0cw==
X-Received: by 10.84.231.197 with SMTP id g5mr144805pln.71.1499391812594; Thu, 06 Jul 2017 18:43:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.130.3 with HTTP; Thu, 6 Jul 2017 18:43:31 -0700 (PDT)
In-Reply-To: <CABkgnnV9JzZG6HY_y_pxSRSUwX3ocxv7L0UCaiuaJs1sMfPWcg@mail.gmail.com>
References: <CABkgnnW+veDVq27v+wTz0cA=eGPRTLQ1A90A0ynHLPU88Pg77Q@mail.gmail.com> <CANatvzzN6sQ2Pqb4jkQyZAY-KUYDb_J2sbW=K0zrQ0LCTJ2NVw@mail.gmail.com> <CABkgnnV9JzZG6HY_y_pxSRSUwX3ocxv7L0UCaiuaJs1sMfPWcg@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Fri, 07 Jul 2017 10:43:31 +0900
Message-ID: <CANatvzw6VGMH8tJbhCxmgTR8_uuxtodiwS2-LT6XkyuBHJz+Fg@mail.gmail.com>
Subject: Re: Unidirectional streams PR
To: Martin Thomson <martin.thomson@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/AvDNi8gVkbfZTzPielbcJ5EF_To>
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 01:43:34 -0000

2017-07-07 10:05 GMT+09:00 Martin Thomson <martin.thomson@gmail.com>:
> On 7 July 2017 at 10:57, Kazuho Oku <kazuhooku@gmail.com> wrote:
>> Could somebody clarify what a server is expected to do when there are
>> no more streams than can be used to send a response (i.e. when a
>> server has used all the Stream IDs up to 2^32-2 and then receives a
>> request)?
>
> I think that the only sensible approach is to give up on the
> connection before this point is reached.
>
> A client can't know exactly how many streams a server has open, so I
> think that the only sensible course of action is to initiate graceful
> shutdown whenever the endpoint might be inclined to MAX_STREAM_ID that
> is 2^32-1 or greater.
>
> (In the PR, the limit is 2^32-1.)

Thank you for the clarification.

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).

-- 
Kazuho Oku