[MANAGING ACK] ACK ranges of sent ACK frames may exclude a gap

[PremRL]

I have been using this application for quite some time now, and I want to thank you for developing and maintaining this.

In the test environment, which experiences some packet loss, I encountered a situation where an "aioquic" receiver does not identify certain gaps, as demonstrated below.

PKN	Client	PKN	aioquic server
0	stm#0-1000 -> RECEIVED
1	stm#1000-2000 -> RECEIVED
2	stm#2000-3000 -> LOST
3	stm#3000-4000 -> RECEIVED
		10	ACK (largest=3, 1st_range=0, gap#0=0, range#0=1) -> RECEIVED
4	stm#4000-5000 -> LOST
6	stm#2000-3000 -> RECEIVED
7	stm#6000-7000 -> RECEIVED
8	stm#7000-8000 -> LOST
		11	MAXDATA -> RECEIVED
9	ACK (largest=11, ...) -> RECEIVED
		12	ACK (largest=9, 1st_range=0, gap#0=0, range#0=1) -> RECEIVED

In this example, ACK frame (number#12), sent to the client, does not identify packet number#4 as a gap in its ACK ranges after receiving ACK#9. Upon reviewing the code in aioquic/src/aioquic/quic/connection.py, I discovered that the "highest_acked + 1" removes an ACK range entirely, and because of this, it cannot represent a gap range for the subsequent numbers if they are missing.

I tried "space.ack_queue.subtract(0, highest_acked)", and it worked quite well. Therefore, I think it would be an improvement to implement this change in aioquic.

Thank you.

[rthalley]

We'll take a look in more detail; I agree there is a problem but I'm not sure about your proposed fix.