IETF Logo Mail Archive

Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis

V Anil Kumar <anil@csir4pi.in> Sun, 15 December 2019 14:20 UTC

Return-Path: <prvs=245d99bcc=anil@csir4pi.in>
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 0EAF8120047 for <multipathtcp@ietfa.amsl.com>; Sun, 15 Dec 2019 06:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 HdQB-5zWOdJK for <multipathtcp@ietfa.amsl.com>; Sun, 15 Dec 2019 06:20:33 -0800 (PST)
Received: from vastu26.nic.in (vastu26.nic.in [164.100.10.73]) (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 B74EF12001A for <multipathtcp@ietf.org>; Sun, 15 Dec 2019 06:20:31 -0800 (PST)
IronPort-PHdr: 9a23:uQDpyBSHpD+ycQhx1WJruwivYdpsv+yvbD5Q0YIujvd0So/mwa69YhaN2/xhgRfzUJnB7Loc0qyK6vumAzRaqsnQ+Fk5M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aFRrwLxd6KfroEYDOkcu3y/qy+5rOaAlUmTaxe7x/IAi4oAnLqMUanZVuJqkzxxbNv3BFZ/lYyWR0KFyJgh3y/N2w/Jlt8yRRv/Iu6ctNWrjkcqo7ULJVEi0oP3g668P3uxbDSxCP5mYHXWUNjhVIGQnF4wrkUZr3ryD3q/By2CiePc3xULA0RTGv5LplRRP0lCsKMSMy/XrJgcJskq1UvBOhpwR+w4HKZoGVKOF+db7Zcd8DWGZNQtpdWylHD4ihbYUAEvABMP5YoYfjpFUAoxywCxSoBOztxD9FnWX50bEg3uQlCwzKwA4tEtQTu3rUttX1M6ISXPi6w6LV0TjDafJW2TPg44bNbxAhpOuDXahtesfW00YvEQLFjlGLpIP5JDOV1/4NvmeD7+phT+6vimgnphh3rzOyxckskpHEip8Rx1za7yl13Yc4KN6iREJme9KoDoZcuiOCO4drTM4vQXtktSI4x7EcpJK3YiYHxI4oyhPcbfGMbpKG7Qj5VOmLJDd1nHdleLWiiBms6UWg0ej8VtWs0FZNsypFjsHAtnAT2BzX7ciKUv598V2g2TaLzQzT5eZEIV4umaraLZ4t2r8wlpwNvkTfBiL6hUH7gLGMekk5++Wl6P7rbqj8qpOCKoN5iBnyMqE0lcy+BeQ4PBIOX2+e+emkzrLj+0z5QLFRg/IqianZsYraKMsDpq64GQNV04Aj5w6lDzi6yNQYgWUHLFVddRKCkojpP03OIPHgDfiln1SskCtryOzePrD6A5XCMGTDkLn7cbZ68U5cx1l78dcKxZVZQo0GPfnzEhvts8HTDjciLxa90u/jENV0kIgZXDTcLLWeNfbs+XaO5+ZnAPSJbZVd7D/7KvwN7OXvlyMhmBkce//6jtMsdHmkE6E+cA2ian32j4JESD9Ssw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2F2AACrQPZd/9kBqMBlGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYF+gRxYgkkKlTCbLwkBAQIBAQEBATcBAYRAAoI0OBMCAwEMAQEBBAEBAQEBBQMBAQEChVRYgjspAYNPAQU9DQgnEAEKDQsJJQ9IBgsItEcaAoNNhmSBNoFlikcGggCBEYMTPoEEiTMEl06IEI8cgj6WII5TFAOLXqkrAYF6gXtNOIMnUBGNPoEPAQeNH2yQQwEB
X-IPAS-Result: A2F2AACrQPZd/9kBqMBlGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYF+gRxYgkkKlTCbLwkBAQIBAQEBATcBAYRAAoI0OBMCAwEMAQEBBAEBAQEBBQMBAQEChVRYgjspAYNPAQU9DQgnEAEKDQsJJQ9IBgsItEcaAoNNhmSBNoFlikcGggCBEYMTPoEEiTMEl06IEI8cgj6WII5TFAOLXqkrAYF6gXtNOIMnUBGNPoEPAQeNH2yQQwEB
X-IronPort-AV: E=McAfee;i="6000,8403,9471"; a="311046809"
X-IronPort-AV: E=Sophos;i="5.69,317,1571682600"; d="scan'208,217";a="311046809"
Received: from unknown (HELO mail.gov.in) ([192.168.1.217]) by vastu9internal.nic.in with ESMTP; 15 Dec 2019 19:50:27 +0530
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_6/0qJeHl4V954bH4XMGGcw)"
Received: from nic.in ([192.168.1.217]) by dr-msgfe10.nic.in (Oracle Communications Messaging Server 7.0.5.34.0 64bit (built Oct 14 2014)) with ESMTPA id <0Q2K00B075638800@dr-msgfe10.nic.in> for multipathtcp@ietf.org; Sun, 15 Dec 2019 19:50:27 +0530 (IST)
Sender: anil@csir4pi.in
Received: from [192.168.1.217] (Forwarded-For: 137.97.123.48) by dr-msgfe10.nic.in (mshttpd); Sun, 15 Dec 2019 19:50:27 +0530
From: V Anil Kumar <anil@csir4pi.in>
To: Joe Touch <touch@strayalpha.com>
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: <fa91c3e72444.5df68e83@nic.in>
Date: Sun, 15 Dec 2019 19:50:27 +0530
X-Mailer: Oracle Communications Messenger Express 7.0.5.34.0 64bit (built Oct 14 2014)
Content-language: en
X-Accept-Language: en
Priority: normal
In-reply-to: <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> <A534F828-E876-454F-B734-1B5AC32FB027@strayalpha.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/n2squp-XWveHiZQuwgM_syFfX9o>
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: Sun, 15 Dec 2019 14:20:36 -0000

Hi Joe,

On 12/14/19 10:48 PM, Joe Touch  <touch@strayalpha.com> wrote: 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > 
> > 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”.
> 
> 
> 
> 
>  
> 

Thank you for sharing this information.
I agree with this. 
Anil

> 
> 
> 
> 
> 
> Joe
> 
> 
>  
>

v2.23.0 | Report a Bug | By Email