IETF Logo Mail Archive

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

<mohamed.boucadair@orange.com> Wed, 19 July 2017 18:43 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564D6127180; Wed, 19 Jul 2017 11:43:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 FJMYxFPhfnyW; Wed, 19 Jul 2017 11:43:19 -0700 (PDT)
Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1511267BB; Wed, 19 Jul 2017 11:43:18 -0700 (PDT)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 6171AC051F; Wed, 19 Jul 2017 20:43:17 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 2F83B20071; Wed, 19 Jul 2017 20:43:17 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 20:43:16 +0200
From: mohamed.boucadair@orange.com
To: Joe Touch <touch@isi.edu>, Olivier Bonaventure <olivier.bonaventure@tessares.net>, Internet Area <int-area@ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>
Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP
Thread-Index: AQHTAK4x0P3r/ocVwkudgYRoNLkuu6Jbe2Nw
Date: Wed, 19 Jul 2017 18:43:16 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A00F3B9@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <fe384d2b-a0ba-9444-2ee9-cd0de6d24b7c@tessares.net> <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <0174561d-9baf-13e7-06a4-a8f843c3621f@tessares.net> <608a81e9-f61c-b0b2-646f-777e5f5937c9@isi.edu> <6a116785-51d2-6270-fb1f-10f9a2e64c31@tessares.net> <aa347f86-6be0-57b4-cd84-628eeaab6261@isi.edu>
In-Reply-To: <aa347f86-6be0-57b4-cd84-628eeaab6261@isi.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
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/int-area/5jUCTu1XEz2Mhjrb_T37XmlAz7U>
Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jul 2017 18:43:20 -0000

Re-, 

I don't understand your argument here, especially because you are the one who proposed me the following (check mptcp archives, April 20, 2017) which we endorsed in the latest version of the specification:

"If that were the case, you'd simply be defining a new application service and asking for a TCP port number."

Are you saying that you suggested us a bad design choice?

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Joe Touch
> Envoyé : mercredi 19 juillet 2017 18:43
> À : Olivier Bonaventure; Internet Area; tsv-area@ietf.org
> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
> 
> 
> 
> On 7/19/2017 12:41 AM, Olivier Bonaventure wrote:
> > Joe,
> >
> >> - but I remain concerned with "injection piggybacking"
> >
> > To which section of the draft are you referring to ?
> It starts in the arch discussion in Sec 2:
> 
>    As shown in Figure 3, the Converter places its supplied information
>    inside the handshake packets.
> 
> That's what I refer to as "injection piggybacking"
> 
>    With TCP, the Converter protocol places the destination address and
>    port number of the final Server in the payload of the SYN.
> 
> And that is the part that violates RFC793 semantics when that SYN reaches
> the final destination rather than the server-side proxy.
> 
> To be clear, I'm not interested in further trying to "fix" this mechanism
> so it can work. It can't and it shouldn't IMO. Let's use our cycles for
> more productive things.
> 
> Joe
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

v2.23.0 | Report a Bug | By Email