IETF Logo Mail Archive

RE: Splitting transport and application error code spaces

Mike Bishop <Michael.Bishop@microsoft.com> Tue, 15 August 2017 06:52 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 B5DC41324AC for <quic@ietfa.amsl.com>; Mon, 14 Aug 2017 23:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level:
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZTf-1FLkrT6f for <quic@ietfa.amsl.com>; Mon, 14 Aug 2017 23:52:53 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0137.outbound.protection.outlook.com [104.47.42.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4F0124234 for <quic@ietf.org>; Mon, 14 Aug 2017 23:52:53 -0700 (PDT)
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=syKnQMe4OTOVfEveQXbRSEmKCuSoLtfDKtd3twRYXZ4=; b=k28Abb0B0DWe4RlQ8HnUBz337S3EdUpPgYDBybBD5xA0pCFd52deTJ962UCoA+Xxuy1VC/FPMBgSlk49A0PxmKCeQn5uLtD1jiuKIfzUfu9sNRPhMA3UviA6ePnwVw3DCeqyimddnE1Vn/huxReIV+ANnMqIbaiPholAFhYNuN4=
Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0510.namprd21.prod.outlook.com (10.172.95.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.8; Tue, 15 Aug 2017 06:52:51 +0000
Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.01.1385.000; Tue, 15 Aug 2017 06:52:51 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: Martin Thomson <martin.thomson@gmail.com>, Jana Iyengar <jri@google.com>
CC: QUIC WG <quic@ietf.org>
Subject: RE: Splitting transport and application error code spaces
Thread-Topic: Splitting transport and application error code spaces
Thread-Index: AQHTEmRSPsl9gZnFJ0aVX2eLrEQ0JKJ/O0rXgAFEn4CABA5DAIAADZAAgABk9xA=
Date: Tue, 15 Aug 2017 06:52:51 +0000
Message-ID: <MWHPR21MB0141C504874E7704D62BF388878D0@MWHPR21MB0141.namprd21.prod.outlook.com>
References: <CABkgnnXcjaqXeRLq=+W98HnubFSEy_DWB7PbaK8GEDUK+Wvetg@mail.gmail.com> <CY4PR21MB0136EE9B4C91C296860A38F687890@CY4PR21MB0136.namprd21.prod.outlook.com> <CABkgnnU6gP++XeByfz3ML75VCuowrDA94DvjijZxL=sRCBiOSA@mail.gmail.com> <CAGD1bZYv8LDuyOH=tP1wDk+Ja+=Yy1MYAGLUxtyB2DpBLXdqwQ@mail.gmail.com> <CABkgnnXDc8Fzh0Y6yB9BUWxtXi2kcfKTS+=znPPvuppHRdA3ZQ@mail.gmail.com>
In-Reply-To: <CABkgnnXDc8Fzh0Y6yB9BUWxtXi2kcfKTS+=znPPvuppHRdA3ZQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2601:600:8080:5a28:39b2:9ce8:c7eb:c810]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR21MB0510; 6:c/S1vGH63RHJNC0qz77EVfNUxLkSWyjSsC3GZEcra4tBoof5vmOBytF5/U/a+au8P7Rap3KVNoAcHW6Sxrk5X9I6FYcbtpYnZ/dnc3mIo2YkOF1+jnEPoiybOcBGHBwhDcYyamjMrBATElNoSMohfDcuhucB87FjKiKnaMSr9jW0h12ePJKUfikd7X//5xKdZtkCYA+rGM7LPj8+34vnra5bpvOs2r0xKIrz2iMv7DBzfQfq/xgrTJnO8AXZedeurhXPgw/FaDBP0OMH5c/20agtfgkup6X5+eZaXTLQuHNPlrsB9Kw7Jbdkjlg0hRYXc9YPpLgzrBD6izwUcVwZvA==; 5:u5HtT2jOwPz2kuPIi3FyNmxvy1ETjUHcB3/u83YOpryjXNLzktjmjfIRfzOItO3FjCA4dbT5a0g7u8crC5i3rSIJ02369HvDGC8tiNjhdGQGa6FlKCffROihzqLiH4jKa4zQ9yAUhQ9fLxEH7Ce+wg==; 24:uvtnP+oylPAFDCNP/lt9XL4MxkT2bHaIUbO5PtOlM9h8cshvmjJYZ9TrKYFTF1irE2tJPfP14cEFlGfB00yyucw+eGyl+bbkwQV+zPnjO8U=; 7:drwnjIz4Bf2Uh1Q1BlmxHLScZtkrt/lvPWpVY6NMjmFB/iqiN9zTcnxna5rLweCZ6c0hdCPc1FS0QQVYE4/ZYcmWyiTr7rGVFUB0Nku48NRT9pBMVfK6eqLKx/DIKhmioDOqItVoTmel0Yslpb1Ake2CvwQ5NbWWzB5pwb/wnAwyG5uQ3HOKgBcGUNeKDmey64ooGfcX+P+XFN/r02mU0Lx2jtHMgf8aNiB/U1njmDo=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 78c456dc-ea05-4dd7-7e64-08d4e3aa3fa7
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603144)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0510;
x-ms-traffictypediagnostic: MWHPR21MB0510:
x-exchange-antispam-report-test: UriScan:(89211679590171)(211936372134217)(153496737603132);
x-microsoft-antispam-prvs: <MWHPR21MB0510EC8E221AF8AF94401727878D0@MWHPR21MB0510.namprd21.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(920507026)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123558100)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0510; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0510;
x-forefront-prvs: 04004D94E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(47760400005)(199003)(377454003)(13464003)(189002)(24454002)(97736004)(50986999)(76176999)(5005710100001)(189998001)(34040400001)(229853002)(7736002)(74316002)(8990500004)(101416001)(2900100001)(54356999)(86362001)(86612001)(10290500003)(2906002)(68736007)(39060400002)(478600001)(6506006)(305945005)(4326008)(3280700002)(77096006)(25786009)(53546010)(3660700001)(10090500001)(6246003)(7696004)(53936002)(72206003)(5660300001)(106356001)(105586002)(6116002)(102836003)(6436002)(93886004)(2950100002)(99286003)(81166006)(81156014)(8936002)(8676002)(55016002)(14454004)(9686003)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0510; H:MWHPR21MB0141.namprd21.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)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2017 06:52:51.5782 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0510
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Bi9rp7fRnHSk4POrI06CKOuvjBY>
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: Tue, 15 Aug 2017 06:52:56 -0000

I'm a little unhappy about that one.  I see the logic, but that would leave each direction of a stream solely in the hands of the sender and the receiver has no way to communicate (at the transport layer) if it wishes that stream to cease.  (Other, perhaps, than starving it via flow control.)  Though I agree, it is consistent with the principle that stream lifetime is entirely in the hands of the application.

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Monday, August 14, 2017 5:49 PM
To: Jana Iyengar <jri@google.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; QUIC WG <quic@ietf.org>
Subject: Re: Splitting transport and application error code spaces

On 15 August 2017 at 10:00, Jana Iyengar <jri@google.com> wrote:
> I'm not sure exactly what this split buys us... and it changes 
> behavior on receiving STOP_SENDING.

So, what the split buys us is certainty: an application is responsible for the lifetime of streams.  In return the application can be certain that the transport won't destroy any state that it puts on streams at a whim.  The split enforces this separation.

This issue with STOP_SENDING is a good one.  I have a solution to that as well: move STOP_SENDING to HTTP.  If the required reaction (RST_STREAM), is an application-layer action, then we should make the trigger application-layer as well.

v2.23.0 | Report a Bug | By Email