SNAT port exhaustion still possible in v2 SDK

Author: j82w

articles/cosmos-db/troubleshoot-dot-net-sdk.md

@@ -42,7 +42,7 @@ Checking the [portal metrics](monitor-accounts.md) will help determine if it's a
 RequestTimeout usually happens when using Direct/TCP, but can happen in Gateway mode. These are the common known causes, and suggestions on how to fix the problem.
 
 * CPU utilization is high, which will cause latency and/or request timeouts. The customer can scale up the host machine to give it more resources, or the load can be distributed across more machines.
-* Socket / Port availability might be low. When using the .NET SDKs released before the 2.0 version, clients running in Azure could hit the [Azure SNAT (PAT) port exhaustion]. This an example of why it is recommended to always run the latest SDK version.
+* Socket / Port availability might be low. Clients running in Azure could hit the [Azure SNAT (PAT) port exhaustion]. The chance of hitting this is reduced by using the v2 or v3 SDK. This an example of why it is recommended to always run the latest SDK version.
 * Creating multiple DocumentClient instances might lead to connection contention and timeout issues. Follow the [performance tips](performance-tips.md), and use a single DocumentClient instance across an entire process.
 * Users sometimes see elevated latency or request timeouts because their collections are provisioned insufficiently, the back-end throttles requests, and the client retries internally without surfacing this to the caller. Check the [portal metrics](monitor-accounts.md).
 * Azure Cosmos DB distributes the overall provisioned throughput evenly across physical partitions. Check portal metrics to see if the workload is encountering a hot [partition key](partition-data.md). This will cause the aggregate consumed throughput (RU/s) to be appear to be under the provisioned RUs, but a single partition consumed throughput (RU/s) will exceed the provisioned throughput.