From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============4473592432319381799=="
MIME-Version: 1.0
From: Florian Westphal <fw at strlen.de>
To: mptcp at lists.01.org
Subject: [MPTCP] Re: [PATCH mptcp-next 0/3] mptcp: add fastclose option
Date: Thu, 26 Nov 2020 15:44:29 +0100
Message-ID: <20201126144429.GF2730@breakpoint.cc>
In-Reply-To: 36da4a96-332b-5d17-54c8-1e37b730af59@tessares.net
X-Status: 
X-Keywords:                  
X-UID: 6953

--===============4473592432319381799==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Matthieu Baerts <matthieu.baerts(a)tessares.net> wrote:
> On 25/11/2020 18:49, Florian Westphal wrote:
> > I plan to hold the MPTCP reset patches back for the time being until
> > netlink + mptcpd are aware of its existence.
> =

> I certainly missed something here but are you here talking about MP_TCPRST
> support? Or still about the send of fast-close?

Oh, no, I jumped off the fastclose train here.  This is only wrt. MP_TCPRST.
Another approach would be to add the *send side* for tcprst first,
perhaps it helps with tcpdump deciphering.

But for RX there is really no point when the kernel can't pass that
information along to a consumer such as mptcpd.

> If it is about fast-close, why netlink + mptcpd needs to be aware first?
> Could we eventually send fast-close when the userspace app (here using
> packetdrill format) does this:
> =

>     setsockopt(<fd>, SOL_SOCKET, SO_LINGER, {onoff=3D1, linger=3D0}, 8);
>     close(<fd>);
> =

> (if we accept this socket option)
> No rush of course, just in case these patches were already written :)

Yes, I think it might make sense to allow userspace to generate a
fastclose at will.

The last iteration I sent autogenerated a fastclose for the 'unread data
in socket queue when userspace called close' case, which is analogous to
what the linux TCP stack does when you close with unread data in the
local socket.

But I think extending it to linger makes sense as well.
--===============4473592432319381799==--