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

[Gregory Detal <[e-mail]>]

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 <
[e-mail]> wrote:

> 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 <[e-mail]>:
> >
> >
> >
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/multipathtcp
>
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>



-- 
[image: Tessares SA] <http://www.tessares.net> Gregory Detalº | Co-Founder
& CTO
[e-mail] | [phone] <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.