Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis

Joe Touch <touch@strayalpha.com> Sat, 14 December 2019 17:18 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BAE12009E for <multipathtcp@ietfa.amsl.com>; Sat, 14 Dec 2019 09:18:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Level:
X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKQbFK7AvEnm for <multipathtcp@ietfa.amsl.com>; Sat, 14 Dec 2019 09:18:30 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D971812006B for <multipathtcp@ietf.org>; Sat, 14 Dec 2019 09:18:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YQZWiRMnTO08bmsZOvfjZyUiu73s414AD+q0+yUgbp4=; b=25HqW39BYTKQQUnxN/Yoy1dnX crS6NOkZs0Qn2sHrxoL1U0pcRGln8I29sxeJuDYS3t7LNhA/sWiYJMhhdOL1alF6mgJKBm4Z2PJZf X4im3MEqTFWetAhKvvV7g29nD9WtXr5gRlJC95HhmS6uNE1shCHEOv52iL1BYyKkwmA8tK4gmj1mW CGLRkAv9OOw7E28uNsIbFaJ8t+Jw188CfXyU3dpFmWd42zh4f8cZndUXjIhzmpg3MsRoAYtDKNv2A KUGpEmSAgJM5NrISGZ89p4/+aIiMHT4arx4JUsr0TUQoYDJ7f8k7YVzn9yoCcClg0NWCdQK0oVVhY 7PMGfyCQg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:58231 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1igB3f-0000kv-WE; Sat, 14 Dec 2019 12:18:28 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_537517FA-CE59-431B-9A3E-80C4FE6CB3E4"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <fa6b23f5763c.5df53382@nic.in>
Date: Sat, 14 Dec 2019 09:18:22 -0800
Cc: Christoph Paasch <cpaasch@apple.com>, MultiPath TCP - IETF WG <multipathtcp@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, mptcp Upstreaming <mptcp@lists.01.org>
Message-Id: <A534F828-E876-454F-B734-1B5AC32FB027@strayalpha.com>
References: <fb16f29f7ecc.5df421a5@nic.in> <20191213182409.GB9430@MacBook-Pro-64.local> <fa7667443ba6.5df46de9@nic.in> <fa8982c55716.5df4db73@nic.in> <fa8986877804.5df4dc82@nic.in> <fb0db65e7ad2.5df4dd8e@nic.in> <fa90a0fa4d9e.5df4dfde@nic.in> <fa91bb215a0d.5df4e4fd@nic.in> <fa9985d3d9b.5df4e5ef@nic.in> <fa6b23f5763c.5df53382@nic.in>
To: V Anil Kumar <anil@csir4pi.in>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/QcGzWUauvg90BlqTGulAxOzGJTo>
Subject: Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Dec 2019 17:18:32 -0000


> On Dec 14, 2019, at 5:39 AM, V Anil Kumar <anil@csir4pi.in> wrote:
> 
>> The implementation needs to enforce a strict priority of DSS over SACK and ADD_ADDR.
> TCP options have evolved over a period of time, and I do not think as such any document/guidelines exist on  enforcing priority for one over the other, though it turns out be an interesting topic.  Also, more TCP options could come up in future for implementing  new features.  So, it is likely that implementations would follow different strategy when it come to option priority. 

FYI, this has come up as an issue before.

TCP options are individual and accepted in isolation. They are easily confirmed only during SYN exchange; anything after that requires a stateful, reliable transmission mechanism for coordination.

There is no way to retrofit any ordering constraints, or prioritization. If you need that sort of feature, it needs to be built inside a single option as “sub options”.

Joe