August 12, 2026 at 11:32 PM, "Matthieu Baerts" <[email protected] mailto:[email protected]?to=%22Matthieu%20Baerts%22%20%3Cmatttbe%40kernel.org%3E > wrote:
>
> Note: Chenguang is looking at a bug where, when an MP_FAIL is received
> before being in fully_established, the kernel accept going to fully
> established, and creating new subflows, then reject them once done.
>
> Same when receiving a 4th packet without MPTCP options.
>
> I think the MP_FAIL should do a fallback if possible, but it is probably
> also required to check the fallback status or something similar when
> receiving an MPJ.
Hi, Matt
Sorry, I'm not very familiar with the details of this patch.
No offense intended, I just have a question I'd like to ask based on my
understanding and the RFC documentation: Should MP_FAIL trigger a fallback?
For the multiple‑subflow case, if one subflow encounters an MP_FAIL, it should
be closed with a RST, and the data will be retransmitted over the other healthy
subflows. This should not cause the entire MPTCP connection to fallback to regular
TCP, right?
RFC8684's contents:
'''
The receiver of this option MUST discard all data following the data sequence number
specified. Failed data MUST NOT be DATA_ACKed and so will be retransmitted on other subflows.
'''
For the single‑subflow case, according to the RFC, MP_FAIL should subsequently
lead to a fallback under the infinite mapping (INFINITEMAP) situation, shouldn't it?
RFC 8684's contents:
'''
A special case is when there is a single subflow and it fails with a checksum error.
If it is known that all unacknowledged data in flight is contiguous (which will usually
be the case with a single subflow), an infinite mapping can be applied to the subflow
without the need to close it first, essentially turning off all further MPTCP signaling.
'''
Thanks
Gang
>
> >
> > I would prefer avoiding additional conditionals, if not well reasoned.
> >
> Agreed, the commit messages in this series are not explaining (enough)
> the reason and the context.
>
> BTW, Chenguang, please use 'mptcp-net' for fixes (and mptcp-next for
> features). Also fixes should have a Fixes tag.
>
> Cheers,
> Matt
> --
> Sponsored by the NGI0 Core fund.
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.