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

[Magnus Westerlund <[e-mail]>]

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