Subject: Re: [quicwg/base-drafts] Enumerate rules for not generating acks (#563)

From: Lars Eggert <[email-masked]>
Date: Thu, 01 Jun 2017 00:24:24 -0700

I think the entire text related to when to generate ACKs, what should be in generated ACK blocks, what information sender and receiver need to maintain for the packets and ACK blocks they send and receive may need some more explanation, and maybe examples. QUIC is sufficiently different from other IETF transport protocols here that at least for me, many details remain unclear.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/563#issuecomment-305411280

---

From: Patrick McManus <[email-masked]>
Date: Thu, 01 Jun 2017 06:58:18 -0700

I think this specific issue should be closed with simple statements about the 2 packets in question (and maybe Public Reset for good measure).

but to lars's point I think there is a lot of ack related language that could lead to interop issues. Below is one of my favorites, which leads the casual reader to wonder just how required ack is :)

> To limit receiver state or the size of ACK frames, a receiver MAY limit the number of ACK blocks it sends. A receiver can do this even without receiving acknowledgment of its ACK frames, with the knowledge this could cause the sender to unnecessarily retransmit some data. When this is necessary, the receiver SHOULD acknowledge newly received packets and stop acknowledging packets received in the past.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/563#issuecomment-305501271