IETF Logo Mail Archive

RE: Split error codes in two

Mike Bishop <Michael.Bishop@microsoft.com> Wed, 06 September 2017 17:55 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 1CFAD132494 for <quic@ietfa.amsl.com>; Wed, 6 Sep 2017 10:55:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 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] 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 e5dirBcpnZ99 for <quic@ietfa.amsl.com>; Wed, 6 Sep 2017 10:55:17 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0125.outbound.protection.outlook.com [104.47.33.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025F8132055 for <quic@ietf.org>; Wed, 6 Sep 2017 10:55:17 -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=oreXEfaKVXBfQEJ73ZP64XX0GgxeStsBTl5WgzPae/c=; b=Q9BeiGk4XXQK/A37dLXrN1vJ0qXcTkECH79xYWugEhjIqBkISssoRAxNqolGdfZM3hEGq3rrLY4KB0TH8UMzV2PRsxPLfbvyP5GBRgWvTtL80vCEmoIOYmqlWKgAxXT9R/3w5C/wveMvCF9ZrzsvARJXMM3n/JGNghSQvciKD54=
Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0749.namprd21.prod.outlook.com (10.173.51.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.0; Wed, 6 Sep 2017 17:55:14 +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.20.0056.003; Wed, 6 Sep 2017 17:55:14 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: "Philipp S. Tiesel" <phils@in-panik.de>, Jana Iyengar <jri@google.com>
CC: Victor Vasiliev <vasilvv@google.com>, QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>, Nick Harper <nharper@google.com>
Subject: RE: Split error codes in two
Thread-Topic: Split error codes in two
Thread-Index: AQHTJTn9lu8pyhHlCkWTBQfMudDeAKKmFGeAgAASp4CAAAOOAIAA0yCAgAAOnACAAAMMAIAAAK4AgACHAwCAAI1zwA==
Date: Wed, 06 Sep 2017 17:55:14 +0000
Message-ID: <MWHPR21MB0141F305CCE2B686F09549F887970@MWHPR21MB0141.namprd21.prod.outlook.com>
References: <CABkgnnWwGAyHzkST9o9ueVmBw3_TpJun=dv2X+HL2snXSZJgew@mail.gmail.com> <CAAZdMafBWFWtC7A60P1CMm_6nUnbW+_Tx_7re1bAo7Vx2kLdcA@mail.gmail.com> <CABkgnnWphw3k=f3==2y3AhexQCj9Py50SLSEH06nN3MN0SCerQ@mail.gmail.com> <CAAZdMacHC1HKhXMR4G9CKUOmYyQMsQBab+tampP-PG6n_jJZoA@mail.gmail.com> <CACdeXiLS7W8cJbnT=orHkcd9reH=8QqhOzxWnUEpWZmfcdvd2g@mail.gmail.com> <CAGD1bZa-h0ZVh7kUYQtG3r93eH6TqRXnQ6YXAcscCrCQHk8LeA@mail.gmail.com> <CABkgnnXMFUP_c+2r6YeJouJXanHd8tFcqDKgU=C9UF0stPcXOw@mail.gmail.com> <CAGD1bZZZG9L0_d7Tmo8vfdAx+=LU+yi97N42vKFGo82K16Zycw@mail.gmail.com> <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de>
In-Reply-To: <05505C10-8737-4C58-BC91-E401D2659AF0@in-panik.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:c::51f]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR21MB0749; 6:Z9TMPr1b45lSK8Z5W/XWoUR+tv/sRUICy11bDiWHts6XOeCVru1B6TYIN3Ko9egdK5btQeQ8wgr+Ig3ZMl3OpdgB3pDmDpqLusus6ygfts4MRvjBHQxNvtv25MbLqpeN9KXKEaP5UrnVryeC5qgUKwmT/X10OPiMw9Mmis7ig7J0uic7xAmannMgkhG7TSNw390d8CR25eQYwiyzkiTTI8/YOrk6C9YqyNrol/blXNaw/kP5x+sQ6g2eWQvYhKGRvAhm1Vlk9/lrCrZCBA1oYzMyJLxODCxabcJCAiMPLtJNZw+lEKuz5MEWNkDVzDx0FkiS6HnsFhOJKOr27gHL9w==; 5:3IKUwlp+obmTwtafv7zCZvJjnDPggQcBMzofVY5vK84Fi07ICWHoMXjscJFLwpfulOjUV/IY6Y6lrUd44Npqg32JQ0Le6AKlbqfznTn3P2hunj/aPBPhuwSQo/NemSOIsEBynpEU4HhXoZgUbqxIqA==; 24:v2CHVL7nB8PmPi+Iw3Cj+sqYYYRl+N8JN78P9YlQ62LESjDKLjgzMw+phLDnC6deMuJIFrcNS6UZlKF2LOT/zbfU6hEWgtkwJxzRp+sRbOg=; 7:ZOJtV832eJoEGuXIszAyhQCYG0HtSOJXjSVYSBE39hv5Iem71wfDDEIejA3hUZR6YR/ZvaqncqCqKwnadwyV6FHhqdxqNg6hoHKvX9KgidnZJCSdbThFAx7nHerBNb+IIMtNIs030oGeuwMafcId6jocE5U05V+Oe8IAZSU0bUbYgVih0l4+kuY6mP3MFuJRlpcRPr/pnR/dldn1a9+9ndosXLLi1usdFosyNSi/qcQ=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 9591c8f8-e52e-4288-1f7e-08d4f5506d53
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0749;
x-ms-traffictypediagnostic: MWHPR21MB0749:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com;
x-exchange-antispam-report-test: UriScan:(278428928389397)(211936372134217)(153496737603132);
x-microsoft-antispam-prvs: <MWHPR21MB07491C6C54A08A7A8AD6A77F87970@MWHPR21MB0749.namprd21.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(920507026)(6055026)(61426038)(61427038)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0749; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0749;
x-forefront-prvs: 0422860ED4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(47760400005)(199003)(13464003)(377454003)(24454002)(51444003)(189002)(8936002)(81166006)(7696004)(2950100002)(9686003)(81156014)(14454004)(72206003)(8990500004)(10290500003)(8676002)(68736007)(5660300001)(3660700001)(74316002)(97736004)(7736002)(478600001)(189998001)(5005710100001)(10090500001)(3280700002)(34040400001)(305945005)(2906002)(54906002)(93886005)(33656002)(50986999)(54356999)(76176999)(25786009)(55016002)(99286003)(6116002)(105586002)(4326008)(77096006)(6436002)(39060400002)(101416001)(53546010)(6506006)(106356001)(102836003)(6246003)(229853002)(53936002)(86362001)(2900100001)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0749; 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)
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: 06 Sep 2017 17:55:14.5810 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0749
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Q6GsTmuBMGxWUGVtuuLAGL6XV_M>
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: Wed, 06 Sep 2017 17:55:19 -0000

