Re: [multipathtcp] Offload MPTCP Proxy (was RE: potential MPTCP proxy charter item)

Christoph Paasch <> Mon, 07 November 2016 16:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14AA712961E for <>; Mon, 7 Nov 2016 08:06:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.799
X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nWdN9ml9pgyD for <>; Mon, 7 Nov 2016 08:06:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BF526129605 for <>; Mon, 7 Nov 2016 08:06:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailout2048s; c=relaxed/simple; q=dns/txt;; t=1478534787; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XhuKagxp8TuETwdu92Mu9gJbBQgS43GGyT1CrQcCjGg=; b=vZO4dzhiJd62v8K46+YhEIOG1mX0BoTF2XiOm8CqkjfzFneSxKrpMPqkNTKFTbq/ O6BxTrg8as0aUWNI5HPzkJg+52FjLdclRw3KNenzByCTqt8C3ng7veEHnlYLSufL CSnPhIdH+SXa7GuMGjC3s/WjKDVGiUNr9IX3cSmrmq8kFWzApK3p/IS9nSDApVS9 JzA7JaUuyvZq8nr4d1jKwax8j9HI44ZWNYj+um2laJYAwirEYahCI3ROI8tbNCLq QPCOHdwS/6lBpd9y0XagGhu+yJ+iH2kiqldtvaWsfeeFG6/LwnXlEBPbK9Zxz/px cvYzeyECF4Gm8uoKIgZFBw==;
Received: from ( []) by (Apple Secure Mail Relay) with SMTP id 98.04.18952.386A0285; Mon, 7 Nov 2016 08:06:27 -0800 (PST)
X-AuditID: 11973e12-7490c9a000004a08-1d-5820a683a2d5
Received: from ( []) by (Apple SCV relay) with SMTP id FD.C6.23613.386A0285; Mon, 7 Nov 2016 08:06:27 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 8bit
Content-disposition: inline
Content-type: text/plain; charset="utf-8"
Received: from localhost ([]) by (Oracle Communications Messaging Server 64bit (built Jun 15 2016)) with ESMTPSA id <>; Mon, 07 Nov 2016 08:06:27 -0800 (PST)
Date: Mon, 07 Nov 2016 08:06:28 -0800
From: Christoph Paasch <>
Message-id: <20161107160628.GG3546@Chimay.local>
References: <787AE7BB302AE849A7480A190F8B933009DAD705@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-reply-to: <787AE7BB302AE849A7480A190F8B933009DAD705@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUi2FAYpdu8TCHCYOofJYuV51YwW2xYPYXF 4vDbp+wWn1dfZ7O40fCDxYHVY+esu+weS5b8ZPJoeXaSzePYh69sHq+OfWcJYI3isklJzcks Sy3St0vgynh2t4W14I10Re9+zQbGw2JdjJwcEgImEscm3mXtYuTiEBLYyyix6cdidpjEhx09 TBCJjYwS0+ceYARJ8AoISvyYfI+li5GDg1lAXuLIpWyQMLOAtMSjvzPYIcLqElOm5EK0vmaU mLzvNhNIjbCApET3nTvMIDaLgKrE++vrwGw2AS2Jt7fbWUFsEQEFiX1t/SwgzcwCzxklrl6Z BNUcJ9HwFaKIV8BA4smPNhYQW0ggWeLfz5nMIIs5BVIk2r7xgIRFBZQl/h6+BzZHQuA9m8SF fU9ZJzCKzELywiyEF2YheWEWwgsLGFlWMQrlJmbm6GbmmeglFhTkpOol5+duYgRF0HQ7oR2M p1ZZHWIU4GBU4uF90a8QIcSaWFZcmXuIUZqDRUmcdwu/bISQQHpiSWp2ampBalF8UWlOavEh RiYOTqkGxrDYgCcpJatmTPfPUzO5t1xQRfNleXWRijj/sakhky4dO+LlLij5d++8+ogdsQpP zOrV9lh2zPtx5ky75ea0THO37R/+Bc4LsvzysOrD+Xdbbgm/fc77IKUqpkjs+d/r8d13FfdO fGRiuPC0hXlyWMvun+JnItJPqH9Wfu92ZeutGJ+FMVuuXFFiKc5INNRiLipOBAB5J9yUgQIA AA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUi2FDMr9u8TCHC4MspWYuV51YwW2xYPYXF 4vDbp+wWn1dfZ7O40fCDxYHVY+esu+weS5b8ZPJoeXaSzePYh69sHq+OfWcJYI3isklJzcks Sy3St0vgynh2t4W14I10Re9+zQbGw2JdjJwcEgImEh929DBB2GISF+6tZ+ti5OIQEtjIKDF9 7gFGkASvgKDEj8n3WLoYOTiYBeQljlzKBgkzC0hLPPo7gx0irC4xZUouROtrRonJ+26DzRQW kJTovnOHGcRmEVCVeH99HZjNJqAl8fZ2OyuILSKgILGvrZ8FpJlZ4DmjxNUrk6Ca4yQavkIU 8QoYSDz50cYCYgsJJEv8+zmTGWQxp0CKRNs3HpCwqICyxN/D91gmMArNQnL1LISrZyG5ehbC 1QsYWVYxChSl5iRWmuklFhTkpOol5+duYgRHQmHUDsaG5VaHGAU4GJV4eF/0K0QIsSaWFVfm HmKU4GBWEuHlXgoU4k1JrKxKLcqPLyrNSS0+xJgM9O5EZinR5HxglOaVxBuamBiYGBubGRub m5iTJqwkznutQz5CSCA9sSQ1OzW1ILUIZgsTB6dUA2N46RVWNybuso/fTtWpWKsHK1u1fFIT F7j2yNN14dLbh/4uabrCmO6loB/VzLxF9nfMut0yGx+dmLrikfgCv3LhkOerVO+oRNQmKR3b 3My6wjHn+/+eZyztVl0ct3eXT7nAvqKSZU7ZQSOW19VBvT+XslkWthWu4jzpmu95SI17csgh hfVvhJRYijMSDbWYi4oTAaexJZjIAgAA
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] Offload MPTCP Proxy (was RE: potential MPTCP proxy charter item)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Nov 2016 16:06:29 -0000


On 07/11/16 - 15:03:49, wrote:
> 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 think it is not only for "offloading" but also just to allow for native
MPTCP. When there is a choice between native MPTCP and proxied MPTCP, the
former should always be preferred. I guess we all agree on that.

> (-) 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). 

When MPTCP goes end-to-end, the routing is optimal because the TCP-subflows
don't have to go through a detour to reach the proxy. The path through the
proxy is always less or equally as good as the direct path.

>From a QoE perspective I see a benefit in that the native server has more
info on the traffic-characteristics it is sending to the client. So it can
optimize based on this. This info (coming from the server-side) is not
available to the proxy.

> (-) 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.

This shows that we need signalling on an MPTCP-connection so that the client
can tell the server "don't send on this subflow now". We actually already have
this with the MP_PRIO-option, but something more sophisticated might be needed.

While a proxy might have access to the data-quota and can schedule traffic
based on this, data-quota is not the only variable that makes one want to
avoid cellular. If the device is a mobile device, battery-constraints come
into play as well.


> 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 []
> > Envoyé : dimanche 6 novembre 2016 22:12
> > À : Mirja Kühlewind; BOUCADAIR Mohamed IMT/OLN; Alan Ford
> > Cc :
> > 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 mailing list