Games

343 INDUSTRIES

Season 2 Lone Wolves Launch

Alex Wakeford

Debrief 009

Silver Debrief: Solace

Esports

<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="975" height="244" src="https://wpassets.halowaypoint.com/wp-content/2022/04/image.png" alt="" class="wp-image-33928" srcset="https://wpassets.halowaypoint.com/wp-content/2022/04/image.png 975w, https://wpassets.halowaypoint.com/wp-content/2022/04/image-300x75.png 300w, https://wpassets.halowaypoint.com/wp-content/2022/04/image-768x192.png 768w" sizes="(max-width: 975px) 100vw, 975px" /></figure>



During the development of the Halo Infinite, the 343 Industries team partnered closely with Dolby, innovators in the science of sight and sound for movies, TV shows, music, and gaming. Thanks to Dolby technologies we were able to take the audiovisual experience for Halo Infinite to all new heights, delivering that same world-class experience to players at home. For the Halo Championship Series, we wanted to build off the partnership and extend to Halo esports in all new ways. 



Today we’re excited to announce that the Halo Championship
Series is now officially partnered with Dolby to showcase the amazing experience
that Dolby brings to Halo Infinite. 



As part of the partnership, Dolby will be onsite with a
booth in Kansas City, Orlando, and the Halo World Championship right here in
Seattle, showcasing the extraordinary spatial sound of Dolby Atmos and visual
fidelity of Dolby Vision in Halo Infinite. Fans will be able to go hands-on to
truly experience the difference for themselves. Dolby will also be offering
free trials of Dolby Atmos for Headphones via the Dolby Access app on Microsoft
Store so you can have the same experience right in the comfort of your home.



Be sure to stop by the booth and try it out for yourself,
we’re very interested in hearing feedback from our competitive players!



And, in the future, we’re also working with Dolby to deliver
the HCS broadcast in Dolby Atmos and Dolby Vision so fans at home watching the
show can experience every moment like never before. 



We want to thank Dolby for supporting the Halo community not
only with their amazing technology already in place with Halo Infinite, but
also for supporting the HCS and providing a great experience for players and
fans at the events. 



We’ll see you in Kansas City!

Official HCS

Dolby Joins the HCS

Debrief 008

Silver Debrief: Reckoning

“So, who spilled coffee on the MCC servers on Friday 04/01?”



My name is Dana and I’m one of the engineers on the Halo Publishing Team who responded to the recent incident which affected matchmaking and custom games browser in Halo: The Master Chief Collection.



<hr class="wp-block-separator"/>



<h2 class="wp-block-heading">MCC’s Dedicated Server Model</h2>



In order to contextualize the details shared in this blog, here are some basic details on MCC’s server model. MCC uses dedicated servers for matchmade games and custom game browser sessions. Other game modes in MCC use peer-hosted session (where one player within the game is designated the game host).



These servers are virtual machines hosted by another team at Microsoft which serves first- and third-party Xbox studios and that team is in turn served by Azure technologies. These servers run an application which we call the Unified Dedicated Server (UDS). The UDS is effectively the server counterpart to the MCC game client and contains a wrapper which can configure and launch server versions of any of the games within MCC.



The UDS is a “trusted” authority meaning that it can’t be tampered with like MCC game clients potentially can be on PC. As such, in addition to creating a fair and reliable game experience (where all players in a game have comparable ping, the host has a stable connection, and no one has “host advantage” or “host disadvantage”), it is also a trusted source for tracking match statistics. These stats and other trusted events are used for things like calculating competitive skill ranks and progressing challenges.



From an MCC client perspective (i.e. the version of MCC that runs on your local PC or Xbox), we look at the setup of the UDS in two phases: allocation and configuration.



To allocate a dedicated server, the MCC game client makes a request to our microservice which handles some other details of the allocation on the client’s behalf. A virtual machine is allocated in the optimal region (based on ping—or manual selection in the case of the custom game browser) with sufficient machines standing by and information about the allocated machine is communicated back to the game client. From there, we enter the configuration stage where a connection between the client is established and the client begins sending configuration data for the match (which Halo game to launch, what map and game variant to load, etc.)



<hr class="wp-block-separator"/>



<h2 class="wp-block-heading">The Incident</h2>