What transport-level single-stream errors are there which shouldn't kill the connection?  The only ones I can think of are flow control violations and max-stream-ID violations.  Perhaps "frame for stream in wrong state," though you have to be somewhat gracious about that one given reordering.  I think I'm okay with making those fatal.

I'm less convinced that STOP_SENDING is HTTP-specific.  To my mind, it's the wire expression of a read_close(), just as RST_STREAM is the wire expression of a write_close().  If we'd gone the advisory route, it would be an HTTP-ism.  (Or at least, the mandated behavior would be at the HTTP layer.)  However, if we think other applications aren't ever going to want to close a read stream....

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Philipp S. Tiesel
Sent: Wednesday, September 6, 2017 2:16 AM
To: Jana Iyengar <jri@google.com>
Cc: Victor Vasiliev <vasilvv@google.com>; QUIC WG <quic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>; Nick Harper <nharper@google.com>
Subject: Re: Split error codes in two


> On 6. Sep 2017, at 03:12, Jana Iyengar <jri@google.com> wrote:
> On Tue, Sep 5, 2017 at 6:10 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On Wed, Sep 6, 2017 at 10:59 AM, Jana Iyengar <jri@google.com> wrote:
>>> In the current draft, we've already changed that requirement: the 
>>> application is expected to generate a RST_STREAM in response to a 
>>> received RST_STREAM.
>>> 
>> That text was removed with the addition of STOP_SENDING.  (Or at 
>> least I couldn't find it).  I think that's the right answer, because 
>> this will be entirely discretionary on the part of applications.
>> 
> Yup, I was just pointing out the reasons that we don't need RST_STREAM to be a transport directive.

RST_STREAM is also referenced in the "Stream Errors” section and still makes sense for transport errors only effecting a single stream

Removing RST_STREAM also means making all errors effecting just a single stream connection errors leading to teardown of the whole connection.

AVE!
  Philipp S. Tiesel / phils…

v2.23.0 | Report a Bug | By Email