From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Frederic Sowa Subject: Re: Add a SOCK_DESTROY operation to close sockets from userspace Date: Thu, 19 Nov 2015 23:09:16 +0100 Message-ID: <1447970956.3057330.444776169.61AEFA6C@webmail.messagingengine.com> References: <20151119.005318.838757439536205791.davem@davemloft.net> <20151119.104811.1447518072450380661.davem@davemloft.net> <1447949964.22599.220.camel@edumazet-glaptop2.roam.corp.google.com> <1447969264.22599.253.camel@edumazet-glaptop2.roam.corp.google.com> <1447969982.3054314.444761185.363F62E7@webmail.messagingengine.com> <1447970641.22599.261.camel@edumazet-glaptop2.roam.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Tom Herbert , David Miller , zenczykowski , Lorenzo Colitti , Stephen Hemminger , Linux Kernel Network Developers , Eric Dumazet , Erik Kline , Dmitry Torokhov To: Eric Dumazet Return-path: Received: from out5-smtp.messagingengine.com ([66.111.4.29]:44311 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759342AbbKSWJR (ORCPT ); Thu, 19 Nov 2015 17:09:17 -0500 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 3BF94204F0 for ; Thu, 19 Nov 2015 17:09:17 -0500 (EST) In-Reply-To: <1447970641.22599.261.camel@edumazet-glaptop2.roam.corp.google.com> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, Nov 19, 2015, at 23:04, Eric Dumazet wrote: > On Thu, 2015-11-19 at 22:53 +0100, Hannes Frederic Sowa wrote: > > > > > You don't steer QUIC source addresses at all? I think most networking > > failures are of transient nature thus the kernel routing subsystem is > > not aware of link quality and packets get lost anyway e.g. in the air? > > Thus binding on multiple interfaces and keepalives seem still > > appropriate, no? > > Imagine you are in your home near a wifi AP, then you close a door and > switch to 3G, or another AP. > > No down time. packet will eventually reach its destination. > > Application does not have to care. > > Why QUIC should absolutely use '4-tuple UDP connections' when this is > likely to fail in this scenario ? My point is the "eventually" and the very much increased latency until the kernel learns about new better source addresses it has available. I would monitor link quality over time and decide source address based on this on the sending side.