Re: [PATCH mptcp-next RFC v4 2/2] mptcp: send MP_FAIL and infinite mapping on the same ACK

Hi Chenguang,

On 19/08/2026 13:16, Chenguang Zhao wrote:
> 
> 在 2026/8/19 00:19, Matthieu Baerts 写道:
>> Hi Chenguang,
>>
>> On 18/08/2026 11:14, Chenguang Zhao wrote:
>>> From: Chenguang Zhao <[email protected]>
>>>
>>> On a single subflow, accepting MP_FAIL must leave MPTCP mode at once
>>> (RFC8684 §3.7). Emit the infinite mapping on the MP_FAIL reply ACK,
>>> then call mptcp_try_fallback() immediately after.
>> I think Sashiko is right about the issue of lacking option space to have
>> both the MP_FAIL and the infinite mapping sent together.
> Yes, Sashiko is right, I did not consider all the aspects.
>> Please also note this from RFC 8684 §3.7.11 [1]:
>>
>>> This infinite mapping will be a DSS option (Section 3.3) on the first
>>> new packet, containing a Data Sequence Mapping that acts retroactively
>> The "on the first new packet" seems to suggest the infinite mapping
>> shouldn't be attached to the MP_FAIL.
>>
>> [1] https://datatracker.ietf.org/doc/html/rfc8684#section-3.7-11
>>
>>
>> Maybe a fallback for the single subflow without csum is enough? Or maybe
>> nothing needs to be done? Or maybe this fallback is just an
>> optimisation, and can be done in net-next (and both commits can be
>> combined)? WDYT?
> 
> Hi Matthieu
> 
> I am getting a bit confused, so let me summarize my current understanding to verify if I got this right.
> In the existing kernel code, fallback will be triggered upon receiving MP_FAIL. However, the FALLBACK_DONE
> flag is currently set inside mptcp_update_infinite_map(), which only gets invoked when transmitting a data packet.
> This creates a timing window between receiving MP_FAIL and sending the first subsequent packet, resulting in this minor bug.
> Our goal is to close this timing window: set the FALLBACK_DONE flag immediately after MP_FAIL is received.
> Besides, add a __mptcp_check_fallback() check within mptcp_can_accept_new_subflow() to reject MP_JOIN requests ahead of time.
> 
> Is my understanding correct? I will send out a v5 RFC based on the above ideas.      

I'm not sure that it can work: if there is a fallback, no MPTCP options
are supposed to be sent after that point. That's why the fallback should
be done after having sent the infinite mapping.

I didn't check in the details: *maybe* the fully_established bit could
be reset earlier in some cases, but it feels like it can only be done
when a fallback can be done, so never had extra subflows or reinjection,
and no checksum. But then again, in this case, we are not supposed to
receive an MP_FAIL. Then why bother and not simply fallback, and that's
it, no?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.