Re: [aqm] ACK Suppression

["Agarwal, Anil" <[e-mail]>]

Bless, Roland (TM) <[e-mail]>
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.
With 100 ACKs, each ACK will result in cwnd increase by 2 * MSS (assuming delayed Acks) during slow start and 
2 * MSS / cwnd during congestion avoidance.
With a single ACK covering 200 segments,  cwnd will increase by L*MSS, during slow start and 
L * MSS / cwnd during congestion avoidance; L =2, as stated in RFC 3465. Hence, cwnd increase will be much slower.
Unless L is set to a larger value.

Anil

-----Original Message-----
From: aqm [mailto:[e-mail]] On Behalf Of Mikael Abrahamsson
Sent: Wednesday, October 07, 2015 4:18 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [aqm] ACK Suppression

On Wed, 7 Oct 2015, [e-mail] wrote:

> not built up!  The purpose of queueing is to absorb bursts that can't 
> be anticipated, not to build up congestion in order to have enough 
> data to perform a dubious optimization that can best be done at the 
> source of traffic in cooperation with the destination.

There is no congestion when the ACK suppression kicks in and is useful.

If I download at 250 megabit/s, at 1500 byte packets, this is around 21kpps. That means I am sending around 10kpps worth of ACKs.

If my media access layer only gives me access to send packets every 1-3 ms (but I can send many packets at a time each time), that means I basically will have 10-30 ACKs in queue each time I get access to the medium.

For each transmit opportunity, you will see a "train of ACKs" with a duration of 0.1-0.5ms, then there will be nothing for 1-3ms, then you will see a train of ACks again.

So providing that the router in question actually knows what it's doing, this is a useful optimization. Actually, I'd say I don't really understand why the TCP stack is sending 10kpps anyhow, is this very fine grained resolution used for anything anyhow? Even considering that this "train of ACKs" will arrive back-to-back, is the difference that big compared to just sending fewer ACKs (from the host, so the router doesn't have to optimize).

My ISP has a very common service with is 250 megabit/s down and 10 megabit/s up. If this TCP ACK suppression doesn't exist, then much of the customer upstream capacity is used for ACKing the download packets (for no great use for the user as far as I can tell).

Wouldn't it make sense to for TCP to limit ACKs to once per millisecond or 1/10th RTT, whatever is lower? Or something along these lines, perhaps the 1/10th of RTT is not low enough, so perhaps 1/50th of RTT.

For instance for my test here with around 10ms RTT, what would limit the ACKs from 10kpps to 2kpps in the host stack itself (with 1/50th of RTT being lower in this case).

It would at least make sense when using a time based media access layer such as LTE, DOCSIS etc.

-- 
Mikael Abrahamsson    email: [e-mail]

_______________________________________________
aqm mailing list
[e-mail]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_aqm&d=BQICAg&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=O9YyDhG9aYPKoP_qfqzx2qr1WyA9s7n8zHybjDGhnkM&s=KQjsKwtKdO7fKEDJ2iWN7o0p-LVDX5-7it_eroz_ew0&e=