Subject: Re: [quicwg/base-drafts] Largest acked in ACK frame MUST NOT decrease (#2205)

From: Magnus Westerlund <[email-masked]>
Date: Mon, 07 Jan 2019 06:59:11 -0800

Yes, the ECN related issue is resolved. 

What I don't know if it is resolved fully is the implementation requirements is that a sender MUST be capable of handling an ACK frame with Largest Acknowledged that is smaller than highest received? From my perspective there are good and valid arguments why this may be required, however I think consensus needs to be established on that. 

-- 
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/2205#issuecomment-451961932

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 07 Jan 2019 19:57:39 +0000 (UTC)

@gloinul 
> What I don't know if it is resolved fully is the implementation requirements is that a sender MUST be capable of handling an ACK frame with Largest Acknowledged that is smaller than highest receive…

I am not sure if I'm following the context, but my understanding is that a sender MUST be capable of that, because we allow an endpoint to simply retransmit the payload of a packet that is being deemed lost; see #1612.

-- 
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/2205#issuecomment-452061707

---

From: MikkelFJ <[email-masked]>
Date: Mon, 07 Jan 2019 12:45:35 -0800

Just a stray thought: is this requirement really strictly needed? It would complicate trasnmitters that split work into multiple processing units which might not be fully synced on the latest ACK'ed.

-- 
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/2205#issuecomment-452075712

---

From: janaiyengar <[email-masked]>
Date: Mon, 07 Jan 2019 17:57:21 -0800

@gloinul, what @kazuho says. Also, a sender needs to be able to simply deal with reordering on the ack path. Did you mean something else?

-- 
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/2205#issuecomment-452147455

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 08 Jan 2019 02:40:40 -0800

My concern was primarily about the clearness of this behavior in the specification text. In transport I find the following which indicates this but are not explicit. 

13.1.1:    To limit receiver state or the size of ACK frames, a receiver MAY
   limit the number of ACK Ranges it sends.

19.3:

  Largest Acknowledged:  A variable-length integer representing the
      largest packet number the peer is acknowledging; this is usually
      the largest packet number that the peer has received prior to
      generating the ACK frame. 

I think there are strong hints, with the above "usually the largest" indicating that it is not always. I would have made this explicit in 19.3, but then I prefer being more explicit than not. I think it is possible interop issue point. Anywhere else this is more explicit? (I have read github master version)

@mikkelfj I think there are strong points for allowing an ACK frame to acknowledge only a part of the range between highest received and confirmed to be have been ACKed. The two main reasons I see.
- high rate flows suffering an packet loss burst so that the number of ACK ranges becomes to large to fit a single QUIC packet. 
- Low complexity receivers ACKing a single range of received packets and doing this for reordered packets.

-- 
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/2205#issuecomment-452253504

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 08 Jan 2019 10:47:17 +0000 (UTC)

@gloinul 
> I think there are strong hints, with the above "usually the largest" indicating that it is not always. I would have made this explicit in 19.3, but then I prefer being more explicit than not. I think it is possible interop issue point. Anywhere else this is more explicit?

As suggested by @martinthomson in #2312, 
[section 13.2](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.13.2) might be the correct place. I am advocating for describing the design principle the PR, but we might (or might not) be interested in expanding how ACK could look like.

-- 
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/2205#issuecomment-452255549

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 08 Jan 2019 04:10:09 -0800

So #2312 results in certain implications, that an ACK could arrive that addresses older state, thus resulting in acknowledging some PNs that was previously unacknowledged. As 13.2 is about retransmissions, I think there are other desing principle aspects of ACKs that probably should be covered, but then earlier in 13.1.  

-- 
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/2205#issuecomment-452276722