From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6F4254968F5 for ; Thu, 11 Jun 2026 17:18:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781198315; cv=none; b=MO8kaAvCzUg8ZDw2VTrGqZc+3gaq1qc9ApAlBtOVujXkCoUI4Kjr3Jq77oFKz13Pi0aKUMntIjAiudBOWrQWoZOc/UPfIS67fT7oXaQbwvxKNqUVIEhxP+dRp2+Ou22iecU0cTvPzHTjaC1RpzXIA2g4ML//9LP5mQXTYRqorcE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781198315; c=relaxed/simple; bh=kAobYEkJDMjkUITJUMNyBriLzXiAe6UXFHqVuVHGqxw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=W797cJN3rdPsdVsn3gVrlO9BX+d5omLZff6WEbo27yxp49C2/NToM3khP6mr8l7t7lF20DJ0qO4+fv8YkXDPtNmrhQgE2oQ4ll1LOl+6OKWE4VaK0FjWZDWouM7hGsCJz7Awm8Ml1Dd5ZY/XJ1Uc+UbGPULcSMltANRZSsHxLoI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=rHFYjUZJ; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rHFYjUZJ" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4903d730b1fso548255e9.2 for ; Thu, 11 Jun 2026 10:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781198305; x=1781803105; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=AoP+cy2ffp1XgHOvwchIi8ndfKfAxNydtkxTWle4y9Q=; b=rHFYjUZJM3ER+3l1P5F7c0asHSesLMxBRreOo5xHxWaSpz5JFbBzSMheMvRwtGY00C ED6S7FFQjyxwzgtkdjR88vGS7XIYkOVT0KpYt/z51EXpm28ub6yH6PD0bybk7sWq8I2M ecwjpl6yPxPt6/rxsk1GR3LilFiqDQxP9zC19aT99jlOAbRqai6b19Q90bac7pHJLq0D trRjI1vV50CL7W94D7Wh/+97+eft9R2v1yhMg9dq0GIW0MiTfbt0PjPyyru+aMKNKqg7 YxxXM2IwzCEpfz6NQ6rAs/eD+CfEpnQjTJB70WgYyVMfSXQvQYIJ07IakbCQ2hr+c4to mVwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781198305; x=1781803105; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AoP+cy2ffp1XgHOvwchIi8ndfKfAxNydtkxTWle4y9Q=; b=gpqVPv9g87SYNr0cvSzkKS2uDJOYdWhQiWaMAbFNnOpLPq4vINKX7HdJvw+tiOKsmU B+0qiYAaCErf5rIvXybA8loHcBQ/626aupBUn64PbhmCmtuW5K9+Fi+Zqpybm0uDYkgF I8chFil8RVH5x0WvHwvaweLqBSr1DAfQXm0L8xbS9QzZunYJ6+H8sxfd19T2zRFtx70j cAHDot8Hye3CrOco2p70VuWbgxDIG7rpP28W9sZTdFhPSjkNpx0yDhrv4IcHmVnRxcBH 4tGjSF7pQ8qqVgjvzCMAcpU0SdTGblSF8Rj01+sjzInkVtqEiuHltgDzWQ++gjH3U4yU vyYw== X-Forwarded-Encrypted: i=1; AFNElJ+L0PcONmMva9iPVA34BBkBXoCbEFY27yRhIuMvGfw5X7/k1lIX5IoK7dfOs5lDSHTp5i7gAQbhlmvrCyo=@vger.kernel.org X-Gm-Message-State: AOJu0YyR2MWhCJWfd9s7XvkQC74RzA8gcXLSWIjZ2+yFgOFPYodCmksq 9ubyu28dWMDalw86SWE/0/tloKEkeTVUSVL2ZnDexy+64Y/tGqU/0tl+ X-Gm-Gg: Acq92OGaLmOk89QSvtLHHDcRpt0CG5FukXQwI7yfN6JG5I03UdDjsNw10dIOxvJ+cXw bcSNtVK6Zfa0ZbL0xvhkF7zscMmLB/f9Twyy7Oi5eehO8Lb52imnZqGOgQn17n53T9qNWr/S2oD eFyttnd56EmawLuPnGZop4b9vbSRKdkggFyq1X2Sr6p7lfm9dPqEWqJ5x8Ug/0T84HHgL0LKFcK m4BdSZvihei3i/4MZajluM1+jpnkXnr8IfI7bOPVRLz8OfdFl76+WbcuSwCiyrprLQpbRzqPuYR QeJUCyDGGxnQwNwX3DqZwn8MPxeKUUVf10bKHe0RazAZYnMgoyHit+0o3/WjAbLz+RkroPmRVL+ Zepme99x0443BUHWdXKkNM/BpTqEsr2Shkx1YlhQzP0sXFbFvxyeL5dICt5L4xmUTSRGkdDY8aj 9ztqm+dqeINUnsW+JrHESZYnxzM6xto506uHdEQMS11HKopCJ36HziP4OcbEY= X-Received: by 2002:a05:600c:4e04:b0:490:b9d3:a9ce with SMTP id 5b1f17b1804b1-490e5640aa8mr56905655e9.30.1781198305135; Thu, 11 Jun 2026 10:18:25 -0700 (PDT) Received: from gandalf.schnuecks.de (p5b2e2404.dip0.t-ipconnect.de. [91.46.36.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4606c10435dsm335137f8f.35.2026.06.11.10.18.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jun 2026 10:18:24 -0700 (PDT) Received: by gandalf.schnuecks.de (Postfix, from userid 500) id 0C018319F7E6; Thu, 11 Jun 2026 19:18:24 +0200 (CEST) Date: Thu, 11 Jun 2026 19:18:23 +0200 From: Simon Baatz To: "Matthieu Baerts (NGI0)" Cc: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, Neal Cardwell , Kuniyuki Iwashima Subject: Re: [PATCH net-next v2 05/15] tcp: allow mptcp to drop TS for some packets Message-ID: References: <20260605-net-next-mptcp-add-addr6-port-ts-v2-0-758e7ca73f4d@kernel.org> <20260605-net-next-mptcp-add-addr6-port-ts-v2-5-758e7ca73f4d@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260605-net-next-mptcp-add-addr6-port-ts-v2-5-758e7ca73f4d@kernel.org> 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 and contain TSopt, the TSopt MUST be sent in every non- segment for the duration of the connection, [...] If a non- 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