[tcpm] Why draft-gomez-tcpm-ack-rate-request?

[Gorry Fairhurst <[e-mail]>]

Thanks again for raising questions about ACK traffiuc - I'm quite passionate we look again at AcK traffic volume and rate.
I've just reread and I'm still quite skeptical this is the right solution - look forwrad to the talk.

Why is this so important to use a TCP option to signal, rather than just specify a better method?


1. An option increases the probability that someone might block/change the option on path.
2. Any receiver that sees this option has anyway to decide how to process ACKs - and mkight also need to deal with offload.
- The use-case for IOT might not need an option:
For receivers that see one segment/RTT then ACKing each segment immediately seems reasonable. Sending 2 segments would make anyway have this effect.
When would you not wish to send fewer ACKs?
3. The use cases for asymmetry or processinbg load might not need an option:
I don't understand the motive here, in QUIC some have been using one ACK every ~10 packets
in some implementations (wuth whatever caveat to do something differenet for the first ~100 packets).
I'd like to argue this is enough "control" for most cases, and not so much "ACK traffic" in many cases where that matters.

I'll look forward to seeing the slides and udnerstanding more,

Gorry