Added suggestioni from issue

Author: flang-msft

articles/azure-cache-for-redis/cache-best-practices-connection.md

@@ -7,7 +7,7 @@ author: flang-msft
 ms.service: cache
 ms.custom: linux-related-content
 ms.topic: conceptual
-ms.date: 09/29/2023
+ms.date: 04/22/2024
 ms.author: franlanglois
 ---
 
@@ -31,18 +31,22 @@ We recommend these TCP settings:
 
 |Setting  |Value |
 |---------|---------|
-| *net.ipv4.tcp_retries2*   | 5 |
+| `net.ipv4.tcp_retries2`   | 5 |
 
-For more information about the scenario, see [Connection does not re-establish for 15 minutes when running on Linux](https://github.com/StackExchange/StackExchange.Redis/issues/1848#issuecomment-913064646). While this discussion is about the StackExchange.Redis library, other client libraries running on Linux are affected as well. The explanation is still useful and you can generalize to other libraries.
+For more information about the scenario, see [Connection does not re-establish for 15 minutes when running on Linux](https://github.com/StackExchange/StackExchange.Redis/issues/1848#issuecomment-913064646). While this discussion is about the _StackExchange.Redis_ library, other client libraries running on Linux are affected as well. The explanation is still useful and you can generalize to other libraries.
 
 ## Using ForceReconnect with StackExchange.Redis
 
-In rare cases, StackExchange.Redis fails to reconnect after a connection is dropped. In these cases, restarting the client or creating a new `ConnectionMultiplexer` fixes the issue. We recommend using a singleton `ConnectionMultiplexer` pattern while allowing apps to force a reconnection periodically. Take a look at the quickstart sample project that best matches the framework and platform your application uses. You can see an example of this code pattern in our [quickstarts](https://github.com/Azure-Samples/azure-cache-redis-samples).
+In rare cases, _StackExchange.Redis_ fails to reconnect after a connection is dropped. In these cases, restarting the client or creating a new `ConnectionMultiplexer` fixes the issue. We recommend using a singleton `ConnectionMultiplexer` pattern while allowing apps to force a reconnection periodically. Take a look at the quickstart sample project that best matches the framework and platform your application uses. You can see an example of this code pattern in our [quickstarts](https://github.com/Azure-Samples/azure-cache-redis-samples).
 
 Users of the `ConnectionMultiplexer` must handle any `ObjectDisposedException` errors that might occur as a result of disposing the old one.
 
 Call `ForceReconnectAsync()` for `RedisConnectionExceptions` and `RedisSocketExceptions`. You can also call `ForceReconnectAsync()` for `RedisTimeoutExceptions`, but only if you're using generous `ReconnectMinInterval` and `ReconnectErrorThreshold`. Otherwise, establishing new connections can cause a cascade failure on a server that's timing out because it's already overloaded.
 
+In an ASP.NET application, you can use integrated implementation in the _Microsoft.Extensions.Caching.StackExchangeRedis_ package instead of using the _StackExchange.Redis_ package directly. If you're using _Microsoft.Extensions.Caching.StackExchangeRedis_ in an ASP.NET application rather than using _StackExchange.Redis_ directly, you can set the `UseForceReconnect` property to true:
+
+   `Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true`
+
 ## Configure appropriate timeouts
 
 Two timeout values are important to consider in connection resiliency: [connect timeout](#connect-timeout) and [command timeout](#command-timeout).
@@ -51,7 +55,7 @@ Two timeout values are important to consider in connection resiliency: [connect
 
 The `connect timeout` is the time your client waits to establish a connection with Redis server. Configure your client library to use a `connect timeout` of five seconds, giving the system sufficient time to connect even under higher CPU conditions.
 
-A small `connection timeout` value doesn't guarantee a connection is established in that time frame. If something goes wrong (high client CPU, high server CPU, and so on), then a short `connection timeout` value causes the connection attempt to fail. This behavior often makes a bad situation worse. Instead of helping, shorter timeouts aggravate the problem by forcing the system to restart the process of trying to reconnect, which can lead to a *connect -> fail -> retry* loop.
+A small `connection timeout` value doesn't guarantee a connection is established in that time frame. If something goes wrong (high client CPU, high server CPU, and so on), then a short `connection timeout` value causes the connection attempt to fail. This behavior often makes a bad situation worse. Instead of helping, shorter timeouts aggravate the problem by forcing the system to restart the process of trying to reconnect, which can lead to a _connect -> fail -> retry_ loop.
 
 ### Command timeout
 
@@ -66,7 +70,7 @@ Avoid creating many connections at the same time when reconnecting after a conne
 If you're reconnecting many client instances, consider staggering the new connections to avoid a steep spike in the number of connected clients.
 
 > [!NOTE]
-> When you use the `StackExchange.Redis` client library, set `abortConnect` to `false` in your connection string.  We recommend letting the `ConnectionMultiplexer` handle reconnection. For more information, see [StackExchange.Redis best practices](./cache-management-faq.yml#stackexchangeredis-best-practices).
+> When you use the _StackExchange.Redis_ client library, set `abortConnect` to `false` in your connection string.  We recommend letting the `ConnectionMultiplexer` handle reconnection. For more information, see [_StackExchange.Redis_ best practices](./cache-management-faq.yml#stackexchangeredis-best-practices).
 
 ## Avoid leftover connections