IETF Logo Mail Archive

RE: Splitting transport and application error code spaces

Mike Bishop <Michael.Bishop@microsoft.com> Fri, 11 August 2017 14:42 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 759301321AA for <quic@ietfa.amsl.com>; Fri, 11 Aug 2017 07:42:29 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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=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 OtAMb8bfVnMd for <quic@ietfa.amsl.com>; Fri, 11 Aug 2017 07:42:22 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0099.outbound.protection.outlook.com [104.47.40.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F349129AD3 for <quic@ietf.org>; Fri, 11 Aug 2017 07:42:22 -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=v3FpMN54mZHyA3X9X9bJ6o+z2R3YD8RfEFaqLSlHog8=; b=SgrALSYbvdgSZ03JbTOxktisudL6GAp665k3njSBYurxifqQCS+Z5NkXYylp3esfLwOE2N7rWWlVVUOzivXu4Y6L4R6aJREzm2gq5sD1OFedQLzO+8b/MVwd6bhobW46nxT0nhz2mbIV7XHfBMycafzEtoXCE+WsZE+mRQzcQvo=
Received: from CY4PR21MB0136.namprd21.prod.outlook.com (10.173.189.18) by CY4PR21MB0118.namprd21.prod.outlook.com (10.173.189.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.5; Fri, 11 Aug 2017 14:42:21 +0000
Received: from CY4PR21MB0136.namprd21.prod.outlook.com ([10.173.189.18]) by CY4PR21MB0136.namprd21.prod.outlook.com ([10.173.189.18]) with mapi id 15.01.1362.011; Fri, 11 Aug 2017 14:42:21 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: Martin Thomson <martin.thomson@gmail.com>, 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/O0rX
Date: Fri, 11 Aug 2017 14:42:21 +0000
Message-ID: <CY4PR21MB0136EE9B4C91C296860A38F687890@CY4PR21MB0136.namprd21.prod.outlook.com>
References: <CABkgnnXcjaqXeRLq=+W98HnubFSEy_DWB7PbaK8GEDUK+Wvetg@mail.gmail.com>
In-Reply-To: <CABkgnnXcjaqXeRLq=+W98HnubFSEy_DWB7PbaK8GEDUK+Wvetg@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:8092:506c:dad1:8720]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0118; 6:tsOPGbY9g1i29vTjIe7G7frNVjmom9fQjpct2beXG3c6qLKq9DNpgHQRaRuPxxbHFBBXs/d/QtAKBqFsqvYsg5u9GlyogF0kWSeCpKv1qzAK1uO3ed2EDmzYmC9RZR+F4UlUpUxMLj8DxCoJI6t/DZpKtqQc1EAd1u9b2pG1UVrD4+vyVdkB0y6ZiYOcDE3oC7pO3xqOUBORyP9Sk/eCCTn7xfCdXwkaBPxwwOOTh3900cDFZ5vYzKhrAO2imC9v9iSNdpwFh7QNyWg3lJRGfnB7uNKZobXBXFV+1hFewBUELigToalz+vuMCIFXUbqWAL9DQAR/TCPlAk5EguPN/A==; 5:/ZJKrXa+ciq32uUyqe2vLtHwcd0eleRvlV4V8xxNncPpgvL0uRekFvSuz9Xx9HR4+IyC1Xy4CqXBa9oK1Lvp/7n4zoId+1izFjLfY9iQanDOYEdLHkVOTOsmlxsAB2ltse527qKyver4I0d63mKV6w==; 24:5qEJcsXlvmoS5yQt4eAh+upPNopwcQSF2D/rgCxKjBt2REjXuaCqvMj1HSysjv7MTg0FrG7aO9BasTgZ5nSkDoshVW/xMN4uOg46NEp3zX4=; 7:ih/SqhNylLShEx6Fk1qXFFdZkmidhtAvRsFfeYB8NlwGY1HDSvYKM5cwg3I/HM0N1iLTMJ4HGue5IeW7BvQq52+mpwKz8dY/HyaL0cVNRiWEr8DNoPDqZI32j4ce2rqK09ShCBhBVlDgTnrD3GzC0GVm1EPkx6+c+a8dGLOXhfmyrX8Y9b/LcYMoovns5irte1YWuzuUm1J3phYUHHUaaiOl/iWYD8Rw0B809u1L5o0=
x-ms-office365-filtering-correlation-id: 48b32838-a346-47d2-2bcf-08d4e0c72c4e
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)(2017052603135)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0118;
x-ms-traffictypediagnostic: CY4PR21MB0118:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com;
x-exchange-antispam-report-test: UriScan:(158342451672863)(189930954265078)(219752817060721);
x-microsoft-antispam-prvs: <CY4PR21MB0118EDC159833FF7F22305CC87890@CY4PR21MB0118.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)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0118; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0118;
x-forefront-prvs: 03965EFC76
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(47760400005)(189002)(377454003)(199003)(14454004)(10090500001)(478600001)(6506006)(189998001)(53546010)(74316002)(77096006)(55016002)(6436002)(3660700001)(10290500003)(606006)(5660300001)(229853002)(2950100002)(97736004)(86612001)(72206003)(86362001)(53936002)(33656002)(6246003)(236005)(9686003)(101416001)(54896002)(6306002)(39060400002)(575784001)(7696004)(966005)(105586002)(7736002)(106356001)(54356999)(76176999)(99286003)(50986999)(8936002)(2900100001)(25786009)(2906002)(102836003)(81156014)(81166006)(5005710100001)(8990500004)(6116002)(3280700002)(8676002)(68736007)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0118; H:CY4PR21MB0136.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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_CY4PR21MB0136EE9B4C91C296860A38F687890CY4PR21MB0136namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2017 14:42:21.0329 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0118
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/aGuQrFqlfWyENBOJvPKgb7c9Ang>
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, 11 Aug 2017 14:42:29 -0000

