Bless, Roland (TM) <roland.bl...@kit.edu> 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:aqm-boun...@ietf.org] On Behalf Of Mikael Abrahamsson Sent: Wednesday, October 07, 2015 4:18 PM To: dpr...@reed.com Cc: aqm@ietf.org Subject: Re: [aqm] ACK Suppression On Wed, 7 Oct 2015, dpr...@reed.com 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: swm...@swm.pp.se _______________________________________________ aqm mailing list aqm@ietf.org 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= _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
