IETF Logo Mail Archive

Re: STOP_SENDING

Subodh Iyengar <subodh@fb.com> Mon, 31 July 2017 23:57 UTC

Return-Path: <prvs=9385c1793f=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 9E85E12EB8C for <quic@ietfa.amsl.com>; Mon, 31 Jul 2017 16:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level:
X-Spam-Status: No, score=-2.719 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, URIBL_BLOCKED=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=Vny2yxhl; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=G4wI6MZH
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 Kzs0amLH6yiJ for <quic@ietfa.amsl.com>; Mon, 31 Jul 2017 16:57:38 -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 ACA1E129A96 for <quic@ietf.org>; Mon, 31 Jul 2017 16:57:38 -0700 (PDT)
Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6VNrAfp013241; Mon, 31 Jul 2017 16:57:36 -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=S4xH7tDo7f2wOOU7mx4ry3mGMBU6i5kSvEH5Zqmdvdo=; b=Vny2yxhluEci88c32iS0RfM45NpZXypD+WCBc5n2CO+NB7VcLYFPcdMBOcbKvF7RoQRY lIjRdWAJxmHhYb8iCHPNAr/8TZrVo4OoQw5rZuyKjdflexROeS6KKUzDwjgrn1/czrt5 ls/asYKIjw1EKpyGsrOpxL5zW0zH4WCZ4+o=
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2c282b9shh-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 31 Jul 2017 16:57:36 -0700
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.21) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 31 Jul 2017 19:57:35 -0400
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=S4xH7tDo7f2wOOU7mx4ry3mGMBU6i5kSvEH5Zqmdvdo=; b=G4wI6MZHkbM0BMkAvr2CW6jj/0VQuvv8aTPKHUY8MNqu+n/jyr1AVnujfWC2wbV2F0P6JDfiqJhDp9mqHNsZ6icvig9yhO4FLBTGekgZz+kCq+EnFwiGx104GjZ8wNHMQO1DHLa8py27g5tVf+e8jqttv1ttJVVVFhZaogT5bZs=
Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Mon, 31 Jul 2017 23:57:34 +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.1304.023; Mon, 31 Jul 2017 23:57:34 +0000
From: Subodh Iyengar <subodh@fb.com>
To: Martin Thomson <martin.thomson@gmail.com>, QUIC WG <quic@ietf.org>
Subject: Re: STOP_SENDING
Thread-Topic: STOP_SENDING
Thread-Index: AQHTCZGIY51TFpy/zEi+0IsMXc5nPKJumE+/
Date: Mon, 31 Jul 2017 23:57:34 +0000
Message-ID: <MWHPR15MB1455C9C91344082BD1EF4CAAB6B20@MWHPR15MB1455.namprd15.prod.outlook.com>
References: <CABkgnnU2N3gQvtBf-Ff3veT=f=8WApykWfNw+7aCNdZ0a3WO7Q@mail.gmail.com>
In-Reply-To: <CABkgnnU2N3gQvtBf-Ff3veT=f=8WApykWfNw+7aCNdZ0a3WO7Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2620:10d:c090:200::5:78a6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1455; 20:MMS0AfHCzgP8MNJlGAysXwzN+vEh3yVhNRgYnKcPUbejPMWRMmtJoXNiGh87iIUj1GsEiMfuUAfDd8NtRG6NVx6W7WnNuyK0lSHX3zMYaKfLl5jALDFah0q1fMD30RUffeaPUzoX/Acp/7zNof4q8aSDN8jq98wWFP7tEs4yccE=
x-ms-office365-filtering-correlation-id: 7ba87cbc-68be-461c-d3a3-08d4d86fea12
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR15MB1455;
x-ms-traffictypediagnostic: MWHPR15MB1455:
x-exchange-antispam-report-test: UriScan:(166708455590820);
x-microsoft-antispam-prvs: <MWHPR15MB1455E95660E243C73E2B0E3FB6B20@MWHPR15MB1455.namprd15.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1455; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1455;
x-forefront-prvs: 03853D523D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39400400002)(39410400002)(39850400002)(52314003)(377454003)(199003)(189002)(6606003)(2950100002)(478600001)(8676002)(99286003)(55016002)(81166006)(81156014)(3280700002)(3660700001)(6436002)(53936002)(8936002)(229853002)(77096006)(2900100001)(97736004)(6246003)(7116003)(38730400002)(5660300001)(189998001)(39060400002)(50986999)(6506006)(76176999)(54356999)(74316002)(68736007)(606006)(53546010)(33656002)(25786009)(966005)(14454004)(105586002)(106356001)(86362001)(2906002)(54896002)(236005)(7696004)(9686003)(6306002)(102836003)(6116002)(101416001)(7736002)(19627405001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1455; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1455C9C91344082BD1EF4CAAB6B20MWHPR15MB1455namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2017 23:57:34.4123 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1455
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-07-31_10:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/f58YYvWtMw9uBSDt0qbt2-RWqCo>
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: Mon, 31 Jul 2017 23:57:41 -0000

I commented on the PR, but had a design comment

Sending one more frame type has the added burden of needing to retransmit it before we go to closed state unless we make STOP_SENDING non retransmittable. Since this frame type is advisory anyway, does it really need to be retransmittable? Also it doesn't make sense to send this if we have received the peers RST. A peer's RST might have raced with our STOP_SENDING and the peer might have got rid of state for the stream. Thus any retransmitted STOP_SENDING frames might just be ignored.


Previously we had a bidirectional RST. With this change, it makes me a bit nervous for an endpoint to rely on a peer following advisory behavior for them to be able to close their stream, for example what would we do about a client that chooses not to send a RST on STOP_SENDING, do we rely on stream limits only? close the connection? It would be much more comfortable with a client MUST send a RST when getting a STOP_SENDING.

Subodh


________________________________
From: QUIC <quic-bounces@ietf.org> on behalf of Martin Thomson <martin.thomson@gmail.com>
Sent: Sunday, July 30, 2017 5:10 PM
To: QUIC WG
Subject: STOP_SENDING

https://github.com/quicwg/base-drafts/pull/171

As mentioned in Prague, I want to merge the PR formerly known as
DISINTEREST.  Mike has updated it and it is now ready to do.  I plan
to merge this in 48 hours, absent any substantial objections.

v2.23.0 | Report a Bug | By Email