Adding pipelined explanation

Author: ealsur

articles/cosmos-db/nosql/troubleshoot-dotnet-sdk-slow-request.md

@@ -5,7 +5,7 @@ author: ealsur
 ms.service: cosmos-db
 ms.subservice: nosql
 ms.custom: devx-track-dotnet
-ms.date: 08/02/2023
+ms.date: 07/10/2024
 ms.author: maquaran
 ms.topic: troubleshooting
 ms.reviewer: mjbrown
@@ -173,9 +173,9 @@ For multiple store results for a single request, be aware of the following:
 Show the time for the different stages of sending and receiving a request in the transport layer.
 
 * `ChannelAcquisitionStarted`: The time to get or create a new connection. Connections can be created for numerous reasons such as: The previous connection was closed due to inactivity using [CosmosClientOptions.IdleTcpConnectionTimeout](sdk-connection-modes.md#volume-of-connections), the volume of concurrent requests exceeds the [CosmosClientOptions.MaxRequestsPerTcpConnection](sdk-connection-modes.md#volume-of-connections), the connection was closed due to a network error, or the application is not following the [Singleton pattern](#application-design) and new instances are constantly created. Once a connection is established, it is reused for subsequent requests, so this should not impact P99 latency unless the previously mentioned issues are happening.
-* `Pipelined` time is large might be caused by a large request.
-* `Transit time` is large, which leads to a networking problem. Compare this number to the `BELatencyInMs`. If `BELatencyInMs` is small, then the time was spent on the network, and not on the Azure Cosmos DB service.
-* `Received` time is large might be caused by a thread starvation problem. This is the time between having the response and returning the result.
+* `Pipelined`: The time spent writing the request into the TCP socket. Request can only be written on a TCP socket one at a time, a large value indicates a bottleneck on the TCP socket which is commonly associated with locked threads by the application code or large requests size.
+* `Transit time`: The time spent on the network after the request was written on the TCP socket. Compare this number to the `BELatencyInMs`. If `BELatencyInMs` is small, then the time was spent on the network, and not on the Azure Cosmos DB service. If the request failed with a timeout, it indicates how long the client waited without response, and the source is network latency.
+* `Received`: The time between the response was received and processed by the SDK. A large value is normally caused by a thread starvation or locked threads.
 
 ### ServiceEndpointStatistics