IETF Logo Mail Archive

RE: Is CONNECTION_CLOSE frame Ack-eliciting？

Mike Bishop <mbishop@evequefou.be> Wed, 05 June 2019 21:13 UTC

Return-Path: <mbishop@evequefou.be>
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 870FF12013B for <quic@ietfa.amsl.com>; Wed, 5 Jun 2019 14:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=evequefou.onmicrosoft.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 lFQCDj62T-N1 for <quic@ietfa.amsl.com>; Wed, 5 Jun 2019 14:13:30 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780137.outbound.protection.outlook.com [40.107.78.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 C93391200B5 for <quic@ietf.org>; Wed, 5 Jun 2019 14:13:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8t9HRZ+7wTGrtQLfVmm5A0yrNNfdzpHsdRrgVhnzOeA=; b=QSakVh2YQ9Gdsbh+kd79Is1GRO5hyvO6GOTh9GrltqESA0oKvsOeYeNMvyiytfQgZlqPitH5QuNDYJOPpTiFoI4E//R7jaPXW0cpnJZ2X9RevTuJMVrh5Vk/hIzaRcjNcgMA6cdYZSMd2Lce0VMd4Nz6CYImzG/lnDagNV++HN8=
Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0630.namprd22.prod.outlook.com (10.172.139.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.22; Wed, 5 Jun 2019 21:13:27 +0000
Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6%6]) with mapi id 15.20.1943.018; Wed, 5 Jun 2019 21:13:26 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: Christian Huitema <huitema@huitema.net>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Marten Seemann <martenseemann@gmail.com>
CC: Nick Banks <nibanks@microsoft.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, IETF QUIC WG <quic@ietf.org>, Jiuhai Zhang <jiuhai.zhang@gmail.com>
Subject: RE: Is CONNECTION_CLOSE frame Ack-eliciting？
Thread-Topic: Is CONNECTION_CLOSE frame Ack-eliciting？
Thread-Index: AQHVG5bLhdeFO0b9D0S3XNuHX2zZ7qaNE4cAgAADKYCAAAI/gIAAHtAAgAABbICAAAZOgIAAA4WAgABDqACAAAiaUA==
Date: Wed, 05 Jun 2019 21:13:26 +0000
Message-ID: <CY4PR22MB09836EEFFAF0A50CC976EDE0DA160@CY4PR22MB0983.namprd22.prod.outlook.com>
References: <CAG9+TpaByVDQZujwtRo9LHcqFn2cOxmy09y-JmVOAzMVroagVw@mail.gmail.com> <CAKcm_gO7A8gq7a234D8DF-yAre-7_rubJsn10bPXsS6eQPW5zg@mail.gmail.com> <BL0PR2101MB10437A1A42141B3481712B95B3160@BL0PR2101MB1043.namprd21.prod.outlook.com> <CAN1APdfvQ9iewtPz0GBvyONaHfBNpyp28Q4rY97=o6ranmGD2g@mail.gmail.com> <CAKcm_gP=yjZXSJ39pv=zJw8T+Uvvf6CCocY9gWmO6NU90ACavw@mail.gmail.com> <CAN1APdeVD7ummf=fEvsjBDMOrGRxvbwmtnRi--rO8p39Jp0wtw@mail.gmail.com> <CAOYVs2ohkoMWqxYPO4JAm2oyBEYQjDuvgmqyNH5kWiRXS29Tgg@mail.gmail.com> <CAKcm_gOyD124KK3jnjxcboiq9dKG37WpOhdy_q-Ta_Nkg=1XiQ@mail.gmail.com> <3432c428-9c16-93cf-4455-b030c9527beb@huitema.net>
In-Reply-To: <3432c428-9c16-93cf-4455-b030c9527beb@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be;
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c055faa6-123a-489d-fdeb-08d6e9faa6d0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR22MB0630;
x-ms-traffictypediagnostic: CY4PR22MB0630:
x-microsoft-antispam-prvs: <CY4PR22MB0630993CD5AB4DEB380718D9DA160@CY4PR22MB0630.namprd22.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 00594E8DBA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(136003)(396003)(39830400003)(376002)(189003)(199004)(13464003)(60444003)(66574012)(256004)(81156014)(14444005)(508600001)(81166006)(52536014)(11346002)(8936002)(7696005)(14454004)(5660300002)(486006)(7736002)(316002)(446003)(476003)(74316002)(305945005)(26005)(54906003)(9686003)(6436002)(3846002)(6506007)(33656002)(4326008)(86362001)(53936002)(229853002)(55016002)(6116002)(99286004)(53546011)(66066001)(76116006)(68736007)(66556008)(73956011)(102836004)(66946007)(6246003)(66476007)(186003)(76176011)(74482002)(71200400001)(25786009)(64756008)(110136005)(71190400001)(66446008)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0630; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: t0rZCGtenIad15bEePPxLyDZwTwtmFkstTQaj3GuUd7+9cTFDr35LqKehThistB7onivsWB8RJhlLhD+qjjDLXJRK6wVwNbIj/iv1mqipnh2IoTkyjOCgsrx6dvmJU1qlrqVw8GOWfa8iNVG8OeML9tjAgiq3TkZTndj7r0RkTy2TL80e8B2vGOQtc80kTN5m+7Oo0PJNYSuJ7wJ5lkGpA0fa7t7Q2JYOfTd3xDDKueI55yWdalxwPOOQUqVnK6avqZgtMSM3DdmRKTJKyec3u2POpEGAzk2JLaL9LSBG6Zm/9JOBNl1C+6c7NlHnAkUDLX0gFaWOXq26bpF5TmEQ+9Mut/fdzZxBw+Ie+aYlJzIO19VMkpPS9iSsxcE03igxzUStFSKrx8WxnaZLnChxB8cMQmRrFR4vVdSHZWfJzQ=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: c055faa6-123a-489d-fdeb-08d6e9faa6d0
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2019 21:13:26.8323 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mbishop@evequefou.be
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0630
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/5s8bZ7GUqtwhewy50Y2UJ2M-1-A>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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, 05 Jun 2019 21:13:33 -0000

