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

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 <mirja.kuehlewind@tik.ee.ethz.ch<mailto:mirja.kuehlewind@tik.ee.ethz.ch>>
Date: 13 January 2018 at 12:30:08 AM GMT+9
To: tcpm@ietf.org<mailto:tcpm@ietf.org> <tcpm@ietf.org<mailto:tcpm@ietf.org>>
Cc: multipathtcp <multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>>
Subject: Re: [multipathtcp] [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ?

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 <touch@strayalpha.com<mailto:touch@strayalpha.com>>:
>
>
>
> 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
> multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>
> https://www.ietf.org/mailman/listinfo/multipathtcp

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

이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 포함된 정보의 전부 또는 일부를 무단으로 제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.