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 issues seems like significant rationalization. Joe On 9/18/2017 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 easy way to deploy MPTCP technology rather > than updating clients or servers. > -- > Yoshi > > On Mon, Sep 18, 2017 at 11:51 AM, Tom Herbert <[email protected] > <mailto:[email protected]>> wrote: > > > Olivier, > > The benefits of using MPTCP are understood. The question is cost of > this solution. As you mention above MPTCP requires client and server > cooperation, but this solution requires cooperation between clients > and middleboxes, and middlebox and server. The number of cooperating > parties is not be reduced, and effectively turns TCP connection > negotiation into a three-way negotiation. The server/middlebox > interaction may be mostly transparent, but not the former. The clients > and middlebox support requires new protocol which means new software > needs to be deployed on clients and middleboxes. This takes time and > engineering effort. And there are a lot more network carriers than > there are significant content providers or client vendor, so that is > more parties to deal with in deployment. Given this, please provide > the details on why this path is going to be faster than working > directly with the content providers to start support MPTCP. WIth the > right motivation and effort, I believe that most major content > providers could have good support for MPTCP within 3 years. What is > your time and effort estimate for deploying this solution across all > clients and bringing up the converter in a significant number of > networks? > > Tom > > >> Also, the > >> cost analysis should take into account any negative effects on > nodes > >> outside of the devices being touched-- this solution is not > >> transparent to the outside world (similar to how NAT isn't really > >> transparent to end hosts). > > > > > > The negative effect is that the smartphone needs to include > MPTCP and the > > SOCKS client. The SOCKS server is a single-point of failure > inside the ISP > > network. It is not totally transparent since the smartphone > needs to be > > configured with a SOCKS server, but there are clear benefits > since this kind > > of solution is deployed by several ISPs in several countries. > > > > > > Olivier > > > > > _______________________________________________ > tcpm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpm
