IETF Logo Mail Archive

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

Mike Bishop <Michael.Bishop@microsoft.com> Tue, 29 November 2016 23:08 UTC

Return-Path: <Michael.Bishop@microsoft.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 CEB62124281 for <quic@ietfa.amsl.com>; Tue, 29 Nov 2016 15:08:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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=microsoft.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 F9sC5rnDMJ_t for <quic@ietfa.amsl.com>; Tue, 29 Nov 2016 15:08:18 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0132.outbound.protection.outlook.com [104.47.38.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6439129CC0 for <quic@ietf.org>; Tue, 29 Nov 2016 15:08:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+BsbD+aN/+Y/vWlOYGhclVEVeQOq3adyQjnKJ2Tqe9M=; b=Snmz+BsvbD93sdWZjjGesXVpb7vGqPwrrUclDXLG8xoa4NGw6LUCaad802SgQ+Ix5gePa/c/Qw/HkmHVETSfiy9hU9hdmPcqSr6AJkyH/8ejUyOO1n8lIPDk8PWImscTRbL/ewXOomWxBb4HkUPGVLSt2qkqfCSyRa0CZOGSYyI=
Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Tue, 29 Nov 2016 23:08:15 +0000
Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0747.015; Tue, 29 Nov 2016 23:08:15 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: "Aron ." <aron.schats@gmail.com>, Jana Iyengar <jri@google.com>
Subject: RE: [QUIC] Why not be explicit about Stream 3 flow control exception?
Thread-Topic: [QUIC] Why not be explicit about Stream 3 flow control exception?
Thread-Index: AQHSPrgGfIvDjV/wrUKopO/WTiVcT6DwZA8AgAABlICAAEZPUA==
Date: Tue, 29 Nov 2016 23:08:15 +0000
Message-ID: <BN6PR03MB2708B678CB998FD85E8F070D878D0@BN6PR03MB2708.namprd03.prod.outlook.com>
References: <CAGudDpPfgQCWKXVv0v2B2MT8kkPnis2monE1ZGWRfHjyd_Tqmg@mail.gmail.com> <CAGD1bZYj3nTweFmBy4-XbvUkhhnqbwscb=q0HHtZkPrYrw0kVQ@mail.gmail.com> <CAGudDpMvccsPn7vJx9fM=hXgdCu93QUavzWZGMjE_0CrYK1cTQ@mail.gmail.com>
In-Reply-To: <CAGudDpMvccsPn7vJx9fM=hXgdCu93QUavzWZGMjE_0CrYK1cTQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com;
x-originating-ip: [2001:4898:80e8:2::d3]
x-ms-office365-filtering-correlation-id: 66de8df4-1c31-4aa1-b6b0-08d418ac99bd
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2705;
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:b2EJxiDaDQKC7rEgSLaBELUTH39ZVzhY/eIY5+fkzWkl32I/yg4FZirKbF0FElsFuUgM1DbAzemzJ5bpwWWJdpzuzxXorC8bs8IExFBFrp6XZ+h69VfB+AW792Xry7i5s2bhzQT9YF6kD2cLz8u1kG7gKiLyYh2wOc/Fjt4eAmgzEwvJ2kYnl8v2LmsEZUy+LDJ7Ya4kkAMSuhAulEfxfvFtxgV5dtMY7/bUTozUiJdSmuLk07OVPVamPlg9he0djOEMVAYkifUMNNSjXgWMdSRSjpWMLkXJFAFDQbeQs6KYCCjXOyXXyQOHubgVDnTuXlgGp0a39ec0ya9Hrn35jConmXyYSGSpCmB5pcMmQLPINU0v9xzunNubLDvIyT+DfC5wEzsoV6C1QinPwxsSGD8MfLQNRPuN8JjBfE70Zb3Mt0vcnWHZ9Rmij0EKQhYy1B424uwDZ3KBzXx+3HAtgnWGmcbMv3ke+Y5nqrY72HY=
x-microsoft-antispam-prvs: <BN6PR03MB270511063F617B1EE669E9B7878D0@BN6PR03MB2705.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558021)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148)(6047074)(6042181); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705;
x-forefront-prvs: 01415BB535
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(24454002)(377454003)(76576001)(105586002)(4326007)(5660300001)(8936002)(81156014)(106356001)(33656002)(9686002)(8676002)(92566002)(50986999)(68736007)(81166006)(189998001)(7696004)(97736004)(101416001)(54356999)(76176999)(99286002)(19609705001)(2950100002)(2906002)(86612001)(5005710100001)(10090500001)(10290500002)(5001770100001)(606004)(122556002)(790700001)(6506003)(86362001)(8990500004)(2900100001)(7736002)(3280700002)(77096006)(74316002)(38730400001)(106116001)(39060400001)(102836003)(3660700001)(229853002)(6116002)(7846002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708B678CB998FD85E8F070D878D0BN6PR03MB2708namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2016 23:08:15.7089 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/GFgSa_ZamVQANtdtZt4mFONphcI>
Cc: IETF QUIC WG <quic@ietf.org>
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: Tue, 29 Nov 2016 23:08:25 -0000

Protocol negotiation (like many areas) needs to be ironed out.  I see some obvious paths here:

  *   Use ALPN in the TLS handshake
     *   Implies a general requirement on the crypto handshake to support app-layer protocol agreement
  *   Use port numbers, like TCP/UDP already do
     *   QUIC is a new transport that shares the UDP port space; same rules for interpreting incoming messages can apply

I tend toward a combination of the two, since we’ve already seen HTTP/2 get into the pickle that I still need to do version negotiation even once I know it’s some flavor of HTTP.

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Aron .
Sent: Tuesday, November 29, 2016 10:51 AM
To: Jana Iyengar <jri@google.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: [QUIC] Why not be explicit about Stream 3 flow control exception?

This is interesting.  Is there a way for QUIC peer to tell which protocol over QUIC is used?  In other words, at which point do I realize that it's not HTTP/QUIC I am talking to?  Is it for upper-level code to figure out?

On Tue, Nov 29, 2016 at 1:45 PM, Jana Iyengar <jri@google.com<mailto:jri@google.com>> wrote:
Hi Aron,

Apologies for getting to this late -- the IETF kept me busy.

[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?

The second bullet point is about any application-chosen stream. An application may choose to not exempt any stream if there are no special streams.

This need not be negotiated on the wire, but can be known for any given application. Specifically, the http-mapping draft is the document which, in the current design, should say that stream 3 should be excluded from connection-level flow control.

- jana

v2.23.0 | Report a Bug | By Email