Return-Path: 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 CC13C129516 for ; Thu, 23 Mar 2017 16:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VqupENsCaOtR for ; Thu, 23 Mar 2017 16:40:44 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C89127058 for ; Thu, 23 Mar 2017 16:40:43 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id y18so987971itc.1 for ; Thu, 23 Mar 2017 16:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Ck7IzmXsCvOLBDDx64Bgj1IyVZnjmXGyQliFg8Ad2wk=; b=jp9j6zk0mr3p57M7/vsfCqW1Lm3LTdN6ENuAE6hcNTfEH9agSD4Tv5K6myCwSJl3YU uTmgL+KMOp1DiNewBoBkc0+SjY9ECvzTYc0VVy8uQnqaFJf+CrD5DCtYqiY7PMV0kaHx BsP09pHvQB++2kPoGbd3lJN/L83UOoHVzTYQ1vCPrtO6qa6AzDYSjAEb5TcpFJ+4cvWn FNoucVaX5+BstCPqVXSML0JFLRa/dH1eCOQnhDqfyfQ5jO3oOaP1+FIjkMPYU1DJI+4A uAPo/7ot9KRGTxqOqe4gtS8bXtadXBIwoQrNUoGeEE+eko8HfpCN5blWjemiE+qN1aCa C2fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Ck7IzmXsCvOLBDDx64Bgj1IyVZnjmXGyQliFg8Ad2wk=; b=bgp6Hj/S+jTFIjiSB/eYq7sKlVY8PYKA+o651dbRY9KOzTZJX3HdquFee/Lu4yJjl9 1ykuj1vfZ/ENJTK12fSmaom4mPujrs0FIRD7YRjAs6azbPNmIRLuXA1Jw3VUqESAgdjg ruEAF8tH3IF0b5A/MC0CLTQv42ArcWr4Sw3Ph8w/fB+nS+aRa/buuvt/8clufFYkX397 K1nZYgE8Lm9ubleW1gvC2gl8RDWuj3qRV7mSnXvTSZENybUPOn/3Mc2kwPKfnoxfRc3X D9Vzuy4HudjK61sC2knhCFQDsQxlzumVB4riNwLkvCUddlFGgsNUB0+rF4ThmEiwpoV2 osVg== X-Gm-Message-State: AFeK/H3tmUDSANXbKjFrUNxQTu2yLZUEas3JLxNqz85L75F4P+ijF1W59anhoDJuR3BfLg== X-Received: by 10.36.89.211 with SMTP id p202mr367944itb.97.1490312443170; Thu, 23 Mar 2017 16:40:43 -0700 (PDT) Received: from [172.20.24.94] (clargranips04.c.subnet.rcn.com. [207.181.197.3]) by smtp.gmail.com with ESMTPSA id y21sm374329ioi.0.2017.03.23.16.40.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 23 Mar 2017 16:40:12 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_38361FA2-18E3-4C7B-89F7-4B87FDD37DEA" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E214F1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 23 Mar 2017 23:40:11 +0000 Cc: multipathtcp@ietf.org Message-Id: References: <148913232809.5852.12101301305757163816.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009E214F1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [multipathtcp] New Version Notification for draft-boucadair-mptcp-plain-mode-10.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 23:40:47 -0000 --Apple-Mail=_38361FA2-18E3-4C7B-89F7-4B87FDD37DEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Med, all, Thanks for this, and I=E2=80=99m sorry it=E2=80=99s taken a couple of = weeks to respond. This document is certainly clearer to follow than = previous versions and it=E2=80=99s clearer where you=E2=80=99re going = with this now. You have two different ways of implementing MPTCP = proxying which work in different deployment scenarios. My main concern remains the need for this MP_PREFER_PROXY option. The use case as I see it is for the CPE acting as an MCP to insert this = into the flow in order to signal for the other MCP to pick up the flow = and proxy it. But I still find myself asking why? Why is this solution uniquely better than either: - Explicitly address the MCP using MP_CONVERT; or - Just insert MCP into everything which doesn=E2=80=99t support MPTCP = anyway This would potentially require DHCP to deliver the MCP address for point = 1, and potential policy configuration as to what to proxy and what not = to for point 2, but are these significant issues? What sort of policy = would a client be able to apply which a proxy would not be able to? And = are there any scenarios why the MP_PREFER_PROXY bit is the only way of = achieving what you want? Given this option is now a separate option and not a bit in the = MP_CAPABLE handshake I am less concerned about its impact on the base = protocol spec, since this can be kept entirely separate, but I am still = puzzled as to the actual real-world requirements of this rather than the = other two options. As a side issue, and not to derail this conversation, I=E2=80=99d rather = the term =E2=80=9CMP_CONVERT" didn=E2=80=99t look quite so much like an = MPTCP option when it wasn=E2=80=99t. Regards, Alan > On 10 Mar 2017, at 08:43, mohamed.boucadair@orange.com wrote: >=20 > Dear all,=20 >=20 > A new version of the draft is available online. This version = integrates the comments that were raised on the mailing list.=20 > We had many off-line discussions with Alan, this version is the = outcome of those discussion. The main changes are: >=20 > * MP_CONVERT object does not consume anymore the MPTCP option = codepoints space. > * A new MPTCP option (MP_PREFER_PROXY) is defined to demux native = connections vs proxied one when the implicit mode is in use. > * MCPs are now able to detect if remote MCPs do not support MP_CONVERT > * Only TCP is covered > * Interference with TFO are discussed=20 >=20 > Comments, questions, and suggestions are always welcome. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Envoy=C3=A9 : vendredi 10 mars 2017 08:52 >> =C3=80 : Wim Henderickx; Luis M. Contreras; stefano.secci@lip6.fr; = Wouter >> Cloetens; Suresh Vinapamula; Denis Behaghel; BOUCADAIR Mohamed = IMT/OLN; >> Suresh Vinapamula; Robert Skog; Luis Contreras; JACQUENET Christian >> IMT/OLN; Bart Peirens; Ullrich Meyer; Denis Behaghel; Olivier = Bonaventure; >> SungHoon Seo; Stefano Secci >> Objet : New Version Notification for = draft-boucadair-mptcp-plain-mode- >> 10.txt >>=20 >>=20 >> A new version of I-D, draft-boucadair-mptcp-plain-mode-10.txt >> has been successfully submitted by Mohamed Boucadair and posted to = the >> IETF repository. >>=20 >> Name: draft-boucadair-mptcp-plain-mode >> Revision: 10 >> Title: Extensions for Network-Assisted MPTCP Deployment = Models >> Document date: 2017-03-09 >> Group: Individual Submission >> Pages: 25 >> URL: https://www.ietf.org/internet-drafts/draft-boucadair- >> mptcp-plain-mode-10.txt >> Status: = https://datatracker.ietf.org/doc/draft-boucadair-mptcp- >> plain-mode/ >> Htmlized: = https://tools.ietf.org/html/draft-boucadair-mptcp-plain- >> mode-10 >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-mptcp- >> plain-mode-10 >>=20 >> Abstract: >> Because of the lack of Multipath TCP (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 >> Conversion Point (MCP). Network-Assisted MPTCP deployment models = are >> designed to facilitate the adoption of MPTCP for the establishment = of >> multi-path communications without making any assumption about the >> support of MPTCP by the communicating peers. MCPs located in the >> network are responsible for establishing multi-path communications = on >> behalf of endpoints, thereby taking advantage of MPTCP capabilities >> to achieve different goals that include (but are not limited to) >> optimization of resource usage (e.g., bandwidth aggregation), of >> resiliency (e.g., primary/backup communication paths), and traffic >> offload management. >>=20 >> This document specifies extensions for Network-Assisted MPTCP >> deployment models. >>=20 >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --Apple-Mail=_38361FA2-18E3-4C7B-89F7-4B87FDD37DEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Med, all,

