Re: Unidirectional streams PR

Subodh Iyengar <subodh@fb.com> Fri, 30 June 2017 23:14 UTC

Return-Path: <prvs=83545874e9=subodh@fb.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 C54DB12EA5A for <quic@ietfa.amsl.com>; Fri, 30 Jun 2017 16:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=Ly03RlFQ; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=XssrXEeX
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 0Dy5D8lQvxfo for <quic@ietfa.amsl.com>; Fri, 30 Jun 2017 16:14:19 -0700 (PDT)
Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A777129B4C for <quic@ietf.org>; Fri, 30 Jun 2017 16:14:19 -0700 (PDT)
Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v5UNDrbT014595; Fri, 30 Jun 2017 16:14:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=PFrb+evWpCn3IiEm2f1OvZIHJTx5qsiHePOSrT8BTn0=; b=Ly03RlFQvFMJ9czhyihKzvum2H7WUWAaRP3EH8gU1dzVQjeZnvY7c0Hl4ZcARh32ipwq pybzX/kXQZISr79wF5Cr+lf9LAPo+eycZVqsLkimhHPR0/JmjEVDkJ0TlRsmKD4tW0hB khxy1ydM0/yJrMr8LtJjoITpiU+OJtpDgGU=
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2bdvs10tpn-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Jun 2017 16:14:07 -0700
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.23) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 30 Jun 2017 16:14:05 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PFrb+evWpCn3IiEm2f1OvZIHJTx5qsiHePOSrT8BTn0=; b=XssrXEeXcgzToBf7KQDkZSS8+xIPGhbCPu2JN6ixYJTKGzk3kWKsyeyL27WE11Q560EygVhm3LfT5PYoSxLl/PkAZTiG8mIC5R2YzUmRPRGyRJNPoLS+bW3IlLtxmj9GaTxpiwcBA94RP7zzNkWUKAANriEd0Jzel4NvOIjgtM4=
Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1453.namprd15.prod.outlook.com (10.173.234.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.15; Fri, 30 Jun 2017 23:14:03 +0000
Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.1220.015; Fri, 30 Jun 2017 23:14:02 +0000
From: Subodh Iyengar <subodh@fb.com>
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, "quic@ietf.org" <quic@ietf.org>, Christian Huitema <huitema@huitema.net>, Mike Bishop <Michael.Bishop@microsoft.com>
Subject: Re: Unidirectional streams PR
Thread-Topic: Unidirectional streams PR
Thread-Index: AQHS7K8qYA+OJNlgCk66zUVoUQGXHqI0Yv6AgATdKACAAP5zgIAAEIwAgAAHqgCAAA02gIAAfdKAgAARSACAAAzfAIAAEzGAgAD+vQCAAAZIgIAAHNIAgAAGBYCAAcjsJA==
Date: Fri, 30 Jun 2017 23:14:02 +0000
Message-ID: <DM5PR15MB14494D50B82F681CE0027483B6D30@DM5PR15MB1449.namprd15.prod.outlook.com>
References: <CAN1APdc_ckZu39ZZTETv04iZieogoE_NQCBR-n0jHrC-9dM7Aw@mail.gmail.com> <5d69489d-8f46-ebbe-4e5c-fa6c02ffd8dd@huitema.net> <CAF4GZgBm7525i2GxiN-Pv66g0WqbDH==fRXN27=7ursNA70w1Q@mail.gmail.com> <20170628124221.GA15608@ubuntu-dmitri> <CAN1APdc3YO4-FEc6C--PzFGxzQiAUeBZ96HkjtjS1RR0qigrzw@mail.gmail.com> <CAE=ybzNtSZx9-bj9-n-ieLMB=YvJCjCExugvA3_JPVrdEEqK9A@mail.gmail.com> <DB5PR07MB123748F2AB7374DAC0CC9E1484DD0@DB5PR07MB1237.eurprd07.prod.outlook.com> <MWHPR21MB0141BD23011EB26F882C864787DD0@MWHPR21MB0141.namprd21.prod.outlook.com> <CABkgnnXEq9-jxedU_Rmi4XQ+t0SNUOAMbyWXcnhyLKz+OzP2CQ@mail.gmail.com> <2240c2a68910453e97fc50d42e8a1d4f@usma1ex-dag1mb5.msg.corp.akamai.com> <CAKcm_gMb9PkBKhTRF3ue2KGgwHgKN8rsanD8rqqr_wUFJ3GNZQ@mail.gmail.com> <83e22460-8864-e6f7-546a-d0e77e4f8ae8@huitema.net> <MWHPR21MB0141DAB51088DE57504B12F087D20@MWHPR21MB0141.namprd21.prod.outlook.com> <176a76c7-bdcd-9007-1f26-e436f61076f3@huitema.net>, <CAN1APdcMn8ik_UFqBx7T7xPSrBpdYOD3oQgC_XRrdrz2ikFDFw@mail.gmail.com>
In-Reply-To: <CAN1APdcMn8ik_UFqBx7T7xPSrBpdYOD3oQgC_XRrdrz2ikFDFw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=fb.com;
x-originating-ip: [2620:10d:c090:180::1:8fdd]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1453; 20:aDvvTAGH3mQzpQqxwd2uOc72QjgnuX1mv6QT9/QOqGWMqZ6VxGZZkd+EX9alN93VsDDIewlg9rKwK3R6WQV/FGEyf3YzqOEigXC65MNOeBtTZIOAIxk07YfxWJVqvBGcLy2xKC/NYXdSUm847qqCMEg0fyOhAQ8dXeeWSi5SBX0=
x-ms-office365-filtering-correlation-id: 2bcedc5b-b8bf-4730-3915-08d4c00db243
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR15MB1453;
x-ms-traffictypediagnostic: MWHPR15MB1453:
x-microsoft-antispam-prvs: <MWHPR15MB1453FC593D32D7EE1E5D36F9B6D30@MWHPR15MB1453.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(133145235818549)(278428928389397)(236129657087228)(148574349560750)(247924648384137);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1453; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1453;
x-forefront-prvs: 0354B4BED2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39450400003)(39840400002)(24454002)(377454003)(81166006)(8936002)(25786009)(8676002)(1511001)(2900100001)(39060400002)(2561002)(50986999)(53546010)(54356999)(76176999)(3480700004)(38730400002)(102836003)(7736002)(2501003)(6116002)(2421001)(19627405001)(478600001)(2950100002)(33656002)(6436002)(77096006)(189998001)(53936002)(6246003)(14454004)(561944003)(8666007)(93886004)(229853002)(2906002)(236005)(5660300001)(99286003)(6506006)(74316002)(54896002)(3660700001)(6486002)(3280700002)(7116003)(6512007)(86362001)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1453; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR15MB14494D50B82F681CE0027483B6D30DM5PR15MB1449namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2017 23:14:02.2534 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1453
X-OriginatorOrg: fb.com
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-30_15:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/gIiJNIJrF8V03emWKSbCM0cYgZw>
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, 30 Jun 2017 23:14:22 -0000

