No way to explicitly communicate an ack delay

[ianswett]

Currently the recovery draft specifies a default ack delay of 25ms, which may be slightly too low in some environments and much too high in others(ie: datacenters). In order to implement efficient loss recovery, the peer needs to know what ack delay is being used. This should be communicated via transport params.

A similar proposal exists to add this to TCP, we should ensure it exists in QUIC as well.
https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-options-for-low-latency-00.pdf

[ianswett]

Discussion at IETF 100 included noting that this needs to be the max ack delay, and not an effort to communicate the exact delay in all circumstances. Also, if it's in transport params, then it's not encrypted. There was interest in communicating this to better inform TLP, however.

[pravb]

Yes this is a deficiency in TCP and makes TLP less effective in cases where there is a single tail packet outstanding. I would request that we at least communicate the max ACK delay value in transport parameters. I would think communicating any changing values over time is optional and I would be fine with that not being included in V1. I also think it is likely that most implementations will simply pick a constant value for ACK delay rather than a dynamically tuned one.

[pravb]

I don't want to conflate this with another related issue but communicating the maximum stretch ACking value back to sender can also be useful to implement ACK clocked congestion control like Reno. Today TCP implementations are using different thresholds for ABC and in many cases are sub-optimally growing the cwnd.

[janaiyengar]

Closing this in favor of #981