Re: Is CONNECTION_CLOSE frame Ack-eliciting?

Ian Swett <ianswett@google.com> Wed, 05 June 2019 16:38 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 A042C120234 for <quic@ietfa.amsl.com>; Wed, 5 Jun 2019 09:38:40 -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 Rt5galloEvnE for <quic@ietfa.amsl.com>; Wed, 5 Jun 2019 09:38:36 -0700 (PDT)
Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (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 4BF2412012C for <quic@ietf.org>; Wed, 5 Jun 2019 09:38:36 -0700 (PDT)
Received: by mail-wm1-x343.google.com with SMTP id u8so1309168wmm.1 for <quic@ietf.org>; Wed, 05 Jun 2019 09:38:36 -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=JUPD9W6JoPD29sCFRmv9mSp98P/BVAuZJ8RSQmjzV8c=; b=ImqYyeKQ+yYCfIFu6o+QU1+XpKI+XqcLAOBy0uh8IMyqgfxpVna1vhNRPSux+2kbed EBHt3DFVcWM1lyhwoADNzuj7tKETvYnFPHz4ziLsAxIAdRC4js8fGMzh7gYY2Jat+YlI q/yynQvo0LKKRDibGX742EujY9sr8SF2W8sAiRGuKW0Ntwh0+W4wdg/89EtbnzpbfRdV +6+1r7UlZ007qOmjx5RC4GW7qjEVjIzPkuv6SOdoi84EhddLIqnlQd2nL1vzp5uyDvSV gJ5V7zt1lPR659iZBDIEgqZgedZw2i6E+VkjP6Ye4E9u6P1oXsoFxur7qOXm41tCtX5c oiJQ==
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=JUPD9W6JoPD29sCFRmv9mSp98P/BVAuZJ8RSQmjzV8c=; b=k9DuOqqq9eTDb2L9Kogmumgifnr2xH4lHTz+jlXl2C2OyJhPTaZaEL/Hy3TyFjeE8p 7rnlpAOQsQHC1O2JlvFU3CY8kGr5gK9LD6XRPUHSMuHagxDMUnVsrBIszTXJJjNyTmj8 /4eKiW9ctb1RLwfixmwcPzYrzpu8LmSnlNWgjcfXQH9V0CYskCvO1riIW0Z69hHEsKbh ZZfdYeGGCRIogNlvhwI2Ba1Ql7m92153iMZHmMm+l/rU5eq9k/2G0OL+H7jCpLVeu/84 G63swwRItuI4IsTTxx8G9hoctva2ZVsc9+iJ2l425dKUDV66GwUoOs9XgO8dFDoLvaix YIsA==
X-Gm-Message-State: APjAAAVPaDpJVXsFFVyjKuphsMQ9fX0RlH0cT2mrvMTEPo0NQzdIAMrt BJaIWktbkzS0z3hk6JMh55wSJPB6yGwiuI9zZGO0Kw==
X-Google-Smtp-Source: APXvYqwGNzbCHp7ux9vBk+hqtgz9DXGSGWnmMliUVXhyWr+zi7lPcOYJ/AgDSakwO0nbwVSrc9DNegaOP76CO3Cn6vs=
X-Received: by 2002:a1c:b757:: with SMTP id h84mr18608166wmf.127.1559752714356; Wed, 05 Jun 2019 09:38:34 -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> <CAOYVs2ohkoMWqxYPO4JAm2oyBEYQjDuvgmqyNH5kWiRXS29Tgg@mail.gmail.com>
In-Reply-To: <CAOYVs2ohkoMWqxYPO4JAm2oyBEYQjDuvgmqyNH5kWiRXS29Tgg@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Wed, 05 Jun 2019 12:38:21 -0400
Message-ID: <CAKcm_gOyD124KK3jnjxcboiq9dKG37WpOhdy_q-Ta_Nkg=1XiQ@mail.gmail.com>
Subject: Re: Is CONNECTION_CLOSE frame Ack-eliciting?
To: Marten Seemann <martenseemann@gmail.com>
Cc: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, Nick Banks <nibanks@microsoft.com>, IETF QUIC WG <quic@ietf.org>, Jiuhai Zhang <jiuhai.zhang@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007ab2db058a963a92"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/g43GJpoC_GLbXawICVdg5POCSls>
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:41 -0000

In the past, having an ACK bundled with CONNECTION_CLOSE has been useful to
debug what the peer did and did not receive as of the end of the connection.

Agreed on sending CONNECTION_CLOSE in response to CONNECTION_CLOSE being
mostly useless.  I believe some wanted to allow it because if they received
a CONNECTION_CLOSE in response to their CONNECTION_CLOSE, they could remove
all state for the connection, including the saved CONNECTION_CLOSE packet?

On Wed, Jun 5, 2019 at 12:25 PM Marten Seemann <martenseemann@gmail.com>
wrote:

> 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> 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?
>>>
>>>