[multipathtcp] draft-boucadair-mptcp-plain-mode-07

<mohamed.boucadair@orange.com> Fri, 20 May 2016 05:46 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 36A2212D69D; Thu, 19 May 2016 22:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.345
X-Spam-Level:
X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 I4HHBiXag8Gx; Thu, 19 May 2016 22:46:54 -0700 (PDT)
Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177BF12D69B; Thu, 19 May 2016 22:46:53 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 37477206A2; Fri, 20 May 2016 07:46:52 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 132554005B; Fri, 20 May 2016 07:46:52 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0294.000; Fri, 20 May 2016 07:46:52 +0200
From: mohamed.boucadair@orange.com
To: MultiPath WG <multipathtcp@ietf.org>
Thread-Topic: draft-boucadair-mptcp-plain-mode-07
Thread-Index: AdGyWviLMJyWTP3NRLeXff5sM+09Mw==
Date: Fri, 20 May 2016 05:46:51 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/multipathtcp/KRcmwPmi4QHPc8YMJy-w7BRCUKU>
Cc: "draft-boucadair-mptcp-plain-mode@ietf.org" <draft-boucadair-mptcp-plain-mode@ietf.org>
Subject: [multipathtcp] draft-boucadair-mptcp-plain-mode-07
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: Fri, 20 May 2016 05:46:56 -0000

Dear all, 

An updated version of the specification is available online: https://datatracker.ietf.org/doc/draft-boucadair-mptcp-plain-mode/?include_text=1. This version takes into account comments that were received during the IETF meeting and other bilateral meetings.

The authors do think that this effort is within the scope of this WG, especially this part of the charter: 

"Finally, the working group will explore whether an MPTCP-aware
middlebox would be useful, where at least one end host is MPTCP-enabled.
For example, potentially helping MPTCP's incremental deployment by
allowing only one end host to be MPTCP-enabled and the middlebox acts as
an MPTCP proxy for the other end host, which runs TCP; and potentially
helping some mobility scenarios, where the middlebox acts as an anchor
between two MPTCP-enabled hosts. The working group will detail what real
problems an MPTCP-enabled middlebox might solve, how it would impact the
Multipath TCP architecture (RFC6182), what proxy approach might be
justified as compared against alternative solutions to the problems, and
the likely feasibility of solving the technical and security issues."

We would like to formally ask the WG to consider adoption of this draft.

Comments, suggestions, and questions are more than welcome.

Cheers,
Med

> -----Message d'origine-----
> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de
> internet-drafts@ietf.org
> Envoyé : jeudi 19 mai 2016 17:45
> À : i-d-announce@ietf.org
> Objet : I-D Action: draft-boucadair-mptcp-plain-mode-07.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
>         Title           : An MPTCP Option for Network-Assisted MPTCP
> Deployments: Plain Transport Mode
>         Authors         : Mohamed Boucadair
>                           Christian Jacquenet
>                           Denis Behaghel
>                           Stefano Secci
>                           Wim Henderickx
>                           Robert Skog
>                           Olivier Bonaventure
>                           Suresh Vinapamula
>                           SungHoon Seo
> 	Filename        : draft-boucadair-mptcp-plain-mode-07.txt
> 	Pages           : 31
> 	Date            : 2016-05-19
> 
> Abstract:
>    One of the promising deployment scenarios for Multipath TCP (MPTCP)
>    is to enable a Customer Premises Equipment (CPE) that is connected to
>    multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of its
>    network attachments.  Because of the lack of MPTCP support at the
>    server side, some service providers now consider a network-assisted
>    model that relies upon the activation of a dedicated function called
>    MPTCP concentrator.  This document focuses on a deployment scheme
>    where the identity of the MPTCP concentrator(s) is explicitly
>    configured on connected hosts.
> 
>    This document specifies an MPTCP option that is used to avoid the
>    encapsulation of packets and out-of-band signaling between the CPE
>    and the MPTCP concentrator.  Also, this document specifies how UDP
>    traffic, in particular, can be distributed among available paths by
>    leveraging MPTCP capabilities.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-boucadair-mptcp-plain-mode/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-boucadair-mptcp-plain-mode-07
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt