RE: Is CONNECTION_CLOSE frame Ack-eliciting?

Nick Banks <nibanks@microsoft.com> Wed, 05 June 2019 16:38 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 AF78712004E for <quic@ietfa.amsl.com>; Wed, 5 Jun 2019 09:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.02
X-Spam-Level:
X-Spam-Status: No, score=-0.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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 CxQhk9vNP0Sv for <quic@ietfa.amsl.com>; Wed, 5 Jun 2019 09:38:19 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740091.outbound.protection.outlook.com [40.107.74.91]) (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 14CE9120041 for <quic@ietf.org>; Wed, 5 Jun 2019 09:38:18 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=l4Unp8c/XF05nYSwu1YQB5+jf4vxn2mIwmYU+ilSMSBpBziQST+yFNzWCqwW/5zceD0wNK3/mskwPDvrkS0/83YxiBIKUL1h0UAYZ3+MiByeyjcZmEQFEFph+EKKlT2/4+FlVgALuti56HbN1PG87QjlyKpsnLKkuFGYdKDjb+E=
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=osKh7Frh+8Yxw59F4HqWKsWOaNEd2r1Go0RFqQkmBWc=; b=mXpkdbdBPnShOY20CNJT6gBT3NG6VWIpa4vngVQTZtYnGKYWLTlVLy3tIqOO6uVanJTW8navAVKqC+x1jjEt6SRFLAECXBV7kgYwppiBSiK6fVLMK+APj5w5IcjPIbKS/EBeBhqHzHitvHijp92kcpL/zkgK/xfCpC3i8OFISgI=
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=osKh7Frh+8Yxw59F4HqWKsWOaNEd2r1Go0RFqQkmBWc=; b=cTynQZhmP99al52WI+JjG5VIaqA7qX2BdZGwNl+sPSe8xclNBlcqQiFCbAsw1SdaasMkmrZpeCJ5Yp6ZqqnEq9JUwsKJPgRLV/MQVdaEjHS1CqogYjTQlfBXED6TPlSDToyAmHP7YbddC0sT4aHxo0gS2NOEOysHKUVQhg9yzAc=
Received: from BL0PR2101MB1043.namprd21.prod.outlook.com (2603:10b6:207:37::13) by BL0PR2101MB1027.namprd21.prod.outlook.com (2603:10b6:207:30::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.3; Wed, 5 Jun 2019 16:38:15 +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 16:38:15 +0000
From: Nick Banks <nibanks@microsoft.com>
To: Marten Seemann <martenseemann@gmail.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
CC: Ian Swett <ianswett@google.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: AQHVG5bFgUQ+cxLqqU2bDm3dQiViRqaNE4cAgAAAi0CAAATdgIAAHtAAgAABbICAAAZOgIAAAelQ
Date: Wed, 05 Jun 2019 16:38:15 +0000
Message-ID: <BL0PR2101MB1043C760EB1C7C7BB0AE4374B3160@BL0PR2101MB1043.namprd21.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>
In-Reply-To: <CAOYVs2ohkoMWqxYPO4JAm2oyBEYQjDuvgmqyNH5kWiRXS29Tgg@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-05T16:38:13.7448829Z; 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=65cfeb2c-4ade-4d0c-bcc8-e84854c0a570; 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: 43f50326-0957-429a-4b3a-08d6e9d4357e
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:BL0PR2101MB1027;
x-ms-traffictypediagnostic: BL0PR2101MB1027:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <BL0PR2101MB1027C86733FADEBD34AA69EDB3160@BL0PR2101MB1027.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00594E8DBA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(396003)(376002)(136003)(366004)(189003)(199004)(14454004)(68736007)(8936002)(33656002)(76176011)(7696005)(66574012)(8990500004)(52396003)(81166006)(81156014)(71200400001)(5070765005)(66446008)(64756008)(66556008)(66476007)(73956011)(66946007)(76116006)(10290500003)(478600001)(102836004)(7736002)(46003)(6506007)(53546011)(446003)(11346002)(71190400001)(966005)(486006)(476003)(2906002)(6246003)(6116002)(790700001)(53936002)(9686003)(55016002)(236005)(54896002)(25786009)(6306002)(229853002)(52536014)(74316002)(6436002)(4326008)(86362001)(110136005)(54906003)(256004)(14444005)(186003)(22452003)(5660300002)(99286004)(316002)(517774005)(10090500001)(606006)(440504004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB1027; H:BL0PR2101MB1043.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: 25DImVSaNi4zi3DBJJGdivFKgiMsm9ASQb5vvzhv1FS+tLGNNxppjMd15daFnPDy0iWL2h8jK0kI0MzYmiXsgc/g9/o3mQ3FMjbW8udHi9RAiDp56ho6lBDpf1SMVHRYgLJlLhe/T8sCkznKjRO5+7JayzS2N6Rxi5OSYDjepDfcCOjg6lI01r0OMSd5o3NYR9Lj9R+8MEDFWwp4swWyYS8LqojOLL+0hDreQpL1zUgbLg4ig/MuY36UNHySMO2sc8X0k6wFaMvtoQjQovhWXw/tad3aUuO5oy9yxUA76U28r0ImNy21eAGYrGilH+KVywBfkjzPFWYgZ/qwzR1Mo1+EKTe3Vx+7UiSWSyiAHNpcxlIr+h3lfa+d6JVujNemTeVyClQUEcZFOy9zBhcKasAAklfRW3bpxN3df1INWCQ=
Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB1043C760EB1C7C7BB0AE4374B3160BL0PR2101MB1043_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 43f50326-0957-429a-4b3a-08d6e9d4357e
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2019 16:38:15.6993 (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: BL0PR2101MB1027
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/UnI-6MqDTFzrJQQNvm9xenV6BVM>
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 16:38:22 -0000

There is no absolute requirement that you maintain the minimal state to generate the CONNECTION_CLOSE. Personally, I feel a MAY is missing in that sentence. Additionally, I feel that an endpoint SHOULD (not a MUST because it’s unenforceable) respond with an immediate CONNECTION_CLOSE of its own, so the peer can use that as a signal of acknowledgement and immediately go away, without waiting the full draining period. But, I know I’m not in the majority with that opinion.

On the topic of sending ACKs with CONNECTION_CLOSE, I am more referring to bundling ACKs with the initial CONNECTION_CLOSE. I agree, that sending ACKs with the responding CONNECTION_CLOSE doesn’t do much.

- Nick

From: Marten Seemann <martenseemann@gmail.com>
Sent: Wednesday, June 5, 2019 9:26 AM
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Cc: Ian Swett <ianswett@google.com>; Nick Banks <nibanks@microsoft.com>; IETF QUIC WG <quic@ietf.org>; Jiuhai Zhang <jiuhai.zhang@gmail.com>
Subject: Re: Is CONNECTION_CLOSE frame Ack-eliciting?

It doesn't really make sense to send a CONNECTION_CLOSE frame in response to a CONNECTION_CLOSE, since in the closing state an endpoint retains "only enough information to generate a packet containing a CONNECTION_CLOSE frame and to identify packets as belonging to the connection", i.e. an endpoint won't even open the packet (but it might reply with another CONNECTION_CLOSE).
Of course, and endpoint can send as many packets after this as it wants (there's no way it could be penalized for misbehaving), although I'm not sure why we're explicitly allowing sending CONNECTION_CLOSE as a response.

I'm not really sure what the benefit is of sending an ACK frame bundled with a CONNECTION_CLOSE. There's nothing the receiving peer can do in reaction to receiving that ACK - the connection is already closed. Furthermore, it would be wrong to conclude that all stream data has been processed by the application. An ACK for a STREAM frame only means that the STREAM frame was processed by the QUIC stack, not by the application.

On Thu, Jun 6, 2019 at 12:03 AM Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>> wrote:
10.3: "After receiving a CONNECTION_CLOSE frame, endpoints enter the draining state. An endpoint that receives a CONNECTION_CLOSE frame MAY send a single packet containing a CONNECTION_CLOSE frame before entering the draining state, using a CONNECTION_CLOSE frame and a NO_ERROR code if appropriate."

On 5 June 2019 at 17.58.19, Ian Swett (ianswett@google.com<mailto:ianswett@google.com>) wrote:
Nick, I agree that bundling an ACK with a CONNECTION_CLOSE is useful, and our implementation does that as well.

However, it seems like the existing text indicates you'd never expect to get a CONNECTION_CLOSE in response to a CONNECTION_CLOSE?  Or am I misreading the text about draining?

On Wed, Jun 5, 2019 at 10:08 AM Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>> wrote:
CONNECTION_CLOSE can be response to CONNECTION_CLOSE and that response can contain other frames.. So technically you can ACK a connection close.

Doing so might actually make sense if the original closer take that as a signal to drain faster.



On 5 June 2019 at 16.00.16, Nick Banks (nibanks=40microsoft.com@dmarc.ietf.org<mailto:nibanks=40microsoft.com@dmarc.ietf.org>) wrote:
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<mailto:quic-bounces@ietf.org>> On Behalf Of Ian Swett
Sent: Wednesday, June 5, 2019 6:48 AM
To: Jiuhai Zhang <jiuhai.zhang@gmail.com<mailto:jiuhai.zhang@gmail.com>>
Cc: IETF QUIC WG <quic@ietf.org<mailto: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%7Cb0b15118b76a4bc6b06e08d6e9d27df3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636953487602332765&sdata=IhmvEOZRBJf%2FD7y5e5FZS0sO6yqe9Ztu2nK7%2FUp3voU%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%7Cb0b15118b76a4bc6b06e08d6e9d27df3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636953487602342762&sdata=tYID8lqmH2DVpOjm07pmSCyKOOBlBDDijlTm8FLQ2G0%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?