Fix Gorry's editorial comments (#3237)

This attempts to fix Gorry's editorial comments from the QUIC mailing list.

draft-ietf-quic-recovery.md

@@ -148,8 +148,8 @@ All transmissions in QUIC are sent with a packet-level header, which indicates
 the encryption level and includes a packet sequence number (referred to below as
 a packet number).  The encryption level indicates the packet number space, as
 described in {{QUIC-TRANSPORT}}.  Packet numbers never repeat within a packet
-number space for the lifetime of a connection.  Packet numbers monotonically
-increase within a space, preventing ambiguity.
+number space for the lifetime of a connection.  Packet numbers are sent in
+monotonically increasing order within a space, preventing ambiguity.
 
 This design obviates the need for disambiguating between transmissions and
 retransmissions and eliminates significant complexity from QUIC's interpretation
@@ -222,8 +222,8 @@ sent after the epoch starts is acknowledged.  TCP waits for the gap in the
 sequence number space to be filled, and so if a segment is lost multiple times
 in a row, the loss epoch may not end for several round trips. Because both
 should reduce their congestion windows only once per epoch, QUIC will do it
-correctly once for every round trip that experiences loss, while TCP may only
-do it once across multiple round trips.
+once for every round trip that experiences loss, while TCP may only do it
+once across multiple round trips.
 
 ### No Reneging
 
@@ -248,7 +248,7 @@ more accurate round-trip time estimate (see Section 13.2 of {{QUIC-TRANSPORT}}).
 
 At a high level, an endpoint measures the time from when a packet was sent to
 when it is acknowledged as a round-trip time (RTT) sample.  The endpoint uses
-RTT samples and peer-reported host delays (see Section 13.2 of
+RTT samples and peer-reported ACK delays (see Section 13.2 of
 {{QUIC-TRANSPORT}}) to generate a statistical description of the connection's
 RTT. An endpoint computes the following three values: the minimum value
 observed over the lifetime of the connection (min_rtt), an
@@ -272,8 +272,8 @@ latest_rtt = ack_time - send_time_of_largest_acked
 ~~~
 
 An RTT sample is generated using only the largest acknowledged packet in the
-received ACK frame.  This is because a peer reports host delays for only the
-largest acknowledged packet in an ACK frame.  While the reported host delay is
+received ACK frame.  This is because a peer reports ACK delays for only the
+largest acknowledged packet in an ACK frame.  While the reported ACK delay is
 not used by the RTT sample measurement, it is used to adjust the RTT sample in
 subsequent computations of smoothed_rtt and rttvar {{smoothed-rtt}}.
 
@@ -300,7 +300,7 @@ min_rtt is set to the latest_rtt on the first sample in a connection, and to the
 lesser of min_rtt and latest_rtt on subsequent samples.
 
 An endpoint uses only locally observed times in computing the min_rtt and does
-not adjust for host delays reported by the peer.  Doing so allows the endpoint
+not adjust for ACK delays reported by the peer.  Doing so allows the endpoint
 to set a lower bound for the smoothed_rtt based entirely on what it observes
 (see {{smoothed-rtt}}), and limits potential underestimation due to
 erroneously-reported delays by the peer.
@@ -311,7 +311,7 @@ smoothed_rtt is an exponentially-weighted moving average of an endpoint's RTT
 samples, and rttvar is the endpoint's estimated variance in the RTT samples.
 
 The calculation of smoothed_rtt uses path latency after adjusting RTT samples
-for host delays.  For packets sent in the ApplicationData packet number space,
+for ACK delays.  For packets sent in the ApplicationData packet number space,
 a peer limits any delay in sending an acknowledgement for an ack-eliciting
 packet to no greater than the value it advertised in the max_ack_delay transport
 parameter.  Consequently, when a peer reports an Ack Delay that is greater than
@@ -383,7 +383,7 @@ A packet is declared lost if it meets all the following conditions:
   packet ({{packet-threshold}}), or it was sent long enough in the past
   ({{time-threshold}}).
 
-The acknowledgement indicates that a packet sent later was delivered, while the
+The acknowledgement indicates that a packet sent later was delivered, and the
 packet and time thresholds provide some tolerance for packet reordering.
 
 Spuriously declaring packets as lost leads to unnecessary retransmissions and
@@ -508,8 +508,8 @@ SHOULD be set to 500ms, resulting in a 1 second initial timeout as recommended
 in {{?RFC6298}}.
 
 A connection MAY use the delay between sending a PATH_CHALLENGE and receiving
-a PATH_RESPONSE to seed initial_rtt for a new path, but the delay SHOULD NOT
-be considered an RTT sample.
+a PATH_RESPONSE to seed the initial RTT for a new path, but the delay
+SHOULD NOT be considered an RTT sample.
 
 Until the server has validated the client's address on the path, the amount of
 data it can send is limited to three times the amount of data received,
@@ -664,7 +664,7 @@ experiment with other response functions.
 ## Slow Start
 
 QUIC begins every connection in slow start and exits slow start upon loss or
-upon increase in the ECN-CE counter. QUIC re-enters slow start anytime the
+upon increase in the ECN-CE counter. QUIC re-enters slow start any time the
 congestion window is less than ssthresh, which only occurs after persistent
 congestion is declared. While in slow start, QUIC increases the congestion
 window by the number of bytes acknowledged when each acknowledgment is
@@ -740,13 +740,13 @@ illustrate persistent congestion:
   t=7 | Send Pkt #4 (PTO 3)
   t=8 | Recv ACK of Pkt #4
 
-The first three packets are determined to be lost when the ACK of packet 4 is
-received at t=8.  The congestion period is calculated as the time between the
-oldest and newest lost packets: (3 - 0) = 3.  The duration for persistent
-congestion is equal to: (1 * kPersistentCongestionThreshold) = 3.  Because the
-threshold was reached and because none of the packets between the oldest and the
-newest packets are acknowledged, the network is considered to have experienced
-persistent congestion.
+The first three packets are determined to be lost when the acknowlegement of
+packet 4 is received at t=8.  The congestion period is calculated as the time
+between the oldest and newest lost packets: (3 - 0) = 3.  The duration for
+persistent congestion is equal to: (1 * kPersistentCongestionThreshold) = 3.
+Because the threshold was reached and because none of the packets between the
+oldest and the newest packets are acknowledged, the network is considered to
+have experienced persistent congestion.
 
 When persistent congestion is established, the sender's congestion window MUST
 be reduced to the minimum congestion window (kMinimumWindow).  This response of
@@ -949,7 +949,7 @@ max_ack_delay:
 : The maximum amount of time by which the receiver intends to delay
   acknowledgments for packets in the ApplicationData packet number space. The
   actual ack_delay in a received ACK frame may be larger due to late timers,
-  reordering, or lost ACKs.
+  reordering, or lost ACK frames.
 
 loss_detection_timer:
 : Multi-modal timer used for loss detection.