On Sun, 11 Oct 2015, Jonathan Morton wrote:
On 11 Oct, 2015, at 01:28, David Lang <da...@lang.hm> wrote:
So even if I could wave a magic wand and deploy this on every router, it
would only have an effect in a few places. Endpoint links where the
available bandwidth drastically changes are not the exclusive list of palces
that this would effect, but I think it's pretty close.
Also, since it costs CPU to go through the queue looking for ACK packets to
try and combine, it is a feature unlikly to be enbled on high speed devices.
It would probably only be enabled when the savings in the reduced number of
ACKs that would be transmitted is significant enough to be worth the effort.
Endpoint devices for home users where there is probably also a highly
asymmetric link are a very clear win. Core routers are almost never going to
be a win.
In the case of wifi, aggregation and huge per-TXOP overheads mean that the
cost of sending multiple acks instead of just one is negligible. It’s simply
not worth performing any sort of compression or consolidation except for
(losslessly reversible) aggregation, because the gains pale into
insignificance next to that unavoidable overhead.
the cost in that txop of sending multiple acks instead of one is minor, but does
sending those multiple acks mean that there are data packets that have to wait
for the next txop?
But I actually view this as a tragedy of the commons situation. Sending the
extra packets doesn't hurt you, but it does mean that you are using more airtime
than you need, and that hurts everyone (including, eventually, you)
Anything that we can routinely do to minimize the length of the transmission
should be done.
David Lang
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
