Re: Is CONNECTION_CLOSE frame Ack-eliciting?
Ian Swett <ianswett@google.com> Wed, 05 June 2019 16:08 UTC
Return-Path: <ianswett@google.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 5E53D120169 for <quic@ietfa.amsl.com>; Wed, 5 Jun 2019 09:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.519
X-Spam-Level:
X-Spam-Status: No, score=-15.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 kk2p9BU1uBr0 for <quic@ietfa.amsl.com>; Wed, 5 Jun 2019 09:08:17 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812761201C5 for <quic@ietf.org>; Wed, 5 Jun 2019 09:08:17 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id s3so2841122wms.2 for <quic@ietf.org>; Wed, 05 Jun 2019 09:08:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DuFFzzcnPoKlOZL05rFbF/jmGsZW1Ls4vplhGkJKx1g=; b=iC4PwNOfmoiQVeLkDXUHHPEnHtxRA6uI1hjMCBiAfyb1frG8zRF88TVY2zLrqDBkQ+ Qz6PQ/mdVqf+WhiESkk3rpbBwRzQ4UmsPtJmj1jii9L+/oACbAsYFqzrP3jfbJyU5PSZ 5xluuvyDTM9itwjQWg53bc0MN4LXHW6zQaikGbZX9AGTRmFBjl9h5T3ceKo7o7C5MbMI 9HRXG6571/wP3nV0mOMgNuZbQNRanNs7oM0nkr+tnwfl4l2pyUEdBy7hHQVa/pYIFl66 tw3/VxJYsOUemF+VKA+lPj84489+9XXEo2rmBf/29sTPsqpGcHREzHQF6v1FniJl3E+m 2YXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DuFFzzcnPoKlOZL05rFbF/jmGsZW1Ls4vplhGkJKx1g=; b=tBKt43ZlBfaSWE1V7y5/sF2eZGXX3q3v/Esb5zrX4/XXwi3dGFPDYdWDZ2TMXrhRIK k9AAkhrVVPr4NGTfLqdkonQbb25YAE8PjzTY+SyXoKifLFwwukjRIwIsOD0ZPOYOjUaz sVfU9PEoTK3emJcO/pzpPxufqmiz1tBvetnrMqTd9JfzOl21qcujL8L0yU3Ta874Abex +9OTDsPb+/RsFhFTRYPtuXMfY2AduM8YrnEM+5S4NKDl1j+IDERV+q1xxdNdbYDVPWba ZQCi8jyk5wZm5iszExU8RMU6/u9j7JafPKHKPkINMIgpIICB/+zmqGdX9iRLblYCbGW2 PoBg==
X-Gm-Message-State: APjAAAXLZ3cTlzryqQc80IuEvJ0ySKMKada6Mkl3OiJ3jQlDBfgOdHHU lOVYXPZKiyiD8FZY6yajO1Hn24TDAS9nXCy5ZHOX0Q==
X-Google-Smtp-Source: APXvYqwrB6FKclw8PGoPBkECMn0hcTJ1re02SwWATJap10Z05YcufeusKG/4N7w8jNj4zhBk+TXQdE3ZXSMOnpZ51RY=
X-Received: by 2002:a7b:c775:: with SMTP id x21mr23032878wmk.9.1559750895422; Wed, 05 Jun 2019 09:08:15 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAN1APdeVD7ummf=fEvsjBDMOrGRxvbwmtnRi--rO8p39Jp0wtw@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Wed, 05 Jun 2019 12:08:03 -0400
Message-ID: <CAKcm_gPWQxeqJxqj=ssE=y=HhQ08f-m5Wi+pU+XRT-sYd3Zxpg@mail.gmail.com>
Subject: Re: Is CONNECTION_CLOSE frame Ack-eliciting?
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Cc: Nick Banks <nibanks@microsoft.com>, IETF QUIC WG <quic@ietf.org>, Jiuhai Zhang <jiuhai.zhang@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000000fc97b058a95cee0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/agRUtj3e1GDpE0wbhA6FWc4pdS0>
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:08:20 -0000
Thanks, I missed that. On Wed, Jun 5, 2019 at 12:03 PM Mikkel Fahnøe Jørgensen <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) 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> 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) 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> *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> >> 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? >> >>
- Is CONNECTION_CLOSE frame Ack-eliciting? Jiuhai Zhang
- Re: Is CONNECTION_CLOSE frame Ack-eliciting? Ian Swett
- RE: Is CONNECTION_CLOSE frame Ack-eliciting? Nick Banks
- RE: Is CONNECTION_CLOSE frame Ack-eliciting? Mikkel Fahnøe Jørgensen
- Re: Is CONNECTION_CLOSE frame Ack-eliciting? Ian Swett
- Re: Is CONNECTION_CLOSE frame Ack-eliciting? Mikkel Fahnøe Jørgensen
- Re: Is CONNECTION_CLOSE frame Ack-eliciting? Ian Swett
- Re: Is CONNECTION_CLOSE frame Ack-eliciting? Marten Seemann
- RE: Is CONNECTION_CLOSE frame Ack-eliciting? Nick Banks
- Re: Is CONNECTION_CLOSE frame Ack-eliciting? Ian Swett
- Re: Is CONNECTION_CLOSE frame Ack-eliciting? Christian Huitema
- RE: Is CONNECTION_CLOSE frame Ack-eliciting? Mike Bishop
- Re: Is CONNECTION_CLOSE frame Ack-eliciting? Philipp S. Tiesel
- Re: Is CONNECTION_CLOSE frame Ack-eliciting? Gorry Fairhurst
- Re: Is CONNECTION_CLOSE frame Ack-eliciting? Roland Zink