On the afternoon of 04/01, our internal QA team escalated a potential matchmaking issue they were encountering on our release candidate (RC) build (the build expected to ultimately release to our players) for our upcoming MCC game update. Ensuring that this update is in good shape and able to ship by our target date has been my top priority in recent weeks, so I began investigating immediately.



After some initial investigation, the symptom became apparent. A server was being successfully allocated, but configuration was failing. It seemed surprising that this issue wouldn’t have been observed earlier in our RC testing, but as this was observed on a relatively new MCC build, the investigation was directed towards identifying what code changes since our last released game update (roughly a sixth month delta during which time numerous features were added and hundreds of bugs were fixed) could have introduced the issue.



However, it was around this time that reports started rolling in from MCC players that they were experiencing their own matchmaking issues in our production environment (the “real” environment where you play MCC as opposed to the “artificial” internal environment where we test iterative development changes for MCC). The issue we were observing in our internal environment was logically inferred to be caused by code churn from the past six months of development, so surely the production issue was not related. An issue actively impacting our players in the production environment takes priority of an internal issue, though, so our investigation retargeted that issue immediately.



It didn’t take long to confirm that the production issue was, in fact, the very same one impacting our internal RC build!



On one hand, it was a relief to confirm that the issue wasn’t something unique to our RC that would jeopardize our upcoming game update. But the fact that both builds (which were separated by six months of iterative development) were abruptly impacted in exactly the same way had concerning implications of its own. We had made two backend changes for MCC in the preceding days (in preparation for our upcoming game update), but these were logically incapable of introducing the behavior we were observing. Still, we rolled both changes back to entirely rule them out as potential causes.



Shortly after confirming this, we rolled out our first mitigation step for the issue which was to enable peer-to-peer fallback for MCC matchmaking. This allows matches where server configuration fails to fall back to a peer host (like custom games use). The peer-to-peer experience is not the ideal or intended experience and, with the lack of a trusted host we described earlier, doesn’t allow certain challenges to be progressed or skill ranks to be calculated. Still, it would at least increase matchmaking success rates and allow folks to get into matches more reliably for their Friday evening Halo-ing.



It was approaching midnight on Friday. Here’s what we knew so far…



Players were frequently failing to configure dedicated servers. From looking through logs corresponding to failures on the dedicated servers themselves, the primary configuration data was never being received from clients in the first place. Two wildly different MCC builds (one of which had been working as expected in the production environment for the past several months) were affected by the issue in exactly the same way. Recent service changes we’d made were not causal (but had been reverted just in case anyway). The primary mitigation steps we’d taken so far were enabling peer-to-peer fallback and disabling bans. Unfortunately, as we learned further into the weekend, this ban change failed to immediately take effect due to a completely unrelated issue.



On Saturday morning, now that we’d ruled out any MCC-specific changes being causal, we began engaging partner teams across Microsoft. We cast a gradually wider net as each team owning services along the path between client and server conducted their own investigation, slowly narrowing things down. On Saturday we also built a more complete understanding of the issue from a combination of data aggregation and manual reproduction of the issue aided by network traffic capture tools.



<hr class="wp-block-separator"/>



<h2 class="wp-block-heading">On Thin ICE</h2>



The server configuration process is conducted by way of a series of packets sent between the client and server. The client-server connection itself is negotiated via <a rel="noreferrer noopener" href="https://datatracker.ietf.org/doc/html/rfc8445" target="_blank">Internet Connectivity Establishment (ICE)</a> in order to send STUN packets between them. STUN is a protocol for <a rel="noreferrer noopener" href="https://datatracker.ietf.org/doc/html/rfc8489" target="_blank">Session Traversal Utilities for Network Address Translator (NAT)</a>. In our case, these STUN packets are used for managing <a rel="noreferrer noopener" href="https://www.ietf.org/rfc/rfc768.txt" target="_blank">User Datagram Protocol (UDP)</a> flow between the client and server. The connection is negotiated via binding requests which allow the client to identify the address of the server. The client will only accept solicited traffic from the server (traffic sent along an established connection), but the server can accept unsolicited traffic (allowing the client to initially establish the connection).



This process looks like an initial establishment followed by a series of configuration messages telling the server which Halo game library to launch and optionally providing map and game variant data. What we observed was that the client would send the expected initial packets, the server would receive them and send the expected packets in response, but the client never received them!



