Subject: Re: [quicwg/base-drafts] Fragility in ECN counters with lost acks (#1481)

From: Magnus Westerlund <[email-masked]>
Date: Tue, 03 Jul 2018 06:57:49 -0700

I agree with @martinthomson here. Assuming that ACK losses resulting in that the sender don't know what happened to some PNs at all, then adding slack corresponding to the unknown packets ensures that ECN usage does not terminate due to the loss of the ACKs. And by updating the comparison baseline on such an event one can correctly detect issues going forward. And I think implementations will want to ensure that that ACK loss that results that no indication of reception for a particular PN is rare as that would be treated as a loss, even if the packet was received. 

Regarding the sender memory of what it has seen ACKs for and what not. If the sender has chosen to forget about if a PN was received or not, then it has passed beyond some Horizon. And if the packets data has been retransmitted, the sender have received some indication that the packet was lost. Which means it is likely not unaccounted for. We have to assume that the sender has a deep enough history of what it sent and has outstanding. And if the sender anyway are declaring packet loss and going into recovery, then potentially having missed some ECN-CE does not matter. Resetting the ECN counter state is thus safe in this case. 

-- 
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/1481#issuecomment-402166815

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Jul 2018 22:23:45 -0700

I realize that my example was flawed.  You have to allow for an increase for any unacknowledged packets less than the minimum acknowledged packet number in the ACK.  In the example above, the last ACK stopped at 10 and the new one starts at 20.  The naive interpretation says that 9 packets might have arrived, been acknowledged, and had the acknowledgment lost and subsequently abandoned.  However, packet 8 might have arrived after 10 was acknowledged.

The other thing is that this assumes that if you acknowledge packet 20, then you would also acknowledge packets with higher numbers.  This is probably a safe assumption, but we would have to require it. 

-- 
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/1481#issuecomment-402929174

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Jul 2018 19:49:13 +0000 (UTC)

I have drafted an initial text to resolve this. See PR #1555. I took the simpler way out that if one detects ACK loss one simple skip to do the counter comparisons. That should be less error prone and is something that should happen very seldom. 

-- 
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/1481#issuecomment-404629725

---

From: janaiyengar <[email-masked]>
Date: Tue, 17 Jul 2018 21:22:03 +0000 (UTC)

Closed #1481 via #1565.

-- 
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/1481#event-1738756348