Re: [PATCH net-next v2 05/15] tcp: allow mptcp to drop TS for some packets

[Matthieu Baerts <matttbe@kernel.org>]

Hi Simon,

Thank you for you review.

11 Jun 2026 19:18:29 Simon Baatz <gmbnomis@gmail.com>:

> Hi Matt,
>
> On Fri, Jun 05, 2026 at 07:21:49PM +1000, Matthieu Baerts (NGI0) wrote:
>> With TCP-timestamps (padded) taking 12 bytes and ADD_ADDR IPv6 + port
>> taking 30 bytes, the 40-byte limit for the TCP options is reached. In
>> this case, it is then not possible to send the address signal.
>>
>> The idea is to let MPTCP dropping the TCP-timestamps option for some
>> specific packets, to be able to send some specific pure ACK carrying >28
>> bytes of MPTCP options, like with this specific ADD_ADDR. A new
>> parameter is passed from tcp_established_options to the MPTCP side to
>> indicate if the TCP TS option is used, and if it should be dropped. The
>> next commit implements the part on MPTCP side, but split into two
>> patches to help TCP maintainers to identify the modifications on TCP
>> side. This feature will be controlled by a new add_addr_v6_port_drop_ts
>> MPTCP sysctl knob.
>>
>> It is important to keep in mind that dropping the TCP timestamps option
>> for one packet of the connection could eventually disrupt some
>> middleboxes: even if it should be unlikely, they could drop the packet
>> or even block the connection. That's why this new feature will be
>> controlled by a sysctl knob.
>
> RFC 7323 (which obsoletes RFC 1323) specifies an "all or nothing"
> approach for the TS option.  Section 3.2 states:
>
>    Once TSopt has been successfully negotiated, that is both <SYN> and
>    <SYN,ACK> contain TSopt, the TSopt MUST be sent in every non-<RST>
>    segment for the duration of the connection, [...] If a
>    non-<RST> segment is received without a TSopt, a TCP SHOULD silently
>    drop the segment.
>
> So, selectively omitting the TS option on established subflows
> appears to go against RFC 7323 at the TCP level.  Do we consider that
> an acceptable deviation for MPTCP subflows?

Yes, to me, it is acceptable. Please note that here, TCP TS is only
dropped on some specific packets -- ADD_ADDR with v6 + port --
which are TCP pure ACK acking the same sequence as the previous
one (dupack from a TCP point of view). So it is just a signalling packet,
specific to MPTCP. If it is dropped by a middlebox, that's not nice, but
that's OK.

Or do you think something would break when this happens?

One last thing: sending an ADD_ADDR with v6 + port is certainly
specific to some use-cases, most connections will not do that.

> (Maybe I am missing something obvious here, but I couldn't find any
> prior discussion on this aspect.)

The discussions were on the MPTCP mailing list and bug tracker.

Cheers,
Matt