Without receiving the initial acknowledgement, the client could never move on to sending the configuration data itself. After ten seconds of not receiving acknowledgment, the client would time out which would manifest as a failure in matchmaking or the custom game browser. 30 seconds after allocation with no configuration, the UDS would shut down (putting the virtual machine back into standby, ready to be allocated again).



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1100" height="791" src="https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_01.jpg" alt="" class="wp-image-33806" srcset="https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_01.jpg 1100w, https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_01-300x216.jpg 300w, https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_01-1024x736.jpg 1024w, https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_01-768x552.jpg 768w" sizes="(max-width: 1100px) 100vw, 1100px" /></figure>



Parallel Wireshark captures from the client (left) and server (right) when reproducing the issue with trace view (top) and UDP stream view (bottom). IP addresses have been anonymized. The server responses (blue in the UPP stream view) are not received by the client.



Interestingly, in the cases where the client did receive the response from the server and successfully configure, it would continue to succeed any subsequent attempts to configure that virtual machine for a period of about 15 minutes. Failures were also inconsistent; a client could fail to configure a given server and then succeed on its next attempt. In the retail environment, it is highly unlikely that a client would ever make two contiguous configuration requests to the same server, but this provided some further details for our investigation.



The number of virtual machines allocated rose to higher-than-normal levels because, in most cases, they would fail configuration and clients would move onto allocate another machine and repeat the process. Meanwhile, the amount of actual UDP traffic between clients and servers fell well below normal.



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1100" height="395" src="https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_02.jpg" alt="" class="wp-image-33820" srcset="https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_02.jpg 1100w, https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_02-300x108.jpg 300w, https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_02-1024x368.jpg 1024w, https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_02-768x276.jpg 768w" sizes="(max-width: 1100px) 100vw, 1100px" /></figure>



 MCC dedicated server machine allocations from 03/28 through 04/03



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1100" height="363" src="https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_03.jpg" alt="" class="wp-image-33834" srcset="https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_03.jpg 1100w, https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_03-300x99.jpg 300w, https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_03-1024x338.jpg 1024w, https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_03-768x253.jpg 768w" sizes="(max-width: 1100px) 100vw, 1100px" /></figure>



 MCC dedicated server outgoing User Datagram Protocol (UDP) bytes from 03/28 through 04/03



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1100" height="355" src="https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_04.jpg" alt="" class="wp-image-33848" srcset="https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_04.jpg 1100w, https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_04-300x97.jpg 300w, https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_04-1024x330.jpg 1024w, https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_04-768x248.jpg 768w" sizes="(max-width: 1100px) 100vw, 1100px" /></figure>



MCC dedicated server outgoing User Datagram Protocol (UDP) packets from 03/28 through 04/03



<hr class="wp-block-separator"/>



<h2 class="wp-block-heading">Mitigation</h2>



Thankfully, we were able to reliably reproduce the issue ourselves which allowed us to set up and capture various network diagnostics in real-time from the client and server simultaneously. This allowed us to narrow down the issue somewhat as we tracked the returning packets on their way back to the client. However, the network topology between client and server is somewhat complex and some components of it are stateful—meaning that the same inputs can result in different outputs based on surrounding factors. As a result, identifying exactly where packets were getting lost along the way was an unfortunately time-consuming process.



In parallel to this investigation, we sought to simplify our test case. MCC and the UDS are each complex applications which can introduce noise or red herrings into this kind of investigation. To combat this, we built a simple test application to replicate our traffic scenario without any other implementation details getting in the way. We found that we could consistently reproduce the issue with our simple test app if the server sent an unsolicited packet to the client (before the client established a connection). This behavior which was consistently resulting in failure would have resulted in success prior to 04/01.



Armed with this information, we were able to make a targeted change to the traffic pattern on our UDS (i.e. a change which would not require a game update for MCC). We rolled this change out in parallel to two of our development branches and began testing the fix against our live MCC build and our upcoming release candidate at the same time. With this change, we observed our server configuration success rate go from something like 25% to 100%. This testing took place on Tuesday afternoon into Wednesday morning, and we deployed our new UDS build containing the change at scale early Wednesday afternoon.



