Re: Add a SOCK_DESTROY operation to close sockets from userspace

[Hannes Frederic Sowa <hannes@stressinduktion.org>]

On Thu, Nov 19, 2015, at 22:41, Eric Dumazet wrote:
> On Thu, 2015-11-19 at 13:29 -0800, Tom Herbert wrote:
> > > We (TCP stack) compete with QUIC, based on UDP, which has no issues like
> > > that. We need to allow TCP sessions being signaled of a non temporary
> > > network disruption.
> > >
> > 
> > Eric, can you provide some detail on this statement?
> > 
> > I don't understand why QUIC wouldn't have this same issue. Seems like
> > it is still connection oriented just like TCP, so if the application
> > does a read expecting data from a peer and reverse reachability is
> > lost, the the read on the socket hang just like reading a TCP would.
> > If this is true, then the TCP solution would might actually be a
> > better since it allows a means for a third party (presumably a daemon
> > monitoring the network) to signal the application via closing specific
> > TCP sockets. I don't see how this could work in UDP especially if
> > these are unconnected sockets. What am I missing?
> 
> Quic simply sends UDP packets to a destination IP, port 443 (generally)
> 
> Say your UDP client binds to 0.0.0.0:<allocated/ephemeral port>
> 
> Kernel pick up source address given current working routing, on a per
> packet basis.
> 
> Their notion of 'flow' is provided by the use of an unique connection
> ID, included somewhere in the payload.
> 
> The replies from QUIC server will then reach the UDP port, because
> server learned the latest source IP known for the client.

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?

Bye,
Hannes