Crowdsourced Network Planning For Connection-Bridging Startup

An anonymous reader writes "Tom's Hardware reports on the Connectify Switchboard software that "divides the user's traffic between Wi-Fi, 3G/4G and Ethernet-based connections on a packet-by-packet basis. Even a single stream — such as a Netflix movie — can be split between two or three Internet connections for a higher resolution and faster buffering." As part of its Kickstarter campaign, Connectify is geolocating their backers to optimize deployment of their servers. This is a clever way for supporters to influence the project beyond pledge levels and stretch goals, and it's actually kind of fun to watch."

Oh boy, sign me up!!!

[fuzzyfuzzyfungus]

I, for one, am 100% gung-ho about having a 3rd-party in the 'cloud' handling every single one of my packets so that they can balance them between my connections!

The proprietary client adding complexity to my machine's network stack is a bonus, of course.

Re:

[rHBa]

Sounds like the cloud version or RAID 0, great if you just need performance and don't expect any reliability...

Re:

[Architect_sasyr]

My first thought was the clouds version of the y2k defined SCTP protocol

Re:

[dgatwood]

I, for one, am 100% gung-ho about having a 3rd-party in the 'cloud' handling every single one of my packets so that they can balance them between my connections!

There are already lots of third parties handling each of your packets. I'm not sure why one extra router would be a cause for concern.

Re:

[agizis]

"It's worse than you know." "It usually is."

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,

Re:

[agizis]

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 [wikipedia.org]

Alex from Connectify

[agizis]

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.

Re:

[al.caughey]

I've see you read... why do you move your lips?

Re:

[Cwix]

How do you plan to handle the privacy implications?

Re:

[agizis]

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.

Re:Alex from Connectify

[agizis]

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.

Re:

[Mitreya]

keep as little information as possible, but we a) are focused on speed, not security and b) must comply with court orders.

Can you please elaborate on that?
I understand the focused on speed part, but what is this about court orders? Is there a preemptive order requiring you to limit privacy?

Re:

[agizis]

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 [slashdot.org]

Re:

[msauve]

You may wish to correct the impression given by the summary (packet by packet basis). While decisions may be made by examining individual packets, it's really balancing sockets, which is what makes it possible.

(and you might want to provide a more terse, less marketecture oriented explanation on your website)

Never mind.

[msauve]

I went the the Connectify site, and based my comments on Dispatch. My bad.

Re:

[agizis]

No problem, thanks for the question anyway.

Re:

[agizis]

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 firew

Re:

[msauve]

Yea, I realized I was looking at the wrong product.

Will you make any decisions based on the source networks? e.g. even with a single local Inet link to a single ISP, there might be benefit to then splitting out to multiple Connectify servers located in different BGP peers, routing around peering chokepoints and creating transits which might otherwise not be available.

How about a home appliance, sitting in front of the router to the ISP (or on a Linux router)?

I was disappointed to see that Linux support s

Re:

[Architect_sasyr]

Are you using SCTP or have you rolled your own standard?

Re:

[agizis]

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

Re:

[JLennox]

It would be cool if I could run switchboard on a pi and reserve it to all my devices.

But I guess that's not a question :)

Re:

[agizis]

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 traf

Re:

[agizis]

If we get a packet but haven't yet delivered the previous one in the sequence, we hold onto it until we either get the missing packet, so we can deliver what we have in order, or until we've seen a packet come in on all interfaces, and can declare the missing packet as lost, and then deliver everything we have.

Re:

[gratuitous_arp]

Thanks for taking questions. Take business travelers who have a laptop with builtin 802.11, and a 4G card for when they are not around an open access point. With switchboard, they would be able to use the 4G network even when they are connected to the 802.11 and observe increased speeds. That sounds like something a lot of people would use.

Do you consider this to be your target market, or something else?

Re:

[agizis]

Absolutely, that was the main scenario we were thinking about as we designed this. It does a nice job of putting links together so you really can a skype video call from the hotel. Since then we've been amazed to find out how many other scenarios there are: people with 2 DSL lines to the houses, business disaster recovery scenarios, people needing to get video streams into or out of areas where they can only get 3G service... the list keeps growing. But yes, the business traveler was who was in our mind

Re:

[OhSoLaMeow]

VOIP is a good example of this - RTP packet routing can take various paths. It's up the the receiver and it's jitter buffer to coalesce the packets back into order.

buzzword

[Ryanrule]

buzzword

This is new?

[MrDoh!]

Isn't this A) what you could do with a bit of messing about on old trumpet winsock installs, and B) what routers like the Cradlepoint stuff do already? The cradlepoint is more designed to auto roll over to a 3G connection if the main route drops, but can easily be configured to just add to the bandwidth. Not sure how this is different/new?

Re:

[gl4ss]

Isn't this A) what you could do with a bit of messing about on old trumpet winsock installs, and B) what routers like the Cradlepoint stuff do already?

The cradlepoint is more designed to auto roll over to a 3G connection if the main route drops, but can easily be configured to just add to the bandwidth. Not sure how this is different/new?

I guess the new aspect would be being affordable.. there has been demos of stuff like using ten 3g connections to transfer data pretty fast.

Re:

[agizis]

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, yo

Re:

[agizis]

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 [ncp-e.com]

MPTCP

[fufufang]

MPTCP is way better than what Connectify is proposing... It is an open standard too...
http://mptcp.info.ucl.ac.be/ [ucl.ac.be]
http://datatracker.ietf.org/wg/mptcp/charter/ [ietf.org]

Re:

[agizis]

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/ [ncp-e.com]
That's why Switchboard uses UD

Right problem, wrong solution

[FuzzNugget]

Yes, many of us have shitty internet connections from a small selection of shitty providers. I know, let's saturate our already oversold connectivity to give said shitty providers another excuse to crank up rates with the bonus of hitting your usage caps even sooner!

From what I can tell, this "Switchboard" is basically trying to consolidate and minimize connection overhead, which should theoretically offer modest performance gains. But your bandwidth is your bandwidth, no amount of software is going to stretch it.

I wonder how much Kickstarter capital would need to be raised to start an ISP that doesn't employ the business model off shitting on its customers.

Out-of-order packets?

[bakuun]

Using the Netflix example, wouldn't some packets going over 3G and others going over wired broadband cause massive problems with packets arriving out of order? There are methods for handling that in TCP of course, but I wonder how effective they would be in as exterme circumstances as we'd be talking about here.

Re:

[agizis]

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.

Re:

[agizis]

Oh, I see what you're thinking. No, we don't make a mess of anything.

Look at our typical scenario: two ISPs, let's say 7Mbps DSL and 10Mbps cable and latencies that differ by, let's say, 20ms, with careful reordering you can see single-socket performance of about .95*(10+7) with average packet latency somewhere between the two. Without some careful reordering, TCP is very good at slowing way, way down, and a lot of UDP media streamers just fall apart completely.

If you're us, and you get a packet but y

Load balancing was in Linux 20 years ago.

[Kaz Kylheku]

Yawn!

Re:

[agizis]

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.

Multipath TCP

[funkboy]

Sorry to rain on your parade, but multipath TCP [multipath-tcp.org] already does this...

Re:

[agizis]

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 [ncp-e.com]