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

David Allan I <> Tue, 18 April 2017 22:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E3BB13149A for <>; Tue, 18 Apr 2017 15:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W_8t7WOm_S3R for <>; Tue, 18 Apr 2017 15:06:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 49B8C12EC3F for <>; Tue, 18 Apr 2017 15:06:25 -0700 (PDT)
X-AuditID: c6180641-42bff700000058cf-e9-58f647836b67
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 0A.E2.22735.38746F85; Tue, 18 Apr 2017 19:06:13 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0339.000; Tue, 18 Apr 2017 18:06:21 -0400
From: David Allan I <>
To: "" <>, "" <>
Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work
Thread-Index: AQHSuH+u1jXzvDFKRxmRsHBM53IcbqHLrr7w
Date: Tue, 18 Apr 2017 22:06:22 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C68D5BB5Ceusaamb105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPrG6r+7cIg1UbLS0+r77OZrFs7QpG ByaPti+TmTyWLPnJFMAUxWWTkpqTWZZapG+XwJVx7KJpwZzyilVLlrM0MDaUdDFyckgImEhs +LaBpYuRi0NIYAOjRP+uxYwQznJGic/X+thBqtgEDCT2/P/CCGKLCKRJ7FnyhxnEFhbwkDiw 5C0rRNxT4tOru1A1RhIHDh5lA7FZBFQlHq5YCxbnFfCVOPPnNli9kICNxJFFU8DinAK2Euc3 HgOrZxQQk/h+ag0TiM0sIC5x68l8JohLBSSW7DnPDGGLSrx8/I8VwlaSmLT0HCtEfb7E5f53 rBC7BCVOznzCMoFReBaSUbOQlM1CUjaLkQMorimxfpc+RImixJTuh+wQtoZE65y57MjiCxjZ VzFylBYX5OSmGxluYgTGyDEJNscdjHt7PQ8xCnAwKvHwLnj8NUKINbGsuDL3EKMEB7OSCO/5 pm8RQrwpiZVVqUX58UWlOanFhxilOViUxHnflV+IEBJITyxJzU5NLUgtgskycXBKNTCueNdt 0OZSo2OmuvNRR8DC4hudlb/Va//s+L97/hMm+Xn7+9Iur6o+H7nn95UfHas0QrQ0dbd6vo3S 2m7pwvj3yUyulleGzNtVdS0+vNw3/dGWyTmx3sK8Fp9fnHzqHzux+u0JA6ltrkcZ/39huNd0 f3dET82m4OP8Cr3L9lQtXS29mqV7CXOLEktxRqKhFnNRcSIAwW+uPI0CAAA=
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 22:06:27 -0000

Consider this email to be a hum in favour of the work.

Cheers D

From: multipathtcp <<>> on behalf of "<>" <<>>
Date: Tuesday, 18 April 2017 at 10:17
To: "<>" <<>>
Subject: [multipathtcp] Consensus call on potential MPTCP proxy work

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.
Phil & Yoshi

Hums during the meeting:

•         Should the MPTCP WG do any MPTCP proxy work, or do none – about 2:1 or 3:1 in favour of doing work

•         Should the MPTCP WG do proxy work based on option #1 in slide 12? Strongly more yes than no

•         Should the MPTCP WG do proxy work based on option #2 in slide 12? more no than yes

•         Should the MPTCP WG do proxy work based on option #3 in slide 12? Weak & roughly equal
We believe the work does not require an update to the MPTCP WG charter.