Re: [multipathtcp] towards a potential work item on two-ended proxy

Alan Ford <> Thu, 04 August 2016 08:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D18712B00A for <>; Thu, 4 Aug 2016 01:06:15 -0700 (PDT)
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 tvSnWzmMvwiK for <>; Thu, 4 Aug 2016 01:06:13 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2EE2912D0E0 for <>; Thu, 4 Aug 2016 01:06:13 -0700 (PDT)
Received: by with SMTP id x83so41305218wma.3 for <>; Thu, 04 Aug 2016 01:06:13 -0700 (PDT)
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=01v6QFiX9XGPIvxmdRZrcvnTK92yISrNgHCVVb3iwEA=; b=R3HwJ9e1Zg0SHmlSg/fTAbm/xBAC7/aOv4sHlrHnHQjXSrsiDr8fNP/JKMHZbhHmgd C8xs7AWJe8tiCmYch6wlIMaRB3jhqmgnVLs560eEXOvy3YFlv0Dq0EEecFuV0WQ26GDY KOiW4D0AKODSARh+hjC2D0kcxIKc98FQzvBcAL0cHrXHKNd/6dy6eLR1nZCUj9dFGwV5 Cug21e846Cwlvj03V3BfBrxqKKd2YFEviq2YPPlI0che+YF6rmlaMFklJbtW9cSpWhNk siO6gsaRSdHSiqgMwHOkiKRmcxOgP/xj+fRlc7mkzWVpCCu7czSKlg86XY3wuH8y9War JoJw==
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=01v6QFiX9XGPIvxmdRZrcvnTK92yISrNgHCVVb3iwEA=; b=EKHDhpYb8loHvbPUN8dS6/DXROgXhq0SS83rzs6ZiPH1PYXMBGh2kdwelbkHJfPksI N2cveOoIxyk2uuHvimMrjUcgrnCJZ09fbYJlgzlv5XGDGXoC5cHfdn+xiUUl7h6S4sam 2yeXo5nvpFzVUFsscTl5GGiKeL0eKKJpQdgatG3MuMVpmld/O0GWcrAdIbwbWD0LMtp6 M2bhZ8/6yzivQvJp3WqHn8/I1dOzaNeCvCrw8V7HEa+9RH8pjxlKCm8YiWXRrnNoGVg3 Pb8wNVTgew/iNrib6z+ju2hE0aT4G7y+zi/fTAMTQSQlQC6AFvXAjNfhlWG/CulHo/zm ISqw==
X-Gm-Message-State: AEkoouuDv71WF9fveUmOJ9FxRI6XgHtMKUp2JMuoTqq8KTTtEk73bRmBySvI/pYHhoHpPA==
X-Received: by with SMTP id sn1mr73634030wjb.29.1470297971620; Thu, 04 Aug 2016 01:06:11 -0700 (PDT)
Received: from alans-mbp.lan ( []) by with ESMTPSA id iw1sm11529077wjb.20.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 04 Aug 2016 01:06:11 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_1FA547F9-831B-428E-86DF-870F6B90F040"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933008DF9BB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Thu, 4 Aug 2016 09:06:10 +0100
Message-Id: <>
References: <> <> <> <> <> <> <> <> <787AE7BB302AE849A7480A190F8B933008DF9BB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
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: Thu, 04 Aug 2016 08:06:15 -0000

Hi Med,

> On 4 Aug 2016, at 06:53, <> <> wrote:
>> As I’ve said before, the plain mode option is not MPTCP-specific and is
>> simple a signal that says “everything that follows is actually targeted
>> for IP address a.b.c.d” - this is entirely transport-agnostic.
> [Med] The plain mode allows for example to distinguish between native and proxied MPTCP connection. 
> I'm puzzled here since MPTCP allows to inform a remote peer about an IP address while this is not TCP-specific. Isn't that information transport-agnostic as per you argument? (not mine).

I don’t get this argument… You keep referring to “plain mode option” but this is not - in the current draft - a MPTCP option, this is simply something in the payload.

Your MPTCP proxy leverages MPTCP in order to apply new IP addresses to an existing MPTCP connection, which is great, but does not require any protocol extensions to do this. The only additional information it needs is the target, in the initial subflow, and this is provided by information in the payload.

This information is carried in the payload, and does not carry any information which is specific to MPTCP.

To be clear on this - I am not opposed to doing this work, and indeed I would be entirely happy to see the charter clarified to support work on two-ended proxies. This is valuable work. But in this WG, this work should be to the limit of “how you could use MPTCP between two proxies” … If you need a wire protocol defined which is not MPTCP-specific (which this does not appear to be), that work should be done somewhere like intarea or tsvarea and referenced by this work.