Playing matchmaking in client mode (not host) can be truly frustrating when the latency or packet loss of the host suffers. Unfortunately for everyone, the quality of connection is not properly assessed when selecting host.
In Microsoft Research reports A and **(Jitu Padhye at Microsoft Research) regarding matchmaking latency and network path quality, it is acknowledged that more probes can be added to increase the number of potential hosts. Please join me in urging Microsoft and 343i to add these necessary improvements to host selection.
Halo Networking Facts
1. Round Trip Time or RTT is the amount of time it takes to send a signal plus the amount of time it takes for an acknowledgement of that signal to be received. RTT is mainly impacted by the distance a signal must travel, the number of relays between locations, and the speed/traffic of each relay.
2. The player with the lowest variation in User Datagram Protocol Round Trip Time (milliseconds) to other players in the game will provide the best hosting performance as long as that connection does not suffer greatly at any point during the match.
3. Good host makes the game fun for everyone. On host with low RTT the significance of host advantage decreases greatly, hence the number of games played on good host directly increases the overall satisfaction and likability of the game.
4. Jitter is the variation in RTT measurements. Low jitter levels by the host are very important to in-game performance. High jitter levels cause things like unexpected visual distortions and erratic hit registration.
5. Games hosted by players with poor RTT and jitter cause client players to have a less than enjoyable experience, regardless of the game’s result.
6. The way matchmaking is currently configured, RTT is not real-time evaluated, it is predicted using tools. These tools try to make a calculated guess while using location based IP statistics. There is significant room for error using this method.
7. Assuming each potential host has the required upstream bandwidth, the most accurate way to select the best host is to evaluate RTT, jitter and packet loss in real time.
In the introduction of report A the authors claim:
“Since probing consumes time and bandwidth, and players have limited patience for matchmaking, only a small fraction of potential hosts can be probed. Furthermore, in games where player machines communicate directly with each other rather than only with the host, it is prohibitive to probe all the potential paths traffic will take, which can be quadratic in the number of online players.”
Firstly, additional probing my be beneficial, but it is not needed to evaluate RTT between established UDP connections. Therefore, it should not consume much additional time. Signed send/receive timestamps of any game UDP packet can be evaluated as soon as all players have established a connection with each other.
Even if it took additional time to compute the test, the time would not be a much more noticeable difference. Players are much more impatient when it comes to playing on bad host than they are when waiting for a match.
Also, the study on patience and other studies cited in these reports are both flawed in their data analyzation and are 5 years or more older than the report itself making them somewhat irrelevant to current FPS titles.
Although it may be prohibitive to probe all potential paths, an RTT test would provide enough information for algorithms to more adequately estimate the quality of all paths. Since NAT type can determine which path game data will take, NAT must be considered when analyzing test results in order to best evaluate the latency of all potential paths. Regardless of the flow directions of these connections, all critical information is still passed through the host box.
Furthermore, although it is true that the required amount of bandwidth be available by the host to pass through all necessary game data, these statistics are not properly evaluated by the current system. Hosting an 8 person game of Halo only requires about 350 Kbps upload speed. Playing as a client only uses about 50 Kbps. Most often, the loss of data between a good host and a client occurs because the client that can’t receive the data is experiencing difficulties or high traffic on their network or ISP’s edge router that causes them to lose packets or send/receive them with high latency.
Currently, host selection doesn’t take into account when the loss or latency of data is at the fault of the client’s congested or poorly linked network and not the fault of the host, even though it is possible to track that information. This missing consideration eventually punishes those with a good connection who game without shared internet by allowing clients who play on a congested network to negatively affect the record of a good host.
Furthermore, say for instance someone has FTTH or Corporate/Institutional grade internet with low latency and jitter and an open NAT. They shouldn’t be required to purchase a new console every couple months to start hosting games again if their host record consistently yields exceptionally low RTT variations.
Finally, disconnects that occur while hosting as a result of attacks should not reduce the frequency of the victimized player’s ability to host games. It is possible to recognize how packets react differently during an attack. This can be used to prevent unjustly damaging the host records of notably good connections.
In conclusion, since the best performing connections on Xbox LIVE can always be detected before the game starts, they should always be selected to host the match. It is much less frustrating to play through being a client with bad internet on a good host than it is for those with good internet to play in a game on a low performing host. If UDP measurements of RTT, RTT variations and packet loss are used, the impact of lag on player satisfaction will be greatly reduced, thus increasing Halo’s online customer retention qualities.
