IETF Logo Mail Archive

Re: Is CONNECTION_CLOSE frame Ack-eliciting？

"Philipp S. Tiesel" <philipp@tiesel.net> Thu, 06 June 2019 07:55 UTC

Return-Path: <philipp@tiesel.net>
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 D7E5F12004B for <quic@ietfa.amsl.com>; Thu, 6 Jun 2019 00:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001] autolearn=unavailable autolearn_force=no
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 E6OmR406dD7W for <quic@ietfa.amsl.com>; Thu, 6 Jun 2019 00:55:44 -0700 (PDT)
Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 F1CEA12004F for <quic@ietf.org>; Thu, 6 Jun 2019 00:55:43 -0700 (PDT)
X-Envelope-From: philipp@tiesel.net
Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x567tY1B025950 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 6 Jun 2019 09:55:34 +0200
Received: from philipp-laptop.ods.tu-berlin.de ([130.149.141.20]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <philipp@tiesel.net>) id 1hYnDR-000174-Th; Thu, 06 Jun 2019 09:53:41 +0200
From: "Philipp S. Tiesel" <philipp@tiesel.net>
Message-Id: <0752F79E-FDC9-4204-B804-EAC60DD61654@tiesel.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_07B2B210-DA50-4F2C-B1F4-4A221557333B"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: Is CONNECTION_CLOSE frame Ack-eliciting？
Date: Thu, 06 Jun 2019 09:55:35 +0200
In-Reply-To: <BL0PR2101MB1043C760EB1C7C7BB0AE4374B3160@BL0PR2101MB1043.namprd21.prod.outlook.com>
Cc: Marten Seemann <martenseemann@gmail.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, Ian Swett <ianswett@google.com>, IETF QUIC WG <quic@ietf.org>, Jiuhai Zhang <jiuhai.zhang@gmail.com>
To: Nick Banks <nibanks=40microsoft.com@dmarc.ietf.org>
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> <BL0PR2101MB1043C760EB1C7C7BB0AE4374B3160@BL0PR2101MB1043.namprd21.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/825MG83wChd64R0XSZQW7vKIB6Q>
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: Thu, 06 Jun 2019 07:55:46 -0000


> On 5. Jun 2019, at 18:38, Nick Banks <nibanks=40microsoft.com@dmarc.ietf.org> wrote:
> 
> 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 initialCONNECTION_CLOSE. I agree, that sending ACKs with the responding CONNECTION_CLOSE doesn’t do much.

It can still be useful on short lived connections to update the congestion window cache as well as loss and bandwidth estimates.

AVE!
   Philipp S. Tiesel

-- 
Philipp S. Tiesel 
https://philipp.tiesel.net/

v2.23.0 | Report a Bug | By Email