Game Developers Note Net Neutrality Concerns To FCC 74
eldavojohn writes "A list of notes from game developers (PDF) was sent in a letter to the FCC which represented a net neutrality discussion between the developers and FCC representatives. Game Politics sums it up nicely, but the surprise is that developers are concerned with latency, not bandwidth, unlike the members of many other net neutrality discussions. One concern is that each and every game developer will need to negotiate with each and every ISP to ensure their traffic achieves acceptable levels of latency for users. 'Mr. Dyl of Turbine stated that ISPs sometimes block traffic from online gaming providers, for reasons that are not clear, but they do not necessarily continue those blocks if they are contacted. He recalled Turbine having to call ISPs that had detected the high UDP traffic from Turbine, and had apparently decided to block the traffic and wait to see who complained.' It seems a lot of the net neutrality discussions have only worried about one part of the problem — Netflix, YouTube and P2P — while an equally important source of concern went unnoticed: latency in online games."
Not any surprise (Score:3, Informative)
Actually, this is no surprise at all. Maybe most people only focus on the raw speed - i.e., throughput. However, for many applications, the latency - and the lack of sudden latency variations - is more important. These apps are called "inelastic", because they don't tolerate changes in the latency. For example: In a real-time VoIP application, sudden changes in latency make delayed packets useless and the voice gets cut. Yep, you can use a buffer, but that will add an anoying delay in your conversation, so in general the application is highly sensitive to latency changes.
The same happens with games. If you are playing against sb else, your latency can determine if you live or die. AND, the main problem is that the only solution comes from QoS mechanisms that tag, segregate and priorize different flows of traffic. What, I believe, is somehow against net neutrality.
not only games... (Score:3, Informative)
latency is also important for voice-over-IP...
Re:What about an open standard for TCP priorities? (Score:3, Informative)
Besides, ideally, at some point most packets will be encrypted by default. You wouldn't WANT to be able to distinguish types of packets from each other.
Re:What about an open standard for TCP priorities? (Score:1, Informative)
You're looking for Quality of Service (QoS). Been part of IP for a while now.
It supports a set of flags that can be on or off: Bulk (latency is unimportant but bandwidth is), low-latency (latency is important, bandwidth is not), low-price (packet should be delivered using the cheapest service possible) and I think there were one or two more but I can't remember them currently.
I'm not sure how many routers actually honor these flags, not many I think. Any way, abuse of the low-latency flag fails because on most network admin sites I've read, they strongly recommend filtering rules that only permit 100KiB of low-latency per minute per user, anything higher than that will get converted to Bulk or standard traffic instead.
Re:What about an open standard for TCP priorities? (Score:2, Informative)
I'd like to see that study. Actually QOS seems like a better option if used properly. I could prioritise packets from things that are latency sensitive (Skype, Games and to a lesser extent HTTP) and de-prioritize ones from things that aren't (Torrents). I could imaging it working very well if the backbone supported it.
E.g. in USB isochronous streams and interrupt endpoints are allocated bandwidth up front they are handled at the start of a frame. Bulk transfers get whatever is left. So your mouse is guaranteed to be responsive even if you're copying a huge file to a disk. Adding capacity won't do this if you have applications that are designed to use all the capacity available. Like Bittorrent.
The classic case for throttling people is that you have a bunch of people with cheap and thus heavily contended connections. Once someone torrents they use up essentially all of the bandwidth to the point that Skype is unusable and even HTTP is painfully slow. People complain and the ISP decides to throttle Bitorrent. Of course this isn't quite right technically - really all the applications on the network should say truthfully what they actually need. Of course there's little chance of that happening - if the network supported QOS applications trying to Bittorrent would just lie to get better transfer rates. So you end up with the ISP throttling torrents. Now you could say that the ISP should reduce contention ratios. Actually they offer a range of contention ratios at different prices, the problem is that people who expect to max out their connection pay for the cheapest one.
It's actually worth pointing out that this case is not one that really supports "network neutrality". A neutral network right now would be saturated with bittorrent packets to the point where it was unusable for latency sensitive things like gaming. Even a QOS network that trusted users would. These guys would be happier if the ISP throttled bittorrent more aggressively so that there was always some spare bandwidth to be used for latency sensitive applications like games and Skype.
I.e. using the salad bar metaphor you have
A minority that must get at least one olive on their place every minute (the gamers, Skype users etc) vs a minority that will empty the salad bar regardless of size (the torrenters). It seems like the gamers would be in favour of reducing plate size - i.e. the salad bar equivalent of throttling. That limits the speed of torrents a bit but it makes latency sensitive applications keep working. It's still an all you can eat buffet of course, so long as they let you stay as long as you want.
Re:Doh! (Score:3, Informative)
Throttling does not affect packet latency. At the router level, it generally involves selectively discarding packets. Data is not drip-fed at the bit level or byte level.
In order to intentionally affect latency, it would have to do a lot more work by buffering them for a period of time before forwarding onwards.
Now throttling can affect latency of logical messages within a TCP stream depending on the size of those messages, due to the retransmissions required, but does not affect the latency of UDP packets as stated.