Return-Path: 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 782BC1200F5 for ; Thu, 6 Jun 2019 06:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zinks.de 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 nmbXnbsgS4iB for ; Thu, 6 Jun 2019 06:57:47 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::1]) (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 2BDC3120074 for ; Thu, 6 Jun 2019 06:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1559829464; s=strato-dkim-0002; d=zinks.de; h=In-Reply-To:Date:Message-ID:From:References:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=82bfCDgcbOZa5idmzBGUzE2PAnSBP3GUIwSwXU7VPh4=; b=GpWDJ5XtUqxgfH1+3xQA7JVRCznHn9OYj7nCzF53j+7Lg65p0iNZ9PorWMUeKTbp4U 8HnpRZUaBhnUN+cqW39wRF50BYnUJVoj43ydZf2pol9fMPc/9AvK4MWfM5WZxwBhC8UF 8psVvrFWerqPRq992Y9IApv7xqvlLHyNpDd6TcSln5GIXgPuecoyHR6/6egikP8BabXr FUOOljecGdQC9So+OsXtZLUlGPnEpxuu/AZUeMEmRXIJCj7sp0XAMZNZDzvBS4xDP0h5 wjZihP9ekRwF52oEYZja2+0/qxThY6KWJ4hAxCHB/noLbElhdWNgleRkK6r61fAI4IbP 1fEA== X-RZG-AUTH: ":PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKt0Zib1EwEOzr8+BNkxXWP+OqyFZyRGTJiOMmxcOom4Q2/Hg1L" X-RZG-CLASS-ID: mo00 Received: from [IPv6:2003:f4:73c1:9a00:b409:f58e:e178:266] by smtp.strato.de (RZmta 44.22 AUTH) with ESMTPSA id 608fa8v56DvhG28 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Thu, 6 Jun 2019 15:57:43 +0200 (CEST) Subject: =?UTF-8?Q?Re=3a_Is_CONNECTION=5fCLOSE_frame_Ack-eliciting=ef=bc=9f?= To: quic@ietf.org References: <3432c428-9c16-93cf-4455-b030c9527beb@huitema.net> From: Roland Zink Message-ID: Date: Thu, 6 Jun 2019 15:57:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <3432c428-9c16-93cf-4455-b030c9527beb@huitema.net> Content-Type: multipart/alternative; boundary="------------D0787D1D7B599115AF27DE69" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 13:57:51 -0000 This is a multi-part message in MIME format. --------------D0787D1D7B599115AF27DE69 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit In LTE networks mobile devices RRC (Radio Resource Control) disconnect after a few seconds from the mobile network. They only connect back from time to time for example when they enter another tracking area. When some data needs to be send to it then those device needs first to be paged within a tracking area and only after they reconnect the data can be send. Often server idle timeouts are longer than the RRC disconnect timeout. This means when the server closes the connection and send something to do so then this requires all the signalling to bring the device online again just for a TCP FIN. For TCP there are middle boxes which optimize those in mobile networks. Some numbers: Devices stay 5-10% shorter in connected (radio active) state Number of paging request because of data to be delivered is reduced by 10-20% There is an Android App available in the PlayStore named Devmon which shows in a graph when such a thing happens. It needs root access and tcpdump to determine if a TCP FIN was received, see https://play.google.com/store/apps/details?id=com.flashnetworks.netmon. For QUIC the silent connection close after an idle timeout avoids that overhead for mobile devices and networks. Regards, Roland Am 05.06.2019 um 22:40 schrieb Christian Huitema: > On 6/5/2019 9:38 AM, Ian Swett wrote: > >> 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? > Most of the arguments I heard one way or the other are based on power > management. Sending one more message requires waking up the radio, etc., > which consumes significant power on a mobile device. Replying with a > connection close allows the peer to immediately exit the waiting state, > which might save some power -- but probably not as much as what is saved > on the client with not sending an extra message. If the client does send > a connection close, the server has to keep the state for 3*RTO, which is > not a very big deal. > > -- Christian Huitema > > --------------D0787D1D7B599115AF27DE69 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

In LTE networks mobile devices RRC (Radio Resource Control) disconnect after a few seconds from the mobile network. They only connect back from time to time for example when they enter another tracking area. When some data needs to be send to it then those device needs first to be paged within a tracking area and only after they reconnect the data can be send. Often server idle timeouts are longer than the RRC disconnect timeout. This means when the server closes the connection and send something to do so then this requires all the signalling to bring the device online again just for a TCP FIN.


For TCP there are middle boxes which optimize those in mobile networks. Some numbers:

Devices stay 5-10% shorter in connected (radio active) state

Number of paging request because of data to be delivered is reduced by 10-20%


There is an Android App available in the PlayStore named Devmon which shows in a graph when such a thing happens. It needs root access and tcpdump to determine if a TCP FIN was received, see https://play.google.com/store/apps/details?id=com.flashnetworks.netmon.


For QUIC the silent connection close after an idle timeout avoids that overhead for mobile devices and networks.


Regards,

Roland



Am 05.06.2019 um 22:40 schrieb Christian Huitema:
On 6/5/2019 9:38 AM, Ian Swett wrote:


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?

Most of the arguments I heard one way or the other are based on power
management. Sending one more message requires waking up the radio, etc.,
which consumes significant power on a mobile device. Replying with a
connection close allows the peer to immediately exit the waiting state,
which might save some power -- but probably not as much as what is saved
on the client with not sending an extra message. If the client does send
a connection close, the server has to keep the state for 3*RTO, which is
not a very big deal.

-- Christian Huitema
--------------D0787D1D7B599115AF27DE69--