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

From: janaiyengar <[email-masked]>
Date: Tue, 18 Dec 2018 14:17:09 -0800

This is implicitly assumed, and, as @martinthomson points out in [his comment](https://github.com/quicwg/base-drafts/pull/2189#discussion_r242012566), not doing so can cause undesired outcomes. There should be normative text in the transport draft requiring this behavior.

-- 
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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Dec 2018 01:02:21 -0800

So the situation is that if one so far have ACKed: 1,2,3,6,7. Then if 4,5 shows up at the receiver and it is going to ACK those, it must at least send an ACK that contains 4,5 and 7, thus likely acking 4-7? It should not be allowed to send an ACK saying 4, 5 in the above situation as that doesn't indicate the receiver total progress, i.e. all the way to 7? 

I think requiring Largest Acknowledge to always indicate highest solves some issues and likely simplifies a lot of implementations. But it may result in larger ACK frames as one will have include the full current state between the largest Acknowledged and so far into the past PNs that you need to go. In severe re-ordering cases that could be a lot. 

Will this cause cause the ACK to be to large to include? Especially maybe in connections with a large delay bandwidth product going full steam encountering a serious hick up in the network. For example if an ACK is required to ack packet 4000 + 1E9 and you have 500 gaps that has arrived the last RTT/4 and really should be included. Resulting in an ACK frame that is at least 1000 bytes large, possibly bigger.

-- 
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-448519817

---

From: ianswett <[email-masked]>
Date: Wed, 19 Dec 2018 14:21:53 +0000 (UTC)

There are a few things this precludes, and we we should understand those before doing this.

1) A very limited implementation(ie: hardware) can't always send only one ACK block without giving up on reordered packets.  I don't have such an implementation, but at some point I remember discussing this idea with people who seemed interested in it.
2) One cannot do multipath with QUIC v1 and it means the multipath design will have to use a PN space per path, as described in Christian's draft: https://tools.ietf.org/html/draft-huitema-quic-mpath-req-01#section-4.11  I think that's likely the right choice for other reasons, but I'm hesitant to make that decision now.
3) An RTT sample can only be taken based on the largest acked.  Therefore, if there is a large amount of reordering(ie: 1RTT), you don't get any RTT samples for an RTT.  If we care about this, we can probably solve it a different way in the recovery draft, but that likely means using ack delay sometimes and not others.

In regards to Martin's comment, I thought we already had text that said ACKs with lower packet numbers than the largest ACK packet number should be ignored, since they're old?

-- 
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-448612503

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Dec 2018 06:48:47 -0800

@ianswett regarding your question. "In regards to Martin's comment, I thought we already had text that said ACKs with lower packet numbers than the largest ACK packet number should be ignored, since they're old?"

At least when it comes to ECN, the editors have been working hard to reformulate which has resulted in that there is nothing that applies this from the PN increasing for the ACKs. So to solve the ECN part, I think (re-)introducing that aspect into the text is the simpliest fix for ECN. But there clearly are other aspects here. 

-- 
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-448621319

---

From: janaiyengar <[email-masked]>
Date: Wed, 19 Dec 2018 14:32:24 -0800

@ianswett: The problem doesn't go away if you ignore acks that are lower than largest_acked. The problem is that the receiver sent the acks in the wrong order because packets were received in the wrong order, but ECN counts are going up. 

That said, it is a corner case. I think that with the current spec, under these conditions, ECN gets turned off since validation fails. I think that's a reasonable outcome, and I'm fine with it. @gloinul?

-- 
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-448767423

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Dec 2018 10:52:32 +0000 (UTC)

ECN Validation as I currently understand it will not fail if the sender to receiver reordering happens as long as the ACKs from the receiver to sender are not reordered. So to my understanding what is missing is a requirement for the sender to no process verfication for out of order ACKs. It will not fail if the largest acknowledge is not increasing as the comparison is done on number of newly ACKed packets versus counts change. 

-- 
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-448955294

---

From: janaiyengar <[email-masked]>
Date: Thu, 20 Dec 2018 14:59:44 -0800

I think #2215 is enough to address the original problem, so I'd like to close this issue. I think #2198 and #2215 are enough. @gloinul: sound ok?

-- 
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-449163090