Alternative to #1654. Reduces the amount of communication required compared to the status quo when the RTT is not varying wildly.
This preserves the pre-existing behavior where max_ack_delay is effectively clamped below the current RTT. It might be useful to also offer an escape hatch to force it higher, although such a configuration is contrary to the "SHOULD" recommendation of the ack frequency draft.
I'm honestly not completely confident I understand all the nuance here, but it seems like a nice simplification and looks like we got decent test coverage of what's going on.
Alternative to #1654. Reduces the amount of communication required compared to the status quo when the RTT is not varying wildly.
This preserves the pre-existing behavior where
max_ack_delay
is effectively clamped below the current RTT. It might be useful to also offer an escape hatch to force it higher, although such a configuration is contrary to the "SHOULD" recommendation of the ack frequency draft.