Discussion in quic-recovery of delayed ack being 25ms does not seem to relate to anything

[jrudolph]

This paragraph didn't seem to relate to anything else in the document:

A shorter delayed ack time of 25ms was chosen because longer delayed acks can delay loss recovery and for the small number of connections where less than packet per 25ms is delivered, acking every packet is beneficial to congestion control and loss recovery.

Is it left-over from a previous version?

[ianswett]

Thanks for pointing this out.

The intent was to explain why 25ms was chosen, given it's smaller than most TCP implementations default delayed ack time.

There were more exceptions before, but now there's only the one, which makes the preceding paragraph awkward as well.
"The majority of constants were derived from best common practices among widely deployed TCP implementations on the internet. Exceptions follow."

[ianswett]

I realized that the 25ms recommendation is in transport, so this is just out of place now.

[jrudolph]

I realized that the 25ms recommendation is in transport, so this is just out of place now.

Ah, I see, I remember I went looking for it in transport, but I think I looked for "delayed ack" and didn't come up with anything fitting. I've got no concrete suggestion how to resolve it but moving the notice to transport in some form would probably make sense.