IETF Logo Mail Archive

Re: Is CONNECTION_CLOSE frame Ack-eliciting？

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 06 June 2019 09:33 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 D244C1201EC for <quic@ietfa.amsl.com>; Thu, 6 Jun 2019 02:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_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 pW063FpnBJ65 for <quic@ietfa.amsl.com>; Thu, 6 Jun 2019 02:33:08 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id CDF61120086 for <quic@ietf.org>; Thu, 6 Jun 2019 02:33:07 -0700 (PDT)
Received: from MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id A8C891B000DF; Thu, 6 Jun 2019 10:32:58 +0100 (BST)
Message-ID: <5CF8DDCA.6050707@erg.abdn.ac.uk>
Date: Thu, 06 Jun 2019 10:32:58 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Philipp S. Tiesel" <philipp@tiesel.net>
CC: Nick Banks <nibanks=40microsoft.com@dmarc.ietf.org>, Marten Seemann <martenseemann@gmail.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, IETF QUIC WG <quic@ietf.org>, Ian Swett <ianswett@google.com>, Jiuhai Zhang <jiuhai.zhang@gmail.com>
Subject: Re: Is CONNECTION_CLOSE frame Ack-eliciting？
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> <0752F79E-FDC9-4204-B804-EAC60DD61654@tiesel.net>
In-Reply-To: <0752F79E-FDC9-4204-B804-EAC60DD61654@tiesel.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/4PUlT-5VdSmHtdOFdCrIXb1Fi6M>
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 09:33:11 -0000

On 06/06/2019, 08:55, Philipp S. Tiesel wrote:
>
>
>> On 5. Jun 2019, at 18:38, Nick Banks 
>> <nibanks=40microsoft.com@dmarc.ietf.org 
>> <mailto: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*initial*CONNECTION_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/
>
I'd agree this can be really useful and there may be more transport 
characteristics that could usefully be cached.

Gorry

v2.23.0 | Report a Bug | By Email