Re: [multipathtcp] potential MPTCP proxy charter item

Alan Ford <alan.ford@gmail.com> Mon, 07 November 2016 06:22 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 B9B88129C5E for <multipathtcp@ietfa.amsl.com>; Sun, 6 Nov 2016 22:22:42 -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 WlR5P90N3peO for <multipathtcp@ietfa.amsl.com>; Sun, 6 Nov 2016 22:22:41 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 4C096129C59 for <multipathtcp@ietf.org>; Sun, 6 Nov 2016 22:22:41 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id a197so161317782wmd.0 for <multipathtcp@ietf.org>; Sun, 06 Nov 2016 22:22:41 -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=UCP9zEV1BQJn0kwfJLFAYESCvUDbJi9Dm6FkLKCwG0o=; b=SMjdesqZ9r5J1ct4V/M6VqyZWeAIPTow2r9lRq18j4TrkdIaHx8eAf+CW7awe7n5nZ etk1vyAIYUM+Wm4ItBkQgoU358VAewr+EWeOSRsMt2ZkHwY4tqFI9nKq7irFtIp6ARjf 8hFWjL/kB4Zqnk9PSMuBDXXE4wMvSou/G5sVo0rAzna0HZsibvYLtLz+QTH3ZLJaa3jw d4xdrhg7e6RugLNKuJVXTy2bG7o9IkEOI/vvnwqbNAgccRhQwNEzWBUFUFw0OiV88P0R GKeG3b6iV0XtA5uQfuwRNkfMBzMGozuuMo1LFe/03iK1yiPsU9jtoJL+m4RKwBNALD9i WbFw==
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=UCP9zEV1BQJn0kwfJLFAYESCvUDbJi9Dm6FkLKCwG0o=; b=D9qNvqtaUNUZmMd8tC6X273bmVijEnctm6O4g0XROsiKyxVfpVPFYhPDCAwgP9V2DE CXthelrfDdjNhdf5v2X1iBQzfAhXazp1+QAixBLqz+TRw8GQsdEzWF8KpWtq7ECDPYJJ IPWM9RaDmOpd69Vefbw2CCxlFM5kS/3M4PnfbrGlbhNqyF6s/ZtkZ3S5w5egjbNcjUyM JlTG91sCldGSnggFPjvQuk9J2F9gJBzsh+Qxiku5pon+HvYTLPg7hR2ekpVkYXI+OUxd VC38ImRMiTf+kGbFVDewFbtqnT2Jhb/4qThN7FLEZvCEPeolKavMkftDrJw+hPXqcqCq 1ZFQ==
X-Gm-Message-State: ABUngvd+UWR5N/NdGvKOJaTBkoxKTZZo1sl2tw6uZg0niENY4/8xbUmqVQaDBWbKxDFbnA==
X-Received: by 10.28.52.76 with SMTP id b73mr6959669wma.8.1478499759834; Sun, 06 Nov 2016 22:22:39 -0800 (PST)
Received: from [172.20.10.10] (188.29.165.29.threembb.co.uk. [188.29.165.29]) by smtp.gmail.com with ESMTPSA id g142sm11510066wmd.2.2016.11.06.22.22.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 06 Nov 2016 22:22:39 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_4D619603-974F-4485-9F38-251782E66D27"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <alan.ford@gmail.com>
In-Reply-To: <87270f12-59ee-3caf-eeef-685195b35dcd@uclouvain.be>
Date: Mon, 7 Nov 2016 06:22:36 +0000
Message-Id: <A5256E6E-E2BA-4763-AEF9-3CC50EB432A2@gmail.com>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <428609FE-DE79-45CD-B668-EF95F409B593@tik.ee.ethz.ch> <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> <787AE7BB302AE849A7480A190F8B933009D9CA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <85D52AE4-FE5F-4977-8927-6BDB72614D07@gmail.com> <787AE7BB302AE849A7480A190F8B933009DAAA88@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <D2630820-7586-4361-A626-3278F22C319C@gmail.com> <87270f12-59ee-3caf-eeef-685195b35dcd@uclouvain.be>
To: Olivier.Bonaventure@uclouvain.be
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/BOpDGQY71uhPi_Q7LyfgmjUW3u0>
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: Mon, 07 Nov 2016 06:22:43 -0000

Hi Olivier,

> On 6 Nov 2016, at 21:06, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> wrote:
> 
> The implicit mode was suggested by network operators. The MCP resides on the path between the CPE and the destination server. The main benefit of the implicit mode is that the MCP does not need to perform any address translation. Given all the complications with NAT, this is a huge benefit, in particular in IPv6 deployments. In IPv4 deployments, the CPE can use a single address and there is no need for a pool of IPv4 addresses on the MCP.
> 
> In implicit mode, the MCP needs to distinguish between an MP_CAPABLE generated by the endhost and an MP_CAPABLE added by the CPE.

Broad question - why?

If the answer is simply “to know when to terminate the MPTCP connection” (i.e. if the end host does it you want it to run all the way to destination, but if the CPE has done it you want to handle at the proxy), then thinking out loud here, could the desired behaviour not be achieved by deciding to proxy only based on the SYN/ACK (i.e. based on the far end’s capabilities) and otherwise be transparently adding MPTCP to everything? That way you get even greater MPTCP coverage whilst not interfering with destinations which have already deployed it.

Regards,
Alan