Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ?

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Mon, 04 December 2017 21:17 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 57B8412711D; Mon, 4 Dec 2017 13:17:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 MrxQ2sLz_ppX; Mon, 4 Dec 2017 13:17:12 -0800 (PST)
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 17588126DD9; Mon, 4 Dec 2017 13:17:11 -0800 (PST)
Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0CD45278333; Tue, 5 Dec 2017 06:17:09 +0900 (JST)
Received: by mail-wm0-f47.google.com with SMTP id f206so10596658wmf.5; Mon, 04 Dec 2017 13:17:08 -0800 (PST)
X-Gm-Message-State: AKGB3mLh3rALpfSn0FTYa9Nh3r1Om9RgtDVbFY7eA6aXPbxL7+q8DISu jM+cSx49IQmF1mF99FCSWKNjHwzt7rglIjfkVmM=
X-Google-Smtp-Source: AGs4zMaTVKsu/0Jt/U2E0zM9zkZbcGWg+KsHVy1pEVjLtAfR6Xo2ukK26hioItBi7ZA/lqgAXF/mch+OZCXFm2jDrvk=
X-Received: by 10.28.24.132 with SMTP id 126mr4196697wmy.34.1512422226903; Mon, 04 Dec 2017 13:17:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.165.153 with HTTP; Mon, 4 Dec 2017 13:17:06 -0800 (PST)
In-Reply-To: <CAK6E8=f0GG+Y45NqQ3zb_ChFWpWZ4mS5sgeQVPO7e0zmTbOyeA@mail.gmail.com>
References: <AM5PR0701MB25475FD66E9553F2947DD22C933F0@AM5PR0701MB2547.eurprd07.prod.outlook.com> <AM5PR0701MB25470B276B0889170FC309FE933F0@AM5PR0701MB2547.eurprd07.prod.outlook.com> <1d4eda72-b822-c8b5-1207-d52ce2e3fe62@strayalpha.com> <CAK6E8=f0GG+Y45NqQ3zb_ChFWpWZ4mS5sgeQVPO7e0zmTbOyeA@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Mon, 04 Dec 2017 13:17:06 -0800
X-Gmail-Original-Message-ID: <CAO249yee_RpHRKYuCjJTOhkFzG_hmyLy=mpJGF6-vC+w-bYG4Q@mail.gmail.com>
Message-ID: <CAO249yee_RpHRKYuCjJTOhkFzG_hmyLy=mpJGF6-vC+w-bYG4Q@mail.gmail.com>
To: Yuchung Cheng <ycheng@google.com>
Cc: Joe Touch <touch@strayalpha.com>, multipathtcp <multipathtcp@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="001a1146fdc895cd65055f8a3df7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/KsC8HlZlhakaWBeG2P3K93d2R1M>
Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ?
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 04 Dec 2017 21:17:14 -0000

On Mon, Dec 4, 2017 at 10:24 AM, Yuchung Cheng <ycheng@google.com> wrote:
>
>
> TFO today is still facing bad middle-boxes issues and
> demands extreme conservative heuristics to deploy (see last
> presentation by Praveen in tcpm). Ultimately they need to be
> applied by either the client or the proposed converters.
>

I am personally thinking it will be less impactful in case of this
converter, although I agree for general use of TFO.
In my understanding, the converters will be deployed inside ISPs where they
provide internet connections to their clients (in early deployment scenario)
So, I guess TFO will be used only between their client and their cloud for
this as they don't have to use TFO from the converters to servers.
--
Yoshi (with no hat)