I've read through both approaches and commented on both PR with concrete issues. I would like to voice some high level thoughts as well.

I believe the purpose of the unidirectional streams exercise is two-fold: maybe reduce complexity of transport, enable applications to have easier mappings.

I have implemented the stream state machine specified in the current draft and I have to stress this very much that no matter what state diagram we specify in the draft, the implementation of the state machine will not match 1:1, there are always hidden states. One such concrete example is when you reset a stream you might want to discard any incoming data vs if you're in half closed you would want to process and buffer it. This creates a new hidden state which is not captured in the state machine.

To me personally, the initial draw for pure unidirectionality (@Martin's proposal) was to reduce the number of states in the transport to make the transport easier to implement and not so much the easier mappings of applications. We're chartered to work on HTTP/2 first and that's my primary interest as well. It seems though that in HTTP/2 the vast majority of transactions are actually bidirectional, and it only needs unidirectional support for pushes. I think unidirectional streams doesn't add new functionality to HTTP/2.

However after looking at the proposals and the feedback, as a transport implementor I'm rethinking my initial draw towards purely unidirectional streams such that I might as well take up the burden to implement bi-directionality once so that the apps can be simpler.

That being said we need some concept of unidirectionality in the transport to support the push use case for HTTP/2. It is kind of awkward right now that we need to send a FIN from the client to close a push stream.

I'm not in favor of #656 because it adds more complexity to the state machine, however I'm more of a fan of @Ian's do nothing + app dictates a manual transition, since that allows us to keep the same state machine flow and let the app get undirectionality by explicitly having the app transition the stream state machine as needed. There are some cool things in @Martin's proposal that I would actually like to see back in the HTTP mapping with bidi streams like stream headers for pushed streams, however I'd rather prefer the do nothing + manually transition states with application coordination.

Subodh
________________________________
From: QUIC <quic-bounces@ietf.org> on behalf of Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Sent: Thursday, June 29, 2017 12:02:09 PM
To: quic@ietf.org; Christian Huitema; Mike Bishop
Subject: Re: Unidirectional streams PR

On 29 June 2017 at 20.40.50, Christian Huitema (huitema@huitema.net<mailto:huitema@huitema.net>) wrote:

I am looking at the "mixed" scenario, in which the client would open an unidirectional stream with an associated "stream N" in the other direction. Will we say that doing so automatically pushes the server's maximum stream ID to some value greater than N?

I believe the streams need to operate independently: having endpoint A open a unidirectional stream A/N that can be responded to by endpoint B necessarily requires that B has granted A a limit of at least the value A/N. If the stream A/N permits association by one or more streams B/M initiated by B, each of those streams necessarily must be at or below the limit granted by A but only once those streams are in fact opened. Endpoint A might never grant sufficient streams to enable B to respond. The identifiers B/M chosen by B are unknown to A.

Note that there is a problem with enforcing how many streams that can be associated with A/N because A/N might be closed and gone. Keeping state is problematic. On the other hand it is trivial to reject associations with streams that have not yet been opened, especially if streams are opened in strict order. Implicit opening of lower valued streams will not work, and is not needed.