Original text:
by the endpoints and network load.  An endpoint's loss detection and congestion control mechanisms however need to be tolerant of this delay at the peer.  An endpoint signals its tolerance to its peer <del> using an ACK-FREQUENCY frame, shown below: </del>  Following the common frame format described in Section 12.4 of QUIC- <del> TRANSPORT, ACK-FREQUENCY frames have a type of 0xXX, and contain the </del>  following fields: A variable-length integer representing the sequence number <del> assigned to the ACK-FREQUENCY frame by the sender to allow </del>  receivers to ignore obsolete frames, see multiple-frames. A variable-length integer representing the maximum number of ack- value smaller than the "min_ack_delay" advertised by this endpoint is invalid. <del> Receipt of invalid values in an ACK-FREQUENCY frame MUST be treated </del>  as a connection error of type FRAME_ENCODING_ERROR. <del> ACK-FREQUENCY frames are ack-eliciting.  However, their loss does not </del>  require retransmission. <del> An endpoint MAY send ACK-FREQUENCY frames multiple times during a </del>  connection and with different values. An endpoint will have committed a "max_ack_delay" value to the peer, which specifies the maximum amount of time by which the endpoint will <del> delay sending acknowledgments.  When the endpoint receives an ACK- FREQUENCY frame, it MUST update this maximum time to the value </del>  proposed by the peer in the Update Max Ack Delay field. 5. <del> An endpoint can send multiple ACK-FREQUENCY frames, and each one of </del>  them can have different values.  An endpoint MUST use a sequence <del> number of 0 for the first ACK-FREQUENCY frame it constructs and </del>  sends, and a strictly increasing value thereafter. <del> An endpoint MUST allow reordered ACK-FREQUENCY frames to be received </del>  and processed, see Section 13.3 of QUIC-TRANSPORT. <del> On the first received ACK-FREQUENCY frame in a connection, an </del>  endpoint MUST immediately record all values from the frame.  The sequence number of the frame is recorded as the largest seen sequence number.  The new Packet Tolerance and Update Max Ack Delay values MUST be immediately used for delaying acknowledgements; see sending. <del> On a subsequently received ACK-FREQUENCY frame, the endpoint MUST </del>  check if this frame is more recent than any previous ones, as follows: 6. <del> Prior to receiving an ACK-FREQUENCY frame, endpoints send </del>  acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT. <del> On receiving an ACK-FREQUENCY frame and updating its recorded </del>  "max_ack_delay" and "Packet Tolerance" values (multiple-frames), the endpoint MUST send an acknowledgement when one of the following conditions are met: On sending an update to the peer's "max_ack_delay", an endpoint can use this new value in later computations of its Probe Timeout (PTO) period; see Section 5.2.1 of QUIC-RECOVERY.  The endpoint MUST <del> however wait until the ACK-FREQUENCY frame that carries this new </del>  value is acknowledged by the peer. Until the frame is acknowledged, the endpoint MUST use the greater of computing the PTO period.  Doing so avoids spurious PTOs that can be caused by an update that increases the peer's "max_ack_delay". <del> While it is expected that endpoints will have only one ACK-FREQUENCY </del>  frame in flight at any given time, this extension does not prohibit having more than one in flight.  Generally, when using "max_ack_delay" for PTO computations, endpoints MUST use the maximum

Reviewer comments:
Also rename ACK-FREQUENCY to ACK_FREQUENCY to
Use instead of following naming convention in the transport draft.

Revised text:
by the endpoints and network load.  An endpoint's loss detection and congestion control mechanisms however need to be tolerant of this delay at the peer.  An endpoint signals its tolerance to its peer  <ins> using an ACK_FREQUENCY frame, shown below: </ins> Following the common frame format described in Section 12.4 of QUIC-  <ins> TRANSPORT, ACK_FREQUENCY frames have a type of 0xAF, and contain the </ins> following fields: A variable-length integer representing the sequence number  <ins> assigned to the ACK_FREQUENCY frame by the sender to allow </ins> receivers to ignore obsolete frames, see multiple-frames. A variable-length integer representing the maximum number of ack- value smaller than the "min_ack_delay" advertised by this endpoint is invalid.  <ins> Receipt of invalid values in an ACK_FREQUENCY frame MUST be treated </ins> as a connection error of type FRAME_ENCODING_ERROR.  <ins> ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not </ins> require retransmission.  <ins> An endpoint MAY send ACK_FREQUENCY frames multiple times during a </ins> connection and with different values. An endpoint will have committed a "max_ack_delay" value to the peer, which specifies the maximum amount of time by which the endpoint will  <ins> delay sending acknowledgments.  When the endpoint receives an ACK_FREQUENCY frame, it MUST update this maximum time to the value </ins> proposed by the peer in the Update Max Ack Delay field. 5.  <ins> An endpoint can send multiple ACK_FREQUENCY frames, and each one of </ins> them can have different values.  An endpoint MUST use a sequence  <ins> number of 0 for the first ACK_FREQUENCY frame it constructs and </ins> sends, and a strictly increasing value thereafter.  <ins> An endpoint MUST allow reordered ACK_FREQUENCY frames to be received </ins> and processed, see Section 13.3 of QUIC-TRANSPORT.  <ins> On the first received ACK_FREQUENCY frame in a connection, an </ins> endpoint MUST immediately record all values from the frame.  The sequence number of the frame is recorded as the largest seen sequence number.  The new Packet Tolerance and Update Max Ack Delay values MUST be immediately used for delaying acknowledgements; see sending.  <ins> On a subsequently received ACK_FREQUENCY frame, the endpoint MUST </ins> check if this frame is more recent than any previous ones, as follows: 6.  <ins> Prior to receiving an ACK_FREQUENCY frame, endpoints send </ins> acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT.  <ins> On receiving an ACK_FREQUENCY frame and updating its recorded </ins> "max_ack_delay" and "Packet Tolerance" values (multiple-frames), the endpoint MUST send an acknowledgement when one of the following conditions are met: On sending an update to the peer's "max_ack_delay", an endpoint can use this new value in later computations of its Probe Timeout (PTO) period; see Section 5.2.1 of QUIC-RECOVERY.  The endpoint MUST  <ins> however wait until the ACK_FREQUENCY frame that carries this new </ins> value is acknowledged by the peer. Until the frame is acknowledged, the endpoint MUST use the greater of computing the PTO period.  Doing so avoids spurious PTOs that can be caused by an update that increases the peer's "max_ack_delay".  <ins> While it is expected that endpoints will have only one ACK_FREQUENCY </ins> frame in flight at any given time, this extension does not prohibit having more than one in flight.  Generally, when using "max_ack_delay" for PTO computations, endpoints MUST use the maximum