Re: [multipathtcp] potential MPTCP proxy charter item

Alan Ford <> Tue, 08 November 2016 12:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97D49129A9C for <>; Tue, 8 Nov 2016 04:41:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 RG-v23_QJnp5 for <>; Tue, 8 Nov 2016 04:41:35 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBB441297CE for <>; Tue, 8 Nov 2016 04:41:34 -0800 (PST)
Received: by with SMTP id o141so66182422lff.1 for <>; Tue, 08 Nov 2016 04:41:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=KNJNj01lIvmGb9Qm/7QS0IXZAzkMMKIJ6VhG+bbcpao=; b=FPmwhFBtCbzmiDayO2v+HU/9K9hyG+j9kKvVU7l3hXYGy4WQ3AGJZ8s5atGcuNHWy8 ILv/X9qbaQtX7WtkbzW2ytRZh2/LL/xDN3QjHg1FYGmESXjsmKTV6vS4B0leONYALRZn ASQXjtAcWKANiOcE3YN6zvP4Q+ZSKAOC1ueRdHG4PGN5vdjt4P8SOWn2t78ufptCIgIF oO1hUT/cOtWlHBXT89O71dYcXGWF650RsCFfeYM+TO/I2UKNOo7fiIb0ddhPJAQ3sOkl XCdTWlVaMVxJneRlrseHNZhMiBIc+EDdBdy2cxhc/7KKcipd9iVz0Dr3XcchMhdPuwAV nuXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=KNJNj01lIvmGb9Qm/7QS0IXZAzkMMKIJ6VhG+bbcpao=; b=S99K3fVGKY/Q3nNTmC9FwMSDXNfuPza2oFjByBmIsGbB6Uum0V/nWRXBNP0INSOfjP cbr3BbUrTkDVCzMSLIzTkj2SskILOblw4YTLA5V1L/Y18rBo13VxuD0bnvq2EU5//yQ/ tKUji0omSTgFWWc4XNkINSOj7VmEn4J87BnEawqzl8i0v6rVBxhT8iTQh4r0WSUAMD1M hOcOzWzBXZUxUIKsyFmJCCAS3tjJrvDrcZaEtdlR4xIVAyAJFLuuOLz5FrSTIM2R+557 ApZi9Eiabt9bkbUAtvtsepjsnJGe7whj7FD8opoG6AV1s08ucxBgdF4JZrAAbEbeaybD g46g==
X-Gm-Message-State: ABUngvdsqHGMGBq7uzWt3HDJewtJ8NInpRSo/tBiWG97K1sWffrx6UAEITOt6sRDGJo6iQ==
X-Received: by with SMTP id h87mr6999123lfi.91.1478608892878; Tue, 08 Nov 2016 04:41:32 -0800 (PST)
Received: from ([]) by with ESMTPSA id h71sm6048564ljh.21.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Nov 2016 04:41:32 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B71F54DC-47C4-4E0D-AE34-9B6BAB2C5F82"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DADF3F@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Tue, 08 Nov 2016 12:41:29 +0000
Message-Id: <>
References: <> <> <> <787AE7BB302AE849A7480A190F8B933009D9577B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <22907_1476946228_58086934_22907_5464_1_a7bca8d2-7656-4ff0-9f01-cf307f017148@OPEXCLILM42.corporate.adroot.infra.ftgroup> <> <> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.corporate.adroot.infra.ftgroup> <> <> <> <> <> <> <> <> <> <787AE7BB302AE849A7480A190F8B933009DADF3F@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] 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: Tue, 08 Nov 2016 12:41:37 -0000

Hi Med,


> De : Alan Ford [ <>] 
> Envoyé : lundi 7 novembre 2016 17:37
> À : <>
> Cc : BOUCADAIR Mohamed IMT/OLN; <>
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> Hi Olivier,
> On 7 Nov 2016, at 07:50, Olivier Bonaventure < <>> wrote:
> Why is it an /option/, however? When you are explicitly targeting a
> proxy node, surely the proxy is just as capable of pulling the data out
> of the payload here?
> Because the addressing information that is used for the proxy is part of the control plane and not part of the bytestream. I think that it is very important from an architectural viewpoint to maintain a clean separation between the byte stream that is exchanged between the applications and all control information that should be placed inside options.
> We explore the possibility of adding information in the bytestream for MPTCP and eventually decided to place all control information in options. If you look at HTTP, proxy-related information is part of the HTTP headers and not part of the payload. This is the same type of problem.
> And this appears to be where we fundamentally disagree. I don’t see this as part of the control plane, I see proxying (at least in explicit mode) as an application of MPTCP, and should be at the application layer.
> [Med] I still don’t understand this subtlety between “application of MPTCP” (you claim) and “MPTCP-specific use case” (we claim). If we extrapolate your argument, one can object that multi-pathing is an “application of TCP” (not even specific to TCP), and should not be defined as a TCP option. But the reality is that there is a TCP option for multi-patting.

This is a layering issue. MPTCP provides an end-to-end transport. Proxying solutions are also end-to-end protocols - one end encapsulates in a different transport (from TCP to MPTC), and the other end decapsulates (from MPTCP to TCP). It does not make sense (to me) to apply an end-to-end application (proxying) at the transport layer.

Network translation is different and relies on changing fields in the same transport, not changing to a different one (I am coming at this from the perspective that MPTCP, although an extension to TCP, provides sufficiently different functionality that it it a different transport for the purposes of this discussion).

> It seems too specific an application to be embedded in the protocol. This does not seem equivalent to NAT, since it is requiring additional signalling.
> [Med] FWIW, instructing NAT state with in-band signaling information is specified by the IETF and widely deployed:
> · <>
> · <>
> · <>  

As far as I can see, none of those involve changes at the transport layer.