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

[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?

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

 
-- 
Simon Baatz <gmbnomis@gmail.com>