Merge pull request #107486 from asudbring/natpatch

tweaks to wording

Author: PRMerger9

articles/virtual-network/nat-overview.md

@@ -191,7 +191,7 @@ We want to know how we can improve the service. Share your [feedback on the Publ
 ## Limitations
 
 * NAT is compatible with standard SKU public IP, public IP prefix, and load balancer resources.   Basic resources (for example basic load balancer) and any products derived from them aren't compatible with NAT.  Basic resources must be placed on a subnet not configured with NAT.
-* IPv4 address family is supported.  NAT doesn't interact with IPv6 address family.  NAT cannot be deployed on a subnet with IPv6 prefix.
+* IPv4 address family is supported.  NAT doesn't interact with IPv6 address family.  NAT can't be deployed on a subnet with an IPv6 prefix.
 * NSG flow logging isn't supported when using NAT.
 * NAT can't span multiple virtual networks.
 

articles/virtual-network/troubleshoot-nat.md

@@ -49,7 +49,7 @@ Frequently the root cause of SNAT exhaustion is an anti-pattern for how outbound
 
 #### Design patterns
 
-Always take advantage of connection reuse and connection pooling whenever possible.  These patterns will avoid resource exhaustion problems outright and result in predictable, reliable, and scalable behavior. Primitives for these patterns can be found in many development libraries and frameworks.
+Always take advantage of connection reuse and connection pooling whenever possible.  These patterns will avoid resource exhaustion problems and result in predictable behavior. Primitives for these patterns can be found in many development libraries and frameworks.
 
 _**Solution:**_ Use appropriate patterns
 
@@ -85,14 +85,14 @@ The following table can be used a starting point for which tools to use to start
 
 ### Connectivity failures
 
-Connectivity issues with [Virtual Network NAT](nat-overview.md) can be due to several different issues:
+Connectivity issues with [Virtual Network NAT](nat-overview.md) can be caused by several different issues:
 
 * transient or persistent [SNAT exhaustion](#snat-exhaustion) of the NAT gateway,
 * transient failures in the Azure infrastructure, 
 * transient failures in the path between Azure and the public Internet destination, 
 * transient or persistent failures at the public Internet destination.
 
-Use tools like the following to validation connectivity. [ICMP ping is not supported](#icmp-ping-is-failing).
+Use tools like the following to validation connectivity. [ICMP ping isn't supported](#icmp-ping-is-failing).
 
 | Operating system | Generic TCP connection test | TCP application layer test | UDP |
 |---|---|---|---|
@@ -105,32 +105,32 @@ Review section on [SNAT exhaustion](#snat-exhaustion) in this article.
 
 #### Azure infrastructure
 
-Even though Azure monitors and operates its infrastructure with great care, transient failures can occur as there is no guarantee that transmissions are lossless.  Use design patterns that allow for SYN retransmissions for TCP applications. Use connection timeouts large enough to permit TCP SYN retransmission to reduce transient impacts caused by a lost SYN packet.
+Azure monitors and operates its infrastructure with great care. Transient failures can occur, there's no guarantee that transmissions are lossless.  Use design patterns that allow for SYN retransmissions for TCP applications. Use connection timeouts large enough to permit TCP SYN retransmission to reduce transient impacts caused by a lost SYN packet.
 
 _**Solution:**_
 
 * Check for [SNAT exhaustion](#snat-exhaustion).
 * The configuration parameter in a TCP stack that controls the SYN retransmission behavior is called RTO ([Retransmission Time-Out](https://tools.ietf.org/html/rfc793)). The RTO value is adjustable but typically 1 second or higher by default with exponential back-off.  If your application's connection time-out is too short (for example 1 second), you may see sporadic connection timeouts.  Increase the application connection time-out.
 * If you observe longer, unexpected timeouts with default application behaviors, open a support case for further troubleshooting.
 
-We do not recommend artificially reducing the TCP connection timeout or tuning the RTO parameter.
+We don't recommend artificially reducing the TCP connection timeout or tuning the RTO parameter.
 
-#### public Internet transit
+#### Public Internet transit
 
-The probability of transient failures increases with a longer path to the destination and more intermediate systems. It is expected that transient failures can increase in frequency over [Azure infrastructure](#azure-infrastructure). 
+The chances of transient failures increases with a longer path to the destination and more intermediate systems. It's expected that transient failures can increase in frequency over [Azure infrastructure](#azure-infrastructure). 
 
 Follow the same guidance as preceding [Azure infrastructure](#azure-infrastructure) section.
 
 #### Internet endpoint
 
-The preceding sections apply in addition to considerations related to the Internet endpoint your communication is established with. Other factors that can impact connectivity success are:
+The previous sections apply, along with the Internet endpoint that communication is established with. Other factors that can impact connectivity success are:
 
 * traffic management on destination side, including
 - API rate limiting imposed by the destination side
 - Volumetric DDoS mitigations or transport layer traffic shaping
 * firewall or other components at the destination 
 
-Usually packet captures at the source as well as destination (if available) are required to determine what is taking place.
+Usually packet captures at the source and the destination (if available) are required to determine what is taking place.
 
 _**Solution:**_
 
@@ -142,9 +142,11 @@ _**Solution:**_
 
 #### TCP Resets received
 
-If you observe TCP Resets (TCP RST packets) received on the source VM, they can be generated by the NAT gateway on the private side for flows that are not recognized as in progress.  One possible reason is the TCP connection has idle timed out.  You can adjust the idle timeout from 4 minutes to up to 120 minutes.
+The NAT gateway generates TCP resets on the source VM for traffic that isn't recognized as in progress.
 
-TCP Resets are not generated on the public side of NAT gateway resources. If you receive TCP Resets on the destination side, they are generated by the source VM's stack and not the NAT gateway resource.
+One possible reason is the TCP connection has idle timed out.  You can adjust the idle timeout from 4 minutes to up to 120 minutes.
+
+TCP Resets aren't generated on the public side of NAT gateway resources. TCP resets on the destination side are generated by the source VM, not the NAT gateway resource.
 
 _**Solution:**_
 
@@ -153,7 +155,7 @@ _**Solution:**_
 
 ### IPv6 coexistence
 
-[Virtual Network NAT](nat-overview.md) supports IPv4 UDP and TCP protocols and deployment on a [subnet with IPv6 prefix is not supported](nat-overview.md#limitations).
+[Virtual Network NAT](nat-overview.md) supports IPv4 UDP and TCP protocols and deployment on a [subnet with an IPv6 prefix isn't supported](nat-overview.md#limitations).
 
 _**Solution:**_ Deploy NAT gateway on a subnet without IPv6 prefix.