persistent congestion

[kazuho]

Persistent congestion is on our ToDo list.

When implementing it, we should revisit our sentmap retention strategy.

At the moment, it is the boarder one of 4 PTO since the send-time, or 32 packets. See

quicly/lib/loss.c

Lines 29 to 33 in 1ec0a66

	int64_t retire_before = now - quicly_loss_get_sentmap_expiration_time(loss, max_ack_delay);
	/* Retire entries older than the time specified, unless the connection is alive and the number of packets in the sentmap is
	* below 32 packets. This exception (the threshold of 32) exists to be capable of recognizing excessively late-ACKs when under
	* heavy loss; in such case, 32 is more than enough, yet small enough that the memory footprint does not matter. */

This does not cover the case where the network condition is really bad and the sender is emitting series of small packets (e.g., SSH use-case). Under such a condition, we might drop sentmap entries before they are declared lost.

As we implement persistent congestion detection, we should change the retention strategy so that the sentmap would cover both edges of the persistent congestion period.