Yes, and this isn't load balancing. Load balancing puts each socket on one internet connection where it stays for "life". We divide the traffic between the multiple connections at a packet by packet basis. Which means that unlike load balanced solutions, we can even speed up single sockets like streaming video, uploads and VPNs.
MPTCP is really interesting, but if you want to combine connections to speed up a connection to a server that just supports regular TCP (Netflix, or Box, Dropbox, etc), even having MPTCP to somewhere else in the cloud, like a VPN server or connection aggregation server, doesn't get you very much. Running TCP over TCP in the real world is generally a bad idea, for reasons laid out pretty well here: http://vpnhaus.ncp-e.com/2011/06/30/sstp-the-problem-with-tcp-over-tcp-part-2/(cutting
Of course there are buffers everywhere. We have buffers. Bufferbloat != "having some buffers". Bufferbloat is "when excess buffering of packets inside the network causes high latency and jitter, as well as reducing the overall network throughput", As always Wikipedia is good place to start http://en.wikipedia.org/wiki/Bufferbloat
The latency situation is much more complicated than you describe. You said that we were adding latency to the highest-latency connection. But that's not right, for software that routes every packet optimally: we're looking at a latency of (high-latency connection - ((highest latency connection - lowest latency connection) / 2)).
But it's more complicated than that too, because Internet connections' latencies are not constants.
We don't add to buffer bloat, we go war against it. Buffer bloat is the enemy of Switchboard. Switchboard wants to know where every packet is, and devices that claim to transmit but instead stick them in a buffer are problems. Switchboard is smart enough to sniff this behavior out, and give less packets to such devices, which hopefully leads to smaller queues, and better behavior, and lower latencies. Which is why in many cases Switchboard helps with latency... a typical 4G card will have 25 ms latency when you ping on it, but when you start a file transfer it will soar north of 800 ms. Switchboard will see this change and start routing you around that backlog in real time.
You hit the nail on the head. Dealing with latency differences has probably been the hardest part of all this. We identify packets that are more latency sensitive, and route them over the lowest latency link.... doing this properly effectively divides the difference in latency between the links in half. We also take the QoS headers from the VoIP traffic and use them on our packets when sending them across the net. If your networks do something special for VoIP traffic, they will do the same for our traffic, when we're actually carrying VoIP.
Yes, out of order packets were a real problem, caused by the difference in latency between paths. We get them back in a semblance of order coming out of our network connection.
We rolled our own so we could overcome SCTP's problems with NAT traversal (which only seem partially fixed by trying to tunnel SCTP over UDP) and so we could do things like track the flight time of every packet
Ah, thanks for the question. (sorry I gave this answer to someone else too)
MPTCP is really interesting, but if you want to combine connections to speed up a connection to a server that just supports regular TCP (Netflix, or Box, Dropbox, etc), even having MPTCP to somewhere else in the cloud, like a VPN server or connection aggregation server, doesn't get you very much. Running TCP over TCP in the real world is generally a bad idea, for reasons laid out pretty well here: http://vpnhaus.ncp-e.com/2011/06/30/sstp-the-problem-with-tcp-over-tcp-part-2/
That's why Switchboard uses UDP as much as it can, and defaults to TCP when it absolutely has to, similar to what OpenVPN does.
MPTCP is really interesting, but if you want to combine connections to speed up a connection to a server that just supports regular TCP (Netflix, or Box, Dropbox, etc), even having MPTCP to somewhere else in the cloud, like a VPN server or connection aggregation server, doesn't get you very much. Running TCP over TCP in the real world is generally a bad idea, for reasons laid out pretty well here: http://vpnhaus.ncp-e.com/2011/06/30/sstp-the-problem-with-tcp-over-tcp-part-2/
That's why Switchboard uses UDP as much as it can, and defaults to TCP when it absolutely has to, similar to what OpenVPN does.
Sorry? No, it's right: we go packet-by-packet in our spreading. That's exactly what's so special here. On every Internet connection on your system we make one or more different sockets back to the speed server. Then we can make the right decision for each packet on which of OUR sockets it should become a part of. There's a lot more smarts that have to go into quickly, and correctly figuring out which Internet connection should carry the data: bandwidth, latency, packet loss, and behavior of the firewalls in the path are all taken into consideration.
Thanks for asking,
No, we do not guarantee privacy. We do our best to ensure your privacy, and keep as little information as possible, but we a) are focused on speed, not security and b) must comply with court orders. We work with VPNs, if you have a VPN you trust. dial them after firing up the Switchboard. They encrypt your traffic, then we spread it across connections, on the server side, we put it back together, and then hand it to the VPN server. It all works nicely, you can have speed and security.
We are going to keep the minimum logs required by law. But we are going to comply with the law, just as any company must.
So, for those worried about the privacy implications, there are several options: a) run your own server, we have options to buy the software for your server, or b) use a VPN (dial the VPN after connecting Switchboard... all your traffic will be encrypted by them, then spread out by us, you can get the best of both). Of course you need to have VPN provider whom you trust.
No, both are load balancing. In load balancing each socket is assigned to an internet connection where it stays for its lifetime. Works well with stuff like bittorrent, or networks with lots of users going through the load balancer. This is true channel bonding: each packet is separately routed down the best Internet connection. Even a single video stream or an encrypted VPN can be spread across all the connections. Ok, so then the next question is "can't I do that ifenslave in Linux already". No, you can't, because it round robins, treating every connection exactly the same. Switchboard uses bandwidth, latency, and packet loss to calculate an ideal path for each packet, often getting efficiencies as high as 95% of the speed of the connections added up.
It's so weird to be reading the news on Slashdot, and then realize that it's about you. This is Alex from Connectify, and I'm here, so I guess go ahead and ask me anything as reply to this comment, and I'll answer away.
Well, yes that's why Kickstarter works the way it does. It's not some crazy pure democracy thing, where each person gets to declare how their $50 is to be spent.
What happens, is the team posts its vision, along with a detailed list of what you get at each backing level. Potential backers can basically take it, leave it, or say what they really want. If enough people want something different, the team can add things to the project (but never remove them, because of course, someone else may have already backed for a particular feature). If not enough people back to get the minimum level, the project is cancelled, and the backers are not charged anything.
I'm really surprised at the hostility here to it... the best alternative we have to this is the facebook/twitter model: VC's fund it, it's free to use, and they don't give a damn what you think, ignore your feedback, and sell all of your information. This seems like a refreshing change of pace.
You have it all backwards. The Kickstarter model gives an opportunity to get products built that *customers* want, and are willing to pay for, without having venture capitalist in the middle, funding everything and demanding their return. The backers' relationship to the project is that they are *paying customer*, which is less than being the owner of the company, but much, much more than just being a *user* of a free service like Twitter or Facebook.
Congress has been selling off the frequencies that were reserved for first responders and Federal users to the cell phone companies (see the 1800 MHz band, as an example). They don't really have these dedicated networks anymore. Most of what's left is narrowband (6.25KHz channels) that are of no use for data.
Alex Gizis of Connectify here. Sorry to pitch you here, but this is one of the reasons that we created Connectify Dispatch. By using link aggregation to divide your traffic across a couple different links you can assemble a fast download speed even in the presence of throttling. We use real-time throughput stats to decide how to divvy up the traffic. Plus the pretty graphs give you a sense of what we're doing and why (bandwidth, latency and reliability of each link, mostly). On Kickstarter now: http://www.kickstarter.com/projects/523076551/dispatch-the-internet-faster
No this is different, because Microsoft does not allow you to turn off encryption. It's always WPA2-Personal AES encryption. So you have to give people a key to connect.
MS only gives command line tools to it, so you need to get a user interface to it like Connectify, but then it's for sharing with your other devices and co-workers, no good at all for setting up free airport honeypots.
True, though 5 GHz has more channels, 802.11n uses MIMO (directional beams), and its poorer propagation will mean that it takes a lot more radios to fill it than 2.4 GHz. That said, as more and more things go wireless, with stuff like connectify and Push2TV, it may happen faster than people expect. The iPad, btw has a 5 Ghz 802.11n radio in it...
One of the beauties of both Connectify and Intel's My Wi-Fi is that your laptop is the AP. So if the source of the data is either on your computer or something it gets to via a wire, then it only needs to go over the Wi-Fi once. If you're grabbing the data from another Wi-Fi network as well, then yes, you're right it goes over the air, eating bandwidth twice. And 802.11n is a lot higher speed than 802.11g (the theoretical max for 802.11g is 54 Mbps, btw, but with overhead and stuff, the real numbers are in the range that you mentioned).
Slashdot Mirror
Yes, and this isn't load balancing. Load balancing puts each socket on one internet connection where it stays for "life". We divide the traffic between the multiple connections at a packet by packet basis. Which means that unlike load balanced solutions, we can even speed up single sockets like streaming video, uploads and VPNs.
MPTCP is really interesting, but if you want to combine connections to speed up a connection to a server that just supports regular TCP (Netflix, or Box, Dropbox, etc), even having MPTCP to somewhere else in the cloud, like a VPN server or connection aggregation server, doesn't get you very much. Running TCP over TCP in the real world is generally a bad idea, for reasons laid out pretty well here: http://vpnhaus.ncp-e.com/2011/06/30/sstp-the-problem-with-tcp-over-tcp-part-2/(cutting
Of course there are buffers everywhere. We have buffers. Bufferbloat != "having some buffers". Bufferbloat is "when excess buffering of packets inside the network causes high latency and jitter, as well as reducing the overall network throughput", As always Wikipedia is good place to start http://en.wikipedia.org/wiki/Bufferbloat
The latency situation is much more complicated than you describe. You said that we were adding latency to the highest-latency connection. But that's not right, for software that routes every packet optimally: we're looking at a latency of (high-latency connection - ((highest latency connection - lowest latency connection) / 2)).
But it's more complicated than that too, because Internet connections' latencies are not constants.
We don't add to buffer bloat, we go war against it. Buffer bloat is the enemy of Switchboard. Switchboard wants to know where every packet is, and devices that claim to transmit but instead stick them in a buffer are problems. Switchboard is smart enough to sniff this behavior out, and give less packets to such devices, which hopefully leads to smaller queues, and better behavior, and lower latencies. Which is why in many cases Switchboard helps with latency... a typical 4G card will have 25 ms latency when you ping on it, but when you start a file transfer it will soar north of 800 ms. Switchboard will see this change and start routing you around that backlog in real time.
You hit the nail on the head. Dealing with latency differences has probably been the hardest part of all this. We identify packets that are more latency sensitive, and route them over the lowest latency link.... doing this properly effectively divides the difference in latency between the links in half. We also take the QoS headers from the VoIP traffic and use them on our packets when sending them across the net. If your networks do something special for VoIP traffic, they will do the same for our traffic, when we're actually carrying VoIP.
Yes, out of order packets were a real problem, caused by the difference in latency between paths. We get them back in a semblance of order coming out of our network connection.
We rolled our own so we could overcome SCTP's problems with NAT traversal (which only seem partially fixed by trying to tunnel SCTP over UDP) and so we could do things like track the flight time of every packet
Oh, no, there's nothing like that. But you asked if I "guarantee privacy". I read slashdot daily, so I know that if Hide My Ass has to comply with UK judges and FBI warrants, then we will too: http://yro.slashdot.org/story/11/09/25/0415213/hidemyasscom-doesnt-hide-logs-from-the-fbi
No problem, thanks for the question anyway.
Ah, thanks for the question. (sorry I gave this answer to someone else too)
MPTCP is really interesting, but if you want to combine connections to speed up a connection to a server that just supports regular TCP (Netflix, or Box, Dropbox, etc), even having MPTCP to somewhere else in the cloud, like a VPN server or connection aggregation server, doesn't get you very much. Running TCP over TCP in the real world is generally a bad idea, for reasons laid out pretty well here: http://vpnhaus.ncp-e.com/2011/06/30/sstp-the-problem-with-tcp-over-tcp-part-2/
That's why Switchboard uses UDP as much as it can, and defaults to TCP when it absolutely has to, similar to what OpenVPN does.
MPTCP is really interesting, but if you want to combine connections to speed up a connection to a server that just supports regular TCP (Netflix, or Box, Dropbox, etc), even having MPTCP to somewhere else in the cloud, like a VPN server or connection aggregation server, doesn't get you very much. Running TCP over TCP in the real world is generally a bad idea, for reasons laid out pretty well here: http://vpnhaus.ncp-e.com/2011/06/30/sstp-the-problem-with-tcp-over-tcp-part-2/
That's why Switchboard uses UDP as much as it can, and defaults to TCP when it absolutely has to, similar to what OpenVPN does.
Sorry? No, it's right: we go packet-by-packet in our spreading. That's exactly what's so special here. On every Internet connection on your system we make one or more different sockets back to the speed server. Then we can make the right decision for each packet on which of OUR sockets it should become a part of. There's a lot more smarts that have to go into quickly, and correctly figuring out which Internet connection should carry the data: bandwidth, latency, packet loss, and behavior of the firewalls in the path are all taken into consideration.
Thanks for asking, No, we do not guarantee privacy. We do our best to ensure your privacy, and keep as little information as possible, but we a) are focused on speed, not security and b) must comply with court orders. We work with VPNs, if you have a VPN you trust. dial them after firing up the Switchboard. They encrypt your traffic, then we spread it across connections, on the server side, we put it back together, and then hand it to the VPN server. It all works nicely, you can have speed and security.
We are going to keep the minimum logs required by law. But we are going to comply with the law, just as any company must. So, for those worried about the privacy implications, there are several options: a) run your own server, we have options to buy the software for your server, or b) use a VPN (dial the VPN after connecting Switchboard... all your traffic will be encrypted by them, then spread out by us, you can get the best of both). Of course you need to have VPN provider whom you trust.
No, both are load balancing. In load balancing each socket is assigned to an internet connection where it stays for its lifetime. Works well with stuff like bittorrent, or networks with lots of users going through the load balancer. This is true channel bonding: each packet is separately routed down the best Internet connection. Even a single video stream or an encrypted VPN can be spread across all the connections. Ok, so then the next question is "can't I do that ifenslave in Linux already". No, you can't, because it round robins, treating every connection exactly the same. Switchboard uses bandwidth, latency, and packet loss to calculate an ideal path for each packet, often getting efficiencies as high as 95% of the speed of the connections added up.
It's so weird to be reading the news on Slashdot, and then realize that it's about you. This is Alex from Connectify, and I'm here, so I guess go ahead and ask me anything as reply to this comment, and I'll answer away.
Summary: Author wants us all to start using Waterfall Methodology because he is totally unaware of how it worked out in the 80's and 90's.
Well, yes that's why Kickstarter works the way it does. It's not some crazy pure democracy thing, where each person gets to declare how their $50 is to be spent.
What happens, is the team posts its vision, along with a detailed list of what you get at each backing level. Potential backers can basically take it, leave it, or say what they really want. If enough people want something different, the team can add things to the project (but never remove them, because of course, someone else may have already backed for a particular feature). If not enough people back to get the minimum level, the project is cancelled, and the backers are not charged anything.
I'm really surprised at the hostility here to it... the best alternative we have to this is the facebook/twitter model: VC's fund it, it's free to use, and they don't give a damn what you think, ignore your feedback, and sell all of your information. This seems like a refreshing change of pace.
You have it all backwards. The Kickstarter model gives an opportunity to get products built that *customers* want, and are willing to pay for, without having venture capitalist in the middle, funding everything and demanding their return. The backers' relationship to the project is that they are *paying customer*, which is less than being the owner of the company, but much, much more than just being a *user* of a free service like Twitter or Facebook.
Congress has been selling off the frequencies that were reserved for first responders and Federal users to the cell phone companies (see the 1800 MHz band, as an example). They don't really have these dedicated networks anymore. Most of what's left is narrowband (6.25KHz channels) that are of no use for data.
Alex Gizis of Connectify here. Sorry to pitch you here, but this is one of the reasons that we created Connectify Dispatch. By using link aggregation to divide your traffic across a couple different links you can assemble a fast download speed even in the presence of throttling. We use real-time throughput stats to decide how to divvy up the traffic. Plus the pretty graphs give you a sense of what we're doing and why (bandwidth, latency and reliability of each link, mostly). On Kickstarter now: http://www.kickstarter.com/projects/523076551/dispatch-the-internet-faster
No this is different, because Microsoft does not allow you to turn off encryption. It's always WPA2-Personal AES encryption. So you have to give people a key to connect. MS only gives command line tools to it, so you need to get a user interface to it like Connectify, but then it's for sharing with your other devices and co-workers, no good at all for setting up free airport honeypots.
True, though 5 GHz has more channels, 802.11n uses MIMO (directional beams), and its poorer propagation will mean that it takes a lot more radios to fill it than 2.4 GHz. That said, as more and more things go wireless, with stuff like connectify and Push2TV, it may happen faster than people expect. The iPad, btw has a 5 Ghz 802.11n radio in it...
One of the beauties of both Connectify and Intel's My Wi-Fi is that your laptop is the AP. So if the source of the data is either on your computer or something it gets to via a wire, then it only needs to go over the Wi-Fi once. If you're grabbing the data from another Wi-Fi network as well, then yes, you're right it goes over the air, eating bandwidth twice. And 802.11n is a lot higher speed than 802.11g (the theoretical max for 802.11g is 54 Mbps, btw, but with overhead and stuff, the real numbers are in the range that you mentioned).