Re: [multipathtcp] potential MPTCP proxy charter item

Alan Ford <alan.ford@gmail.com> Tue, 08 November 2016 12:41 UTC

Return-Path: <alan.ford@gmail.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D49129A9C for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 04:41:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG-v23_QJnp5 for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 04:41:35 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB441297CE for <multipathtcp@ietf.org>; Tue, 8 Nov 2016 04:41:34 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id o141so66182422lff.1 for <multipathtcp@ietf.org>; Tue, 08 Nov 2016 04:41:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.25.18.90 with SMTP id h87mr6999123lfi.91.1478608892878; Tue, 08 Nov 2016 04:41:32 -0800 (PST)
Received: from alans-mbp.rd.pexip.com ([46.19.20.98]) by smtp.gmail.com with ESMTPSA id h71sm6048564ljh.21.2016.11.08.04.41.31 (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 <alan.ford@gmail.com>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DADF3F@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Tue, 8 Nov 2016 12:41:29 +0000
Message-Id: <C406A85B-DBC6-4FB6-A88F-5F1000A729B4@gmail.com>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <8bed05c5-9f6f-04aa-8aa8-690aa3ce30f4@uclouvain.be> <CAO249ydpdtR53VBniDczSt4zj_kk32c2W_FoZKs2XED0Jzk7Jw@mail.gmail.com> <787AE7BB302AE849A7480A190F8B933009D9577B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <22907_1476946228_58086934_22907_5464_1_a7bca8d2-7656-4ff0-9f01-cf307f017148@OPEXCLILM42.corporate.adroot.infra.ftgroup> <57543A7A-1542-4C60-A5D3-E1658354BE5A@tik.ee.ethz.ch> <73a1c0dd64a843a5baa645d960c82886@rew09926dag03b.domain1.systemhost.net> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.corporate.adroot.infra.ftgroup> <56CE164A-9A62-4B57-9CFF-33DBD45BA8B2@gmail.com> <e81c001b-ba6b-2990-9a62-09622e1339e1@uclouvain.be> <ACE6C987-A8AD-477B-986C-CFB4A438323F@gmail.com> <8074e8da-71ba-633d-dd67-6fc37adf19e5@uclouvain.be> <E9ECBC32-A8F1-4C9A-9D26-A3FF64C815FA@gmail.com> <3fb34255-bfdd-832e-4143-3872ed4b5d93@uclouvain.be> <7601A655-137D-4197-A2B7-4BB10ED0CB32@gmail.com> <d9f1f3b7-9a2c-e678-45ba-c5987f878254@uclouvain.be> <85EB3C4A-A04F-4259-85A0-BB48A7B46C7D@gmail.com> <787AE7BB302AE849A7480A190F8B933009DADF3F@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/Kd_41b_wmvqpUcq0Wq0yiRgYqqs>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2016 12:41:37 -0000

Hi Med,

Inline...

> De : Alan Ford [mailto:alan.ford@gmail.com <mailto:alan.ford@gmail.com>] 
> Envoyé : lundi 7 novembre 2016 17:37
> À : Olivier.Bonaventure@uclouvain.be <mailto:Olivier.Bonaventure@uclouvain.be>
> Cc : BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org <mailto:multipathtcp@ietf.org>
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
>  
> Hi Olivier,
>  
> On 7 Nov 2016, at 07:50, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be <mailto:Olivier.Bonaventure@uclouvain.be>> 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:
> ·         https://tools.ietf.org/html/rfc6052 <https://tools.ietf.org/html/rfc6052>
> ·         https://tools.ietf.org/html/rfc6146 <https://tools.ietf.org/html/rfc6146>
> ·         https://tools.ietf.org/html/rfc6877 <https://tools.ietf.org/html/rfc6877>  
>  

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

Regards,
Alan