Re: [aqm] [tcpm] ACK Suppression

RFC3449 pointed to some of the reasons & problems with manipulating TCP
ACKs, and could provide a useful background if people needed to get up to
speed on the history...

Gorry

> I'm not sure why this discussion is happening on aqm@ instead of tcpm@...
> I have added cpm to the cc line, and would recommend that anyone
> responding to this thread do the same and remove aqm@.
>
> On Oct 7, 2015, at 2:13 PM, David Lang <david@lang.hm> wrote:
>> So things that reduce the flow of acks can result in very real benefits
>> to users.
>
> Dumb question of the month. What would it take to see wide deployment of
> RFC 5690? That would result in the data/ack ratio being reduced, on
> average, to whatever amount had been negotiated.
>
> Summary for those that haven't read it - TCP implementations today
> generally ack every other packet, with caveats for isolated or final data
> packets. This proposal allows consenting adults to change that ratio,
> acking every third or fourth packet, or every tenth.
>
> If ack reductions are so very valuable, what's the chance of doing that on
> an end to end basis instead of in the network?
>
>> On Oct 7, 2015, at 2:13 PM, David Lang <david@lang.hm> wrote:
>> On Wed, 7 Oct 2015, Jonathan Morton wrote:
>>>> On 7 Oct, 2015, at 23:40, Agarwal, Anil <Anil.Agarwal@viasat.com>
>>>> wrote:
>>>>> Since the cable modem link will lead to clumped ACKs the difference
>>>>> between sending 100 ACKs vs. 1 ACK is probably not that big...
>>>>> (except w.r.t. reliability).
>>>> The difference may not be big in the spacing of new packets that a
>>>> sender will send, unless the sender implements some sort of pacing or
>>>> if the return link is very thin.
>>>
>>>> But with ABC, there will be a difference in the amount of cwnd
>>>> increase at the sender.
>>>
>>> There is also a potential difference for detecting packet loss in the
>>> forward direction.  Itâs entirely possible that thinning would cause
>>> a DupAck condition to be recognised only after three MAC grants in the
>>> reverse direction have elapsed, rather than one.  Receivers are
>>> REQUIRED to send an ack for every received packet under these
>>> conditions, but that would be subverted by the modem.  AckCC would not
>>> induce this effect, because the receiver would still produce the extra
>>> acks as required.
>>>
>>> Packet loss causes head-of-line blocking at the application level,
>>> which is perceived as latency and jerkiness by the end-user, until the
>>> lost packet is retransmitted and actually arrives.  Hence the addition
>>> of two MAC grant delays (60ms?) may make the difference between an
>>> imperceptible problem and a noticeable one.
>>
>> and excessive ack traffic causes congestion and results in packet loss
>> on real-world hightly asymmetric links.
>>
>> So things that reduce the flow of acks can result in very real benefits
>> to users.
>>
>> David Lang_______________________________________________
>> aqm mailing list
>> aqm@ietf.org
>> https://www.ietf.org/mailman/listinfo/aqm
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>