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

"Henderickx, Wim (Nokia - BE/Antwerp)" <> Tue, 18 April 2017 20:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B8AC31200FC for <>; Tue, 18 Apr 2017 13:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.702
X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qnb4HyaFnGl3 for <>; Tue, 18 Apr 2017 13:44:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EBE8E131477 for <>; Tue, 18 Apr 2017 13:44:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cBcicA5dewFY9XmcUkX3le2S8QDz1YXvt200+qncgnY=; b=Iig3LKreLcbDKTY4ftzEeIrVjoz99CIyitf306jurd6ue5SKx+WPaWra9i12EaGGkP6oAAIk1n6Nh+ngsYMcXOno4clMcH+V/bCXN26u7+no5+1SXU7FQSFaDpFfsTJPRf8jb85kcvkPDa3ZkukPMkNp8ReWjS57DRVgC283GUs=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Tue, 18 Apr 2017 20:44:17 +0000
Received: from ([fe80::a1c4:2e6c:8c63:20f1]) by ([fe80::a1c4:2e6c:8c63:20f1%14]) with mapi id 15.01.1034.015; Tue, 18 Apr 2017 20:44:17 +0000
From: "Henderickx, Wim (Nokia - BE/Antwerp)" <>
To: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" <>, "" <>
CC: "" <>
Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work
Thread-Index: AdK4HBNY1jXzvDFKRxmRsHBM53IcbgAZ8zuAAARbgIA=
Date: Tue, 18 Apr 2017 20:44:17 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: nl-BE, en-US
Content-Language: en-GB
user-agent: Microsoft-MacOutlook/f.21.0.170403
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; AM2PR07MB0963; 7:Qnet3EkT9OCF3mOMvZngM9zhJPMVYXIssM7QN+2IQ+tsPFHvLN9913eYua2kioMdNyO3vxrnAx4O0kK22a9IFO/XBlnQH4ylaegxASJgoC+ukTqB+QJ4yBGV6JGKFlYBgQiF56nE2ia5rJO7pu8i09Vrc0Ao54DkjQUzaT51QR5WjQcdty1t9+hOhaure4lcxN6FU2uZjqTTzJZlOEZ94CdMmpSCa1xqdLhA0lVoETAgST9y7FTGZ38CcyiudsLlo9WJiqjctn/1q5ZL/3Gend00nzoPYhiGCVj0/RaUhOt+nMtKhZiFXVaxrQrHL8omer36EaeZlvvilV1+NfsDWA==
x-ms-office365-filtering-correlation-id: bf2cd0be-d0ab-4b7b-43e1-08d4869bae9d
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:AM2PR07MB0963;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(146908506813832)(158342451672863)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:AM2PR07MB0963; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0963;
x-forefront-prvs: 028166BF91
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39850400002)(39450400003)(39840400002)(39410400002)(39860400002)(377454003)(24454002)(33656002)(53936002)(6306002)(6512007)(99286003)(36756003)(2906002)(50986999)(76176999)(54356999)(3660700001)(6506006)(6436002)(6486002)(8656002)(3280700002)(2501003)(102836003)(6116002)(3846002)(229853002)(83506001)(25786009)(53546009)(82746002)(5250100002)(7736002)(305945005)(66066001)(2950100002)(5660300001)(189998001)(8676002)(81166006)(2900100001)(6246003)(38730400002)(86362001)(8936002)(4326008)(83716003)(4001350100001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0963;; FPR:; SPF:None; MLV:sfv; LANG:;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2017 20:44:17.2276 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0963
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, 18 Apr 2017 20:44:23 -0000

If the client and server support mptcp the proxies should not end up in the path, so it will be transparent E2E

On 18/04/2017, 17:39, "multipathtcp on behalf of Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" < on behalf of> wrote:

    Hi Phil, all,
    I have a clarifying question about dual proxy work.
    Does the dual proxy solution have the ability to support native MPTCP at the client and server, or is the assumption that the solution forces the two proxies to become part of a connection regardless of whether the client and server are MPTCP enabled?
    > On Apr 18, 2017, at 4:17 AM, wrote:
    > Hi,
    > During the MPTCP meeting in Chicago we did several hums about potential MPTCP proxy work. Our interpretation of these hums is that we should do a consensus call for the following work:
    > --
    > MPTCP is now seeing widespread deployment in networks to bond together two accesses, such as fixed and mobile broadband, by using two MPTCP proxies, one in the home gateway or Customer Premises Equipment and one in the network. The WG develops a solution where the proxies are both under the control of the operator and where it is assumed that they are not on the default path. The solution is based on using the payload of an MPTCP packet to transfer a signalling message between the proxies. It is believed the solution will not require changes to RFC6824bis. The solution may require a means of configuring set-up information in the proxies, which would be done in coordination with other IETF WGs such as DHC. The WG does not develop a mechanism for the two proxies to discover each other.
    > --
    > Please say whether you support, or don’t support, such work – so we can see if there’s consensus for it.
    multipathtcp mailing list