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

Christoph Paasch <> Fri, 22 July 2016 09:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 993AB12D1D8 for <>; Fri, 22 Jul 2016 02:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.378
X-Spam-Status: No, score=-5.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D82Vd431Lqeo for <>; Fri, 22 Jul 2016 02:19:24 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 22BD012DB99 for <>; Fri, 22 Jul 2016 02:19:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailout2048s; c=relaxed/simple; q=dns/txt;; t=1469179163; x=2333092763; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SJg4ydI7X0En1kSi1DIod1J2TxLEunA1BntEyczfNx8=; b=pW8H32fHeIf44yBBFfTT/Xj+a7Gn/lvKQA1Le8Szv+QAiS0f1EQqQ41E4Nog+hkf YfX0sIg0YQl3jInRGY+pFSN6329nLPfGjP3q6yYHtq45qgzjHDx6RHJOX1h3Z5D4 CFSHv1JWxpaX2oej/dUwn57EFPvf/Kly5mYL2ilushbpdIC4hX/T2ndwwej5rOol JfX23s2o3DGc4zvYEgphZcURa0ahiQ2kXAOBC4BcV83HJCleeLGx6EqeowwhR4yh PjBbqEEeR2vWqKWp8Nz04Apc+BziLLWrR2ZKpX7m5dxPbsmLURmJ5Kn2GuZWZy0o Ol/wvGjAI//xHr7xoJL4dg==;
Received: from ( []) by (Apple Secure Mail Relay) with SMTP id 9E.E0.10360.B15E1975; Fri, 22 Jul 2016 02:19:23 -0700 (PDT)
X-AuditID: 11973e11-f79e76d000002878-34-5791e51bad38
Received: from ( []) by (Apple SCV relay) with SMTP id 51.D8.30701.B15E1975; Fri, 22 Jul 2016 02:19:23 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_FUyoAzcQOJG+lsAORFceBg)"
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built May 17 2016)) with ESMTPSA id <>; Fri, 22 Jul 2016 02:19:23 -0700 (PDT)
From: Christoph Paasch <>
In-reply-to: <>
Date: Fri, 22 Jul 2016 11:19:23 +0200
Message-id: <>
References: <>
To: Philip Eardley <>
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUi2FAYoSv9dGK4we1/phafV19ns1i2dgWj A5NH25fJTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4OHEDW8GH2oqvPxawNzA+yOli5OCQEDCR 2NKq28XICWSKSVy4t56ti5GLQ0hgL6PEuh1z2SASJhI9tzZCJXYwSkxsv8EIkuAVEJT4Mfke C4jNLBAmMa1zAzNE0R9Gib4Jd1lBEsICkhLdd+4wQ9g+Eh1XpoE1sAloSby93Q5WwykQLnF3 xT92EJtFQFVi0alOFpDrmAWMJabMNAIxeQVsJL6uzgIxhYBW3f7kBlIsAjSkZ8lFJogzZSWe nFzEAnKBhMAJNonPTR+ZJzAKz0Jy6Swkl84CW6AuMWVKLkRYW+LJuwusELaaxMLfi5iQxRcw sq1iFMpNzMzRzcwz0kssKMhJ1UvOz93ECIqO6XaCOxiPr7I6xCjAwajEw3vi6YRwIdbEsuLK 3EOM0hwsSuK8H0QmhgsJpCeWpGanphakFsUXleakFh9iZOLglGpgtF1h/XTK3zdGCcJGd2YV bxQMNmqU5TraLVrlxGAkIJziY77j6O0Lps/LPkqkntjifP63jNC8SQflVmk9myb93KL9zL9s 733X2q+0ivXNCmV2Omri91H48v53R5ZPtdCP3zojRvup0M0re1yPb1Tg2vzcc6nOqcwq2c5r pk/8f4YrsUqXOFyUVWIpzkg01GIuKk4EANdiB2xvAgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUiuLqhSVf66cRwgwWHDC0+r77OZrFs7QpG ByaPti+TmTyWLPnJFMAUxWWTkpqTWZZapG+XwJVxceIGtoIPtRVffyxgb2B8kNPFyMkhIWAi 0XNrIxuELSZx4d56IJuLQ0hgB6PExPYbjCAJXgFBiR+T77GA2MwCYRLTOjcwQxT9YZTom3CX FSQhLCAp0X3nDjOE7SPRcWUaWAObgJbE29vtYDWcAuESd1f8YwexWQRUJRad6gSq4QAaaiwx ZaYRiMkrYCPxdXUWiCkEtOr2JzeQYhGgIT1LLjJBnCkr8eTkIpYJjAKzkBw3C8lxs8BmqktM mZILEdaWePLuAiuErSax8PciJmTxBYxsqxgFilJzEitN9RILCnJS9ZLzczcxgsK5oTBiB+P/ ZVaHGAU4GJV4eE88nRAuxJpYVlyZe4hRgoNZSYTX/uHEcCHelMTKqtSi/Pii0pzU4kOMExmB PpzILCWanA+MtrySeEMTEwMTY2MzY2NzE3NaCiuJ885Y1hcuJJCeWJKanZpakFoEcxQTB6dU A2NGkMbkRKfC18uknrAI64TU/5IJyP8t/W75ofgUJfUzXyduVTvEoHDMxvzOjQ191sf6Z68N +xI0cVfzcb+ADVvs5hh1/LzPdFNhRtil6oO1XHX2FzieCoYx8a7fvWtO968lE/4UsM2usft1 utXhcfnugxsnxRjfZhQ/v6osnq9v74vz/qnPPgYosRRnJBpqMRcVJwIAwiOxGNoCAAA=
Archived-At: <>
Cc: MultiPath TCP - IETF WG <>
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: Fri, 22 Jul 2016 09:19:27 -0000


