RE: Is CONNECTION_CLOSE frame Ack-eliciting?

Nick Banks <nibanks@microsoft.com> Wed, 05 June 2019 13:59 UTC

Return-Path: <nibanks@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 75683120098 for <quic@ietfa.amsl.com>; Wed, 5 Jun 2019 06:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level:
X-Spam-Status: No, score=-2.009 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 kEvX-dHpLZxJ for <quic@ietfa.amsl.com>; Wed, 5 Jun 2019 06:59:55 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770095.outbound.protection.outlook.com [40.107.77.95]) (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 B3F33120048 for <quic@ietf.org>; Wed, 5 Jun 2019 06:59:50 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=fy1pBAnAZ1bh1/kgAhjApMTlBb8i9QoUY5pjTRy+pYVQnb3OmuDflcyM6wmr5bdBeUKHWQvrrsCHZnReW++jsUd7BjAWxon9w0ZIxpKDx2mEHSB4mHb/gkGhEdkyBZhluTsp46BkAGkgHSbdxgqYMt4IulESvajIaE4j7suEptw=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Kf91w/fdoH8YuXhYlkVRiyEdRihEYoJsh/H2w/Ky/Wc=; b=xlDDtFOKpLkMZhQscqTiA0BHo5PvTetCyFRRxtztKdAeuGQDFlDU3Rjb6p53VKccHpARc+f7E2/PaAdtM1teXhimCKo+NcRQzpouMpnx/5aKqwr0hFKHGST2vuyccgFlZGXGVo3zsueNW58052qAD9wOncIq9m5UkNQDngMjsQQ=
ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none
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:X-MS-Exchange-SenderADCheck; bh=Kf91w/fdoH8YuXhYlkVRiyEdRihEYoJsh/H2w/Ky/Wc=; b=U0wsVBrqMH+8DstJQ3GeQjgy6aRcgSegj3dm202GCh/ZkjxEos0LI4M/MyaTzUIy0YdkNRRTDk0e9Ew1J8rnP0hkXwa9xyjtH5xjpEKIEaiOJ9eXwmDpnrq3BPOno0BROu8H8i9Ah5JofyTyDKqDnI0WDUrH4i1w189SL0A9Ki0=
Received: from BL0PR2101MB1043.namprd21.prod.outlook.com (2603:10b6:207:37::13) by BL0PR2101MB0930.namprd21.prod.outlook.com (2603:10b6:207:30::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.3; Wed, 5 Jun 2019 13:59:48 +0000
Received: from BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::30e9:8bfc:9b18:9fa1]) by BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::30e9:8bfc:9b18:9fa1%3]) with mapi id 15.20.1987.004; Wed, 5 Jun 2019 13:59:48 +0000
From: Nick Banks <nibanks@microsoft.com>
To: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Jiuhai Zhang <jiuhai.zhang@gmail.com>
CC: IETF QUIC WG <quic@ietf.org>
Subject: RE: Is CONNECTION_CLOSE frame Ack-eliciting?
Thread-Topic: Is CONNECTION_CLOSE frame Ack-eliciting?
Thread-Index: AQHVG5bFgUQ+cxLqqU2bDm3dQiViRqaNE4cAgAAAi0A=
Date: Wed, 05 Jun 2019 13:59:47 +0000
Message-ID: <BL0PR2101MB10437A1A42141B3481712B95B3160@BL0PR2101MB1043.namprd21.prod.outlook.com>
References: <CAG9+TpaByVDQZujwtRo9LHcqFn2cOxmy09y-JmVOAzMVroagVw@mail.gmail.com> <CAKcm_gO7A8gq7a234D8DF-yAre-7_rubJsn10bPXsS6eQPW5zg@mail.gmail.com>
In-Reply-To: <CAKcm_gO7A8gq7a234D8DF-yAre-7_rubJsn10bPXsS6eQPW5zg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-06-05T13:59:43.8384494Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=ba8b261d-4193-4f0c-8b40-9953bede4a5a; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com;
x-originating-ip: [2001:4898:80e8:0:513f:7528:875a:162c]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 47b8c57c-e8b3-410b-04e0-08d6e9be12d0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BL0PR2101MB0930;
x-ms-traffictypediagnostic: BL0PR2101MB0930:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <BL0PR2101MB0930FF9366EDB90E3241CC23B3160@BL0PR2101MB0930.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 00594E8DBA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39860400002)(376002)(396003)(136003)(199004)(189003)(110136005)(8990500004)(71200400001)(6506007)(6436002)(53546011)(68736007)(236005)(66476007)(478600001)(66556008)(52396003)(7696005)(76176011)(790700001)(256004)(14444005)(6116002)(6306002)(99286004)(52536014)(5660300002)(54896002)(9686003)(55016002)(10090500001)(606006)(33656002)(76116006)(46003)(446003)(6246003)(11346002)(71190400001)(2906002)(4326008)(66446008)(64756008)(14454004)(66946007)(186003)(73956011)(10290500003)(966005)(81156014)(81166006)(102836004)(22452003)(486006)(229853002)(74316002)(53936002)(86362001)(7736002)(316002)(25786009)(8936002)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB0930; H:BL0PR2101MB1043.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: j+ZOJryBP/EH4qGjPDq4Q4OsIlpYAggj1q+YVPuIqrUmgYJZfMnKcC23jvPK4RkMeR0HtlZwg8q1JFlxXPEpV/fIp8IssLxGUEtXmvGk42ye4hphOY03FtWk1txe7minily38Vxzd1mozXoXvQ/nlflFZz8yJTWST/yPuaIw7jVib3x8EjWB7RSPmC+my6tqsdn2q79IQqoSXyfBR6naigv/jut37gahUnstS0SqSH/byG0CL+D0FhgInGmTHnVZjkt59NYTiCt0EzDXJRq1hZT3yexk78trEUOzNYyLfDCTDaq+r1ucdGTv0k4RaPs7RKY7Fzy0TzIB5Uiz2quuaeMLtolCQ5ZrajaRoxsUwas8w1iJCo7s71CP3XkjgsFXMQqJltqIoQ9NotTwApN/M2E87r4tNL3dmk3oV3yrn04=
Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB10437A1A42141B3481712B95B3160BL0PR2101MB1043_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 47b8c57c-e8b3-410b-04e0-08d6e9be12d0
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2019 13:59:48.0219 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: nibanks@microsoft.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB0930
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/6nvatAYMIOeWmhj-k0fvcrfv6ao>
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 13:59:58 -0000

