[MPTCP] Re: [RFC PATCH] mptcp: better msk receive window updates

[MPTCP] Re: [RFC PATCH] mptcp: better msk receive window updates

[Florian Westphal]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

Paolo Abeni <pabeni(a)redhat.com> wrote:
> In teory, even MPTCP level retransmissions should kick-in, but the
> current pkt scheduler implementation for re-injection
> (mptcp_subflow_get_retrans) always decice to do nothing, as the subflow
> is _not_ in a lossy CA state.

Retrans skips subflows in lossy CA state, not the other way around?

[MPTCP] Re: [RFC PATCH] mptcp: better msk receive window updates

[Paolo Abeni]

[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]

On Fri, 2021-02-05 at 09:26 +0100, Paolo Abeni wrote:
> On Thu, 2021-02-04 at 23:23 +0100, Paolo Abeni wrote:
> > Move mptcp_cleanup_rbuf() related checks inside the mentioned
> > helper and extend them to mirror more closely TCP ones. To implement
> > them we need to track the subflows mss and the ack_seq delta.
> > Do not relay anymore on tcp_cleanup_rbuf() and send ack explicitly.
> 
> The more I think a about this, the more it looks like a workaround
> instead of a real fix for the still vague root cause. Please keep this
> on-hold.

This is targeting issues/147.

The timeout happens on monodirectional connections (the other way has
already shutdown) when the sender fills completely the MPTCP snd wnd
and the peer, by it's own logic -
mptcp_cleanup_rbuf()+tcp_cleanup_rbuf(), decides to not send the ack
after that for the chunk filling the window has been read by the user-
space.

The above should be possible even for plain TCP, where retransmission
will save the day - but I was unable to trigger that scenario easily.

In teory, even MPTCP level retransmissions should kick-in, but the
current pkt scheduler implementation for re-injection
(mptcp_subflow_get_retrans) always decice to do nothing, as the subflow
is _not_ in a lossy CA state.

I'm unsure how to proceeed. The proposed patch should address the
issue, but likely introduces a lot of unneeded acks and is quite an
hack.

A possible alternative would be scheduling 0win probes even with
pending data - likely an even uglier hack.

Or we could rework mptcp_subflow_get_retrans() to fit this scenario,
but that will possibly (likely???) break active backup.

Or ... ????

Any suggestion more then welcome!

/P

[MPTCP] Re: [RFC PATCH] mptcp: better msk receive window updates

[Paolo Abeni]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

On Thu, 2021-02-04 at 23:23 +0100, Paolo Abeni wrote:
> Move mptcp_cleanup_rbuf() related checks inside the mentioned
> helper and extend them to mirror more closely TCP ones. To implement
> them we need to track the subflows mss and the ack_seq delta.
> Do not relay anymore on tcp_cleanup_rbuf() and send ack explicitly.

The more I think a about this, the more it looks like a workaround
instead of a real fix for the still vague root cause. Please keep this
on-hold.

> Additionally drop the 'rmem_pending' hack, since commit 879526030c8b
> ("mptcp: protect the rx path with the msk socket spinlock") we
> can use instead 'rmem_released'.

This part instead looks good and deserve a patch of its own.

/P