Unfortunately, players currently need to relaunch MCC to receive the new server pairing information (this is something we’re looking to improve in the future). As a result, players saw a lot of false negatives throughout Wednesday afternoon where, even if they had relaunched, someone they matched with hadn’t and they attempted to configure a server from the old deployment (without the fix). Error rates declined as more and more of the population moved up to the new server deployment.



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1100" height="538" src="https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_05.jpg" alt="" class="wp-image-33862" srcset="https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_05.jpg 1100w, https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_05-300x147.jpg 300w, https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_05-1024x501.jpg 1024w, https://wpassets.halowaypoint.com/wp-content/2022/04/1100_MCC_MMBlog_05-768x376.jpg 768w" sizes="(max-width: 1100px) 100vw, 1100px" /></figure>



MCC dedicated server configuration and reservation failures per hour from 03/31 through 04/08



<hr class="wp-block-separator"/>



<h2 class="wp-block-heading">STUNning Conclusion</h2>



We finally had our fix, but what had caused this established traffic pattern (which adhered to the Internet Engineering Task Force (IETF) standard and had served us well for the past few years) to abruptly stop working? Investigation continued. Finally, it was identified that there had been some updates behind the scenes to the servers we use to relay STUN traffic as part of the ICE process which had resulted in misconfigurations.



We took other steps along the way such as adding more logging and other functionality to our UDS builds to make potential issues like this easier to diagnose in the future. We also implemented the traffic pattern change via a configurable switch (so we can reenable the old behavior at any time if needed). We were ultimately able to deploy a fix very quickly (under 24 hours from implementation to release) and without prompting a client-side MCC update (which requires certification and generally longer lead time), but the nature of the investigation to identify the issue in the first place meant that the whole process took much longer than we would’ve hoped.



Modern multiplayer games are complex and rely on a variety of technologies spanning multiple devices and networks. We’re always seeking to evolve and improve our own tech stack and how it interacts with dependent services. Thank you for joining us for this peek behind the curtain, and for your patience while we resolved the incident.

MCC Server Incident Summary

Community

Community Update

Hello Everyone,



With Season 2 locked and loaded for May 3rd, we want to
share a roadmap of what we’re planning to deliver during Season 2 and for the
rest of the year. 



More than anything else, we want this roadmap to be accurate
and reliable. Some items and dates are certain, and these are clearly listed.
Others are marked as “targets” or “goals” and they will become more certain
over time. The roadmap’s timeframe will also expand as we announce longer-term
initiatives. In other words, this roadmap is an evolving document, and we’ll
let you know when we make changes to it.



With all that in mind, here’s the Halo Infinite roadmap for 2022:



<figure class="wp-block-image size-full"><a href="https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite-2022Roadmap-April.jpg"><img loading="lazy" decoding="async" width="1920" height="1080" src="https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite-2022Roadmap-April.jpg" alt="Halo Infinite's 2022 roadmap as of April 22" class="wp-image-33672" srcset="https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite-2022Roadmap-April.jpg 1920w, https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite-2022Roadmap-April-300x169.jpg 300w, https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite-2022Roadmap-April-1024x576.jpg 1024w, https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite-2022Roadmap-April-768x432.jpg 768w, https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite-2022Roadmap-April-1536x864.jpg 1536w, https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite-2022Roadmap-April-1568x882.jpg 1568w" sizes="(max-width: 1920px) 100vw, 1920px" /></a></figure>



This roadmap reflects the same studio priorities <a rel="noreferrer noopener" href="https://www.halowaypoint.com/news/halo-infinite-update-march-2022" target="_blank">that we shared back in March</a>…



<ul><li>Addressing issues negatively impacting player experience.</li><li>Completing Season 2 and delivering it as promised on May 3. </li><li>Continuing work on Campaign Co-op, Forge, and Season 3.</li></ul>



…with a “priority zero” of team health and getting ourselves into a sustainable development rhythm so that we can deliver great experiences to all of you while maintaining a healthy work/life balance.



We know we need to deliver more content and more features more quickly. Staying true to priority zero means that sometimes we need to slow down in order to stay healthy and move faster later. But we’re also aggressively looking at ways to accelerate.



For example, we want to get the Forge toolset into your hands sooner rather than later so that awesome community maps and modes can more rapidly make their way into the game. To make this happen, we’re targeting a Forge open beta later in Season 2. We’ve successfully had Forge in private flighting with a limited audience for some time, so we’ve decided to forgo a large-scale formal flighting program and go right to open beta. With this approach, we can get the core Forge tools out to everyone quicker while also remaining focused on our core priority of continuing to improve foundational aspects of Halo Infinite. Forge will persist from the open beta onwards, evolving and growing over time.



