Re: [multipathtcp] Progressing the MPTCP proxy work

2017-09-19 Thread Olivier Bonaventure
Tom, Only a few companies can control both client and server sides. However, ISPs might be able to control the STB at the client side and the middleboxes in their networks. This may be a relatively easy way to deploy MPTCP technology rather than updating clients or servers. Yoshi, I think

Re: [multipathtcp] Progressing the MPTCP proxy work

2017-09-18 Thread Yoshifumi Nishida
Hi Tom, On Mon, Sep 18, 2017 at 1:43 PM, Tom Herbert wrote: > On Mon, Sep 18, 2017 at 1:06 PM, Yoshifumi Nishida > wrote: > > Hi Tom, > > > > Only a few companies can control both client and server sides. > > However, ISPs might be able to control

Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work

2017-09-18 Thread Joe Touch
If you have a TCP solution that endpoints don't want but ISPs do, you do not have a good solution. Again, this seems like an interim fix that only complicates the landscape for everyone - it impedes deployment of security and could complicate every other option. Every attempt to address these

Re: [multipathtcp] Progressing the MPTCP proxy work

2017-09-18 Thread Tom Herbert
On Mon, Sep 18, 2017 at 1:06 PM, Yoshifumi Nishida wrote: > Hi Tom, > > Only a few companies can control both client and server sides. > However, ISPs might be able to control the STB at the client side and the > middleboxes in their networks. > This may be a relatively

Re: [multipathtcp] Progressing the MPTCP proxy work

2017-09-18 Thread Yoshifumi Nishida
Hi Tom, Only a few companies can control both client and server sides. However, ISPs might be able to control the STB at the client side and the middleboxes in their networks. This may be a relatively easy way to deploy MPTCP technology rather than updating clients or servers. -- Yoshi On Mon,

Re: [multipathtcp] Progressing the MPTCP proxy work

2017-09-18 Thread Tom Herbert
> From the viewpoint of the enduser, there is a benefit in using MPTCP on her > smartphone because she can combine LTE and WiFi to achieve higher bandwidth > or have seamless handovers. From the viewpoint of the network operator, this > is an added value service that they provide to their

Re: [multipathtcp] Progressing the MPTCP proxy work

2017-09-18 Thread Olivier Bonaventure
Tom, I disagree, discussions about deployment and implementation are in scope. The primary argument for necessity that this draft makes is that MPTCP is being deployed too slowly. The main argument of the draft is that deployment on client and servers does not go at the same pace. This is

Re: [multipathtcp] Progressing the MPTCP proxy work

2017-09-18 Thread Tom Herbert
On Mon, Sep 18, 2017 at 2:18 AM, Olivier Bonaventure wrote: > Tom, >> >> >> I disagree, discussions about deployment and implementation are in >> scope. The primary argument for necessity that this draft makes is >> that MPTCP is being deployed too slowly. > > >

Re: [multipathtcp] Progressing the MPTCP proxy work

2017-09-18 Thread Olivier Bonaventure
Tom, I disagree, discussions about deployment and implementation are in scope. The primary argument for necessity that this draft makes is that MPTCP is being deployed too slowly. The main argument of the draft is that deployment on client and servers does not go at the same pace. This is

Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work

2017-09-17 Thread Joe Touch
On 9/17/2017 7:05 PM, Tom Herbert wrote: >> I agree, there is engineering effort to bring MPTCP in the mainline Linux >> kernel, but this is outside the scope of IETF. >> > Oliver, > > I disagree, discussions about deployment and implementation are in > scope. The primary argument for necessity

Re: [multipathtcp] Progressing the MPTCP proxy work

2017-09-17 Thread Tom Herbert
On Sun, Sep 17, 2017 at 1:24 PM, Olivier Bonaventure wrote: > Tom, > > Thanks for your comments. > >> For #1 the assumption, the key assertion in the draft is "There are >> some situations where the transport stack used on clients (resp. >> servers) can be