From patchwork Fri Dec 13 00:58:22 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mat Martineau X-Patchwork-Id: 1208924 X-Patchwork-Delegate: matthieu.baerts@tessares.net Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.01.org (client-ip=198.145.21.10; helo=ml01.01.org; envelope-from=mptcp-bounces@lists.01.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.intel.com Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 47Ysjx2WBdz9sQp for ; Fri, 13 Dec 2019 11:58:45 +1100 (AEDT) Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id D5CB21011369C; Thu, 12 Dec 2019 17:02:02 -0800 (PST) Received-SPF: None (mailfrom) identity=mailfrom; client-ip=192.55.52.88; helo=mga01.intel.com; envelope-from=mathew.j.martineau@linux.intel.com; receiver= Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 989DF1011367D for ; Thu, 12 Dec 2019 17:02:00 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2019 16:58:37 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,307,1571727600"; d="scan'208";a="296773954" Received: from mjmartin-nuc02.mjmartin-nuc02 (HELO mjmartin-nuc02.sea.intel.com) ([10.251.17.224]) by orsmga001.jf.intel.com with ESMTP; 12 Dec 2019 16:58:37 -0800 From: Mat Martineau To: mptcp@lists.01.org Cc: Mat Martineau Date: Thu, 12 Dec 2019 16:58:22 -0800 Message-Id: <20191213005822.29791-7-mathew.j.martineau@linux.intel.com> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20191213005822.29791-1-mathew.j.martineau@linux.intel.com> References: <20191213005822.29791-1-mathew.j.martineau@linux.intel.com> MIME-Version: 1.0 Message-ID-Hash: Z5QCSCWG5YQZQUUNHIL447LTJEW56G5B X-Message-ID-Hash: Z5QCSCWG5YQZQUUNHIL447LTJEW56G5B X-MailFrom: mathew.j.martineau@linux.intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.1.1 Precedence: list Subject: [MPTCP] [PATCH] .topmsg: mptcp: process MP_CAPABLE data option List-Id: Discussions regarding MPTCP upstreaming Archived-At: <> List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Mention RFC 8684, minor spelling fixes and stuff. Signed-off-by: Mat Martineau --- .topmsg | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/.topmsg b/.topmsg index 405b188083ea..0f79c41044b2 100644 --- a/.topmsg +++ b/.topmsg @@ -1,12 +1,12 @@ From: Christoph Paasch -Subject: [PATCH] mptcp: process MP_CAPABLE data option. +Subject: [PATCH] mptcp: process MP_CAPABLE data option -This patch implement the handling of MP_CAPABLE + data option, as -per RFC 6824 bis - MPTCP v1. +This patch implements the handling of MP_CAPABLE + data option, as per +RFC 6824 bis / RFC 8684: MPTCP v1. On the server side we can receive the remote key after that the connection is established. We need to explicitly track the 'missing remote key' -status and avoid emtting mptcp ack till we get such info. +status and avoid emitting a mptcp ack until we get such info. When a late/retransmitted/OoO pkt carrying MP_CAPABLE[+data] option is received, we have to propagate the mptcp seq number info to @@ -16,8 +16,8 @@ that in recvmsg(), where we own msk and subflow sock locks. The above also means that an established mp_capable subflow - still waiting for the remote key - can be 'downgraded' to plain TCP. -Such change could potentially block forever reader waiting for new -data - as they hook to msk, while later wake-up after the downgrade +Such change could potentially block a reader waiting for new data +forever - as they hook to msk, while later wake-up after the downgrade will be on subflow only. The above issue is not handled here, we likely have to get rid of