Ian,

I have encountered issues both in local automated tests and during interop, where one side gets everything it wants and then cleanly closes the connection. The issues arise because the peer hasn’t received the ACK for that last exchange. For that reason, winquic always encodes its latest ACK state with (always frames before) the CONNECTION_CLOSE frame. This doesn’t increase the size of the packet much, and it’s up to the receiver if they want to process the ACKs or not; but it helps these kind of scenarios.

A simple example test case:

Client: Open one bidirectional stream, send data on it, FIN it, and verify the peer does the same. Then close the connection.
Server: Accept one bidirectional stream, receive all data on it and echo it back. Verify all data is sent successfully.

The “Verify all data is sent successfully” fails if you don’t send ACKs with CONNECTION_CLOSE. So, I personally think it’s a good idea to recommend including ACKs. I know it doesn’t provide any guarantees in the presence of packet loss, so ideally you don’t design an app protocol on top of this, but it does make things a little nicer, IMO.

Thank,
- Nick

From: QUIC <quic-bounces@ietf.org> On Behalf Of Ian Swett
Sent: Wednesday, June 5, 2019 6:48 AM
To: Jiuhai Zhang <jiuhai.zhang@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Is CONNECTION_CLOSE frame Ack-eliciting?

Technically, yes.  But connections don't send any packets after processing a CONNECTION_CLOSE frame, so you would never receive and ACK for it.

From: https://tools.ietf..org/html/draft-ietf-quic-transport-20#section-10.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-quic-transport-20%23section-10.1&data=02%7C01%7Cnibanks%40microsoft.com%7Ca3e4b3be88064c15350408d6e9bc9185%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636953393451363725&sdata=bi9%2FDh3XZuUgM%2B23tC54csAhdE5RQENRTQzgj5%2B%2BPlM%3D&reserved=0>
"The draining state is entered once an endpoint receives a signal that
   its peer is closing or draining.  While otherwise identical to the
   closing state, an endpoint in the draining state MUST NOT send any
   packets.  Retaining packet protection keys is unnecessary once a
   connection is in the draining state."

On Wed, Jun 5, 2019 at 8:04 AM Jiuhai Zhang <jiuhai.zhang@gmail.com<mailto:jiuhai.zhang@gmail.com>> wrote:
In https://tools.ietf.org/html/draft-ietf-quic-recovery-20#section-2<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-quic-recovery-20%23section-2&data=02%7C01%7Cnibanks%40microsoft.com%7Ca3e4b3be88064c15350408d6e9bc9185%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636953393451363725&sdata=420rgTO4Iud8HbpF8KvvANjFfPFP%2BtwAnjVS7KszGb4%3D&reserved=0>

Ack-eliciting Frames:  All frames besides ACK or PADDING are

      considered ack-eliciting.



Is CONNECTION_CLOSE frame Ack-eliciting?

Should endpoint responds a ACK frame when receiving a CONNECTION_CLOSE frame?