It is spelled 'acknowledgement'

draft-ietf-quic-http.md

@@ -2805,7 +2805,7 @@ None.
 - Adopted as base for draft-ietf-quic-http
 - Updated authors/editors list
 
-# Acknowledgements
+# Acknowledgments
 {:numbered="false"}
 
 The original authors of this specification were Robbie Shade and Mike Warres.

draft-ietf-quic-qpack.md

@@ -343,7 +343,7 @@ Count in order to identify which dynamic table entries can be referenced without
 potentially blocking a stream.  The decoder tracks the Known Received Count in
 order to be able to send Insert Count Increment instructions.
 
-A Section Acknowledgement instruction ({{header-acknowledgment}}) implies that
+A Section Acknowledgment instruction ({{header-acknowledgment}}) implies that
 the decoder has received all dynamic table state necessary to decode the field
 section.  If the Required Insert Count of the acknowledged field section is
 greater than the current Known Received Count, Known Received Count is updated
@@ -396,9 +396,9 @@ The decoder signals the following events by emitting decoder instructions
 
 After the decoder finishes decoding a field section encoded using
 representations containing dynamic table references, it MUST emit a Section
-Acknowledgement instruction ({{header-acknowledgment}}).  A stream may carry
+Acknowledgment instruction ({{header-acknowledgment}}).  A stream may carry
 multiple field sections in the case of intermediate responses, trailers, and
-pushed requests.  The encoder interprets each Section Acknowledgement
+pushed requests.  The encoder interprets each Section Acknowledgment
 instruction as acknowledging the earliest unacknowledged field section
 containing dynamic table references sent on the given stream.
 
@@ -414,7 +414,7 @@ zero MAY omit sending Stream Cancellations, because the encoder cannot have any
 dynamic table references.  An encoder cannot infer from this instruction that
 any updates to the dynamic table have been received.
 
-The Section Acknowledgement and Stream Cancellation instructions permit the
+The Section Acknowledgment and Stream Cancellation instructions permit the
 encoder to remove references to entries in the dynamic table.  When an entry
 with absolute index lower than the Known Received Count has zero references,
 then it is considered evictable; see {{blocked-insertion}}.
@@ -428,7 +428,7 @@ dynamic table entry will provide the timeliest feedback to the encoder, but
 could be redundant with other decoder feedback. By delaying an Insert Count
 Increment instruction, the decoder might be able to coalesce multiple Insert
 Count Increment instructions, or replace them entirely with Section
-Acknowledgements; see {{header-acknowledgment}}. However, delaying too long
+Acknowledgments; see {{header-acknowledgment}}. However, delaying too long
 may lead to compression inefficiencies if the encoder waits for an entry to be
 acknowledged before using it.
 
@@ -811,10 +811,10 @@ A decoder sends decoder instructions on the decoder stream to inform the encoder
 about the processing of field sections and table updates to ensure consistency
 of the dynamic table.
 
-### Section Acknowledgement {#header-acknowledgment}
+### Section Acknowledgment {#header-acknowledgment}
 
 After processing an encoded field section whose declared Required Insert Count
-is not zero, the decoder emits a Section Acknowledgement instruction.  The
+is not zero, the decoder emits a Section Acknowledgment instruction.  The
 instruction starts with the '1' 1-bit pattern, followed by the field
 section's associated stream ID encoded as a 7-bit prefix integer; see
 {{prefixed-integers}}.
@@ -828,14 +828,14 @@ in {{state-synchronization}}.
 | 1 |      Stream ID (7+)       |
 +---+---------------------------+
 ~~~~~~~~~~
