IETF Logo Mail Archive

Re: [multipathtcp] Consensus call on potential MPTCP proxy work

<mohamed.boucadair@orange.com> Fri, 21 April 2017 06:55 UTC

Return-Path: <mohamed.boucadair@orange.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 03580128DF3 for <multipathtcp@ietfa.amsl.com>; Thu, 20 Apr 2017 23:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Level:
X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, T_SPF_PERMERROR=0.01, UNPARSEABLE_RELAY=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 yqFl198lIPgQ for <multipathtcp@ietfa.amsl.com>; Thu, 20 Apr 2017 23:55:28 -0700 (PDT)
Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7050B126C83 for <multipathtcp@ietf.org>; Thu, 20 Apr 2017 23:55:28 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id CE52B20525; Fri, 21 Apr 2017 08:55:26 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 9D8784005D; Fri, 21 Apr 2017 08:55:26 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0319.002; Fri, 21 Apr 2017 08:55:26 +0200
From: mohamed.boucadair@orange.com
To: "Eggert, Lars" <lars@netapp.com>
CC: Philip Eardley <philip.eardley@bt.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work
Thread-Index: AdK4HBNYFYN3Pf6Ey0Kw29UUSw2QvQCSLSEAAAB3NgAAAGWgAAAAJCvQ
Date: Fri, 21 Apr 2017 06:55:25 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E51D65@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.com>
In-Reply-To: <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/sFkMx98ZW2BcRZ_omPd16wv7w0M>
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 21 Apr 2017 06:55:30 -0000

Re-,

The initial message form Phil includes the following: "We believe the work does not require an update to the MPTCP WG charter". So, the proposal is not to modify the MPTCP WG charter to cover the proxy work (the WG charter already covers "MPTCP-aware middlebox" work), but to decide which technical approach to follow for that item in the charter.

I hopped you can explicit why "MPTCP is architecturally the wrong starting point". This is not obvious to me. Sorry but I'm a fun of https://tools.ietf.org/html/rfc7282#section-4 (Humming should be the start of a conversation, not the end). 

Lacking that information, I don't see a new element here that could lead to change the consensus reached at the Chicago meeting (of course I'm not entitled to do that call anyway). 

Cheers,
Med

> -----Message d'origine-----
> De : Eggert, Lars [mailto:lars@netapp.com]
> Envoyé : vendredi 21 avril 2017 08:27
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Philip Eardley; multipathtcp@ietf.org
> Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work
> 
> Hi,
> 
> On 2017-4-21, at 8:15, mohamed.boucadair@orange.com wrote:
> > I don't see any technical argument in your message.
> 
> we're not asked to have a technical discussion. We're asked whether we
> support this work in MPTCP, and I don't, for the reasons stated. I think
> MPTCP is architecturally the wrong starting point for solutions to this
> operator problem space.
> 
> > Is it respectful for people to cite April 1 in a serous technical
> discussion?
> 
> I provided the reference, because it summarizes my standpoint in a - what
> I consider - humorous way. I do apologize if this caused offense. As I
> said, I do believe that you can bang MPTCP out of shape to make it do
> what's needed here - but that is true for other existing starting points,
> some of which might be a more natural fit. Or not - that's not the
> question we're asked to answer here.
> 
> Lars

v2.23.0 | Report a Bug | By Email