4 ms·

So, how long has SCTP been around? And how many consumers are actually able to use it? The problem is, IP and TCP and NAT and firewalls and BGP and OSPF are al

by lambda 13y ago

So, how long has SCTP been around? And how many consumers are actually able to use it? The problem is, IP and TCP and NAT and firewalls and BGP and OSPF are all fairly fundamental facts of the network we operate on. There's no way to unilaterally move to something else without, well, breaking the internet. IPv6 has been around for 17 years, and we're running out of IPv4 addresses at an alarming rate, yet IPv6 still has single-digit (or less) penetration. The advantage of MPTCP is that it operates over what look to any observer as regular TCP connections. This means it's compatible with all of the NAT and firewall technologies that know how to deal with TCP, while still giving you the bandwidth and reliability advantages of utilizing multiple paths. I'm not really sure how your example about PMTUD is supposed to support your case. That's an example of a technology that doesn't work within the constraints of the network as it's actually built, in which ICMP is not something that can be relied upon. The whole point of the MPTCP hack is to make it compatible with the existing network, and fall back gracefully to a single path TCP connection if that doesn't work, rather than something like SCTP which simply doesn't work at all if you're behind a NAT that doesn't know what SCTP is. What session state that is "fundamental to security controls" does MPTCP lose? There's nothing that I can think of that you could do with MPTCP that you couldn't do with just two or more single path TCP connections. I'm also not sure why you think that QoS would be particularly impacted by multiple paths; you can always just use a single path and leave the second path only as a fallback, and then the QoS story should be exactly the same as you had originally, just with higher availability. Does SCTP do something special to make QoS work better over multiple paths? And why do you think that MPTCP assumes that you know the network end-to-end? Everything I've seen about it's design seems to imply that they were very careful to design with assumptions of the most degenerate possible network conditions that are still successfully able to transmit plain old TCP. Multipath TCP isn't something that Apple just created unilaterally; it's been in development at the IETF for years with several implementations on different operating systems, and lots of experimental data to back it up. I think it's an excellent attempt at getting a working multipath solution out there, that doesn't require boiling the oceans like SCTP or IPv6 do.

windexh8er 13y ago
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.

by lambda 13y ago

windexh8er 13y ago

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.