Misc. small fixes

draft-ietf-quic-recovery.md

@@ -413,9 +413,9 @@ Pseudocode for DetectLostPackets follows:
    DetectLostPackets(acked_packet):
      lost_packets = {};
      foreach (unacked_packet less than acked_packet):
-         if (unacked_packet.time_sent <
-             acked_packet.time_sent - kTimeReorderThreshold * smoothed_rtt):
-           lost_packets.insert(unacked_packet.packet_number);
+       if (unacked_packet.time_sent <
+           acked_packet.time_sent - kTimeReorderThreshold * smoothed_rtt):
+         lost_packets.insert(unacked_packet.packet_number);
        else if (unacked_packet.packet_number <
                 acked_packet.packet_number - reordering_threshold)
          lost_packets.insert(unacked_packet.packet_number);

draft-ietf-quic-tls.md

@@ -105,7 +105,8 @@ This document describes how QUIC can be secured using Transport Layer Security
 improvements for connection establishment over previous versions.  Absent packet
 loss, most new connections can be established and secured within a single round
 trip; on subsequent connections between the same client and server, the client
-can often send application data immediately, that is, zero round trip setup.
+can often send application data immediately, that is, using a zero round trip
+setup.
 
 This document describes how the standardized TLS 1.3 can act a security
 component of QUIC.  The same design could work for TLS 1.2, though few of the
@@ -195,12 +196,12 @@ exchange cannot be observed, modified, or forged.
 
 TLS features can be separated into two basic functions: an authenticated key
 exchange and record protection.  QUIC primarily uses the authenticated key
-exchange provided by TLS; QUIC provides its own packet protection.
+exchange provided by TLS but provides its own packet protection.
 
 The TLS authenticated key exchange occurs between two entities: client and
 server.  The client initiates the exchange and the server responds.  If the key
 exchange completes successfully, both client and server will agree on a secret.
-TLS supports both pre-shared key (PSK) and Diffie-Hellman (DH) key exchange.
+TLS supports both pre-shared key (PSK) and Diffie-Hellman (DH) key exchanges.
 PSK is the basis for 0-RTT; the latter provides perfect forward secrecy (PFS)
 when the DH keys are destroyed.
 
@@ -473,7 +474,7 @@ connection (see {{key-expansion}}).
 
 Different keys are used for QUIC packet protection and TLS record protection.
 Having separate QUIC and TLS record protection means that TLS records can be
-protected by two different keys.  This redundancy is limited to a only a few TLS
+protected by two different keys.  This redundancy is limited to only a few TLS
 records, and is maintained for the sake of simplicity.
 
 
@@ -553,7 +554,7 @@ keys.
 
 After a key update (see {{key-update}}), these secrets are updated using the
 HKDF-Expand-Label function defined in Section 7.1 of {{!I-D.ietf-tls-tls13}}.
-HKDF-Expand-Label uses the the PRF hash function negotiated by TLS.  The
+HKDF-Expand-Label uses the PRF hash function negotiated by TLS.  The
 replacement secret is derived using the existing Secret, a Label of "QUIC client
 1-RTT Secret" for the client and "QUIC server 1-RTT Secret" for the server, an
 empty HashValue, and the same output Length as the hash function selected by TLS

draft-ietf-quic-transport.md

@@ -896,8 +896,7 @@ A STREAM frame is shown below.
 
 The STREAM frame contains the following fields:
 
-* Stream ID: A variable-sized unsigned ID unique to this stream, whose size is
-  determined by the `SS` bits in the type byte.
+* Stream ID: A variable-sized unsigned ID unique to this stream.
 
 * Offset: A variable-sized unsigned number specifying the byte offset in the
   stream for the data in this STREAM frame.  The first byte in the stream has an
@@ -1284,9 +1283,6 @@ The frame is as follows:
 
 The fields of a GOAWAY frame are as follows:
 
-* Frame type: An 8-bit value that must be set to 0x03 specifying that this is a
-  GOAWAY frame.
-
 * Error Code: A 32-bit field error code which indicates the reason for closing
   this connection.
 
@@ -1355,9 +1351,9 @@ A receiver acknowledges receipt of a received packet by sending one or more ACK
 frames containing the packet number of the received packet.  To avoid perpetual
 acking between endpoints, a receiver MUST NOT generate an ack in response to
 every packet containing only ACK frames.  However, since it is possible that an
-endpoint sends only packets containing ACK frame (or other non-retransmittable
-frames), the receiving peer MAY send an ACK frame after a reasonable number
-(currently 20) of such packets have been received.
+endpoint might only send packets containing ACK frames (or other
+non-retransmittable frames), the receiving peer MAY send an ACK frame after a
+reasonable number (currently 20) of such packets have been received.
 
 Strategies and implications of the frequency of generating acknowledgments are
 discussed in more detail in {{QUIC-RECOVERY}}.
@@ -1673,10 +1669,10 @@ offset to determine the flow control offset to be advertised.
 Connection flow control is a limit to the total bytes of stream data sent in
 STREAM frames.  A receiver advertises credit for a connection by sending a
 WINDOW_UPDATE frame with the StreamID set to zero (0x00).  A receiver may
-maintain a cumulative sum of bytes received cumulatively on all streams to
-determine the value of the connection flow control offset to be advertised in
-WINDOW_UPDATE frames.  A sender may maintain a cumulative sum of stream data
-bytes sent to impose the connection flow control limit.
+maintain a cumulative sum of bytes received on all streams to determine the
+value of the connection flow control offset to be advertised in WINDOW_UPDATE
+frames.  A sender may maintain a cumulative sum of stream data bytes sent to
+impose the connection flow control limit.
 
 ## Edge Cases and Other Considerations
 
@@ -1690,13 +1686,13 @@ waiting for a WINDOW_UPDATE which will never come.
 
 ### Mid-stream RST_STREAM
 
-On receipt of an RST_STREAM frame, an endpoint will tear down state for the
+On receipt of a RST_STREAM frame, an endpoint will tear down state for the
 matching stream and ignore further data arriving on that stream.  This could
 result in the endpoints getting out of sync, since the RST_STREAM frame may have
 arrived out of order and there may be further bytes in flight.  The data sender
 would have counted the data against its connection level flow control budget,
 but a receiver that has not received these bytes would not know to include them
-as well.  The receiver must learn of the number of bytes that were sent on the
+as well.  The receiver must learn the number of bytes that were sent on the
 stream to make the same adjustment in its connection flow controller.
 
 To avoid this de-synchronization, a RST_STREAM sender MUST include the final
@@ -1733,7 +1729,7 @@ the receiving application consumes data, similar to common TCP implementations.
 If a sender does not receive a WINDOW_UPDATE frame when it has run out of flow
 control credit, the sender will be blocked and MUST send a BLOCKED frame.  A
 BLOCKED frame is expected to be useful for debugging at the receiver.  A
-receiver SHOULD NOT wait for a BLOCKED frame before sending with a
+receiver SHOULD NOT wait for a BLOCKED frame before sending a
 WINDOW_UPDATE, since doing so will cause at least one roundtrip of quiescence.
 For smooth operation of the congestion controller, it is generally considered
 best to not let the sender go into quiescence if avoidable.  To avoid blocking a