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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Tue, 02 August 2016 04:15 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 75E3A12D146 for <multipathtcp@ietfa.amsl.com>; Mon, 1 Aug 2016 21:15:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, 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 O5DyE0Itu4Dt for <multipathtcp@ietfa.amsl.com>; Mon, 1 Aug 2016 21:15:25 -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 C5E6E12D13B for <multipathtcp@ietf.org>; Mon, 1 Aug 2016 21:15:25 -0700 (PDT)
Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com [209.85.213.53]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 209752786B9 for <multipathtcp@ietf.org>; Tue, 2 Aug 2016 13:15:24 +0900 (JST)
Received: by mail-vk0-f53.google.com with SMTP id s189so113889867vkh.1 for <multipathtcp@ietf.org>; Mon, 01 Aug 2016 21:15:24 -0700 (PDT)
X-Gm-Message-State: AEkoout5/SeJK5jh4ohfj1vzHDK7zJlJEKDhkFLuGwRUnCLlvZZe0F8s77EABrvRq6I5+iIx+M9Bk3ufyyAV+A==
X-Received: by 10.31.208.196 with SMTP id h187mr28479411vkg.84.1470111322648; Mon, 01 Aug 2016 21:15:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.4.164 with HTTP; Mon, 1 Aug 2016 21:15:21 -0700 (PDT)
In-Reply-To: <0084773F-53E5-41A4-A244-430DAF12322A@nokia.com>
References: <b779dd12f1bb412c96c800eddaaf0247@rew09926dag03b.domain1.systemhost.net> <e2aa6ac517194af4b8c25c07f8e469fb@rew09926dag03b.domain1.systemhost.net> <9cafc779-502e-cc7f-676c-f6659e207c81@uclouvain.be> <3100ff74-0c7d-1815-03a1-aa4cec36d1e4@oracle.com> <3D8D4118-39CA-46A6-BFBD-026376C02058@nokia.com> <811b2c78-0976-6994-d759-8cac5fa58864@oracle.com> <0084773F-53E5-41A4-A244-430DAF12322A@nokia.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Mon, 01 Aug 2016 21:15:21 -0700
X-Gmail-Original-Message-ID: <CAO249ycGiQyHy4qoKupE=NkFcSuLrPs3Bu2ie_5xtwogSSPJCw@mail.gmail.com>
Message-ID: <CAO249ycGiQyHy4qoKupE=NkFcSuLrPs3Bu2ie_5xtwogSSPJCw@mail.gmail.com>
To: "Henderickx, Wim (Nokia - BE)" <wim.henderickx@nokia.com>
Content-Type: multipart/alternative; boundary="001a114bd45c2ac4e105390ef79e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/Ra055WmBO41XGlPl0ygY7ZQ41Hw>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
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: Tue, 02 Aug 2016 04:15:27 -0000

Hello,

On Mon, Aug 1, 2016 at 12:05 PM, Henderickx, Wim (Nokia - BE) <
wim.henderickx@nokia.com> wrote:

>
> >>> Since we seem to be only considering TCP, will the protocol field be
> >>> removed from the draft ?
> >> WH> this is to be discussed
> >It has to be or we are allowing protocol encapsulation. In which case we
> >need to define the complete mechanism.
> WH> I would agree to that


Just in case, I might want to clarify this won't be encapsulation since I
think what plain-mode does is protocol conversion.
My concern is protocol conversions between mptcp-tcp and mptcp-udp might be
very different. Also, if we try to support other protocols, we might need
other conversion rules.

Thanks,
--
Yoshi