[QUIC] Why not be explicit about Stream 3 flow control exception?

"Aron ." <aron.schats@gmail.com> Mon, 14 November 2016 20:45 UTC

Return-Path: <aron.schats@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 EAEA0129449 for <quic@ietfa.amsl.com>; Mon, 14 Nov 2016 12:45:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=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 rWfr1xg4AIX2 for <quic@ietfa.amsl.com>; Mon, 14 Nov 2016 12:45:15 -0800 (PST)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 C2A18129606 for <quic@ietf.org>; Mon, 14 Nov 2016 12:45:15 -0800 (PST)
Received: by mail-it0-x230.google.com with SMTP id q124so22788395itd.1 for <quic@ietf.org>; Mon, 14 Nov 2016 12:45:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=iwQlFWZcUlATdGvWTANc0Gis028io7vh4m3ocEEOKuE=; b=eBXGyUx/CP7nUlYHccrJ4W/ghEPTE1PdvZouYPYbCwVpBjuEi7hrylqHtKRBj92csx uVySiG2bNt9DTRTsTeZ0kJrJi7/6oVCyq5g/oUoSUj0+XsmmmEPjb366PkxP51rPPGPh UShor18d2pyYwVMKLY2NfrH5KEChs43S4sGY5rhD/qzaXxmeTHuZCdgrfFigQAZvd0EQ LXYWYg/6oQsegprtu0wuUCBsf8A+JoCOFG1fzmbhZLpRuuyppZiGEvQU61tlvWtb0L8u GXGRucphXaGvXYpWqNZPVFgdNbIWBUUjuijEtdd95yIaJd0CAV/qDDXRFookgTCmi/4o jpiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=iwQlFWZcUlATdGvWTANc0Gis028io7vh4m3ocEEOKuE=; b=CREfmMUi9Aa0dbZsfTLMuDvWmJxSsCmxDiYevYg22LrCAOCBRAmBFYd2MpNAkV2fus h5ROYTD5x20xHIBPrCEk341O9VKKnAaf6Ym5O+IlY9tSPVKT88BSLLw47ZX/XFKf99Gt atqY7o+sRZ0NRcjvz9SmdtjuFj81JO1Ip2QZgMXolGX6h1cFS3X3leoQ9g8CQYGPGbuk olIBloWn+0ZgV3SAyQLt8aHM/k1iJTeJ2qm00dPlOaJIFnJ4DpcYmiqeLJLtMDZj+hy1 xbGxO7jRYfK1ICiP6FNOVTvIulcYBeV+gMSwuMWaMJwsHWLD/lqILdgbjX8giEWXgWoQ TtYw==
X-Gm-Message-State: ABUngvdGDq1bZB4x56iUnxmRotbFfYg3rcuXyM3OGcESs4WTK1g44lkjpwFGsNgwf7diEDyn0ksGxu1t7ccCLg==
X-Received: by 10.107.165.139 with SMTP id o133mr22111694ioe.42.1479156314937; Mon, 14 Nov 2016 12:45:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.125.138 with HTTP; Mon, 14 Nov 2016 12:45:14 -0800 (PST)
From: "Aron ." <aron.schats@gmail.com>
Date: Mon, 14 Nov 2016 15:45:14 -0500
Message-ID: <CAGudDpPfgQCWKXVv0v2B2MT8kkPnis2monE1ZGWRfHjyd_Tqmg@mail.gmail.com>
To: quic@ietf.org
Content-Type: multipart/alternative; boundary="001a1141f18cb81f8a054148eae8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/icWaG2epy7-Mii0Q5f5WvAr_Jj0>
Subject: [QUIC] Why not be explicit about Stream 3 flow control exception?
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 14 Nov 2016 20:45:17 -0000

Hello,

[draft-hamilton-quic-transport-protocol-01] states (p. 35):

o The crypto handshake stream, Stream 1, MUST NOT be subject to
congestion control or connection-level flow control, but MUST be
subject to stream-level flow control.
o An application MAY exclude specific stream IDs from connection-level
flow control. If so, these streams MUST NOT be subject to
connection-level flow control.

The second bullet point is obviously about Stream 3.  Seeing that there is
no way(?) to negotiate which streams are to be excluded, why not spell out
that Streams 1 and 3 are not subject to connection-level congestion control?

  Aron.