Re: [aqm] ACK Suppression

[David Lang <[e-mail]>]

On Thu, 8 Oct 2015, Fred Baker (fred) wrote:

> 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@.

I don't know why it started here, but not everyone on the aqm list is on the 
tcpm list, so removing aqm@ will drop some people from the conversation.

> On Oct 7, 2015, at 2:13 PM, David Lang <[e-mail]> 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.

well, given that people are still running Windows XP, it may get out to some 
things but it's not going to get out to everything. Remember that VMware 
responded to the EoL of XP with a campaign telling people they could keep 
running XP in a VM.

in particular streaming media devices (smart TVs, etc) are not getting many, if 
any, OS upgrades from the vendors, and they are a big part of the problem.

> 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?

a little less than the chance of  shutting off IPv4  :-)

requiring changes to all the software on each end to enable this is wishful 
thinking. The major servers could get the update pretty promtly, but updating 
the client side?? not for a long time.

But in any case, that's addressing a slightly different issue. This discussion 
started based on the fact that when there are queues, and the queues have 
multiple acks for the same flow, it can save queue space, bandwidth, and reduce 
latency by eliminating all but the last ack. If this can be done at a low cpu 
cost (so it can be implemented on consumer endpoint hardware that usually has 
the first bottleneck), it could be a win for the Internet as a whole.

David Lang