IETF Logo Mail Archive

Re: [multipathtcp] Questions on explicit proxy

<mohamed.boucadair@orange.com> Thu, 03 August 2017 06:15 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 611991321F5 for <multipathtcp@ietfa.amsl.com>; Wed, 2 Aug 2017 23:15:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 JrOATzU_VCEC for <multipathtcp@ietfa.amsl.com>; Wed, 2 Aug 2017 23:15:19 -0700 (PDT)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9761A131C6C for <multipathtcp@ietf.org>; Wed, 2 Aug 2017 23:15:19 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 41C7B1C039A; Thu, 3 Aug 2017 08:15:18 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 2464240058; Thu, 3 Aug 2017 08:15:18 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0352.000; Thu, 3 Aug 2017 08:15:17 +0200
From: mohamed.boucadair@orange.com
To: "Nandini Ganesh (nanv)" <nanv@cisco.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
CC: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
Thread-Topic: [multipathtcp] Questions on explicit proxy
Thread-Index: AQHTC70mHDHo8tD06EeFDc/Iu2yRcqJyIqHA
Date: Thu, 03 Aug 2017 06:15:17 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A0165DF@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <9AD3F237-E91D-404E-A6B4-3F988AAE0749@cisco.com>
In-Reply-To: <9AD3F237-E91D-404E-A6B4-3F988AAE0749@cisco.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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0165DFOPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/Me5pXWfafikS-hJgDAI-6CXZbHM>
Subject: Re: [multipathtcp] Questions on explicit proxy
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: Thu, 03 Aug 2017 06:15:21 -0000

Hi Nandini,

Please see inline.

Cheers,
Med

De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de Nandini Ganesh (nanv)
Envoyé : mercredi 2 août 2017 20:29
À : multipathtcp@ietf.org
Cc : Sri Gundavelli (sgundave)
Objet : [multipathtcp] Questions on explicit proxy

Hi,

I have been reviewing both the current drafts for explicit proxy/converters for MPTCP.

I have the following questions regarding plain mode draft

1.       Please can you give an example of a use-case where the D-bit is set MP_CONVERT_IE and how this “source address” will be used?

[Med] The main use case is for IPv6 source address preservation to avoid NPTv6 (RFC6296). An example is shown in slide 18 of https://datatracker.ietf.org/meeting/98/materials/slides-98-mptcp-sessa-network-assisted-mptcp. The packet that will be relayed by the proxy will be sourced with the IPv6 address indicated in the proxy supplied data. Doing so avoids breaking applications with referrals and many other things that would break with NPTv6 (https://tools.ietf.org/html/rfc6296#section-5)


2.       The downstream explicit proxy will always intercept the traffic and convert it to TCP.  If the server is upgraded to support MPTCP, is there a method to dynamically learn this?


[Med] The proxy does not systematically convert an MPTCP connection into TCP; it needs to wait for the SYN-ACK from the remote server to determine whether the remote server is MPTCP compliant. We clarified this in the new converter design; you can refer for instance to slide 8 of https://datatracker.ietf.org/meeting/99/materials/slides-99-mptcp-sessa-0-rtt-tcp-converters

Also, are there any sample implementations of explicit MPTCP proxy as suggested in the drafts?
[Med] I’m aware of some non-public implementations. Those implementations need to be adapted anyway to follow the new spec as sketched in the converter draft. Please use the converter draft as the reference document. Thank you.

Thanks,
Nandini

v2.23.0 | Report a Bug | By Email