 |
 | |
 MooJohn
join:2005-12-18
Milledgeville, GA
 ·Windstream
1 recommendation | Welcome to 2002 So they're going to do what multi-WAN routers have done for 10+ years, except proxy the traffic through their "cloud" for some reason? It may be able to deliver a single stream at the combined max bandwidth vs the older ones that limit traffic to a single interface but that sounds like a lot more complexity for little to no real benefit.
--
John M - Cranky network guy | |
|
| | | Re: Welcome to 2002 Agreed, it make no sense. Your ping times will be much higher since they have to go through their proxy. And if their service is ever shut down your expensive router no longer works. | |
|
| | iansltx
join:2007-02-19
Austin, TX
kudos:2 | Re: Welcome to 2002 Not "much" unless they choose their data centers poorly.
Heck, you might *decrease* ping times if they choose "cloud" providers correctly, close to their members. | |
|
| | | | | Re: Welcome to 2002 Not when they "put the packets back in the right order and send them on their way". Your max ping and jitter can be be no better than the router's worst internet connection. | |
|
| Reviews:
 ·Verizon FiOS
 ·voip.ms
| I could see this use case in emerg situations, but w/ caps on cellular why would one even consider that right now.
What would be more interesting would be wifi aggregation or cell/wifi (like freedom pop), esp w/ whitespace, because once MSO continue putting unreasonable caps on internet, people are going to get smart and start pooling their accounts.
Imagine whitespace vendors popping up undercutting MSO's, or simple neighbors sharing...
In fact this would be useful in cell phones to offload cellular data.
Why would someone promote the MOST expensive option for data is beyond me.
Now if caps keep going down it may make sense to order two links, but that doesn't need proxy servers, any low-cost server can do that... | |
|
| | Reviews:
·AT&T U-Verse
·MegaPath
| Re: Welcome to 2002 You used to be able to share your DSL connection with your neighbors under Speakeasy. But that has been long ago. It was killed before MP took over but no real numbers where shown. I don't see it happening again with caps and the TOS' stopping you from sharing that connection. | |
|
|
1 recommendation | I think the whole point of the proxy is to actually bond the connections together. A normal multiwan separates by threads and picks the one that's up and has capacity. What these guys are trying to do is actually combine the bandwidth for a single thread over multiple links. BIG difference.
I would hope their solution is able to weight the connections based on things like Caps, speeds up and down, and other details like ping times etc. | |
|
|  batterupI Can Not Tell A Lie.Premium
join:2003-02-06
Netcong, NJ | said by MooJohn:So they're going to do what multi-WAN routers have done for 10+ years, except proxy the traffic through their "cloud" for some reason?
If someone didn't combine all the loops into one it would be like when I use a 4G modem with DSL on the same computer. I get the bandwidth of both but can only use one to download a single file; I can't split a SINGLE download between the two. | |
|
| | MooJohn
join:2005-12-18
Milledgeville, GA | Re: Welcome to 2002 The sentence after what you quoted stated that, perhaps just not as succinctly.
--
John M - Cranky network guy | |
|
| | You can do that now for free..
PFsense, put in as many NICS you want all the connections you want. You get more features for free (snort, squid3, strikeback, etc). Using round robin you can have TCP connections go through each nic balancing out..or if you have 1 connection slower you can weight the connections so more go through your faster connection, less through your slower.
My Pfsense box was found at the dump 3 years ago. IDE 80GB Hd, 1Gb ram, 4 nics. 1 lan, 1 'test nic has 3 vlans off of it, 2 wan connections balanced.. | |
|
|
1 recommendation | Re: You can do that now I use PFsense for multi wan 2, and it's great. But it doesn't aggrigate the 2 connections into 1 which is what I think these guys are trying to accomplish. For example, if you have 2, 10mbit connections behind pfsense, the most you can see on a single threaded download is 10mbit. The point of their proxy is to have those 2 connections go to their proxy, their proxy would have full capacity for a single thread at their server, then split it to your router over the 2 connections into your home. | |
|
 whfsdudePremium
join:2003-04-05
Washington, DC
 ·Comcast
