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

Alan Ford <> Tue, 02 August 2016 13:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 886E712D618 for <>; Tue, 2 Aug 2016 06:52:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, 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 0J1RSUoAm5OV for <>; Tue, 2 Aug 2016 06:52:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 50DAA12D613 for <>; Tue, 2 Aug 2016 06:52:35 -0700 (PDT)
Received: by with SMTP id o80so291541340wme.1 for <>; Tue, 02 Aug 2016 06:52:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CL6V3kZs2dHmmIx9CKivA7G2es3I7oQQt98ufd/vkyQ=; b=1I3dwO7pvhIS2tzZzA4lliZcP/TITbphX/27QLA3EPBbUJ3LyagVEVLKcuPJtXdGv0 /3rxM1LejOjHCizZEdry8dRunga9VSjSgkDiaWIRcbvrazQ3+2YIr9A4xEZKkBlY/3Nk g0w5krdJQ6AC90DAsEhb477rdShluzwovPFLkxPeWu1c9qtVMLHXXgbJTyWB/DEMSTyi y3E0iw+9WM9KztFGMQdZhjbN5Ka5lXJL9AQq+87tvU7e7C0xBffiajOm6hhNrkbLvsq6 Ojq4e/HviFc/ONbUsTpKfEekJodd+Xndg6Jh8rHRTNJg2uyREga28XGc4zYecJ1NFNoS psvw==
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 :content-transfer-encoding:message-id:references:to; bh=CL6V3kZs2dHmmIx9CKivA7G2es3I7oQQt98ufd/vkyQ=; b=GriFG9q2QtRjcSUWbUigttUWMBSAi1AB/Cbfrb2q6+vZKfmdF9LgNhaCiTzJMq7EWH nu5mYJajvgG1EeihkV7Jau7DJxwASJ5b+nYom8MM8A3n3hUH380M3DIS8iZ34JS0EM4z E5R/6kSLIXERx2Z9NbgYyXIDKJ5M4BV5F+zGB6vBWN6OHXRo6Lid7LWVFBHXLes0b0Mx nwNhiw9CuTYQUE0Yw3DsnEs2cmUAiAwDX4O/jHUb7hv3LBR0OClmUXsiwP7cit3WElTR phrGv7QQFiok3nVDjLbNvKW0XBowZk0SKNLUwVgL52Ez/gybUqJOcwP67PBtHWGVe2y4 glbw==
X-Gm-Message-State: AEkoouuj2z7YhYA8eWAbpgItUNUIUtKO+6pQMsaDeShtLHasSauTHFv3TJLzhDCAdSfpbA==
X-Received: by with SMTP id t66mr19777031wmt.41.1470145953783; Tue, 02 Aug 2016 06:52:33 -0700 (PDT)
Received: from alans-mbp.lan ( []) by with ESMTPSA id e65sm3181859wmg.3.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 02 Aug 2016 06:52:33 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Tue, 2 Aug 2016 14:52:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: "Henderickx, Wim (Nokia - BE)" <>
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: Tue, 02 Aug 2016 13:52:37 -0000

Hi all,

> On 1 Aug 2016, at 20:05, Henderickx, Wim (Nokia - BE) <> wrote:
> On 01/08/16 20:42, "Rao Shoaib" <> wrote:
>> On 08/01/2016 07:13 AM, Henderickx, Wim (Nokia - BE) wrote:
>>>> Why is it necessary to know that the connection has been proxied ?
>>> WH> Otherwise the concentrator will perform the proxy function although the destination is the application server.
>>> So assume an E2E MPTCP flow. The UE initiates it and the element with the network assisted MPTCP proxy (Concentrator) receives it. The concentrator should not proxy this flow. It should only act upon MPTCP flow that should be proxied in network assisted mode. This is the reason we need an indication about this
>> This seems like a deployment issue not a protocol issue. The decision to 
>> proxy or not proxy should be based on the IP addresses or out of band 
>> signaling. After all the entity adding the option some how knows to add 
>> the option.
>> I liked the initial proposal as it did not require any changes to the 
>> protocol. These change (as I have said before) seem very deployment 
>> specific and IMHO should not be part of the protocol.
> WH> I would disagree since you don’t always control the addressing and it is better to have an explicit signaling in the protocol what to expect to happen.

I’m trying to distinguish the various use cases; can we confirm this is correct?

Transparent Mode
- Source address = real source address
- Destination address = real destination address
- Transparent proxies create MPTCP functionality in the stream, adding and removing the MPTCP headers, mapping seq numa, etc
- Latest proposal is to add an indicator to say “this is proxied” so that a proxy can intercept it

Plain Mode
- Source address = real source
- Destination address = proxy destination address
- Signalling protocol inside indicates real destination address

So - please correct me if this is wrong - but the main difference is that Plain Mode is targeted towards a proxy server whereas the transparent mode does not change src/dst addresses?

The issue I see with a generic proxy bit is that it does not contain any context about what kind of proxy is being intercepted. You could be sending in good faith expecting it to be picked up by Proxy from Operator A, but in fact is picked up by Operator B.

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. If the HAG could know where to find a proxy (e.g. a well-known anycast address) then addresses could be rewritten and packets forwarded, with no need for any MPTCP protocol changes.

However, I fear I may be misunderstanding some of the elements here, so I look forward to a consolidated draft where it should hopefully be much clearer what the proposal is.