On Wed, 7 Oct 2015, [email protected] wrote:
not built up! The purpose of queueing is to absorb bursts that can't be
anticipated, not to build up congestion in order to have enough data to
perform a dubious optimization that can best be done at the source of
traffic in cooperation with the destination.
There is no congestion when the ACK suppression kicks in and is useful.
If I download at 250 megabit/s, at 1500 byte packets, this is around
21kpps. That means I am sending around 10kpps worth of ACKs.
If my media access layer only gives me access to send packets every 1-3 ms
(but I can send many packets at a time each time), that means I basically
will have 10-30 ACKs in queue each time I get access to the medium.
For each transmit opportunity, you will see a "train of ACKs" with a
duration of 0.1-0.5ms, then there will be nothing for 1-3ms, then you will
see a train of ACks again.
So providing that the router in question actually knows what it's doing,
this is a useful optimization. Actually, I'd say I don't really understand
why the TCP stack is sending 10kpps anyhow, is this very fine grained
resolution used for anything anyhow? Even considering that this "train of
ACKs" will arrive back-to-back, is the difference that big compared to
just sending fewer ACKs (from the host, so the router doesn't have to
optimize).
My ISP has a very common service with is 250 megabit/s down and 10
megabit/s up. If this TCP ACK suppression doesn't exist, then much of the
customer upstream capacity is used for ACKing the download packets (for no
great use for the user as far as I can tell).
Wouldn't it make sense to for TCP to limit ACKs to once per millisecond or
1/10th RTT, whatever is lower? Or something along these lines, perhaps the
1/10th of RTT is not low enough, so perhaps 1/50th of RTT.
For instance for my test here with around 10ms RTT, what would limit the
ACKs from 10kpps to 2kpps in the host stack itself (with 1/50th of RTT
being lower in this case).
It would at least make sense when using a time based media access layer
such as LTE, DOCSIS etc.
--
Mikael Abrahamsson email: [email protected]
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