| Multihoming - Service Provider (MSP) Multihoming service providers are likely going to become a thing for multihoming in a v6 environment.
It's being worked on as a part of the set of homenet standards.
»tools.ietf.org/html/draft-haddad···ection-4 | |
|
|
|  MxxCon
join:1999-11-19
Brooklyn, NY | Re: Not going to be any faster HTML standard has absolutely nothing to do with number of simultaneous connections one establishes with a server.
--
[Sig removed by Administrator: signature can not exceed 20GB] | |
|
| |  skeechanAi OtsukaholicPremium
join:2012-01-26
AA169|170
kudos:2 | Re: Not going to be any faster Derp, I meant HTTP.
--
Nocchi rules. | |
|
1 recommendation | Quit comparing to multi-WAN routers This is completely different. Multi-WAN routers only assign a flow to a particular connection, so the throughput you get on that connection is limited to the throughput of whatever connection it was assigned to.
This, on the other hand, is able to provide the aggregate throughput of all connections, by fragmenting packets, sending them through all connections to their proxy service (ignore the "cloud" bullshit marketing), and reassembling them there.
It's nothing new either, this has been done for awhile (Google "VPN bonding" and there have been some other startups doing it too). | |
|
|  ilikemeI live in a van down by the river.Premium
join:2002-08-27
Denton, TX
kudos:1 | Re: Quit comparing to multi-WAN routers Sounds like someone works for the company that makes this. | |
|
| | |
| | | | said by ilikeme:Sounds like someone works for the company that makes this.
For the record, I do not. | |
|
| | rradina
join:2000-08-08
Chesterfield, MO
1 recommendation | No -- it sounds like someone who understands how it will work instead of speculating that it's the same as a multi-WAN router. | |
|
| | | Reviews:
·Verizon FiOS
| Re: Quit comparing to multi-WAN routers Exactly, while I admit for someone with access to a 50/25 FiOS connection I see no need for this, this is more for those with only a few slow links available to make single transfers and high speed streaming possible.
Imagine the guy that only has access to 3mbps dsl trying to stream netflix, it's going to suck, but team up a couple dsl lines and maybe a 3G connection and you can do it.
Only issue I see here is their should be some cap control added, so that you can monitor how much data you allow over each connection. | |
|
| | | | | | Re: Quit comparing to multi-WAN routers exactly!
I would suggest balancing be weighted on speeds up and down, Caps, and latencies. That algorithm might be difficult, but that would be their selling point. PFsense can do weighting based on connection speeds, but there's no cut off when you hit a cap.
Imagine having a DSL with unlimited and a cable connection that's capped. If the device was smart enough it would send all the low priority / low size stuff through the unlimited connection, saving the faster cable connection for larger downloads that you want in a hurry. As the cap on the cable connection is reached, it minimized data through that connection until it cuts it off just before the cap.
That being said, there would have to be other factors, like when the caps start and stop in a given month. | |
|
| | | | rradina
join:2000-08-08
Chesterfield, MO | What's really interesting is that the central aggregation service can make a profit for $5/month. Out of that paltry sum, they have to pay for servers, routers, admins, developers, billing and in + out bandwidth. I would guess their bandwidth needs will be huge. Unlike a typical high-volume site (i.e. YouTube), the aggregate service is in the middle. Every inbound byte will send an outbound byte. That's a pretty strong indicator of how cheap data really is. | |
|
| | batterupI Can Not Tell A Lie.Premium
join:2003-02-06
Netcong, NJ | said by ilikeme:Sounds like someone works for the company that makes this.
He may not be the only one who has a connection to a provider posting on this forum. The doers are an asset, the hangers on, like MCI was, are the danger as they promise everything and deliver nothing.
The problem as I see it combining four 3 meg DSLs will get one a 12/3.2 loop for about $340 a month. I would never put a 4G in the mix because of cost; that loop would most likely get most of the traffic too as it would be by far the fastest. | |
|
|  MellowPremium
join:2001-11-16
Salisbury, MD | Exactly.
But now you have 1 central point of failure added to the mix. | |
|
| | | | Re: Quit comparing to multi-WAN routers said by Mellow:But now you have 1 central point of failure added to the mix. Not only that, but their use of MPTCP isn't ideal. It's not going to handle packet loss very well. They are imposing ordering and reliability on the entire aggregated stream which will only add overhead, on top of the overhead from using TCP for this in the first place. (Remember, at L3 there are no guarantees about packet ordering or reliability; higher layers are expected to handle that.) | |
|
| | | | | Re: Quit comparing to multi-WAN routers Ok, to be clear, I do work for Multipath 
Dropped packets do a fast retransmit on the link with the lowest latency. In general, the system will favour the link with the lowest latency, and back off when it see's packet loss on any particular link.
This is exactly the same as regular TCP.
The overhead of doing MPTCP is between 5 and 15%. So, if you have 2 x 10Mb links, you will get an aggregated speed of between 17 and 19Mb/s.
These numbers are field test results, not lab tests and are true when bonding any combination of DSL, Cable, Wireless, 3G or 4G.
Thanks!
Justin | |
|
| | | | | | Re: Quit comparing to multi-WAN routers said by Justin Colle :Dropped packets do a fast retransmit on the link with the lowest latency. In general, the system will favour the link with the lowest latency, and back off when it see's packet loss on any particular link.
First, thanks for coming by and getting involved in the discussion!
MPTCP is still enforcing reliability and ordering guarantees on the entire aggregated stream. You're tunneling IP packets over that TCP stream - you don't need to enforce those guarantees, and doing so only adds overhead in a place where it may not be needed.
If there's a slight burst of packet loss, your TCP stream is now completely blocked until the packet loss is detected and those packets are retransmitted. While that's probably only going to be a matter of milliseconds, that blocking is going to negatively impact real-time applications like VoIP that don't care about momentary bursts of packet loss.
It's easy for me to say this, and I understand that MPTCP is an "easy solution" to this that will work well enough and allow you to ship the product quickly, but my advice at least for a future version of this would be to investigate another solution. Don't bother with packet reordering or reliability at all. Fragment the packet, send the fragments, the other end can buffer the fragments until it has received all of them (or disregard the fragments if they haven't all been received within a certain amount of time) and then reassemble it. Let the endpoints handle packet drops and reordering; that's the best way to do it because there isn't a "one size fits all" for every application (of course TCP and some other L4 protocols like SCTP will handle it themselves, but then other applications using UDP will implement those guarantees as appropriate for their specific use). | |
|
| | | | | | | Re: Quit comparing to multi-WAN routers said by TAZ :First, thanks for coming by and getting involved in the discussion! No problem! Delighted to answer questions
said by TAZ :You're tunneling IP packets over that TCP stream We don't use standard tunnels, what we do is closer to a transformation at the client and the server. Thats the secret sauce and what we do over and above MPTCP.
said by TAZ :If there's a slight burst of packet loss, your TCP stream is now completely blocked until the packet loss is detected and those packets are retransmitted Like standard TCP, if a single link experiences a burst of packet loss transmission on that link backs off and the packet gets retransmitted on the link with the lowest latency. This appears as a momentary increase in latency, but it would be wrong to describe it as completely blocked. We do not break the end to end nature of TCP which is important in these scenario's.
Our first system used only 3G connections where this scenario can be common, and even in lossy environments you will see efficiencies of 85%+ as very little data gets sent over the lossy link. There is no real difference here between TCP and MPTCP, they both see the lossy link the same way.
Thanks,
Justin | |
|
| | | | | |
••••••
|
| | rradina
join:2000-08-08
Chesterfield, MO | That assumes it's not smart enough to fall back to a simple but stateful round-robin load-balance scheme or just use one link when the central site is unavaialble.
(Since the availability of the central site will never be perfect (shit happens), it seems unlikely the device's engineers turn it into a brick during those times.) | |
|
|  exocet_cmI am the law - Judge DreddPremium
join:2003-03-23
New Orleans, LA
kudos:2 | Untangle can do WAN balancing but not WAN aggregation.
»wiki.untangle.com/index.php/WAN_Balancer
This product claims to do aggregation, which is what you said. But even then, how many have the money to pay for multiple ISPs? | |
|
| | | | Re: Quit comparing to multi-WAN routers said by exocet_cm:This product claims to do aggregation, which is what you said. But even then, how many have the money to pay for multiple ISPs?
IMO, businesses. All their marketing is talking about Netflix and other consumer applications, but you are correct in that it will never take off in that market. In that market, I see far more promise in service provider bonding offerings (like what CenturyLink and AT&T are doing now). | |
|
| | That Device... Looks a lot like a ALIX setup... | |
|
exocet_cmI am the law - Judge DreddPremium
join:2003-03-23
New Orleans, LA
kudos:2 | Cool... Now my grandma can bond her satellite and 56K!
My bad, it said broadband. Grandma is still stuck in the past. | |
|
swarto112Premium
join:2004-02-17
Brookfield, WI Reviews:
·Time Warner Cable
| multi wan been around along time. i was using a home multi wan router about 10 years ago. had both a cable and dsl line...cable had the download speed and del had the upload speed. (we're talking 1.5mb/725 days) i set it to load balance with priorities to the fastest speed. Was lucky enuf to work for a company that wanted me to be able to go on so they footed the bill. also, when i realized that att didnt meter or lock down internet at the time, i cut the cord and ran the whole house of off a moto razr2 hooked to a cradlepoint router. this is all not new...just to the writer. | |
|
| | | Re: multi wan been around along time. The way they are doing it is new. It's not just using one link or the other like a multi WAN router. It is using all links and aggregating the traffic at their datacenter and sending it to the destination. Then when it receives that data back, it splits it up and sends it back to you over the multiple links. | |
|
iansltx
join:2007-02-19
Austin, TX
kudos:2 Reviews:
·Time Warner Cable
·Verizon Online DSL
·Comcast
| Only one good option I'd do connection bonding if it significantly decreased my throughput. But either it doesn't (bonding with 6/768 AT&T DSL) or the resulting connection would be heavily capped (T-Mobile or Verizon LTE). Or I really shouldn't be using the connection for home broadband (Sprint LTE). And bonding two TWC connections probably wouldn't get me 2x the speed because I already see occasional congestion issues, and there are only four channels to bond here.
My time is valuable, and by extension so is a connection that will decrease the time it takes to do stuff. But not $8+ per GB on a home connection valuable. | |
|
| | | Re: Only one good option Why do you want to decrease your throughput? | |
|
| | iansltx
join:2007-02-19
Austin, TX
kudos:2 | Re: Only one good option Uploading large videos to YouTube and doing online backups, mostly. So, upload-intensive stuff. | |
|
 tshirtPremium,MVM
join:2004-07-11
Snohomish, WA
kudos:4 | Can you say... ...EXPENSIVE, boys and girls?
Cause Mr Rodgers is pretty sure accounts from 4 providers, will likely be more $, than a premium account at 1 or 2. | |
|
| | | Re: Can you say... I expect this to be useful for rural DSL users, as getting 2 phone lines is normally a possibility, thus nearly doubling their capacity. Of course it costs 2x as much, but it's not a big deal if that's your only choice.
Depending on how configurable it is, it could be useful to pair a LTE connection with a slow DSL or cable connection as well. Even though LTE tends to be pretty expensive per GB, if the service is configured to use the landline connection for all the baseline possible and only switch to the wireless for surge needs, you might could keep your wireless usage at reasonable levels.
I'd just want the ability to easily switch the service off, as when you're doing something like online gaming, it'd only provide a worse experience. | |
|
 tmh
@comcastbusiness.net | Assuming you can find more than one ISP servicing your area So, we have fiber and cable. Some places have only cable. Most places don't even have cable. What multihoming are they talking about? | |
|
| MxxCon
join:1999-11-19
Brooklyn, NY | Re: Assuming you can find more than one ISP servicing your area you can get 2 cable lines. you can get cable+dsl. you can get cable+fixed wireless.
there are many different connections you can setup.
--
[Sig removed by Administrator: signature can not exceed 20GB] | |
|
| | Check your Terms of Service My guess is AT&T, Verizon, TimeWarner and the rest have considered this possibility... | |
|
|
|
·
·