Comment More things to consider (Score 2) 424
"Making routers actually pay attention to QoS bits, and defining specific queuing behavior for them"
It's fantasic that strides are being taken by the gaming development community to pound on the networking vendors to give gamers (specifically modem users) a "better" Internet. A lot of work has been done in this area in the past couple of years in light of VoIP, but I always envisioned the Diff-Serv/Int-Serv as a perfect app for online gaming =)
However, its not the vendors that are the problem, in this case. Most every router manufacturer has a current "QoS game" that is some adoption of the Diff-Serv approach. The problem lies with the network providers themselves. Rather, its the inter-peer handoff of packets from one provider to another that is the actual core of the problem at hand, as diff-serv "mappings" from one domain to another (ie. passing packets from SprintLink to UUNET) can vary greatly, not to mention the cost negotiations and political games at hand. It can be either really simple or really complex, and if it was simple, we'd probably already see something working =)
To compound this problem, the largely assymetrical nature of the Internet would require these mappings to be identical on both the forward AND reverse path. Its easy to map a packet from inside a network all the way to a peering point. Its a bit more difficult to appropriately map the return path FROM the peer point back to the internal recipient.
I'm not saying that its impossible. The packet marking approach would work great for a completely on-net connection (i.e., where a packet stays entirely within a single backbone provider). Its just right now the inter-domain marking support simply doesn't exist in production form on today's networks.
I think the current focus in high performance networking still relies on the characteristics of the peer-peer or client-server protocol that is used to exchange data. Much can be done at the application layer to realize current bandwidth availability and network characteristics (i.e. loss, delay variation, etc.).
Using a simplistic approach of having the user specify their local link rate is right on the mark in a LAN environment. It makes the protocol simple with few corner cases.
However, with on-line play, relying on the local link rate/capacity of the player's Internet connection does not take into account the many link variations that lie between the player and the server they connect to. It is this transitory network where the majority of bottlenecks occur. It is also where a smarter protocol that utilizes congestion avoidance, adaptive rate control and proper error recovery (at a network level, not a user-level data recovery standpoint) can GREATLY enhance overall user "goodput" (goodput = the users' perceived network throughput). Of course, this creates a more more complex protocol for more cases to consider, but this is actually what we want.
Take for instance TCP. By utilizing the SACK option on TCP connections, a user can achieve 20-50% increased goodput over a convential TCP connection on the same "noisy" Internet link. Of course gaming doesnt use TCP, but it *is* an example of a case where people said "stick a fork in it, its done" about a network protocol (TCP).
Again, I think it is extremely beneficial in examining everying to improve the quality of on-line play (especially for high latency, low bandwidth users). But I still believe that the most gains can be made in putting together a network savvy protocol that is aware and proactive on the connection with its peer. It's not necessarily the delay, but the delay variation thats the most aggrevating for online gameplay.
-Jason Keimig
Information and Telecommunication Technology Center
University of Kansas
It's fantasic that strides are being taken by the gaming development community to pound on the networking vendors to give gamers (specifically modem users) a "better" Internet. A lot of work has been done in this area in the past couple of years in light of VoIP, but I always envisioned the Diff-Serv/Int-Serv as a perfect app for online gaming =)
However, its not the vendors that are the problem, in this case. Most every router manufacturer has a current "QoS game" that is some adoption of the Diff-Serv approach. The problem lies with the network providers themselves. Rather, its the inter-peer handoff of packets from one provider to another that is the actual core of the problem at hand, as diff-serv "mappings" from one domain to another (ie. passing packets from SprintLink to UUNET) can vary greatly, not to mention the cost negotiations and political games at hand. It can be either really simple or really complex, and if it was simple, we'd probably already see something working =)
To compound this problem, the largely assymetrical nature of the Internet would require these mappings to be identical on both the forward AND reverse path. Its easy to map a packet from inside a network all the way to a peering point. Its a bit more difficult to appropriately map the return path FROM the peer point back to the internal recipient.
I'm not saying that its impossible. The packet marking approach would work great for a completely on-net connection (i.e., where a packet stays entirely within a single backbone provider). Its just right now the inter-domain marking support simply doesn't exist in production form on today's networks.
I think the current focus in high performance networking still relies on the characteristics of the peer-peer or client-server protocol that is used to exchange data. Much can be done at the application layer to realize current bandwidth availability and network characteristics (i.e. loss, delay variation, etc.).
Using a simplistic approach of having the user specify their local link rate is right on the mark in a LAN environment. It makes the protocol simple with few corner cases.
However, with on-line play, relying on the local link rate/capacity of the player's Internet connection does not take into account the many link variations that lie between the player and the server they connect to. It is this transitory network where the majority of bottlenecks occur. It is also where a smarter protocol that utilizes congestion avoidance, adaptive rate control and proper error recovery (at a network level, not a user-level data recovery standpoint) can GREATLY enhance overall user "goodput" (goodput = the users' perceived network throughput). Of course, this creates a more more complex protocol for more cases to consider, but this is actually what we want.
Take for instance TCP. By utilizing the SACK option on TCP connections, a user can achieve 20-50% increased goodput over a convential TCP connection on the same "noisy" Internet link. Of course gaming doesnt use TCP, but it *is* an example of a case where people said "stick a fork in it, its done" about a network protocol (TCP).
Again, I think it is extremely beneficial in examining everying to improve the quality of on-line play (especially for high latency, low bandwidth users). But I still believe that the most gains can be made in putting together a network savvy protocol that is aware and proactive on the connection with its peer. It's not necessarily the delay, but the delay variation thats the most aggrevating for online gameplay.
-Jason Keimig
Information and Telecommunication Technology Center
University of Kansas
