News for hackers. Stuff that matters.
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 eloff on Sunday February 21, 2016 @07:02PM (#11147373)
I think you read the graphs wrong, they are % of players with better than 80ms ping. So going from 30% to 80% was an incredible improvement!
Re:Fixing the Internet for Real Time Applications, Part II by PeytonKoran on Sunday February 21, 2016 @10:22PM (#11148205)
Hello,

I am the author, you got that right. And thank you for taking the time to read it.

Peyton

Re:Fixing the Internet for Real Time Applications, Part II by BWStearns on Sunday February 21, 2016 @05:43PM (#11147017)
I wonder if there's a long-term goal here of becoming the AWS for gaming and other realtime network needs.

About to go back and read Part I so please forgive if that's covered in the first part.

Re:Fixing the Internet for Real Time Applications, Part II by raarts on Sunday February 21, 2016 @06:51PM (#11147330)
I'm from the VoIP world and we share this pain. Kudos, this must have been a huge undertaking.
Re:Fixing the Internet for Real Time Applications, Part II by PeytonKoran on Sunday February 21, 2016 @10:23PM (#11148211)
It was, but so much fun and really worth it. :) I am the author. Thank You for reading :)

Peyton

Re:Fixing the Internet for Real Time Applications, Part II by surfmike on Sunday February 21, 2016 @07:58PM (#11147586)
How is this different from Akamai's IP Application Accelerator (https://www.akamai.com/us/en/solutions/products/web-performa...)? Honestly curious.

I would love to see a consumer videoconferencing service built on top of one of these networks.

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.

Peyton

Re:Fixing the Internet for Real Time Applications, Part II by surfmike on Monday February 22, 2016 @02:37AM (#11149189)
Interesting, thanks for that.

You guys should really consider making this a platform that anyone could use!

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 hchenji on Sunday February 21, 2016 @11:12PM (#11148392)
Interesting read. Could you blog about the math/techniques/algorithms you used to determine the best fiber paths?

Consider writing a SIGCOMM paper about it!!

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 ajkjk on Sunday February 21, 2016 @06:22PM (#11147208)
I'm pretty sure that phrase is not meant to be taken so seriously.
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.

Peyton

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 sargun on Monday February 22, 2016 @03:58AM (#11149495)
What prevents you from using GCE or AWS and running chunks of your applications near the edge?
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