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

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 12 Jan 2018 16:29:39 +0100

Hi all,

replying to Joe’s email but directed to the whole group as I would like to clarify one point:

Even though I think this was stated explicitly and correctly in the initial mail by the chairs that was starting the adopting call, I would like to note again that the current charter seems allow the group to work on these kind of approaches. The original mails stated:

> The TCPM charter states that the "WG mostly focuses on maintenance issues
> (e.g., bug fixes) and modest changes to the protocol, algorithms, and
> interfaces that maintain TCP's utility". Assisting the deployment of new TCP
> extensions could be understood as one way to ensure TCP's utility.

draft-bonaventure-mptcp-converters does not propose direct changes in the TCP protocol itself but it aims to support deployment of TCP options and thereby "maintains TCP’s utility".

Of course this proposal could be seen as an application to TCP but given the application is to enable deployment of TCP options such that TCP extensions can be used by other over-the-top applications, it is very closely interconnected to the TCP protocol itself.

I proposed to discuss this doc in tcpm because I think TCP expertise is needed here and I would feel uncomfortable if this work would happen in a wg outside of the tsv area. An alternative would be to narrow the scope of the proposed approach down to enable MCTCP support only and proceed the work in the MPTCP group. However, as there is a much broader TCP expertise in tcpm, I’m very certain that the quality of the final work would be higher if the document would be adopted in tcpm instead.

To my understanding Joe’s initial emails was saying that he does not support the adoption of this document in tcpm as over-the-top applications are out of scope. As explained above, my assessment is that this work is in scope for tcpm. 

Effectively the questions that were originally ask in the adoption call were not so much on the scope but:

1) Is there support for this work in tcpm, meaning are people in this group willing to review and discuss this work?

2) Are there concerns against the adoption of this document? 

I well notice that there have bee three people in the group that have concerns regarding the question if this document is in scope. However, I , and I believe the chairs as well, do not share these concerns based on the provided arguments in the discussion. 

Therefore, I would like to make another request to the group and try to figure out if there is enough energy and interest in this group to pursue this work in tcpm (instead of mptcp or potentially some non-tsv group). Please let me know if you in general support the work and would be willing to review and discuss the proposed draft in this group (question 1 above)!

Of course, please also let me/us know if there are other (technical) concerns that would preclude the adoption of this work that did not come up yet!

Thanks,
Mirja

> Am 06.12.2017 um 05:26 schrieb Joe Touch <[email-masked]>:
> 
> 
> 
> On 12/5/2017 2:48 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>> Hi Joe, all,
>> 
>> Regarding "*out of scope for* TCPM":  Whether a document is in scope of TCPM, or not, depends on the TCPM charter wording. 
> Although I appreciate that's strictly true, I doubt the charter would
> change to include "haiku development".
> 
> By the same token, IMO, this doc falls into one of two categories:
> 
> 1) if, as is, it proposes direct placement of out-of-band data in the
> SYN payload, I think it is a bad idea and not worth pursuing in TCPM
> 
> 2) if, instead, it is corrected to explain that its use of the data
> channel for proxy information is simply a conventional application data
> path, then it would not be a "modification of TCP" at all (minor or
> otherwise). If that isn't clearly out of scope for TCPM, I do not know
> what is or ever would be (can we start haiku next, in that case?)
> 
> Joe
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: 서성훈(5G Core Project) <[email-masked]>
Date: Wed, 17 Jan 2018 23:49:37 +0000

Hi all,

As a coauthor of this draft, I fully support the this work to be dealt in this WG, and of course will contribute additional use cases and so forth.

Regards,
SungHoon

________________________________

From: Mirja Kühlewind <[email-masked]>
Date: 13 January 2018 at 12:30:08 AM GMT+9
To: [email-masked] <[email-masked]>
Cc: multipathtcp <[email-masked]>
Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ?

Hi all,

Thanks,
Mirja

이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못 전송된 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다.
This E-mail may contain confidential information and/or copyright material. This email is intended for the use of the addressee only. If you receive this email by mistake, please either delete it without reproducing, distributing or retaining copies thereof or notify the sender immediately.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 17 Jan 2018 23:54:36 +0000

Hi Mirja,

I strongly support the work on MPTCP Proxy. We (at Cisco) are doing some implementations and like to see a standard specifications on the same for interop and other reasons.

Regards
Sri

From: Mirja Kühlewind <[email-masked]<mailto:[email-masked]>>
Date: 13 January 2018 at 12:30:08 AM GMT+9
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: multipathtcp <[email-masked]<mailto:[email-masked]>>
Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ?

Hi all,

Thanks,
Mirja

