minor edits

Author: duongau

articles/firewall/long-running-sessions.md

@@ -15,7 +15,7 @@ This article explains the TCP idle timeout settings and the behavior of long-run
 
 ## Idle timeout settings
 
-The TCP (Transmission Control Protocol) idle timeout specifies the duration a connection can stay inactive before being terminated by the Azure Firewall. This setting helps optimize the Azure Firewall by closing inactive connections and maintaining overall network performance.
+The TCP (Transmission Control Protocol) idle timeout specifies the duration a connection can stay inactive before the Azure Firewall terminates the connection. This setting helps optimize the Azure Firewall by closing inactive connections and maintaining overall network performance.
 
 Configuring the TCP idle timeout properly can:
 
@@ -28,7 +28,7 @@ Configuring the TCP idle timeout properly can:
 In the aspect of the Azure Firewall, **north-south** traffic refers to the traffic that flows between the Azure Firewall and the Internet, while **east-west** traffic refers to the traffic that flows between Azure resources within the same region or across regions. This also includes traffic between Azure resources and on-premises resources connected through Azure VPN, Azure ExpressRoute, and Virtual network peering. The TCP idle timeout behavior in Azure Firewall is different for north-south and east-west traffic. 
 
 - **North-south**: The default TCP idle timeout is set to **4 minutes** to maintain active connections. You can increase the timeout to a maximum of **15 minutes** by submitting a support request through the Azure portal.
-- **East-west**: There is a **5 minutes** TCP idle timeout on the Azure Firewall. This timeout isn't configurable. 
+- **East-west**: There's a **5 minutes** TCP idle timeout on the Azure Firewall. This timeout isn't configurable. 
 
 ## Long-running TCP sessions
 
@@ -39,17 +39,19 @@ The following scenarios can potentially drop long-running TCP sessions:
 - **Scale-in**: When Azure Firewall scales in, it puts the instance in drain mode for 90 seconds before recycling. Any long-running connections still active after this period are disconnected.
 - **Firewall maintenance**: During maintenance updates, the firewall enters drain mode to allow short-lived sessions to complete. Long-running sessions that remain after the drain period are dropped during the restart.
 - **Idle timeout**: Idle sessions are recycled based on the TCP idle timeout settings. For north-south traffic, you can request an increase in the timeout. For east-west traffic, the timeout is fixed at 5 minutes.
-- **Autorecovery**: If an Azure Firewall instance becomes unresponsive, it is automatically recovered. This process can result in the disconnection of long-running sessions.
+- **Autorecovery**: If an Azure Firewall instance becomes unresponsive, it's automatically recovered. This process can result in the disconnection of long-running sessions.
 
 > [!IMPORTANT]
-> To avoid connectivity issues, configure a keep-alive mechanism within your application that communicates through the Azure Firewall for east-west traffic. This ensures that long-running sessions remain active and are not affected by the idle timeout settings.
+> To avoid connectivity issues, configure a keep-alive mechanism within your application that communicates through the Azure Firewall for east-west traffic. This ensures that long-running sessions remain active and aren't affected by the idle timeout settings.
 
 ## Applications sensitive to TCP session reset
 
-Some applications, such as traditional SAP GUI and SAP RFC (Remote Function Call) based apps, are sensitive to TCP session resets and may not handle them gracefully. To protect these sensitive applications, use network security groups (NSGs). For more information, see [How to secure a virtual network](../virtual-network/virtual-network-vnet-plan-design-arm.md#security) and [Network security groups](../virtual-network/network-security-groups-overview.md).
+Some applications, such as traditional SAP GUI and SAP RFC (Remote Function Call) based apps, are sensitive to TCP session resets and may not handle them gracefully. To protect these sensitive applications, use network security groups (NSGs). 
+
+For more information, see [How to secure a virtual network](../virtual-network/virtual-network-vnet-plan-design-arm.md#security) and [Network security groups](../virtual-network/network-security-groups-overview.md).
 
 > [!NOTE]
-> For north-south traffic, an idle timeout results in a RST (reset) packet being sent in both directions. In contrast, for east-west traffic, no RST packet is sent when an idle timeout occurs.
+> For north-south traffic, an idle timeout results in a reset packet (RST) getting sent to both the source and destination. In contrast, for east-west traffic, a reset **isn't** sent when an idle timeout occurs.
 
 ## Next steps