Re:Fixing the Internet for Real Time Applications, Part II
by eloff on Sunday February 21, 2016 @05:43PM
(#11147015)
The big cloud providers also do similar kinds of things to bring down latency on their networks, but I wonder how effective they are? I've never seen latency comparisons between cloud providers - but there must be differences. None of them seem to use latency as a selling point either. I'd add latency to one of the criteria when choosing between providers if there were a way to compare them. I'm not talking about their latency to me or any arbitrary point, but their latency to internet users in the US in general. Like 50% of users within 80ms RTT. Also packet-loss rates would be nice to know.
Re:Fixing the Internet for Real Time Applications, Part II
by plq on Sunday February 21, 2016 @05:51PM
(#11147053)
Yes, I was actually suprised that all graphs were going up :) Number of users increased -- great but ping times and packet loss should be at an all-time low now and these are the graphs that we want to see!
Re:Fixing the Internet for Real Time Applications, Part II
by PeytonKoran on Sunday February 21, 2016 @10:20PM
(#11148199)
Hello,
I am the author. The difference is that Akamai is working on optimizing bandwidth to their customer from a pipes size perspective, not a latency perspective. In other words, they want the widest highway possible, maybe not the fastest.
Re:Fixing the Internet for Real Time Applications, Part II
by BillyParadise on Monday February 22, 2016 @06:43AM
(#11150139)
I'd be surprised if they haven't already considered it. Building a national backbone is a large endeavour, and now that it's built, a great way to diversify revenue. Games only stay popular for a finite period of time.
Re:Fixing the Internet for Real Time Applications, Part II
by PeytonKoran on Monday February 22, 2016 @11:55AM
(#11152227)
We had to RFP each link, meaning we reached out to every fiber/wave vendor that was present in the data centers we wanted to be in that we could find, and had them submit routes with latency data. Then we tested to verify their data. It is really manual unfortunately.
Re:Fixing the Internet for Real Time Applications, Part II
by plq on Sunday February 21, 2016 @05:49PM
(#11147044)
How is this "fixing the internet"? This is just good old network optimization. And a local one, not "internet-wide" by any means! Colossal undertaking, sure, kudos to Riot team for pulling it off. But... I don't see what makes this different.
Re:Fixing the Internet for Real Time Applications, Part II
by PeytonKoran on Sunday February 21, 2016 @10:21PM
(#11148202)
Hey,
I am the author. We are building it out world wide, but you are correct, this is for one application. The same blueprint could be used for any other application though.
Re:Fixing the Internet for Real Time Applications, Part II
by chatmasta on Sunday February 21, 2016 @10:50PM
(#11148321)
> A reduction in the number of participating routers would lower latency (yay for LoL players), but it would also lower the number of customers they could support.
This is because ISPs oversell their networks. That's great and it makes sense... as long as they can get away with it. But when services like online gaming and netflix gain popularity, the ISP business model is insufficient for delivering quality connections.
Also, nice "pipe dream" pun in the second paragraph. ;)
Re:Fixing the Internet for Real Time Applications, Part II
by madsushi on Monday February 22, 2016 @04:20AM
(#11149566)
1) Databases - if your app servers at the edge need to talk to your database back at your main datacenter, you've just made performance worse. Replicate the data to the edge? Now it's harder to keep consistent.
2) Too many edges - if you regionalize too heavily, you end up restricting your matchmaking pools to smaller groups. Matchmaking theory says that either (a) quality of matches decreases or (b) time to matchmake increases as your pool shrinks. At some point, to have a healthy matchmaking pool in a game with a wide variety of skill levels, you have to consolidate. Riot already had Euro datacenters (with separate accounts, which solves #1).
3) Performance - cloud low-latency UDP performance isn't nearly as good as you can get yourself. Plus, you have more control (and leverage) doing it in-house.
4) Perception - some level of latency becomes imperceptible, 50ms is getting pretty close to that number.
Re:Fixing the Internet for Real Time Applications, Part II
by PhaseMage on Sunday February 21, 2016 @10:13PM
(#11148180)
The TCP/IP internet is irreparably broken for real time applications. The barriers to new entrants wanting to do the same thing as Riot Games is too high.
I've proposed a scalable mesh network, see IsoGrid.org
I am the author, you got that right. And thank you for taking the time to read it.
Peyton
About to go back and read Part I so please forgive if that's covered in the first part.
Peyton
I would love to see a consumer videoconferencing service built on top of one of these networks.
I am the author. The difference is that Akamai is working on optimizing bandwidth to their customer from a pipes size perspective, not a latency perspective. In other words, they want the widest highway possible, maybe not the fastest.
Peyton
You guys should really consider making this a platform that anyone could use!
Consider writing a SIGCOMM paper about it!!
I am the author. We are building it out world wide, but you are correct, this is for one application. The same blueprint could be used for any other application though.
Peyton
This is because ISPs oversell their networks. That's great and it makes sense... as long as they can get away with it. But when services like online gaming and netflix gain popularity, the ISP business model is insufficient for delivering quality connections.
Also, nice "pipe dream" pun in the second paragraph. ;)
2) Too many edges - if you regionalize too heavily, you end up restricting your matchmaking pools to smaller groups. Matchmaking theory says that either (a) quality of matches decreases or (b) time to matchmake increases as your pool shrinks. At some point, to have a healthy matchmaking pool in a game with a wide variety of skill levels, you have to consolidate. Riot already had Euro datacenters (with separate accounts, which solves #1).
3) Performance - cloud low-latency UDP performance isn't nearly as good as you can get yourself. Plus, you have more control (and leverage) doing it in-house.
4) Perception - some level of latency becomes imperceptible, 50ms is getting pretty close to that number.
I've proposed a scalable mesh network, see IsoGrid.org