Re: Is CONNECTION_CLOSE frame Ack-eliciting？

[Roland Zink <[e-mail]>]

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. 
<https://play.google.com/store/apps/details?id=com.flashnetworks.netmon&hl=de>


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