On Mon, Apr 30, 2018 at 6:59 PM, Robert Raszuk <[email protected]> wrote: >> - however as there are significant number of hosts which do not use >> mulipath transport and they are not completely disappearing in any >> foreseeable future, the solution >> needs to take those hosts into account and therefore this document >> discusses how to make multihoming work for the least common >> denominator. Multupath transport (if/when hosts in the network start >> using it) would complement the solution described in the Section4. > > > Why are you keep ignoring option to use MP-TCP proxy as described in number > of IETF work and few commercial products ? With use of proxies hosts on one > end or both ends of TCP connection do not need to be upgraded.
MP-TCP proxy does not look like a solution for the following reasons: 1) MP-TCP proxy is not a silver bullet. What about UDP? More specifically, what about UDP which is not QUIC? What about other protocols? 2) Explicit signalling provided by the network is always better than pure heuristic approach (if the network does not provide any information about what addresses are available then yes, transport has no options but use heuristic). It's a) faster b) saves the network resources c) easier to troubleshoot. 3) as an operator I'd rather avoid having a middle box in the network (for scalability among other reasons). Thanks, no. We might as well just recommend NAT ;) > Smart router (CE) vendors can build it into their OSes too waiting for hosts > vendors to catch up. > > Example: > > https://www.ietf.org/proceedings/85/slides/slides-85-mptcp-0.pdf Thanks for the link. I need to spend more time reading this as I'm not sure I fully understand how it's supposed to work in the scenario, when the network has multiple CPEs, each one connected to different ISPs. -- SY, Jen Linkova aka Furry _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
