From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9AAAE4C68 for ; Fri, 18 Feb 2022 20:35:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645216555; x=1676752555; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=W+wXDZJ5Avml2vqDJodmKpvCfp0yKQ2rmd4zmrGYmyo=; b=lTx0V5vcEtGdCh961q6tRzitI1Gp/ML9491MQQpGClJDwUGJvzfbioCa glzHJCWDGrrgp0wWma7868NTHF9IPpIFmaNqKSFP0Ldnoyq9AHPGO+9Kr jRrN3QjCSQShRFzvKJAV3PkqSLEgzoPgJSt286WsAnKymdzqblFNK6j58 45To1tKK+7Sw4Pu0udAhuAmpR9FcCVrM3P9GFfRHqbPU8sq5Gqa8WOsgi T75cKHO6ZG4R9dBWwLO/85WAMSU9frFB0VVRQFrbYe0mwb3PHqcHv2sqZ 1LmrvVO+pGYyHN9nsKdUlrvfShCgBFjqSSOnF73M35YUZy5NYpJ8fWbWG g==; X-IronPort-AV: E=McAfee;i="6200,9189,10262"; a="250969693" X-IronPort-AV: E=Sophos;i="5.88,379,1635231600"; d="scan'208";a="250969693" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2022 12:35:54 -0800 X-IronPort-AV: E=Sophos;i="5.88,379,1635231600"; d="scan'208";a="504131067" Received: from yungjihy-mobl1.amr.corp.intel.com ([10.209.64.253]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2022 12:33:54 -0800 Date: Fri, 18 Feb 2022 12:33:54 -0800 (PST) From: Mat Martineau To: Paolo Abeni cc: mptcp@lists.linux.dev Subject: Re: [PATCH v5 mptcp-next 0/4] mptcp: more self-tests improvements In-Reply-To: <5098f08134c9cb059b32bcce363f466bd1f2df2f.camel@redhat.com> Message-ID: References: <7a175aba-a3d9-f2d0-fee8-5f616c999013@linux.intel.com> <5098f08134c9cb059b32bcce363f466bd1f2df2f.camel@redhat.com> Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed On Fri, 18 Feb 2022, Paolo Abeni wrote: > On Thu, 2022-02-17 at 17:35 -0800, Mat Martineau wrote: >> On Thu, 17 Feb 2022, Paolo Abeni wrote: >> >>> This iteration tries to address the feedback from Mat on v4. >>> >>> patch 1/4 is new and tries to address the problem behind issues/225 with >>> stricted RFC compliance >>> patch 2 and 3 clean-up endpoint management as per past discussion >>> patch 4 introduce new self-tests, as deserved the previous patch >>> >> >> Hi Paolo - >> >> These changes and tests are working well on my system and fits with what >> we discussed on the previous revisions - thanks! >> >> I was taking another look at the RFC and saw this paragraph: >> >> The MP_JOIN option includes an "Address ID". This is an identifier >> generated by the sender of the option, used to identify the source >> address of this packet, even if the IP header has been changed in >> transit by a middlebox. The numeric value of this field is generated >> by the sender and must map uniquely to a source IP address for the >> sending host. The Address ID allows address removal (Section 3.4.2) >> without needing to know what the source address at the receiver is, >> thus allowing address removal through NATs. The Address ID also >> allows correlation between new subflow setup attempts and address >> signaling (Section 3.4.1), to prevent setting up duplicate subflows >> on the same path, if an MP_JOIN and ADD_ADDR are sent at the same >> time. >> >> That made me wonder if we are supposed to treat this address ID as a type >> of advertisement which would require us to not reuse id 0? I think the >> answer is "no" because nothing in the REMOVE_ADDR section (3.4.2) seems to >> apply to joins, and it's also pretty permissive about not sending >> REMOVE_ADDR. We also won't be sending REMOVE_ADDR for id 0, so the new >> code seems safe in that regard. > > Double checking if I parsed the above correctly. The main > point/question is: which ID should use additional MPJ subflows with the > same source address of the initial MPC subflow? My answer/what the > current code is doing prior and after this patch is 'id 0'. I read the > above as this is also your answer. > > Please correct me if I misinterpret something! > That's part of it. I also wasn't sure if the MPJ syn could also be sent with addr id 0 if the kernel picked some other interface for sending that syn that had not been configured in the path manager - a corner case that I thought had been mentioned earlier in discussion of this patch series. If the outgoing MPJ only has addr id 0 if the MPC source addr is used then that's definitely not any kind of problem. -- Mat Martineau Intel