Merge pull request #210634 from FlorianBorn71/RegionFallbackStrategies

Add sub-chapter for region fallback best practice

Author: Stacyrch140

articles/remote-rendering/reference/regions.md

@@ -10,7 +10,9 @@ ms.custom: references_regions
 
 # Regions
 
-This page lists the currently available regions for use with Azure Remote Rendering. For best results, always use the region that is closest to your physical location.
+This page lists the currently available regions for use with Azure Remote Rendering.
+
+## Region table
 
 | Name | Region | URL |
 |-----------|:-----------|:-----------|
@@ -23,4 +25,13 @@ This page lists the currently available regions for use with Azure Remote Render
 | Southeast Asia | southeastasia | `https://remoterendering.southeastasia.mixedreality.azure.com` |
 | UK South | uksouth | `https://remoterendering.uksouth.mixedreality.azure.com` |
 | West Europe | westeurope | `https://remoterendering.westeurope.mixedreality.azure.com` |
-| West US 2 | westus2 | `https://remoterendering.westus2.mixedreality.azure.com` |
+| West US 2 | westus2 | `https://remoterendering.westus2.mixedreality.azure.com` |
+
+## Region connection best practice
+
+For best results, a client application should always use the region that is closest to your physical location. The [network requirements](./network-requirements.md) chapter mentions strategies how to measure latencies for individual regions.
+The session creation API doesn't implicitly fall back to a different region when creation fails. To make client applications resilient to potential outages in specific regions, it's recommended to add one or more fallback regions to the session creation logic. So if a session can't be allocated and the API returns with a timeout, the client could try the next closest region.
+
+## Next steps
+
+* [Network requirements](./network-requirements.md)