Thanks for this, and I=E2=80=99m sorry it=E2=80=99s taken a = couple of weeks to respond. This document is certainly clearer to follow = than previous versions and it=E2=80=99s clearer where you=E2=80=99re = going with this now. You have two different ways of implementing MPTCP = proxying which work in different deployment scenarios.

My main concern remains = the need for this MP_PREFER_PROXY option.

The use case as I see it is for the CPE = acting as an MCP to insert this into the flow in order to signal for the = other MCP to pick up the flow and proxy it. But I still find myself = asking why?

Why is this solution uniquely = better than either:

- Explicitly address the MCP using MP_CONVERT; or
- Just insert MCP into everything which doesn=E2=80=99t = support MPTCP anyway

This would potentially require DHCP to deliver the MCP = address for point 1, and potential policy configuration as to what to = proxy and what not to for point 2, but are these significant issues? = What sort of policy would a client be able to apply which a proxy would = not be able to? And are there any scenarios why the MP_PREFER_PROXY bit = is the only way of achieving what you want?

Given this option is now a separate = option and not a bit in the MP_CAPABLE handshake I am less concerned = about its impact on the base protocol spec, since this can be kept = entirely separate, but I am still puzzled as to the actual real-world = requirements of this rather than the other two options.

As a side issue, and not = to derail this conversation, I=E2=80=99d rather the term =E2=80=9CMP_CONVE= RT" didn=E2=80=99t look quite so much like an MPTCP option when it = wasn=E2=80=99t.

