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

Wouter Cloetens <> Tue, 25 April 2017 11:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 679E912EC44 for <>; Tue, 25 Apr 2017 04:55:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d-FphLBN7hgg for <>; Tue, 25 Apr 2017 04:55:40 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E2E512EC3E for <>; Tue, 25 Apr 2017 04:55:39 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ( with ESMTPS id F0BDB5228A for <>; Tue, 25 Apr 2017 13:55:37 +0200 (CEST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id EFE55160488 for <>; Tue, 25 Apr 2017 13:55:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id 16PEzaDqOJIz for <>; Tue, 25 Apr 2017 13:55:37 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPSA id BAE2016025C for <>; Tue, 25 Apr 2017 13:55:37 +0200 (CEST)
References: <> <> <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E51D65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <>
From: Wouter Cloetens <>
Message-ID: <>
Date: Tue, 25 Apr 2017 13:55:37 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrfeeliedrgedvgdeglecutefuodetggdotefrucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtqhertddtfeejnecuhfhrohhmpeghohhuthgvrhcuvehlohgvthgvnhhsuceofihouhhtvghrrdgtlhhovghtvghnshesshhofhhtrghthhhomhgvrdgtohhmqeenucfkphepkedurdekfedrkedrudeivdenucfrrghrrghmpehmohguvgepshhmthhpohhuth
X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht
Archived-At: <>
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Apr 2017 11:55:43 -0000

As a hummer during the meeting, I fully support the work on MPTCP proxy 
solutions in the WG.

If I'd pressed to provide a reason, I'd start by admitting that, indeed, 
this is not perfect. It won't solve every use case and every problem. 
The plain mode draft makes no effort to fix the world in one day, which 
is, IMO, exactly why it is a good starting point for a realistic solution.
If there were a silver bullet solution, that would solve everything in a 
simple way, we'd have found it by now, and there would be no debate.
If we could practically redesign IP from the ground up for multipathing, 
channel bonding and congestion control, solved for all higher level 
protocols, then we'd be doing that.
If there were a better alternative available, we'd go for that. I've 
studied some. All have weaknesses. MPTCP, as a proxy mechanism, has a 
leg up on the competition because it defers congestion control to TCP 
and MPTCP, rather than attempting to reinvent TCP. As such, it is the 
best choice for a network topology in which at least one of the links is 
not point-to-point with a fixed upstream and downstream bandwidth budget.

A someone with an engineering mentality, I'd like to see solutions for 
real problems within my lifetime. And I'd rather build those solutions 
in a standard, interoperable way.

bfn, Wouter

On 25/04/17 09:11, wrote:
> Just to clarify our interpretation of the various hums during the meeting.
> We interpreted them as indicating there was one topic that it was worthwhile doing a consensus call on. We did not interpret the hums as indicating clear consensus that we merely needed to confirm on the list.
> So far we see:
> In favour:
> William Ivancic <>
> Stefano Secci <>
> Henderickx, Wim (Nokia - BE/Antwerp) <>
> David Allan I <>
> Robert Skog <>
> Olivier Bonaventure <>
> Costin Raiciu <>
> Against:
> Joe Touch <>
> Juliusz Chroboczek <>
> Eggert, Lars <>
> It is therefore important to hear views from other people. Of course it is also welcome for the technical discussion to continue (indeed, some people may want more of the technical discussion before giving their view on the consensus call).
> Thanks
> Phil & Yoshi
> -----Original Message-----
> From: []
> Sent: 21 April 2017 07:55
> [cut]
> 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).

Chief Home Gateway Architect     SoftAtHome Vaartdijk 3/B701, B-3018 Wijgmaal
Tel: +32-16-852010  Mobile: +32-492-277790   Conf. phone: +32-16-852097

This message and any attachments are confidential, intended solely for
the addressees and are SoftAtHome’s ownership.
Any unauthorized use or dissemination is prohibited. If you are not the
intended addressee of this message, please cancel it immediately and
inform the sender.