-{:#fig-header-ack title="Section Acknowledgement"}
+{:#fig-header-ack title="Section Acknowledgment"}
 
-If an encoder receives a Section Acknowledgement instruction referring to a
+If an encoder receives a Section Acknowledgment instruction referring to a
 stream on which every encoded field section with a non-zero Required Insert
 Count has already been acknowledged, this MUST be treated as a connection error
 of type QPACK_DECODER_STREAM_ERROR.
 
-The Section Acknowledgement instruction might increase the Known Received Count;
+The Section Acknowledgment instruction might increase the Known Received Count;
 see {{known-received-count}}.
 
 
@@ -1629,7 +1629,7 @@ Stream: 4
                               Size=106
 
 Stream: Decoder
-84                  | Section Acknowledgement (stream=4)
+84                  | Section Acknowledgment (stream=4)
 
                               Abs Ref Name        Value
                                1   0  :authority  www.example.com
@@ -1851,7 +1851,7 @@ Editorial changes only
 
 ## Since draft-ietf-quic-qpack-09
 
-- Decoders MUST emit Header Acknowledgements (#2939)
+- Decoders MUST emit Header Acknowledgments (#2939)
 - Updated error code for multiple encoder or decoder streams (#2970)
 - Added explicit defaults for new SETTINGS (#2974)
 

draft-ietf-quic-recovery.md

@@ -64,7 +64,7 @@ normative:
 informative:
 
   FACK:
-    title: "Forward Acknowledgement: Refining TCP Congestion Control"
+    title: "Forward Acknowledgment: Refining TCP Congestion Control"
     author:
       - ins: M. Mathis
       - ins: J. Mahdavi
@@ -219,7 +219,7 @@ QUIC supports many ACK ranges, opposed to TCP's 3 SACK ranges.  In high loss
 environments, this speeds recovery, reduces spurious retransmits, and ensures
 forward progress without relying on timeouts.
 
-## Explicit Correction For Delayed Acknowledgements
+## Explicit Correction For Delayed Acknowledgments
 
 QUIC endpoints measure the delay incurred between when a packet is received and
 when the corresponding acknowledgment is sent, allowing a peer to maintain a
@@ -463,9 +463,9 @@ Loss detection is separate per packet number space, unlike RTT measurement and
 congestion control, because RTT and congestion control are properties of the
 path, whereas loss detection also relies upon key availability.
 
-## Acknowledgement-Based Detection {#ack-loss-detection}
+## Acknowledgment-Based Detection {#ack-loss-detection}
 
-Acknowledgement-based loss detection implements the spirit of TCP's Fast
+Acknowledgment-based loss detection implements the spirit of TCP's Fast
 Retransmit ({{?RFC5681}}), Early Retransmit ({{?RFC5827}}), FACK ({{FACK}}),
 SACK loss recovery ({{?RFC6675}}), and RACK ({{?RACK=I-D.ietf-tcpm-rack}}). This
 section provides an overview of how these algorithms are implemented in QUIC.
@@ -1142,7 +1142,7 @@ sending rate by dropping packets, or alter send rate by changing ECN codepoints.
 ## Traffic Analysis
 
 Packets that carry only ACK frames can be heuristically identified by observing
-packet size.  Acknowledgement patterns may expose information about link
+packet size.  Acknowledgment patterns may expose information about link
 characteristics or application behavior.  To reduce leaked information,
 endpoints can bundle acknowledgments with other frames, or they can use PADDING
 frames at a potential cost to performance.
@@ -1729,7 +1729,7 @@ OnPacketSentCC(sent_bytes):
 ~~~
 
 
-## On Packet Acknowledgement
+## On Packet Acknowledgment
 
 Invoked from loss detection's OnAckReceived and is supplied with the
 newly acked_packets from sent_packets.

draft-ietf-quic-transport.md

@@ -3677,7 +3677,7 @@ An endpoint SHOULD treat receipt of an acknowledgment for a packet it did not
 send as a connection error of type PROTOCOL_VIOLATION, if it is able to detect
 the condition.
 
-## Generating Acknowledgements {#generating-acks}
+## Generating Acknowledgments {#generating-acks}
 
 Endpoints acknowledge all packets they receive and process. However, only
 ack-eliciting packets cause an ACK frame to be sent within the maximum ack
@@ -3756,7 +3756,7 @@ A receiver MUST NOT send an ack-eliciting frame in all packets that would
 otherwise be non-ack-eliciting, to avoid an infinite feedback loop of
 acknowledgments.
 
-### Acknowledgement Frequency
+### Acknowledgment Frequency
 
 A receiver determines how frequently to send acknowledgments in response to
 ack-eliciting packets. This determination involves a trade-off.