Subject: [quicwg/base-drafts] Retaining the largest received packet number (#3541)

From: Martin Thomson <[email-masked]>
Date: Sun, 22 Mar 2020 17:50:37 -0700

In #3537, @ianswett notes that #3315 added this "MUST":

> When discarding unacknowledged ACK Ranges, a receiver MUST retain the largest received packet number.

My understanding is that this prevents the largest acknowledged packet from going backwards.  We use the monotonic increase of the Largest Acknowledged field in two ways:

* In ECN validation, this is used to filter out ACK frames that might have arrived out of order, which might have lower counts legitimately.

* In key updates, where the value of the largest acknowledged is used to drive the change to new keys and to prevent use of old keys after an update.

In my view, having ECN validation fail is quite unfortunate, but likely workable.  On the other hand, uncertainty about largest acknowledged could introduce instability in the key update process.  If an endpoint's conception of what the value is changes, I doubt that we'll see extra key updates (I think that the AEAD would protect us from that), but we might leave open the possibility of interleaving of packets from two different key phases.

I would suggest that we retain this "MUST".

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

---

From: ianswett <[email-masked]>
Date: Mon, 23 Mar 2020 11:17:38 -0700

For out of order ACK frames, you can use the packet number the ACK arrives in.  I realize that we have tried to allow frames to be retransmitted, but I think retransmitting ACK frames without modifying the ACK delay/etc is so harmful we should probably prohibit that one frame from being retransmitted, since it creates a bunch of edge cases.  Or we could let ECN validation could fail, but that'd be a bit sad.

I'm confused about what the issue with key updates is?  The largest acked you've ever seen doesn't change, just the largest acked from the last ACK frame.  When determining the size of the packet number, we say: "The sender MUST use a packet number size able to represent more than twice as large a range than the difference between the largest acknowledged packet and packet number being sent."

I'd rather not make this a MUST unless we have a good reason.  There are valid use cases that become more complex with this constraint.

-- 
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/3541#issuecomment-602772028

---

From: Martin Thomson <[email-masked]>
Date: Thu, 26 Mar 2020 22:17:32 -0700

I really want to understand the use cases that you think that this might break.  Because key updates very much depend on tracking largest acknowledged.

The key updates case has a fairly simple example.  Say you receive packet 10 in key phase 1.  Then 11 in key phase 2.  That's valid.  But if you ACK those and then only remember up to packet 8, packet 9 can use key phase 2 and you won't know that it is invalid.

-- 
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/3541#issuecomment-604819826

---

From: ianswett <[email-masked]>
Date: Fri, 27 Mar 2020 05:55:07 -0700

I'd like to suggest tracking largest acknowledged from forcing all ACK frames to contain the largest acknowledged and have that value never decrease.

Given you need to track largest acknowledged locally(ie: not only in the in-flight ACK frame), I don't think there are any problems there.

I have two cases in mind where the largest acked could validly decrease:
1) A receiver that tracks a limited number of ACK blocks and the oldest block happens to be the one containing largest acked.
2) If an application was reordering tolerant(ie: from https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00) then two different senders on a single 'connection' may be sending packets with disparate packet numbers, causing what appears to be very large scale reordering.  In this case, it'd be valuable to discard the older ACK ranges even if they contained the largest acked.

Maybe the first is an edge case we don't care about in a use case we aren't optimizing for and the latter is solvable with careful issuing of packet number ranges.  Even so, I'm not sure what the motivation is for this change?  I guess the ECN case could be, but using largest acked as a proxy for retransmitted ACKs is a very bad design in my opinion.

-- 
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/3541#issuecomment-604984777

---

From: Martin Thomson <[email-masked]>
Date: Sun, 29 Mar 2020 17:46:13 -0700

I don't think we really need to cater for retransmitted ACK frames in any way.  What I'm concerned about is reordering.

Yes, using the increase of largest acknowledged as a proxy for strict ordering is a little weird, but the assumption is that frame handling is distinct from packet handling and packet numbers are not available when frames are handled.  (I think that's the principle we agreed on; that's why it's OK to use packet numbers in key updates, for example, something that I can confirm is borne out by implementation experience.)

The case you describe here has the appearance of exactly that type of reordering if the two senders also generate their own ACK frames (though this seems very strange).  But I think that the consequences of that sort of design are not our responsibility to deal with.

-- 
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/3541#issuecomment-605729159

---

From: ianswett <[email-masked]>
Date: Mon, 30 Mar 2020 07:59:28 -0700

I don't recall on us agreeing that packet numbers weren't available when frames are handled, can you clarify why that property is important?

-- 
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/3541#issuecomment-606052071

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 30 Mar 2020 19:30:09 -0700

I agree with @martinthomson on the principle of not requiring the enclosing packet's packet number during frame handling, and we use sequence numbers within frames to help with reordering. This was at least true in an earlier version of NCID frames, and we had discussed this principle then. This is also why the ACK_FREQUENCY frame in https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00 includes a sequence number.

That said, I don't understand the issue with key updates here. Largest acked so far is a connection-level state variable that can be used for key updates. I suspect that I'm not understanding the example scenario. @martinthomson, can you elaborate on your key update example?

@ianswett: Is your example motivated by a receiver that does not remember the largest acked or one that does not wish to ack anything but the packet that was just received?

-- 
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/3541#issuecomment-606361195

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2020 20:23:00 -0700

I was under the impression that the argument was that largest acknowledged was not being tracked, but Ian made it clear that the concern was about not signaling it.  That removes key updates as a concern.  If [this comment](https://github.com/quicwg/base-drafts/issues/3541#issuecomment-604819826) remains unclear, then I can't really do better.

-- 
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/3541#issuecomment-606375627

---

From: ianswett <[email-masked]>
Date: Tue, 31 Mar 2020 08:40:25 -0700

@janaiyengar my example was motivated by either case, but primarily not wanting to ACK anything besides what was just received.

-- 
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/3541#issuecomment-606705442