Okay with the general direction, but not wild about the frame split.  In general, nearly-identical frames make me question.



Given that the assigned 0x2 and 0x3 differ by one bit, might it be clearer to have an embedded flag in CONNECTION_CLOSE indicating the source?  That avoids having two frames with identical semantics except the registry in which you look up the value of a field.



Sent from my Windows 10 phone



From: Martin Thomson<mailto:martin.thomson@gmail.com>
Sent: Thursday, August 10, 2017 10:40 PM
To: QUIC WG<mailto:quic@ietf.org>
Subject: Splitting transport and application error code spaces



A while back we decided to use a single error code space.  But in
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F485&data=02%7C01%7Cmichael.bishop%40microsoft.com%7Ce667a5b2f79c451b47f208d4e07b7337%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636380268206522856&sdata=Lo0K3hCLYeiVHx9WIZu3zDU1qp43n4Xc31RirijGbnU%3D&reserved=0, I noticed that we
have an implicit requirement in the protocol not to have the transport
close streams.  If the transport resets streams, it could destroy
critical application state.

The neatest way to enforce the separation of application and transport
is to create an application error space:

  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F722&data=02%7C01%7Cmichael.bishop%40microsoft.com%7Ce667a5b2f79c451b47f208d4e07b7337%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636380268206522856&sdata=Fko06fKB9DbI0S58mUz%2BFyVLZ4kcxNt9e5dKRQ1XH5A%3D&reserved=0

This splits the error codes for application protocols from the
transport codes.  To do this, it splits CONNECTION_CLOSE into
TRANSPORT_CLOSE and APPLICATION_CLOSE.  These two frames have
identical format and semantics, but use different error code spaces.
RST_STREAM and STOP_SENDING now only carry application error codes,
making it clear that resetting streams is the domain of the
application protocol.

In doing this, I noticed that the error code space is ludicrously
large.  So I have a companion PR that shrinks it to a much more
manageable 16 bits:

  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F723&data=02%7C01%7Cmichael.bishop%40microsoft.com%7Ce667a5b2f79c451b47f208d4e07b7337%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636380268206522856&sdata=qkeITvAPa%2BeAPEB%2FCz7wtmujGcqQnzExH7R01fxCKJc%3D&reserved=0

v2.23.0 | Report a Bug | By Email