Re: [aqm] [tcpm] TCP ACK Suppression

On Sat, 10 Oct 2015, David Lang wrote:

> On Fri, 9 Oct 2015, Joe Touch wrote:
>
>> On 10/9/2015 10:58 PM, David Lang wrote:
>>> RFC3449 doesn't completely address the current situation, but it
>>> provides a very good place to start, and it seems to me that the
>>> solitions it explores to address the conerns that it (and you) raise are
>>> actually being addressed pretty completely. There are still some areas
>>> to talk about (ECN interaction for example) and we wshould be talking
>>> about those issues rather than arguing that the proposal violates holy
>>> writ.
>> 
>> I'm OK with the recommendations for the endpoints to modify their ACK
>> behavior, but still am concerned that stripping out ACKs in the middle
>> of the network is problematic for a number of reasons, only some of
>> which are addressed in RFC3449 (which also recommends against deploying
>> them in the general Internet, so if that's your justification then it's
>> very clearly in direct opposition).
>
> Remember that this can only take place when there is enough of a bottleneck 
> that enough of a queue has built up that multiple ack packets are sitting in 
> the queue waiting to be transmitted. Such a queue is only going to build up 
> if the link is a bottleneck [1]. As I undertsand the current Industry Best 
> Practice, unless you have ISPs deliberatly not upgrading (ala the Netflix 
> fights), the core systems almost never queue and so such algorithms would 
> never kick in.
>
> 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.

David Lang

> David Lang
>
> [1] the exception to this is when you have a hop where the transport 
> quanomizes the data the way Wifi and Cell networks do, So if you have a 
> half-duplex link like normal Wifi or a time-slot MAC like a Cell network in 
> the middle of the path, this sort of thing could trigger there, but I'm not 
> convinced that it would be a bad thing there. Full duplex Wifi links that can 
> transmit continuously don't need this
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>