Re: [multipathtcp] potential MPTCP proxy charter item

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Wed, 19 October 2016 20:57 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
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 722E11294D6 for <multipathtcp@ietfa.amsl.com>; Wed, 19 Oct 2016 13:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.332
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVfg_ew3euyJ for <multipathtcp@ietfa.amsl.com>; Wed, 19 Oct 2016 13:57:03 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A44812945E for <multipathtcp@ietf.org>; Wed, 19 Oct 2016 13:57:03 -0700 (PDT)
Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com [209.85.213.46]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5F8CA2783C7 for <multipathtcp@ietf.org>; Thu, 20 Oct 2016 05:57:01 +0900 (JST)
Received: by mail-vk0-f46.google.com with SMTP id 83so43955598vkd.0 for <multipathtcp@ietf.org>; Wed, 19 Oct 2016 13:57:01 -0700 (PDT)
X-Gm-Message-State: AA6/9Rn6c+CJyUMPevdCBd7QCE9sRlnilI0b9kaX0nRBpp2vI0kOBu5p3HKHnyGLJi6rG49iVAk7d/JRorS+Ig==
X-Received: by 10.31.152.195 with SMTP id a186mr7210732vke.79.1476910619879; Wed, 19 Oct 2016 13:56:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.65.7 with HTTP; Wed, 19 Oct 2016 13:56:59 -0700 (PDT)
In-Reply-To: <8bed05c5-9f6f-04aa-8aa8-690aa3ce30f4@uclouvain.be>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <787AE7BB302AE849A7480A190F8B933009D945B7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <428609FE-DE79-45CD-B668-EF95F409B593@tik.ee.ethz.ch> <8bed05c5-9f6f-04aa-8aa8-690aa3ce30f4@uclouvain.be>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Wed, 19 Oct 2016 13:56:59 -0700
X-Gmail-Original-Message-ID: <CAO249ydpdtR53VBniDczSt4zj_kk32c2W_FoZKs2XED0Jzk7Jw@mail.gmail.com>
Message-ID: <CAO249ydpdtR53VBniDczSt4zj_kk32c2W_FoZKs2XED0Jzk7Jw@mail.gmail.com>
To: "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/IBEuBj-oBe9bNxLwH6E0rThh8P8>
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: Wed, 19 Oct 2016 20:57:05 -0000

Hello,

On Wed, Oct 19, 2016 at 12:42 PM, Olivier Bonaventure
<Olivier.Bonaventure@uclouvain.be> 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
preserved.

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.

Thanks,
--
Yoshi