> Am 06.12.2017 um 05:26 schrieb Joe Touch <[email-masked]<mailto:[email-masked]>>:
>
>
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
multipathtcp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 18 Jan 2018 04:55:43 +0000

Same here we are working on implementation and we want to get a standard to ensure interoperability since multiple vendors are involved. I will spent time to review and contribute to this work

From: multipathtcp <[email-masked]> on behalf of "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thursday, 18 January 2018 at 00:54
To: "서성훈(5G Core Project)" <[email-masked]>, Mirja Kühlewind <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: multipathtcp <[email-masked]>
Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ?

Hi Mirja,

Regards
Sri

Hi all,

Thanks,
Mirja

---

From: <[email-masked]>
Date: Thu, 18 Jan 2018 06:45:47 +0000

Hi Mirja, all, 

I reiterate my support to this work. 

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:[email-masked]] De la part de
> Mirja Kühlewind
> Envoyé : vendredi 12 janvier 2018 16:30
> À : [email-masked]
> Cc : multipathtcp
> Objet : Re: [multipathtcp] [tcpm] Working group acceptance of draft-
> bonaventure-mptcp-converters ?
> 
> Hi all,
> 
> Even though I think this was stated explicitly and correctly in the
> initial mail by the chairs that was starting the adopting call, I would
> like to note again that the current charter seems allow the group to work
> on these kind of approaches. The original mails stated:
> 
> draft-bonaventure-mptcp-converters does not propose direct changes in the
> TCP protocol itself but it aims to support deployment of TCP options and
> thereby "maintains TCP’s utility".
> 
> Of course this proposal could be seen as an application to TCP but given
> the application is to enable deployment of TCP options such that TCP
> extensions can be used by other over-the-top applications, it is very
> closely interconnected to the TCP protocol itself.
> 
> I proposed to discuss this doc in tcpm because I think TCP expertise is
> needed here and I would feel uncomfortable if this work would happen in a
> wg outside of the tsv area. An alternative would be to narrow the scope of
> the proposed approach down to enable MCTCP support only and proceed the
> work in the MPTCP group. However, as there is a much broader TCP expertise
> in tcpm, I’m very certain that the quality of the final work would be
> higher if the document would be adopted in tcpm instead.
> 
> To my understanding Joe’s initial emails was saying that he does not
> support the adoption of this document in tcpm as over-the-top applications
> are out of scope. As explained above, my assessment is that this work is
> in scope for tcpm.
> 
> 1) Is there support for this work in tcpm, meaning are people in this
> group willing to review and discuss this work?
> 
> I well notice that there have bee three people in the group that have
> concerns regarding the question if this document is in scope. However, I ,
> and I believe the chairs as well, do not share these concerns based on the
> provided arguments in the discussion.
> 
> Therefore, I would like to make another request to the group and try to
> figure out if there is enough energy and interest in this group to pursue
> this work in tcpm (instead of mptcp or potentially some non-tsv group).
> Please let me know if you in general support the work and would be willing
> to review and discuss the proposed draft in this group (question 1 above)!
> 
> Of course, please also let me/us know if there are other (technical)
> concerns that would preclude the adoption of this work that did not come
> up yet!
> 
> Thanks,
> Mirja
> 
> 
> 
> >> Regarding "*out of scope for* TCPM":  Whether a document is in scope of
> TCPM, or not, depends on the TCPM charter wording.

---

From: Gregory Detal <[email-masked]>
Date: Thu, 18 Jan 2018 09:09:50 +0100

Hi Mirja, all,

The converter draft describes an evolution of a solution that we (Tessares)
have already deployed in several networks to combine xDSL and LTE with
Multipath TCP. We and our customers would like to see a standard
specification for interoperability reasons and we are committed to
contribute to the development of this document.

Regards,

On Fri, Jan 12, 2018 at 4:29 PM, Mirja Kühlewind <
[email-masked]> wrote:

> are out of scope. As explained above, my assessment is that this work is in
> scope for tcpm.
>
> concerns that would preclude the adoption of this work that did not come up
> yet!
>
> Thanks,
> Mirja
>
>
>

-- 
 <http://www.tessares.net> Gregory Detalº | Co-Founder
& CTO
[email-masked] | +32 486 83 50 51 <gregory.detal%40tessares.net>
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
<https://www.google.com/maps?q=1+Avenue+Jean+Monnet,+1348+Ottignies-Louvain-la-Neuve,+Belgium>

ºTRAAL Consulting SPRL

-- 

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.

---

From: Stefano Secci <[email-masked]>
Date: Thu, 18 Jan 2018 14:06:40 +0100

Hello,

in LIP6 we're working since 2014 on MPTCP proxy design and experiments, and I'm personally available to review also next versions of the MPTCP converter work and participate to the discussions.

