Re:“Multipath” TCP Could Turbocharge Bandwidth
by windexh8er on Tuesday October 01, 2013 @10:50AM
(#6476540)
I wasn't advocating SCTP - I was simply using it as an example. Anyone can use it, just like any other protocol. Most operating systems support it today, but again, not advocating it as the "replacement", just using it as an example.
There are no bandwidth or reliability advantages of using multiple path IF you have constraints of network devices upstream. Why? Generally because upstream you're going to be traversing the same endpoint path as you converge. You may have disparate paths for a number of hops but generally your Internet connections on, say, mobile and cable will be geographically tied to the same region (let's say Chicago). There is no guarantee here for reliability (especially if both hosts are NOT multi-homed) - and if there is a problem the closer it is to the destination will exponentially increase the chance that the path for both ends up broken. Beyond that MPTCP doesn't "look" like regular TCP connections - they are regular TCP connections. The only magic is on the source. Where MPTCP solves problems is 1) in wireless handoff situations where the end user doesn't want to drop a session 2) avoiding setting things up like link aggregation in a DC environment (although this means multiple L3 paths must exist which is also additional infrastructure in most cases).
PMTUD was an analogy. It is something that's implemented everywhere and doesn't work. If organizations don't want MPTCP to work - they can very easily stop it through network controls. By default most session aware devices (firewalls, load balancers, etc) can break MPTCP by default since if they don't have the entire session they often will not allow the traffic.
The bases tenant of MPTCP breaks security models by splitting same session traffic over multiple TCP sessions. If part of a conversation goes through firewall A and the other goes through firewall B you lose context. If your firewall is L7 aware you will likely break the application tracking component. I am fully aware that each subflow is it's own session (in terms of setup/teardown) - however new security technologies will need to do extensive corroboration to fully understand flows across disparate parts of the network, and yes there is fallback for when things break.
I don't think MPTCP assumes anything. My point there was that if all the stars do not align you went through extra overhead to do nothing. Back to PMTUD - it's great when it works, but 99% of the time it doesn't.
Finally I realize that Apple has not created this. I've tested MPTCP in operational environments back in 2010 (and have been following it since 2009). The point is, I've seen it in operation and it's very niche focused on where it will showcase significant advantages. It is excellent work, I don't discount that. The reality is, however, that it's not what everyone is making it out to be. I've used it, I've implemented it, I've tested and researched it. Just because Apple is testing it - doesn't mean anything.
Ultimately I feel that closed minded statements around BGP and OSPF are half the misunderstanding of the fundamental problems. LISP is far more prevalent than you likely realize and nobody is boiling the ocean on that front and finally - IPv6 has far more than single-digit penetration. I'm pretty sure you pulled that one out of thin air. Over 40% of my home Internet traffic is IPv6 - just FYI.
There are no bandwidth or reliability advantages of using multiple path IF you have constraints of network devices upstream. Why? Generally because upstream you're going to be traversing the same endpoint path as you converge. You may have disparate paths for a number of hops but generally your Internet connections on, say, mobile and cable will be geographically tied to the same region (let's say Chicago). There is no guarantee here for reliability (especially if both hosts are NOT multi-homed) - and if there is a problem the closer it is to the destination will exponentially increase the chance that the path for both ends up broken. Beyond that MPTCP doesn't "look" like regular TCP connections - they are regular TCP connections. The only magic is on the source. Where MPTCP solves problems is 1) in wireless handoff situations where the end user doesn't want to drop a session 2) avoiding setting things up like link aggregation in a DC environment (although this means multiple L3 paths must exist which is also additional infrastructure in most cases).
PMTUD was an analogy. It is something that's implemented everywhere and doesn't work. If organizations don't want MPTCP to work - they can very easily stop it through network controls. By default most session aware devices (firewalls, load balancers, etc) can break MPTCP by default since if they don't have the entire session they often will not allow the traffic.
The bases tenant of MPTCP breaks security models by splitting same session traffic over multiple TCP sessions. If part of a conversation goes through firewall A and the other goes through firewall B you lose context. If your firewall is L7 aware you will likely break the application tracking component. I am fully aware that each subflow is it's own session (in terms of setup/teardown) - however new security technologies will need to do extensive corroboration to fully understand flows across disparate parts of the network, and yes there is fallback for when things break.
I don't think MPTCP assumes anything. My point there was that if all the stars do not align you went through extra overhead to do nothing. Back to PMTUD - it's great when it works, but 99% of the time it doesn't.
Finally I realize that Apple has not created this. I've tested MPTCP in operational environments back in 2010 (and have been following it since 2009). The point is, I've seen it in operation and it's very niche focused on where it will showcase significant advantages. It is excellent work, I don't discount that. The reality is, however, that it's not what everyone is making it out to be. I've used it, I've implemented it, I've tested and researched it. Just because Apple is testing it - doesn't mean anything.
Ultimately I feel that closed minded statements around BGP and OSPF are half the misunderstanding of the fundamental problems. LISP is far more prevalent than you likely realize and nobody is boiling the ocean on that front and finally - IPv6 has far more than single-digit penetration. I'm pretty sure you pulled that one out of thin air. Over 40% of my home Internet traffic is IPv6 - just FYI.