On Fri, 9 Oct 2015, Yuchung Cheng wrote:
Subject: Re: [aqm] TCP ACK Suppression
On Thu, Oct 8, 2015 at 9:03 PM, David Lang <[email protected]> wrote:
On Fri, 9 Oct 2015, Christian Huitema wrote:
On Thursday, October 8, 2015 5:43 PM, David Lang wrote:
...
For example, in the fq_codel/cake development, we're finding that there
are
some transports that bundle very large numbers of packets together to
send
at one time in order to maximize the transport bandwidth. (for example,
4x4
wifi sends a LOT of data in one transmit timeslot). Treating that large
aggregate as a single packet seriously hurts fairness and latency on the
next
hop. So 'pulling apart' this aggregate into the individual
packets/streams and
making decisions based on the pieces ends up being a serious win in
fairness
and latency.
Define "bundle" please. If they are making sure that several IP packets
are sent back to back in a single Wi-Fi slot, then it is of course
perfectly fine for AQM to handle the IP packets one by one. Does 4x4 Wi-Fi
do something else?
I don't remember the details from the discussion, but the combined bundle
required extra steps to pull apart to get at the individual packets. IIRC,
not doing so ended up with multi-MB chunks of data to be delivered, which
blocked all other traffic while it was being delivered.
Suggesting that the queues that build up produce a special enough case to
consider thinning out the duplicate acks is a far cry from 'making a
recommendation that breaks other recommendations'
That definitely contradicts the TCP specs. So it is very much in "don't
go there" territory...
By 'not going there' you are crippling people's networks for the sake of
following a spec. Rather than following the letter of the old spec, we
should be looking at the reasons for it, and reasons to make exceptions.
There is a long history of introducing new things that break the old way of
doing things, from breaking "classful" network routing to Anycast, there
are lots of things that "broke" the old way of doing things.
In this case there is more than a decade of people doing exactly what
shouldn't even be considered.
I'll ask yet again, if acks have already been delayed so that they will be
delivered at the same time as later acks, how much value do they actually
provide? We need to compare whatever value this is against the cost of the
misinformation that they provide, and the impact on other traffic.
Does DOCSIS suppress/filter ACK with SACK blocks and/or ACKs with
timestamps?
I don't know, but this discussion is not limited to DOCIS.
also, see the other thread covering the RFC discussion. There's a lot more
details there and in the RFC
David Lang
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
