Re: [multipathtcp] potential MPTCP proxy charter item

Yoshifumi Nishida <> Wed, 19 October 2016 20:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 722E11294D6 for <>; Wed, 19 Oct 2016 13:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.332
X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cVfg_ew3euyJ for <>; Wed, 19 Oct 2016 13:57:03 -0700 (PDT)
Received: from ( [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A44812945E for <>; Wed, 19 Oct 2016 13:57:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 5F8CA2783C7 for <>; Thu, 20 Oct 2016 05:57:01 +0900 (JST)
Received: by with SMTP id 83so43955598vkd.0 for <>; Wed, 19 Oct 2016 13:57:01 -0700 (PDT)
X-Gm-Message-State: AA6/9Rn6c+CJyUMPevdCBd7QCE9sRlnilI0b9kaX0nRBpp2vI0kOBu5p3HKHnyGLJi6rG49iVAk7d/JRorS+Ig==
X-Received: by with SMTP id a186mr7210732vke.79.1476910619879; Wed, 19 Oct 2016 13:56:59 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Oct 2016 13:56:59 -0700 (PDT)
In-Reply-To: <>
References: <> <787AE7BB302AE849A7480A190F8B933009D945B7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <>
From: Yoshifumi Nishida <>
Date: Wed, 19 Oct 2016 13:56:59 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item
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: Wed, 19 Oct 2016 20:57:05 -0000


On Wed, Oct 19, 2016 at 12:42 PM, Olivier Bonaventure
<> wrote:
> Mirja,
>> there are two cases to distinguish here:
>> 1) you have one or two MPTCP proxies that terminate the TCP connection and
>> open a new MPTCP connection
> There is a very clear demand for this type of solution and there are various
> implementations that are available or are being developped. Several
> deployments exist and there is a large demand for this type of services. It
> would be silly for the IETF to ignore this use case after having spent years
> to specify the Multipath TCP protocol.

I also think we should not ignore the use case.
But, I am somehow thinking that we might want to clarify the
terminologies a bit more so that we can have more clear focus.

I might be wrong, but these words give me the following impressions.

1: Protocol X proxy:
    It speaks protocol X on behalf of communicating endpoints .
    From one end's point of view, it looks as if the other end speaks
protocol X.

2: Tunneling over protocol X
     Protocol X carries other protocol Y packets (by using
encapsulation)  All info in protocol Y (headers, etc) will be

3:  Protocol X-Y / Protocol Y-X gateway
     Convert protocol X into protocol Y, or convert protocol Y into
protocol X for protocol connectivity/compatibility, etc.
     Some info in the original protocol might be lost due to the conversion.

If I follow these impressions, it seems that some proposals are close
to 3. (again, I might be wrong)
I might want to check if we want to clarify this point in the charter
or leave it ambiguous.
I am just wondering if we might need to clarify the terminology or
adding some texts to avoid miscommunications.