[multipathtcp] Offload MPTCP Proxy (was RE: potential MPTCP proxy charter item)
<mohamed.boucadair@orange.com> Mon, 07 November 2016 15:03 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 DA06A129898 for <multipathtcp@ietfa.amsl.com>; Mon, 7 Nov 2016 07:03:53 -0800 (PST)
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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 rNORZwtBE9RQ for <multipathtcp@ietfa.amsl.com>; Mon, 7 Nov 2016 07:03:52 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD291295CF for <multipathtcp@ietf.org>; Mon, 7 Nov 2016 07:03:52 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 06D0222C662; Mon, 7 Nov 2016 16:03:51 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.42]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id D249F23808A; Mon, 7 Nov 2016 16:03:50 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 16:03:50 +0100
From: mohamed.boucadair@orange.com
To: "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Alan Ford <alan.ford@gmail.com>
Thread-Topic: Offload MPTCP Proxy (was RE: [multipathtcp] potential MPTCP proxy charter item)
Thread-Index: AdI5CCNLdBUL1/EZRzWYNZmJsFcHsg==
Date: Mon, 07 Nov 2016 15:03:49 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAD705@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/st_rupCBAu48mT0Ldnrnrp9wuSw>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: [multipathtcp] Offload MPTCP Proxy (was RE: potential MPTCP proxy charter item)
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 07 Nov 2016 15:03:54 -0000
Hi Olivier, I'm not sure it is that clear we need to systematically include MP_CAPABLE option in the SYN to the ultimate server. I see some value there...but also some side effects. I'm reiterating what I already said in this thread: (+) I see "a big benefit" for some operators to offload the MTPCP proxies if the server is MPTCP-capable. (-) I don’t see "a big benefit" for the client from a QoE perspective, because they already have the MPTCP experience with the network assistance (network aggregation, path resiliency). (-) I don’t see "a big benefit" for the client if the MPTCP-capable server decides to use a given path to place data, while that path is subject to a data volume quota. This means that the client will be mono-path quickly if an MPTCP-capable server adopts some traffic distribution schemes. That said, I have no problem to leave this as a configurable parameter. A configuration knob can be supported to instruct the MCP about the behavior to follow. Also, a white list of servers can be provided to the MCP. This is exactly the kind of technical considerations for which we need a formal WG document so that we can record the WG decision. Cheers, Med > -----Message d'origine----- > De : Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be] > Envoyé : dimanche 6 novembre 2016 22:12 > À : Mirja Kühlewind; BOUCADAIR Mohamed IMT/OLN; Alan Ford > Cc : multipathtcp@ietf.org > Objet : Re: [multipathtcp] potential MPTCP proxy charter item > > > It's clear that the MCP should send the MP_CAPABLE option in the SYN > towards the destination server and fallback to TCP is this fails. Since > there are some middleboxes that continue to silently drop the MP_CAPABLE > option, the MCP should be able to maintain a list of destination servers > where it had to fallback to regular TCP (e.g. after n retransmissions of > the SYN with MP_CAPABLE as suggested in RFC6824) and no attempt to use > MPTCP for these destinations. This cache should be reset on a regular > basis to probe again the destination servers.
- [multipathtcp] Offload MPTCP Proxy (was RE: poten… mohamed.boucadair
- Re: [multipathtcp] Offload MPTCP Proxy (was RE: p… Christoph Paasch
- Re: [multipathtcp] Offload MPTCP Proxy (was RE: p… mohamed.boucadair