Re: [aqm] TCP ACK Suppression

[David Lang <[e-mail]>]

On Fri, 9 Oct 2015, Joe Touch wrote:

> Dave in particular wanted some specific reasons this is a bad idea as
> presented. Here is my summary.
>
> The rest of this discussion should happen on TCPM.
>
> Joe
>
> ---
>
> 1) *you* shouldn't be using a mechanism that destroys information for others
>
> 	whether the timestamps or ACK stream spacing has any
> 	meaning is for the receiver - not you - to decide

The temporal spacing is already lost.

> 2) *you* don't know where your mechanism will have an impact
>
> 	those clumped ACKs might be spaced out further
> 	downstream
>
> 	even if you have a rule of "I'll only gather 3 ACKs",
> 	you can't know if another box - including yours -
> 	downstream might gather those composite ACKs further
>
> 3) you claim this might be safe *if* AQM is widely deployed
>
> 	but *you* don't appear to be making that determination
> 	*before* deploying your approach
>
> 	also, AQM is in the opposite direction, and unless
> 	you deploy this with enough state to track the fact
> 	that your box is seeing traffic in both directions,
> 	you shouldn't be turning it on at all

this discussion started in the context of AQM. AQM is needed in both directions, 
it's not a one-direction only thing.

> As others have noted, the SHOULD of ACK requirements can be exceeded,
> but only with careful consideration of the potential impact. That
> careful consideration does not consist of "I turned it on and I didn't
> hear anyone scream".

that's not the only consideration here. There's also the consideration that the 
ACK stream is already badly distorted.

As it turns out (as discussed on the other thread), the RFC actually recommends 
what we was proposed (with some additional nuances)

David Lang