Best,
Stefano

> Le 12 janv. 2018 à 16:29, Mirja Kühlewind <[email-masked]> a écrit :
> 
> Hi all,
>

---

From: Kuhn Nicolas <[email-masked]>
Date: Thu, 18 Jan 2018 14:08:05 +0000

Hi, 

We are also currently working on this topic for our specific SATCOM use-case.
I am thus available for review and contribute to work on MPTCP converter work.

Kind regards,

Nico

-----Message d'origine-----
De : tcpm [mailto:[email-masked]] De la part de Stefano Secci
Envoyé : jeudi 18 janvier 2018 14:07
À : Mirja Kühlewind
Cc : multipathtcp; [email-masked]
Objet : Re: [tcpm] [multipathtcp] Working group acceptance of draft-bonaventure-mptcp-converters ?

Hello,

Best,
Stefano

>> The TCPM charter states that the "WG mostly focuses on maintenance 
>> issues (e.g., bug fixes) and modest changes to the protocol, 
>> algorithms, and interfaces that maintain TCP's utility". Assisting 
>> the deployment of new TCP extensions could be understood as one way to ensure TCP's utility.
> 
>> channel for proxy information is simply a conventional application 
>> data path, then it would not be a "modification of TCP" at all (minor 
>> or otherwise). If that isn't clearly out of scope for TCPM, I do not 
>> know what is or ever would be (can we start haiku next, in that 
>> case?)
>> 
>> Joe
>> 

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Muley, Praveen (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 19 Jan 2018 04:53:53 +0000

Working on implementation. Please count my support for this  work.

-Praveen 

-----Original Message-----
From: multipathtcp [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, January 17, 2018 10:46 PM
To: Mirja Kühlewind <[email-masked]>; [email-masked]
Cc: multipathtcp <[email-masked]>
Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ?

Hi Mirja, all, 

Cheers,
Med

> Mirja Kühlewind Envoyé : vendredi 12 janvier 2018 16:30 À : 
> [email-masked] Cc : multipathtcp Objet : Re: [multipathtcp] [tcpm] 
> Working group acceptance of draft- bonaventure-mptcp-converters ?
> 
> Hi all,
> 
> initial mail by the chairs that was starting the adopting call, I 
> would like to note again that the current charter seems allow the 
> group to work on these kind of approaches. The original mails stated:
> 
> issues
> > (e.g., bug fixes) and modest changes to the protocol, algorithms, 
> > and interfaces that maintain TCP's utility". Assisting the 
> > deployment of new
> TCP
> draft-bonaventure-mptcp-converters does not propose direct changes in 
> the TCP protocol itself but it aims to support deployment of TCP 
> options and thereby "maintains TCP’s utility".
> 
> Of course this proposal could be seen as an application to TCP but 
> given the application is to enable deployment of TCP options such that 
> TCP extensions can be used by other over-the-top applications, it is 
> very closely interconnected to the TCP protocol itself.
> 
> I proposed to discuss this doc in tcpm because I think TCP expertise 
> is needed here and I would feel uncomfortable if this work would 
> happen in a wg outside of the tsv area. An alternative would be to 
> narrow the scope of the proposed approach down to enable MCTCP support 
> only and proceed the work in the MPTCP group. However, as there is a 
> much broader TCP expertise in tcpm, I’m very certain that the quality 
> of the final work would be higher if the document would be adopted in tcpm instead.
> 
> support the adoption of this document in tcpm as over-the-top 
> applications are out of scope. As explained above, my assessment is 
> that this work is in scope for tcpm.
> 
> concerns regarding the question if this document is in scope. However, 
> I , and I believe the chairs as well, do not share these concerns 
> based on the provided arguments in the discussion.
> 
> Therefore, I would like to make another request to the group and try 
> to figure out if there is enough energy and interest in this group to 
> pursue this work in tcpm (instead of mptcp or potentially some non-tsv group).
> Please let me know if you in general support the work and would be 
> willing to review and discuss the proposed draft in this group (question 1 above)!
> 
> concerns that would preclude the adoption of this work that did not 
> come up yet!
> 
> Thanks,
> Mirja
> 
> 
> 
> > Although I appreciate that's strictly true, I doubt the charter 
> > would change to include "haiku development".
> >
> > 1) if, as is, it proposes direct placement of out-of-band data in 
> > the SYN payload, I think it is a bad idea and not worth pursuing in 
> > TCPM
> >
> > data path, then it would not be a "modification of TCP" at all 
> > (minor or otherwise). If that isn't clearly out of scope for TCPM, I 
> > do not know what is or ever would be (can we start haiku next, in 
> > that case?)
> >
> > Joe
> >