As we continue to improve and ramp up, please understand that all of us at 343 are fully committed to making Halo Infinite the best Halo experience ever. Indeed, the primary reason that we’re extending Season 2 is to give us time before shipping another Season to fully address “quality of life” improvements based on <a rel="noreferrer noopener" href="https://www.halowaypoint.com/news/season-1-outcomes-report-live" target="_blank">learnings from Season 1</a> as well as other data and feedback we’ve collected.



Quality of life (QoL) is shorthand for bug-fixes, new features and/or content to address issues negatively impacting player experience. We’ll be delivering QoL improvements as part of Season releases and as separate updates during Seasons.



Our player-facing term for QoL updates that land during Seasons is “Drop Pods.” And much like their ODST namesakes, these release vehicles are meant to drop in hot, just as soon as they’re ready. Our target is one Drop Pod every month, and you can expect Drop Pods to vary in scope and size. We’ll have more to share about what’s going into Season 2’s Drop Pods as soon as possible after Season 2 launch.



Speaking of which, Season 2 launch is now less than two weeks away, on May 3! If you haven’t already seen the previews for Season 2’s <a rel="noreferrer noopener" href="https://www.halowaypoint.com/news/season-2-map-previews-catalyst-and-breaker" target="_blank">new maps</a> and <a rel="noreferrer noopener" href="https://www.halowaypoint.com/news/season-2-modes-preview" target="_blank">new modes</a>, please have a look. During these preview videos, you’ll spy some of Season 2’s new armor customization options. And here are a few extra combinations to whet your appetite:



<figure class="wp-block-image size-full"><a href="https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite_SpartanLineup_S2_4k_WATERMARKED.jpg"><img loading="lazy" decoding="async" width="2560" height="1440" src="https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite_SpartanLineup_S2_4k_WATERMARKED-scaled.jpg" alt="" class="wp-image-33643" srcset="https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite_SpartanLineup_S2_4k_WATERMARKED-scaled.jpg 2560w, https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite_SpartanLineup_S2_4k_WATERMARKED-300x169.jpg 300w, https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite_SpartanLineup_S2_4k_WATERMARKED-1024x576.jpg 1024w, https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite_SpartanLineup_S2_4k_WATERMARKED-768x432.jpg 768w, https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite_SpartanLineup_S2_4k_WATERMARKED-1536x864.jpg 1536w, https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite_SpartanLineup_S2_4k_WATERMARKED-2048x1152.jpg 2048w, https://wpassets.halowaypoint.com/wp-content/2022/04/HaloInfinite_SpartanLineup_S2_4k_WATERMARKED-1568x882.jpg 1568w" sizes="(max-width: 2560px) 100vw, 2560px" /></a></figure>



We’ll have a lot more to share about Season 2 including a deep dive into its Battle Pass rewards, events—including brand new “multiplayer narrative events” that place your personal Spartan in the center of an evolving Seasonal storyline—game modes, and much more during a community livestream scheduled for next Wednesday, April 27, at 1:00 PM PST on <a href="https://www.twitch.tv/Halo">Twitch.tv/Halo</a> and <a href="https://www.youtube.com/Halo/live">YouTube.com/Halo</a>. We’ll also be discussing the roadmap in more detail during this livestream.



In summary: we are committed to delivering more content faster; we will accelerate while prioritizing team health; you can expect QoL improvements during Seasons via Drop Pods—and you can expect more regular roadmap updates as our plans snap into sharper focus.



On behalf of the entire Halo Infinite team, thank you for your passion and patience as we embark on the road ahead. We’re fired up to deliver what’s already on the roadmap as well as to deliver other content and experiences that we’re not ready to reveal just yet… but that we can’t wait for you to play.



Joseph Staten Head of Creative, Halo Infinite

Season 2 Lone Wolves Launch

Silver Debrief: Solace

Dolby Joins the HCS

Silver Debrief: Reckoning

MCC Server Incident Summary

Halo Infinite Update – April 2022

Among Flood

Season 2: Modes Preview

Fracture: Tenrai Event (Updated)

Silver Debrief: Homecoming