But IIUC, waking the radio happens when receiving the message in the first place.  Sending vs. receiving isn't that different.  So that's an excellent argument for having a silent close on both sides, but not so compelling with regard to whether a CONNECTION_CLOSE can be used in response to a CONNECTION_CLOSE.

-----Original Message-----
From: QUIC <quic-bounces@ietf.org> On Behalf Of Christian Huitema
Sent: Wednesday, June 5, 2019 1:41 PM
To: Ian Swett <ianswett=40google.com@dmarc.ietf.org>; Marten Seemann <martenseemann@gmail.com>
Cc: Nick Banks <nibanks@microsoft.com>; Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>; IETF QUIC WG <quic@ietf.org>; Jiuhai Zhang <jiuhai.zhang@gmail.com>
Subject: Re: Is CONNECTION_CLOSE frame Ack-eliciting？

On 6/5/2019 9:38 AM, Ian Swett wrote:

> In the past, having an ACK bundled with CONNECTION_CLOSE has been 
> useful to debug what the peer did and did not receive as of the end of 
> the connection.
>
> Agreed on sending CONNECTION_CLOSE in response to CONNECTION_CLOSE 
> being mostly useless.  I believe some wanted to allow it because if 
> they received a CONNECTION_CLOSE in response to their 
> CONNECTION_CLOSE, they could remove all state for the connection, 
> including the saved CONNECTION_CLOSE packet?

Most of the arguments I heard one way or the other are based on power management. Sending one more message requires waking up the radio, etc., which consumes significant power on a mobile device. Replying with a connection close allows the peer to immediately exit the waiting state, which might save some power -- but probably not as much as what is saved on the client with not sending an extra message. If the client does send a connection close, the server has to keep the state for 3*RTO, which is not a very big deal.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email