> On Jul 21, 2016, at 6:12 PM, wrote:
> We started the discussion yesterday on a potential new work item on “two-ended proxy scenario” – where there’s an MPTCP proxy in both the CPE and an aggregation point (for instance). The current charter is that one end host is MPTCP.
> If I can try and summarise the brief discussion yesterday (plus some side discussions) (please correct my inaccuracies):
> -          there are now deployments & products with an MPTCP proxy at each end, plus planned Broadband Forum work (WT-348 is about to be made public, with subsequent work to follow). So IETF work is timely (eg help allow an operator to buy CPE from one vendor and aggregation gateway from another vendor). 
> -          However, some people object to going beyond the current charter’s “one-ended proxy scenario” (since the “two-ended proxy” discourages deployment of MPTCP to all the end hosts, which is the ultimate goal)
> -          There are two proposals (transparent & plain mode: draft-boucadair-mptcp-plain-mode-08 & draft-peirens-mptcp-transparent-00). Are these addressing different use cases, or do we need to choose between them? would a (potential) charter item be to standardise existing draft(s), or to solve a problem /scenario?
> -          I think there was mention (by Wim??) that there’s a third proposal – how does this fit in, or did I get it wrong?
> -          One aspect of the plain mode draft is to allow transport of UDP traffic as well as TCP traffic. I think this is a proposal that should be discussed separately  - for instance it needs INT-area expertise.

I think the proxy-work is built of two items:

1. The documentation of how a deployment of one-ended and two-ended proxies look a like and the things that one should consider when doing so.

2. The plain-mode-option.

The point 1) is specific to MPTCP and probably useful to include in the charter.

For the point 2), I agree with Alan's comment in that this is entirely independent from MPTCP. It is basically a mechanism for 0-RTT proxying, by communicating the relevant IP-addresses between the proxies. Thus, I don't think that we should specify the plain-mode option in the MPTCP working-group, as the same plain-mode option might be useful in any other transport-layer protocol. And we probably don't want a list of draft-sctp-plain-mode, draft-tcp-plain-mode, ...


> I think it would be good to have more discussion before attempting to write some potential charter text (and then seeing if there’s consensus for it).
> Thanks!
> Philip Eardley
> Research and Innovation
> This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you.
> We monitor our email system, and may record your emails.
> British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England no: 1800000
> _______________________________________________
> multipathtcp mailing list
> <>
> <>