Regards,
Alan

On = 10 Mar 2017, at 08:43, mohamed.boucadair@orange.com wrote:

Dear = all,

A new version of the draft is = available online. This version integrates the comments that were raised = on the mailing list.
We had many off-line discussions = with Alan, this version is the outcome of those discussion. The main = changes are:

* MP_CONVERT object does not = consume anymore the MPTCP option codepoints space.
* A new = MPTCP option (MP_PREFER_PROXY) is defined to demux native connections vs = proxied one when the implicit mode is in use.
* MCPs are = now able to detect if remote MCPs do not support MP_CONVERT
* Only TCP is covered
* Interference with TFO = are discussed

Comments, questions, and = suggestions are always welcome.

Cheers,
Med

-----Message d'origine-----
De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Envoy=C3=A9 : vendredi 10 mars 2017 08:52
=C3=80 : Wim Henderickx; Luis M. Contreras; stefano.secci@lip6.fr; Wouter
Cloetens; = Suresh Vinapamula; Denis Behaghel; BOUCADAIR Mohamed IMT/OLN;
Suresh Vinapamula; Robert Skog; Luis Contreras; JACQUENET = Christian
IMT/OLN; Bart Peirens; Ullrich Meyer; Denis = Behaghel; Olivier Bonaventure;
SungHoon Seo; Stefano = Secci
Objet : New Version Notification for = draft-boucadair-mptcp-plain-mode-
10.txt


A new version of I-D, = draft-boucadair-mptcp-plain-mode-10.txt
has been = successfully submitted by Mohamed Boucadair and posted to the
IETF repository.

Name: = draft-boucadair-mptcp-plain-mode
Revision: 10
Title:= = Extensions for Network-Assisted MPTCP Deployment Models
Document date: 2017-03-09
Group:= = Individual Submission
Pages: 25
URL: =            https://www.ietf.org/internet-drafts/draft-boucadair-
mptcp-plain-mode-10.txt
Status: =         https://datatracker.ietf.org/doc/draft-boucadair-mptcp-
plain-mode/
Htmlized: =       https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-10
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-mptcp-<= br class=3D"">plain-mode-10

Abstract:
  Because of the lack of Multipath TCP (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
  Conversion Point (MCP). =  Network-Assisted MPTCP deployment models are
=   designed to facilitate the adoption of MPTCP for the = establishment of
  multi-path communications = without making any assumption about the
=   support of MPTCP by the communicating peers.  MCPs = located in the
  network are responsible for = establishing multi-path communications on
=   behalf of endpoints, thereby taking advantage of MPTCP = capabilities
  to achieve different goals that = include (but are not limited to)
  optimization = of resource usage (e.g., bandwidth aggregation), of
=   resiliency (e.g., primary/backup communication paths), and = traffic
  offload management.

  This document specifies extensions for = Network-Assisted MPTCP
  deployment models.




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.

The IETF = Secretariat

_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp

= --Apple-Mail=_38361FA2-18E3-4C7B-89F7-4B87FDD37DEA--